Linux

@mvirts@lemmy.world @kumi@feddit.online @wickedrando@lemmy.ml @IsoKiero@sopuli.xyz @angband@lemmy.world @doodoo_wizard@lemmy.ml

Update - 2026.01.12

After trying to follow all advices I was given and failling miserably, I caved in and reinstalled the entire system, this time using a Debian Stable Live Image.

The drives were there - sda and sbd - the SSD and the HDD, respectively. sda was partioned from 1 through 5, while sbd had one single partition. As I had set during the installation. No error here.

However, when trying to look into /etc/fstab, the file listed exactly nothing. Somehow, the file was never written. I could list the devices through ls /dev/sd* but when trying to mount any one of it, it returned the location was not listed under /etc/fstab. And I even tried to update the file, mannually, yet the non existence of the drives persisted.

Yes, as I write this from the freshly installed Debian, I am morbidly curious to go read the file now. See how much has changed.

Because at this point I understood I wouldn't be going anywhere with my attemps, I opted to do a full reinstall. And it was as I was, again, manually partitoning the disk to what I wanted that I found the previous instalation had created a strange thing.

While all partions had a simple sd* indicator, the partition that should have been / was instead named "Debian Forky" and was not configured as it shoud. It had no root flag. It was just a named partition in the disk.

I may be reading too much into this but most probably this simple quirk botched the entire installation. The system could not run what simply wasn't there and it could not find an sda2 if that sda2 was named as something completely different.

Lessons to be taken

I understood I wasn't clear enough of how experienced with Debian I was. I ran Debian for several years and, although not a power-user, I gained a lot of knowledge about managing my own system tinkering in Debian, something I lost when I moved towards more up-to-date distros, more user-friendly, but less powerful learning tools. And after this, I recognized I need that "demand" from the system to learn. So, I am glad I am back to Debian.

Thank you for all the help and I can only hope I can returned it some day.

Sounds like your /etc/fstab is wrong. You should be using UUID based mounting rather than /dev/sdXY. Very likely you'll need to boot from a usb stick with a rescue image (the installer image should work), and fix up /etc/fstab using blkid

Can you run lsblk within the emergency shell? Sounds a bit like the HDD has taken theplacde of /dev/sdb, upon which there's no second partition nor a root filesystem -> root device not found.

1. Boot into a LiveUSB of the same version of distro you tried to install
2. View the drive mappings to see what they are detected as
3. Ensure your newly created partitions can mount correctly
4. Check /etc/fstab on your root drive (not the LveUSB filesystem) to ensure they match as the ones detected while in LiveUSB
5. Try rebooting

Report changes here.

Since you dont know what’s happening you dont need to be fucking around with busybox. Boot back into your usb install environment (was it the live system or netinst?) and see how fstab looks. Pasting it would be silly but I bet you can take a picture with your phone and post it itt.

What you’re looking for is drives mounted by dynamic device identifiers as opposed to uuids.

Like the other user said, you never know how quick a drive will report itself to the uefi and drives with big cache like ssds can have hundreds of operations in their queue before “say hi to the nice motherboard”.

If it turns out that your fstab is all fucked up, use ls -al /dev/disk/by-uuid to show you what th uuids are and fix your fstab on the system then reboot.

Can you reinstall? If possible, use the whole disk (no dual booting and bootloader to deal with).

Congratulations.

Do you happen to have any USB (or other) drives attached? Optical drive maybe? In the first text block kernel suggests it found 'sdc' device which, assuming you only have ssd and hdd plugged in and you haven't used other drives in the system, should not exist. It's likely your fstab is broken somehow, maybe a bug in daily image, but hard to tell for sure. Other possibility is that you still have remnants of Mint on EFI/whatever and it's causing issues, but assuming you wiped the drives during installation that's unlikely.

Busybox is pretty limited, so it might be better to start the system with a live-image on a USB and verify your /etc/fstab -file. It should look something like this (yours will have more lines, this is from a single-drive, single-partition host in my garage):

# / was on /dev/sda1 during installation
UUID=e93ec6c1-8326-470a-956c-468565c35af9 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=19f7f728-962f-413c-a637-2929450fbb09 none            swap    sw              0       0

If your fstab has things like /dev/sda1 instead of UUID it's fine, but those entries are likely pointing to wrong devices. My current drive is /dev/sde instead of comments on fstab mentioning /dev/sda. With the live-image running you can get all the drives from the system running 'lsblk' and from there (or running 'fdisk -l /dev/sdX' as root, replace sdX with actual device) you can find out which partition should be mounted to what. Then run 'blkid /dev/sdXN' (again, replace sdXN with sda1 or whatever you have) and you'll get UUID of that partition. Then edit fstab accordingly and reboot.

unless the SSD stopped working but then it is reasonable to expect it would no accept partitioning

This happened to me. It still showed up in kde's partition manager (when I plugged the ssd into another computer), with the drive named as an error code.

should apply to debian: https://askubuntu.com/questions/1482380/gave-up-waiting-for-root-file-system-device-after-an-upgrade-to-ubuntu-22

I think everyone here has offered good advice, so I have nothing to add in that regard, but for the record, I fucked up a Debian bookworm install by doing a basic apt update && apt upgrade. The only "weird" software it had was Remmina, so I could remote into work; nothing particularly wild.

I recognize that Debian is supposed to be bulletproof, but I can offer commiseration that it can be just as fallible as any other base distro.

Congrats, you found the only debian that breaks regularly: testing

You can file a bug report and then install something that does not require you to debug early boot issues, like debian 13 or if you really want a rolling release arch or tubleweed.

It could be that /dev/sdb2 really does not exist. Or it could be mapped to another name. It is more reliable to use UUiD as others have said.

What filesystem though? Another possibility is that the required kernel module is not being loaded and the drive cannot be mounted.

Don't be afraid of the command line, breaking Linux is how you end up learning how to use it!

I haven't done this tutorial but if that kind of thing helps you this one looks pretty good.

My best guess is you need to do something like:

(In the shell, one line at a time, enter runs the command)

mkdir /mnt/tmp
mount /dev/sda2 /mnt/tmp
nano /mnt/tmp/etc/fstab

Nano is a text editor that uses your whole terminal, so you will see the contents of /mnt/tmp/etc/fstab (the file that controls where disks are mounted) and replace 'sdb' with 'sda' on the line starting with /dev/sdb2. The bottom of nano's screen shows you the keyboard shortcuts, I think Ctrl W will make it write the file, asking for confirmation of the filename, which should stay the same. Exit nano (Ctrl+x maybe?) then reboot with the command 'reboot'

If you get any errors about access denied or permissions, run 'sudo bash' to get a shell with more power and try again.

Good luck!

What most likely happened is your disk order switched and, as others have mentioned, using /dev/sda1 or something similar to point to partitions is unstable and can't be trusted. Once your system is back up, look up how to specify partitions in /etc/fstab using UUID (something like /dev/disks/by-uuid/xxxx-xxxxxxxxxx-xxxx instead of /dev/sda2)