Date: Mon, 29 Aug 2011 09:10:41 +0200 From: Roger Genre <genre.roger@orange.fr> To: freebsd-current@freebsd.org Subject: hd numbering in 9.0beta1 Message-ID: <4E5B3B71.50203@orange.fr>
next in thread | raw e-mail | index | archive | help
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: <ACPI PCI bus> on pcib8 Aug 26 09:21:30 P5E-WS kernel: siis0: <SiI3132 SATA controller> 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: <SIIS channel> at channel 0 on siis0 Aug 26 09:21:30 P5E-WS kernel: siisch1: <SIIS channel> 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: <WDC WD20EARS-00MVWB0 51.0AB51> 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: <WDC WD3200AAKS-00B3A0 01.03A01> 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: <Maxtor 6V160E0 VA111630> 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: <SAMSUNG HD502IJ 1AA01110> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E5B3B71.50203>