From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 07:40:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14A4C1065673 for ; Mon, 29 Aug 2011 07:40:26 +0000 (UTC) (envelope-from genre.roger@orange.fr) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by mx1.freebsd.org (Postfix) with ESMTP id 788768FC19 for ; Mon, 29 Aug 2011 07:40:24 +0000 (UTC) Received: from P5E-WS.home ([90.25.51.160]) by mwinf5d01 with ME id S7AM1h0043TP4GS037AMXM; Mon, 29 Aug 2011 09:10:22 +0200 X-ME-engine: default Message-ID: <4E5B3B71.50203@orange.fr> Date: Mon, 29 Aug 2011 09:10:41 +0200 From: Roger Genre User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; fr-FR; rv:1.9.1.16) Gecko/20110328 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: hd numbering in 9.0beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 07:40:26 -0000 Hi everybody, I would point out a problem related with the new way, coming in 9.0, to hard disks numbering. As far I remember (5.0 ?), hardware detection of H.D.'s at O.S. boot-up numbered every channel potentially able to attach a disk to, and tagged the disks really attached with the number of his control channel; the sequence (from lowers to highers numbers) begins with scsi or scsi-like (e-sata, usb, fire-wire,...) controllers and ends with the controllers directly depending from the chipset (sata at this time). Such strategy allows to attach easily a new mass-storage device without modifying the disks numbering and thus the relevant fstab files. 9.0beta1 use a different numbering strategy,(with a similar sequence in harware detection) tagging succesively detected disks with adjacent numbers. Please, let me show an example from my computer: lines relevant to hard disks from /var/log/messages (recently installed FreeBSD-9.0beta1): ----------- Aug 26 09:21:30 P5E-WS kernel: pci2: on pcib8 Aug 26 09:21:30 P5E-WS kernel: siis0: port 0xac00-0xac7f mem 0xfe6ffc00-0xfe6ffc7f,0xfe6f8000-0xfe6fbfff irq 17 at device 0.0 on pci2 Aug 26 09:21:30 P5E-WS kernel: siisch0: at channel 0 on siis0 Aug 26 09:21:30 P5E-WS kernel: siisch1: at channel 1 on siis0 ------------ Aug 26 09:21:30 P5E-WS kernel: ada0 at siisch1 bus 0 scbus6 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada0: ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada0: Command Queueing enabled Aug 26 09:21:30 P5E-WS kernel: ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada0: Previously was known as ad16 Aug 26 09:21:30 P5E-WS kernel: ada1 at ata3 bus 0 scbus9 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada1: ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada1: Previously was known as ad18 Aug 26 09:21:30 P5E-WS kernel: ada2 at ata4 bus 0 scbus10 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada2: ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada2: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada2: Previously was known as ad20 Aug 26 09:21:30 P5E-WS kernel: ada3 at ata5 bus 0 scbus11 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada3: ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada3: Previously was known as ad22 ------------- Well, the system remembers the previous numbering (in my example, numbering from 8.2 release, as "production" release installed on a different slice), avoiding confusion. But the "funny" things are that : 1- AMI Bios (MBR style) in my Asus M.B.(3 years old) shows, in the POST table relevant to disks, only the 3 first ones, i.e does not show the disk controlled by the SiI3132 pci-card; ami-bios don't list this disk as bootable in the "disk-boot-order" selection menu, and it's impossible to select it as a bootable disks. (but this disk appears correctly detected by the pci-card internal bios.); and I suppose the ami-bios detects and records the scsi-like disk, but hide it to the user. 2- Grub detects as hd0,hd1,hd2,hd3 the disks appearing in 9.0 as ada1, ada2, ada3, ada0 (i.e. Grub numbers with the scsi-like ones at the end and the chipset-controlled ones at the beginning).(Grub is said to extract the info from bios). At this point, no real problem, as Bsd users warn carefully in the management of their disks between different releases of the O.S. But adding a new hard disk will shift one, more, or all the previous numbers, (depênding from the channel the new disk is attached to), making the /etc/fstab files irrelevant, and leading kernel in panic at boot-up. Well, I could, after adding a new disk, boot-up from a rescue disk to update files, (or "rootmount" manually, log as single, edit the proper config files, ...) but really the "old" numbering strategy was less painfull ! And I would panic if I have to explain that process to a newbee. Perhaps I miss some important new feature introduced in 9.0 to work around that problem ? Moreover, 9.0beta1 installs very easily and works fine; I am near to agree with the recently stated opinion that 9.1 release will never be necessary !! Congratulations to the team Roger As frenchie, I apologize for my poor english.