Inproper ada# assignment in 10-BETA2

[Jin Guojun]

No, BIOS boot is completely irrelevant to this problem. 

It looks like I have to re-address this issue debated 15-20 years ago.

First of all, let's clear BIOS question so you will not argue it again.
BIOS boot sequence can be specified in any order, and it boots desired  drive correctly. 

If not, 10.1-BETA2 will not be loaded, and we will not see this problem, period.

After 10.1-BETA2 is loaded and booted, it enumerates drive(s) dynamically to assign ID to ada or da node. 

Kernel clearly knows which drive is ad1, 2, 3, ..., but it does not assigned proper ID to existing drive(s) for ada and da nodes. 

That is, ad note IDs are still correct, but ada and da node IDs are wrong.

The dynamic enumeration is likely used for moving a boot drive from on system to another
or from one bus to another without manually modifying fstab entries.
That is, this mechanism wants to ensure no matter where this drive is plugged in, 

Boot drive should be always enumerated as ID 0 or the ID installation assigned to.

How to ensure this? For boot drive, this is relatively easy -- the boot drive is always this first one in general, 

so this drive should always enumerated as ada0 or da0.
If installation has assigned drive ID to not 0 somehow, then generic enumeration apply.
Generic enumeration is drive serial number (S#) based enumeration mechanism, which has been used for at least two decades. 
For example, if two drives installed and their S# are AAAA and XXXXX (boot drive),
regardless what SATA port they resides at -- AAAA at ad9 and XXXXX at ad5,
We knew installation will likely name drive XXXXX as ada0 and AAAA as ada1. 
In fixed fashion, drive XXXXX is ad5 and AAAA is ad9, when a new drive is inserted as ad0, 

we knew drive XXXXX will be still ad5 and boot should not fail.
But in current 10.1-BETA2, the new drive is likely will be ada0, drive XXXXX will be ada1, and AAAA will be ada2, then boot will fail.
In case if new drive is inserted as ad8, drive XXXXX will remain as ada0 but AAAA will be ada21.
Even though boot will succeed in this case, but mounting drive AAAA will fail.


The S#-based enumeration will record the S# for corresponding device ID in a dynamic boot configuration file, which is used in boot time to determine what device ID should be assigned to each drive.
After existing drive ID has been enumerated, any new drive(s) will be given a unused ID sequentially.
This ensures that existing drive(s) will always get device ID originally assigned to, so the disk mounting operation will never fail no matter where a disk drive (has FreeBSD already installed) is plugged in.


Hopefully, this explains what is correct the dynamic enumeration operation.
In old time, we have a mechanisms to alter the dynamic enumeration to fixed one, but I do not know if this mechanism is still in 10.x-R.

Because it looks like that current developers have no knowledge about this concept,
I am going to open a bug to track this problem again soon, unless I will hear if we have a work around for this problem.



On Saturday, September 27, 2014 3:15 PM, Mehmet Erol Sanliturk <m.e.sanliturk at gmail.com> wrote:
 






On Sat, Sep 27, 2014 at 1:53 PM, Jin Guojun <jguojun at sbcglobal.net> wrote:

Installed 10-BETA2 on SATA port 4 (ad8) and then added another SATA port 3 (ad6), the system has not correctly enumerate the ada # for the boot device.
>As original boot (without the second SATA drive), the ad8 is enumerated as ada0 -- the boot drive:
>
>Sep 24 22:51:30 R10-B2 kernel: ada0 at ahcich2 bus 0 scbus2 target 0 lun 0
>Sep 24 22:51:30 R10-B2 kernel: ada0: <Hitachi HDP725050GLA360 GM4OA50E> ATA-8 SATA 2.x device
>...
>Sep 24 22:51:30 R10-B2 kernel: ada0: Previously was known as ad8
>
>
>However, after added another SATA drive (ad6), this new drive is assigned to ada0, but ad8 has changed to ada1. This is incorrect dynamic device assignment. FreeBSD has kept using fixed disk ID assignment due to the same problem introduced in around 4-R (or may be slightly later), and after a simple debate, a decision was made to use fixed drive ID to avoid such hassle.
>
>If now we want to use dynamic enumeration for drive ID# assignment, this has to be done correctly -- boot drive MUST assigned to 0 or whatever the # as installation assigned to; otherwise, adding a new drive will cause system not bootable, or make other existing drive not mountable due to enumeration # changes.
>
>Has this been reported as a known problem for 10-R, or shall I open a bug to track?
>
>-Jin
>




One point should be checked :


On mainboards SATA ports are numbered from 0  or 1 to  upward .

BIOS always uses first SATA drive for boot .  This is NOT related to the operating system .

Therefore , it is necessary to check port numbers of existing drives and the bootable SATA drive should be connected

to the smallest numbered SATA port among existent drives .



For example , assume bootable drive is connected to SATA port 2 . 

New drive should be connected to a higher numbered SATA port .

If there are only two SATA ports , then bootable drive should be connected to the first SATA port .


If mainboard BIOS allows definition of any SATA port for boot , and bootable SATA port and drive is specified in there , again it may boot from that drive . Up to now , I did not see any BIOS which supplies such an ordering among SATA ports . Please check your BIOS for such a feature . If it is present you may use it , otherwise it is necessary to reconnect SATA cables .



Thank you very much .


Mehmet Erol Sanliturk