Are you sure you don't need an initrd to use labels in lilo.conf and fstab? It seems unlikely since the system isn't booted enough to use filesystem tools to get it.

Fact of the matter is if you might plug in something that can change your device names, using some alternative, whether than be UUID, labels, or something else, is highly desired. Sticking with "/dev/sdc4" could lead you to an unbootable system if something is added and the motherboard changes the order it provides to the kernel.

I chose to use UUIDs, because I tend to upgrade my harddrives on my media server frequently. I tend to label the drives the same since when I add the new one and copy everything over, the old one will be pulled from the machine or reused and relabeled. UUIDs make this extremely simple and prevent me from having any collisions as I work through this process. It easy to determine what drive is what by looking at the mount point in your fstab. UUIDs are what I have experience with, so that tends to be what I recommend (because I can easily copy/paste my configs to the forum for people to see).

And as far as compiling your own kernel. I don't bother with that anymore. I just don't see the benefit over the time it takes me to do it. But... to each their own.

1 members found this post helpful.

No, but since I'm using grub2, that hardly matters to me.

I disagree, motherboard is not a factor. With static /dev it doesn't change the names of drives, and order of drives can only be changed manually in bios.
This happens because of dynamic device name feature, it has nothing to do with the board.

The bootloader would have no factor on whether you need an initrd or not...

It depends on the motherboard. My old motherboard would end up with device names based on the sata port numbers. I could change which drive was what by simply changing the cables. Some boards may also change if you have a USB drive or card reader hooked up. It can also change if you use add-in cards for things like RAID or additional sata ports.

Your device names for drives are not saved like your network cards. Just check in /etc/udev/rules.d/ and see if you have any automatically generated files for your drives. I don't on any of my machines or VMs. Drives should be assigned dynamically every time you boot. It just so happens that most people don't change their configurations enough and motherboards tend to make their sata ports available first to the OS to have a need to switch to UUID, label, partid, etc.

1 members found this post helpful.

You mentioned it first, and implied initrd was a requirement for having a working bootloader.
Anyway, grub maps the drives differently than other bootloaders.
To change the order of drives with grub, one basically maps drives like:
This works, I have used it for a long time.
So when I boot the machine like this:
It boots the 1st (bios) drive, and kernel calls that drive sdb even if the bios had set the drive to be hd0. Effectively, it assigns names to harddrives.
This is why we disagree, I see no point in having them assigned dynamically when the bootloader assigns them statically, and you see no problem because your bootloader doesn't assign them at all.
I've nothing else to add, I don't really care if it panics in certain scenarios or not, as long as I know the cause.

No, it is required to use UUID (and probably labels) in your bootloader's config. You certainly don't need them for a working bootloader as Slackware's default lilo.conf works by simply referencing the device names.

You're doing the same thing as people using UUIDs to try and get the proper hard drive referenced, just with a different, and more prone to issues, method. Plus, you're not using the default bootloader, lilo, so there's already additional work to get it working. Plus, you have no way of setting it without seeing how the system will reference those drives (whether it will pass them as hd0 or hd1). Using UUIDs will not cause the kernel to ever panic unless the actual boot drive and root partitions are missing, because it will always be referenced by a unique ID.

Most people don't have any need to do this as their configuration doesn't change frequently, so that is probably a big reason why you don't commonly see it used in Slackware (I had used Slackware for over 10 years before I switched to UUIDs). But, for those who run into problems, like OP, it can be an easy way to ensure your system will always boot, no matter how your drives are added.

1 members found this post helpful.

Bassmadrigal, I have discovered that something in the kernel will ignore the map provided by grub and give priority to USB drives when assigning names.
So even if grub maps the drives properly and USB is disabled in bios, the kernel will tag the USB drive /dev/sda when the drive is present at boot, causing a panic because rootfs isn't there.
However, if the USB storage driver is built as a module, this doesn't happen anymore.

That's interesting. Is it an option that can be enabled/disabled in a kernel config? Or are you only able to deal with it by building the storage driver as module?

