[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <508CA3AC.4060600@free.fr>
Date: Sun, 28 Oct 2012 04:17:00 +0100
From: Wallak <wallak@...e.fr>
To: Chris Friesen <chris.friesen@...band.com>
CC: linux-kernel@...r.kernel.org, ak@...ux.intel.com
Subject: Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0
drives and a monolithic kernel configuration)
I've found where this issue come from. This behavior was introduced with
the commit: 0cc15d03bcccdf95e2bd82e094e6064e61b54207.The description is
available below. Removing this patch fix the drive order.
Best Regards,
Wallak.
commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207
Author: Andi Kleen <ak@...ux.intel.com>
Date: Mon Jul 2 17:27:04 2012 -0700
floppy: Run floppy initialization asynchronous
floppy_init is quite slow, 3s on my test system to determine
that there is no floppy. Run it asynchronous to the other
init calls to improve boot time.
[jkosina@...e.cz: fix modular build]
Signed-off-by: Andi Kleen <ak@...ux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@...e.cz>
Wallak wrote:
> Chris Friesen wrote:
>> On 10/26/2012 01:43 PM, Wallak wrote:
>>> Chris Friesen wrote:
>>>> On 10/25/2012 04:49 PM, Wallak wrote:
>>>>> I've a very annoying behavior with the linux-3.6.x kernels
>>>>> release, and
>>>>> a monolithic configuration. The USB 2.0 drives are mapped first with
>>>>> /dev/sda, /dev/sdb... devices, and than the SATA AHCI drives come
>>>>> after.
>>>>> This is out of order with the BIOS configuration and breaks a program
>>>>> like lilo. This is also annoying when we use a static partition
>>>>> mapping.
>>>>>
>>>>> Linux-3.5 works fine. Where this bug come from ? Is this a patch
>>>>> to get
>>>>> the old, and classical behavior ?
>>>>
>>>> As you have discovered it's fragile to rely on /dev/sd* names since a
>>>> BIOS update, kernel update, or motherboard replacement could
>>>> conceivably cause them to change.
>>>>
>>>> Better to use something like partition labels that you control and
>>>> that don't change.
>>>>
>>>> Chris
>>>>
>>> You are right, when we have a configuration with a lot of drvies and
>>> adapters SATA, old SCSI,.. etc. the order may change. But having the
>>> main SATA hard drive defined, as the BIOS boot device, behind external
>>> and removable USB drives is in my opinion a bug.And may lead to
>>> security
>>> issues (drives with the same label, etc...).
>>>
>>> Using =LABEL, or =UUID with a bootloader like grub or lilo, save the
>>> the
>>> boot device mapped drive partition number , and so booting on an older
>>> kernel like linux 3.5 will fail. If we remove the external USB drive,
>>> the boot process will fail too...
>>>
>>> So such a bug have to be fix.
>>
>> If you specify "root=LABEL=<label>" as part of the kernel boot args
>> in grub does it not check the label at boot time?
>
> Using root=LABEL= or root=UUID= don't work on a plain kernel, this
> feature may be handled by an initrd trick. Otherwise for all non root
> partitions UUID= work fine.
> Nevertheless not fixing this bug yields some other issues: Using lilo
> to launch a second OS (other= option) fail, the command try to parse
> partitions available on /dev/sda, and miss the real main HDD. Boot
> drive must be force with lilo options...
> SATA drives have, most of the time, no reason to be behind USB drives.
> If we want to get a reliable behavior: /dev/sda must be mapped to the
> BIOS boot device. Using the same behavior as linux-3.5 will be fine.
>
> Wallak.
>
>>
>> Chris
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists