Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Thanks for the suggestion! That seems to be the mapping from UUID to device, which I didn't know about, so I guess I could just add a new link for the missing UUID.
But in terms of eliminating the usage of all UUIDs, this probably doesn't help.
update-grub is pointless for this.
update-initramfs needs -u to update an existing initramfs and -k <version> if the target kernel version is different from the running one.
p.H wrote: ↑2022-06-04 11:01Be careful, /dev/sd* names are not persistent across reboots and must not be relied on. This is a reason why UUIDs are used instead.
I fully agree with that. Not long ago when checking a SSD with 'smartctl -a /dev/sda' I had the surprise to get results for an HDD that usually is /dev/sdb. I absolutely don't know why the letter had changed this time, stray cosmic ray being surely the most convincing hypothesis.
ralphb wrote: ↑2022-06-04 11:41*sigh* I fully agree with you here! And I know which problem UUIDs are meant to solve, but so far, my experience has been the other way around.
I don't know what triggered the problem you experienced, but it certainly has nothing to do with UUID and would have happened anyway (unless UUID has actually changed, but you'd know it, UUIDs don't change on their own. You are mistaken by the fact that the error message uses UUID to refer to the disk). So IMHO you'd better stick to UUID.
Sorry for not being clear enough. First, I should have said "refer to disk partition".
What I meant is that the error message uses UUID because that's how the partition is referred to but it would have used for instance /dev/sdx otherwise.
Was 'cryptsetup: waiting for encrypted source device UUID=....' (four dots instead of the UUID) the actual message or did you replace the UUID with dots? I assumed that you replaced the real UUID with dots, hence my possible misunderstanding.
fabien wrote: ↑2022-06-04 13:17
when checking a SSD with 'smartctl -a /dev/sda' I had the surprise to get results for an HDD that usually is /dev/sdb. I absolutely don't know why the letter had changed this time
There is no need for a reason. /dev/sd* names are not stable by design.
ralphb wrote: ↑2022-06-04 15:31
I still don't understand why the system waited for an invalid UUID
Don't forget that there is no guarantee that UUIDs and labels are really unique, especially if you move, share or copy the device. Use lsblk -o +UUID,PARTUUID to verify that the UUIDs are really unique in your system.
I've used my notebook extensively over the past two weeks, but so far everything is still working (while still using UUIDs). But this discussion is very handy to have in case something goes wrong again.