But as to my original point, these types of situations are exactly what using UUIDs or labels in your bootloader/fstab will prevent. So if your distro loads up a new kernel or Pat pushes a new -current kernel that changes the naming convention, it won't break your boot process just because device names changed. This would have easily survived the old /dev/hda -> /dev/sda switchover and the user wouldn't even have to care.

1 members found this post helpful.

Depends on the system, one of my systems has no modules at all, so I just deal with it by unplugging the storage when it's about to boot.
If the OP has bumped into the same type of panic with his storage, it could be one of them experimental storage drivers taking priority and there's plenty of them built-in.
My opinion is that some sort of mechanism must exist to inform the kernel which built-in driver must be loaded first, otherwise we're just fixing the engine with ducktape.

It seems that just unplugging things during the boot process to prevent kernel panics is "fixing the engine with ducktape". I don't see why they need to include some mechanism for that when there already exists an easy way to prevent it becoming a problem (using UUIDs/labels for lilo.conf/fstab).

To go back to your engine analogy, it's like telling manufacturers that they need to fix their engines because if you rev them too high, they'll blow, when a transmission already exists to allow you to consistently increase your speed without redlining your engine by simply changing gears.

1 members found this post helpful.

I didn't say "they need", I just said there must be something like that already in the kernel, if there isn't, I'm not going to lose sleep over it because it's not my responsibility.
UUIDs/labels are just a band-aid and you know it, so what if they get the system booted without a panic, when the name is still wrong in the device tree?
Furthermore, I don't owe you anything, and I didn't ask for your advice, or your help. You probably mixed me up with someone else.

How is using UUIDs/labels a bandaid fix? Once the drives are mounted, most people have no reason to care what device name is. Sure, you could have the kernel have some list on what order to start devices, but what happens if, by default, the kernel uses controllers 1, 2, and 3, in that order, and your system only has controller 3 in it. So your devices are correctly labeled /dev/sda, /dev/sdb, and /dev/sdc. Now, what happens if you add controller 1 with two devices. If the kernel uses the original order, it would put those new devices as /dev/sda and /dev/sdb, and the devices on controller 3 would now be /dev/sdc, /dev/sdd, and /dev/sde. Now, suddenly, your system will panic on boot because things aren't as the system expects.

How would you fix that? The kernel isn't expected to handle the order of those devices, because where would it store it? That is what should be done by the system, either through some udev rule that is loaded in the initrd (which I don't know if it is even possible) or by referencing UUIDs/labels.

For many (most?) systems, you never have a need to worry about it as the #1 port on the primary sata controller on the motherboard is almost always presented as the first device and will get labeled as /dev/sda. Even if you add other drives on other ports or add in a separate RAID or sata card, the #1 port on the primary sata controller is still usually presented first. So, if you have your drives hooked up right, they should be named properly.

I never said you owed me anything, however, you came in after this topic was solved and said that the way it was solved wasn't the best way to do it. I'm just backing up the information I provided in the thread.

1 members found this post helpful.

There isn't in the kernel, only in your imagination as far as I can tell.

Rather than taking a powder and sleeping on it, you would do better to research it and tell us what you find to back up your claims instead of further confusing this thread and wasting other's time.

Wrong in the device tree? According to what rule or spec or convention?

This is the whole point that you are missing, the device tree name/path cannot be wrong when there is no rule to define what is "right". Those names are assigned by the kernel before any filesystem is loaded, based only on what the BIOS hands it. If we play musical device, we get musical device name assignments. These are what they are per boot with no inherent persistent state.

UUIDs are not a band aid, they are the very mechanism that was created to unambiguously identify those devices under these very conditions.

Understand them. Use them.

2 members found this post helpful.

It's not clear to me why UUIDs should be considered as band aids and why it should be so important to find (unrealistic!) motivations to avoid them. Just a waste of time IMO.

Sorry I had a bad day. What I meant to say was I can't provide you a well documented working patch for this, even if I did owe you one. Sure the OP says panic is [solved], but that doesn't mean the incorrect device name feature won't come back in the future and cause data loss to someone else.

I don't tell you what to do, so you shouldn't be telling me what to do, unless you want me to tell you where to go.