Random device name

How to manage the fact that on consecutive pxe installations on the same server (HP for the case, UEFI), the installation bootstrap recognizes devices with a random naming order. What was sda becomes sdb, and sdb becomes sda… to give an example

Best practice is to use UUID or LABELS. → $ man fstab

2 Likes

No, you must understand that the system is not yet installed. This happens when the installer boostrap searches for the devices present in the machine. Before in my interpretation to read the kickscript file …

The one thing that I practically never leave to kickstart is partitioning, even on single device systems. True, that requires some interaction.

Appendix B. Kickstart commands and options reference Red Hat Enterprise Linux 8 | Red Hat Customer Portal says:

  • The sdX (or /dev/sdX) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from /dev/disk as an alternative. For example, instead of using the following device name:

part / --fstype=xfs --onpart=sda1

You can use an entry similar to one of the following:

part / --fstype=xfs --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1

part / --fstype=xfs --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1

By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the ls -lR /dev/disk command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.

The doc for RHEL 9 looks almost similar.

2 Likes

Maybe i’m wrong but does this instructions need to be preceded with a

clearpart --all

@jlehtone, No?

if not the disk may not have space left to generate the partitions and fail to install. @tango Guess this is on a fresh install and you don’t mind on what was before on the disk.

Probably. That note was about the XXX is --onpart=XXX, not about all the other (related) directives in the kickstart.

is a fresh install …

my precise question is, if we accept that we must edit lines like the following in the kickstart file
part / --fstype=xfs --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1

Where do I find “pci-0000:00:05.0-scsi-0:0:0:0-part1” or at least the “UUID” if the machine is not installed?
Do you think in the card controller, the bios or other?

Thank you for giving me your time

That is, boot machine with install media. In the installer one can switch to text console with one of the Ctrl-Alt-Fn. Run the ls there and note down the results.

Some of the names in the /dev/disk/by-id/ seem to include serial number. If you have multiple “identical” machines with same brand drives, then you can predict their names from the serial number. Serial numbers you probably see via “BIOS” utility or just looking at the physical device.

If you figure out how the /dev/disk/by-path/ names map to physical drive slots, then use that.

I.e. one should be able to go from serial number of drive on the first physical slot into a “by-path” name, which (hopefully) refers to drive in first slot in every server.

Thank you very much, it’s time to get back to the chassis

Usually when I do this it’s for a cluster of identical machines and so I just do what jlehtone said, boot one of them to the installer, switch over to the shell pane, save the output of lsblk and some lists of /dev/disk/by-path, and use that to construct the ptable to Kickstart them all.

Frequently I’m using /dev/disk/by-path names, but if you know like, you’ve got a smaller system disk and a larger scratch or data disk sometimes you can set --grow --size ...s and Blivet will lay it out for you automatically.

1 Like