System dual boots Windows 10 and Linux. Linux had been openSUSE for quite a while, then Mint, now replaced Mint with openSUSE Leap 15. The first try at Leap installation ended with an error. I rebooted and started installation again. When it showed the partitions, the two hard drives were named sde and sdf. Always before, including the first Leap 15 installation try, the drives were sda and sdb. I aborted installation, and rebooted to a live gparted session. It also showed the two hard drives as sde and sdf. I restarted installation and got it done correctly.
System seems to behave correctly, booting Win10 or Leap. Windows has all partitions with their correct drive letters. Leap has sde and sdf.
What became of sda and sdb? Is there any problem continuing with sde and sdf?
This happens because USB storage module(s) load before HDD storage module(s), and enumeration finds the card reader before the HDDs.
If you really want sda & sdb back on HDDs, check if a BIOS upgrade is available. You may be able to get them back simply by reconfiguring BIOS USB settings, including getting USB out of or to the bottom of boot priorty. Otherwise, reconfigure dracut to exclude USB from the initrds. Back up the prior initrds before generating new ones. If no USB in initrds works, restoring the backed up initrds and moving the USB card reader cable to different motherboard connectors might also have the desired effect. Or, you might start with moving the card reader cable.
I’ll leave the naming as is for now. I’ve done numerous fresh installations of both openSUSE and Mint on this hardware, always keeping the same partitioning. This is the first time the hard drives are not sda and sdb. Both openSUSE and Windows perform fine, so it seems there is not a problem that needs fixing.
Regards,
The reason that openSUSE uses mount by UUID instead of direct by device file, is to avoid problems like your situation where the the detection sequence changes. And as you report your openSUSE is still OK, that proves that this approach works.
At one time, I had a laptop where the hard drive would be “/dev/sdb” if there was a USB plugged in.
The naming appears to depend on weirdness of hardware and firmware.
My current desktop is fine with device names. However, if I use encryption with “/boot” as part of the encrypted root file system, then grub gives a message about an I/O error on disk 1 (I actually have 3 hard drives). With some experimenting, I was able to work out that grub does not give that error if there is a CD or DVD in DVD reader. So apparently, grub sees the DVD as disk 1. So I switched the SATA connectors, so that it wouldn’t be disk 1. But that did not work. Apparently the firmware always wants to make the DVD to be disk 1, no matter where it is plugged in.
Otherwise, reconfigure dracut to exclude USB from the initrds.
yes, that will probably “fix” it, except the whole is solution in search of problem. Device names are not guaranteed to be persistent across reboot by definition; nothing should rely on them.
It shouldn’t, but I’ve seen BIOS updates change device enumeration timings and thus order, hence the suggestion.
yes, that will probably “fix” it, except the whole is solution in search of problem. Device names are not guaranteed to be persistent across reboot by definition; nothing should rely on them.
That’s a good enough paradigm for automated operations, but human brains work differently than computers. My brain knows sda1 is the first partition on the first HD. It doesn’t know and will never remember a randomly generated 36 character UUID string, much less type it in a reasonable length of time.
Computers can count however they want, but humans learn in the first grade if not before: alphabetical order, 1 = first, 0 means none, e is fifth, and existence of a fifth depends on a first, second, third and fourth. Thus it logically follows that if any sdX devices exist, the first is a, second b, third c, etc. If any sdX devices exist, then sda must exist for sde to exist. That software can violate this order as OP sees is mentally discombobulative, and justification for a workaround to avoid being exposed to it.
Today, my old brain is dealing with hard drives as sde and sdf with only a twinge of discombobulation (e.g., why did it do it this time and never before?). I’ll let it ride.
Cheers,
Indeed. And, to extropolate so other Users understand, this is the reason why mounting with UUID (or, if done carefully, by Label) is the only sure way of avoiding a problem caused by device names moving around.