Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled
40 views
Skip to first unread message
Todd Morgan
Aug 31, 2023, 7:20:05 PM8/31/23
to
Package: debian-installer-12-netboot-amd64 (20230607+deb12u1)
Net Installer: https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso
Severity: high
Configured System:
HPE DL20
1x 480GB SSD
3x 960GB SSD
I am installing Debian Linux on servers using UEFI PXE and a preseed file for a touchless installation. This has been our standard method for Debian installs for years, starting with "buster." It has worked VERY reliably for us.
When using the same method to install Debian 12, I am noticing that the installer is detecting the drives out of order. It does not match what the server BIOS or HPE ILO5 displays. With each PXE installation attempt the ordering can vary. Looking in /dev/disk/by-path you can see the symlinks differ between install attempts. Sometimes the order matches the PCI bus reference and sometimes it's jumbled up.
This is an issue when you want to tell partman to use /dev/sda (the first drive) for the installation and have grub installed properly on /dev/sda. This is even worse when trying to do a software RAID1 via preseed. The pairs of drives are not being selected in a predictable fashion.
Interestingly enough, after the installation is complete and the Debian 12 system is booted up, it always shows the drives in the proper order, 100% of the time. But the boot media may or may not be the correct drive. This is only an issue at install time.
This past week I performed dozens of PXE installs on a set of 3 servers. Debian 11 had no problems. Only Debian 12 displayed this behavior on each of the 3 servers. I tried updating firmware on all 3 servers so that it is running the latest versions, but that had no effect.
Pascal Hambourg
Sep 1, 2023, 7:30:05 AM9/1/23
to
On 01/09/2023 at 01:17, Todd Morgan wrote:
>
> When using the same method to install Debian 12, I am noticing that the
> installer is detecting the drives out of order. It does not match what the
> server BIOS or HPE ILO5 displays. With each PXE installation attempt the
> ordering can vary. Looking in /dev/disk/by-path you can see the symlinks
> differ between install attempts. Sometimes the order matches the PCI bus
> reference and sometimes it's jumbled up.
AFAIK /dev/sd* discovery and ordering was never guaranteed to be
>
> When using the same method to install Debian 12, I am noticing that the
> installer is detecting the drives out of order. It does not match what the
> server BIOS or HPE ILO5 displays. With each PXE installation attempt the
> ordering can vary. Looking in /dev/disk/by-path you can see the symlinks
> differ between install attempts. Sometimes the order matches the PCI bus
> reference and sometimes it's jumbled up.
deterministic nor persistent across boots nor match any hardware or
firmware ordering. One should not rely on these names, hence the use of
persistent identifiers such as UUID, device path or disk ID.
> This is an issue when you want to tell partman to use /dev/sda (the first
> drive) for the installation and have grub installed properly on /dev/sda.
identifiers instead.
Todd Morgan
Sep 15, 2023, 11:30:04 AM9/15/23
to
> AFAIK /dev/sd* discovery and ordering was never guaranteed to be > deterministic nor persistent across boots nor match any hardware or > firmware ordering. One should not rely on these names, hence the use of > persistent identifiers such as UUID, device path or disk ID.
I agree. That is why I used UUID for the fstab entries. But this drive ordering issue is specific to the installer. The preseed is expecting a /dev/sd* type of entry in order for partman to partition the correct drive...or in my case (using software RAID1) drives.
> I advise to not hardcode /dev/sd* anywhere and use persistent > identifiers instead.
As stated above, I am not using /dev/sd* anywhere other than in the preseed which requires it.
Pascal Hambourg
Sep 15, 2023, 3:00:04 PM9/15/23
to
On 15/09/2023 at 17:26, Todd Morgan wrote:
>> AFAIK /dev/sd* discovery and ordering was never guaranteed to be
>> deterministic nor persistent across boots nor match any hardware or
>> firmware ordering. One should not rely on these names, hence the use of
>> persistent identifiers such as UUID, device path or disk ID.
>
> I agree. That is why I used UUID for the fstab entries. But this drive
> ordering issue is specific to the installer. The preseed is expecting
> a /dev/sd* type of entry in order for partman to partition the correct
> drive...or in my case (using software RAID1) drives.
If I understand correctly, the issue is not drive ordering but the
>> AFAIK /dev/sd* discovery and ordering was never guaranteed to be
>> deterministic nor persistent across boots nor match any hardware or
>> firmware ordering. One should not rely on these names, hence the use of
>> persistent identifiers such as UUID, device path or disk ID.
>
> I agree. That is why I used UUID for the fstab entries. But this drive
> ordering issue is specific to the installer. The preseed is expecting
> a /dev/sd* type of entry in order for partman to partition the correct
> drive...or in my case (using software RAID1) drives.
preseed capability to handle persistent drive identifiers.
0 new messages