Why is there even a line pointing directly to /dev/sdb1? That alone can exhibit undefined behavior – i.e. explain the timeout waiting for ... messages – because there is no guarantee that your external drive will get that name at boot time every time, and there never was, really.
Dunno. My only guess is I myself inadvertently flagged the external drive for boot. 
Illogical since I try to avoid having my external drives connected during boot, shutdown, and system maintenance.
Still a caveat for other running into similar issues.
That’s most likely not something the installer did, because it generates an /etc/fstab like this. The boot flag has nothing to do with that.
But yes, it still hasn’t made the rounds that one does not refer to such device nodes directly, apparently, which is why I keep talking about it to anyone who will listen.
Well, I absolutely positively did not put that in fstab myself.
Already thought of doing a fresh install, but only seconds ago found out the release of Kubuntu 26.04 LTS ‘Resolute Raccoon’ was published last April 23rd. Totally missed that (busy last weeks).
So that’s solved too.
Was that drive even connected when installing Ubuntu? I think you may have done that yourself and simply forgot about it. Happens all the time.
Nope. Only thing connected to my PC during install of 24.04 was the boot-microSD.
Then the installer can’t have put /dev/sdb1 in /etc/fstab. Maybe it was some graphical helper tool which did that. If you can dig deeper in your memory, it could be worth a bug report, because that’s just not how it’s done and should be fixed.
AFIAK there is no way to trace the history of changes to fstab.
The entry for sdb1 seems related to the boot flag on the external USB-HD.
The entry for luks would be relating to building an encrypted USB-HD.
Only thing connecting those two is the use by me of KDE Partition Manager.
That’s why I asked to dig deeper in your memory. 
No, that has nothing to do with the boot flag.
No, that’s for your LUKS2 encrypted /, I reckon. BTW, I see no /boot there for an unencrypted boot partition. You should be aware that’s not exactly standard and may cause issues with future release upgrades or make them impossible altogether.
Does that alter /etc/fstab?
BTW, what even is your filesystem layout; it didn’t seem relevant at first, but now I’m curious:
lsblk -fe7
Yes, I know you meant my memory. 
But KISS : what would have caused those entries to be added to fstab other than the aforementioned use of KDE PM?
lsblk -fe7
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
nvme0n1
└─nvme0n1p1 ext4 1.0 kubuntu_2404 c0d76448-59ba-48e6-b5e7-d5ed878a3193 1,6T 5% /
What makes me curious why changes like this aren’t logged automatically for future bug finding. Same for some easy GUI from which all relevant information can by pulled up.
So no LUKS2 encryption?
Who says there aren’t any logs? You just have to tell KDE Partition Manager to create them.
FWIW, you can have a history of /etc/fstab or any file, for that matter. The BTRFS filesystem has snapshots for that purpose, so one can opt to install Ubuntu to BTRFS and do snapshots before any and all system changes.
Alternatively, one can make /etc a GIT repository.
Well, a quick look shows KPM doesn’t offer logging., BTRFS is no longer supported, and I prefer EXT4 anyway. I think a efficient out-of-the-box logging repository tool should be part of system management.
But I’ll look into it some more prior to the fresh install of 26.04
KPM does offer logging it’s actions; I even linked to the tip about that. Also, how is BTRFS supposedly not supported?
Plus, I think, if this is morphing into a more general discussion, you should select open a new topic, possibly in the Lounge. This is pretty much unrelated to Nvidia drivers. It also seems as if that title is not quite correct anymore, given that the boot issues seem to stem from the combo of a bad fstab entry and/or an intermittently present device.
1 Like
This topic was already satisfied at 19/33.
Some very useful questions on your part thereafter though.
I am now looking into some system log tools offering historical logging prior to installing 26.04
Have a great Sunday!
2 Likes
This topic was automatically closed after 29 days. New replies are no longer allowed.