Disks in wrong order at boot

I’m trying to install rocky linux on an HPE DL160 gen10 using the following method to create an initial RAID device:

https://docs.microlinux.fr/rockylinux/el8/partitionnement-raid1/#uefi-table-de-partitions-gpt

I have 4 disks on this machine:

  • slot 1: 300 G
  • slot 2: 300 G
  • slot 3: 2T
  • slot 4: 2T

My issue is that in shell mode slot 1 is /dev/sda but slot 2 which should be /dev/sdb is named /dev/sdc.

Any idea how to fix the boot order so the slot 2 is /dev/sdb ?

Mantra: “sd*-names are not persistent”. That is why UUID is used in /etc/fstab.

Question: does array assembly actually depend on the sd*-names (other than on initial creation)?

I don’t know if the disk array is based on disk name, I would admit I didn’t try. I find it odd however it doesn’t take the hardware disk order on startup :confused: It’s a first time for me :slight_smile:

I’m there with jlehtone,
You remove one disk (or it just goes bad) and you reboot, and the sdx naming could be totally different,
if possible better use either the by-uuid, by-partuuid or what better suits your case :+1:

To understand what is what, the Arch Wiki always comes to the rescue :eyes:

Persistent block device naming - ArchWiki

1 Like

@lumarel raid install is done the rescue.

I fixed it by resetting disk boot order in UEFI from the bios. This did the trick. Thanks for the help anyway !

1 Like

Oh great that you found it yourself :slight_smile:

1 Like

Can’t argue with Arch docs. Red Hat tells the tale in this way: Chapter 6. Overview of persistent naming attributes Red Hat Enterprise Linux 8 | Red Hat Customer Portal

2 Likes

Blockquote

I have 4 disks on this machine:

slot 1: **300 TB**
slot 2: **300 TB**
slot 3: 2T
slot 4: 2T

300 TB ?!? 1 Disk?? Did you mean 300 GiB?? 300 GiB make sense, 300 TB does not.

i meant 300 G yes… sorry for the typo. I fixed it, thanks :slight_smile: