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)

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

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.

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.

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.

Congratulations.

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

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.

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.

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.

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