Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
On Sun, Oct 28, 2012 at 04:17:00AM +0100, Wallak wrote: > 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. Hmm the patch should only affect the floppy. I don't see how it could affect anything else. Maybe it's just generic timing change that disrupts your boot sequence (if that's the case something else could have caused it too) Maybe Arjan has an idea. -Andi > > > Best Regards, > Wallak. > > > commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207 > Author: Andi Kleen > 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. > > [jkos...@suse.cz: fix modular build] > > Signed-off-by: Andi Kleen > Signed-off-by: Jiri Kosina > > > > > 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=" 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 > >> > > > -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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. [jkos...@suse.cz: fix modular build] Signed-off-by: Andi Kleen Signed-off-by: Jiri Kosina 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=" 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 a...@linux.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. [jkos...@suse.cz: fix modular build] Signed-off-by: Andi Kleen a...@linux.intel.com Signed-off-by: Jiri Kosina jkos...@suse.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
On Sun, Oct 28, 2012 at 04:17:00AM +0100, Wallak wrote: 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. Hmm the patch should only affect the floppy. I don't see how it could affect anything else. Maybe it's just generic timing change that disrupts your boot sequence (if that's the case something else could have caused it too) Maybe Arjan has an idea. -Andi Best Regards, Wallak. commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207 Author: Andi Kleen a...@linux.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. [jkos...@suse.cz: fix modular build] Signed-off-by: Andi Kleen a...@linux.intel.com Signed-off-by: Jiri Kosina jkos...@suse.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 -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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=" 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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=" as part of the kernel boot args in grub does it not check the label at boot time? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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. Wallak. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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. Wallak. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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? Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
