Re: The order of my SATA and PATA are switching all the time

[T o n g <mlist4suntong@yahoo.com>]

On Tue, 07 May 2013 07:55:24 -0400, Stephen Powell wrote:

>> Recently I added an old PATA HD to my system, which previously consist
>> of two SATA HDs. Ever since then, the order of my SATA and PATA are
>> keep switching.
> 
> This problem, and its solution, are discussed at length on my LILO web
> page, starting with the discussion of the "boot" configuration file
> record.
> 
>    http://users.wowway.com/~zlinuxman/lilo.htm

Indeed!

> Basically, use udev-created symbolic links in /etc/fstab,
> /etc/initramfs-tools/conf.d/resume, and your boot loader.

"The solution to this problem is to use a udev-created symbolic link.  In 
the example configuration file above, /dev/disk/by-id/ata-IBM-
DBCA-203240_HP0HPL43952 is a udev-created symbolic link to the MBR of the 
(normal) boot drive, regardless of which driver is used for IDE hard disks 
and regardless of how many disk drives are in the system, the order in 
which they are discovered, or what the boot device is.  "

That's a good suggestion, but I noticed that the example you gave has:

    boot=/dev/disk/by-id/ata-IBM-DBCA-203240_HP0HPL43952
    root="UUID=04db5929-51e6-424a-ac5b-a592b96b9d04"

I.e., they are not using the same thing. As said before, it is not that I 
can't boot, I can always boot just fine, but half of the time the boot 
process will drop to "(initramfs)" PANIC mode. I.e., it is always the 
"root=" boot option that give me the trouble, yet, I don't like using UUID, 
because, just as you said: 

"Warning: reformatting a partition normally changes the uuid, unless the 
existing uuid is explicitly specified as an option when formatting.  Thus, 
commands such as mkfs (and its derivatives) and mkswap will normally 
change the uuid, which in turn will change the udev-created symbolic link 
in /dev/disk/by-uuid, which in turn may necessitate changes to /etc/
lilo.conf. "

Can I use something like root="ID=ata-IBM-DBCA-203240_HP0HPL43952"? I 
remember nothing worked well, so I reverted to the (now troublesome) 
"safe" /dev/sdXn.

Thanks