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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
