While trying to move my computer to Debian, after allowing the installer to do it’s task, my machine will not boot.
Instead, I get a long string of text, as follows:
Could not retrieve perf counters (-19)
ACPI Warning: SystemIO range 0x00000000000000B00-0x0000000000000B08 conflicts withOpRegion 0x0000000000000B00-0x0000000000000B0F (\GSA1.SMBI) /20250404/utaddress-204)
usb: port power management may beunreliable
sd 10:0:0:0: [sdc] No Caching mode page found
sd 10:0:0:0: [sdc] Assuming drive cache: write through
amdgpu 0000:08:00.0 amdgpu: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
And the system eventually collapses into a shell, that I do not know how to use. It returns:
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait lomg enough?)
- Missing modules (cat /proc/modules; ls /dev)
Alert! /dev/sdb2 does not exist. Dropping to a shell!
The system has two disks mounted:
– an SSD, with the EFI, root, var, tmp and swap partition, for speeding up the overall system – an hdd, for /home
I had the system running on Mint until recently, so I know the system is sound, unless the SSD stopped working but then it is reasonable to expect it would no accept partitioning. Under Debian, it booted once and then stopped booting all together.
The installation I made was from a daily image, as I am/was aiming to put my machine on the testing branch, in order to have some sort of a rolling distro.
If anyone can offer some advice, it would be very much appreciated.
Sounds like your
/etc/fstabis 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/fstabusingblkidYou made me think that perhaps the BIOS/EFI is fudging something up. I checked and I had four separate entries pointing towards the SSD.
When you do fix it, the internet would appreciate a follow up comment on what you did to fix the problem
I will. Don’t know when, but I will.
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 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.
Perhaps? It fell into a busybox. How can I do what you are requesting?
- Boot into a LiveUSB of the same version of distro you tried to install
- View the drive mappings to see what they are detected as
- Ensure your newly created partitions can mount correctly
- Check
/etc/fstabon your root drive (not the LveUSB filesystem) to ensure they match as the ones detected while in LiveUSB - Try rebooting
Report changes here.
@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.
It wasn’t for nothing, you got some learning out of the experience and a story to tell. Good luck with the new system, maybe hold upgrading that to testing for a while, there’s plenty to break and fix even without extra quirks from non-stable distribution :)
Have fun and feel free to ask for help again, I and others will be around to share what we’ve learned on our journeys.
Sounds like the right choice! I’m glad you got Debian up and running,
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 0If 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.
Tbf he said he doesn’t know how to use the terminal, and he’ll need to use at least sudo, vim and cat plus the stuff you mentioned. A drive getting inserted into the disk order is probably the correct thing, I thought UUID was the default on new installs for that reason…
I’d argue that if the plan is to run Debian testing it’s at the very least beneficial, if not mandatory, to learn some basics of the terminal. Debian doesn’t ship with sudo by default, so it’s either logging in directly as root or ‘su’. Instead of vim (which I’d personally use) I’d suggest nano, but with live setup it’s also possible to use mousepad or whatever gui editor happens to be available.
I suppose it’d be possible to use gparted or something to dig up the same information over GUI but I don’t have debian testing (nor any other live distro) at hand to see what’s available on it. I’m pretty sure at least stable debian installs with UUIDs by default, but I haven’t used installer from testing in a “while” so it might be different.
The way I’d try to solve this kind of problem would be to manually mount stuff from busybox and start bash from there to get “normal” environment running and then fix fstab, but it’s not the most beginner friendly way and requires some prior knowledge.
mandatory
Yes but, not in the first few weeks.
My holistic suspicion is that OP has his home folder on a USB/esata drive and he’s not telling yet.
Edit
Apparently no
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.
If I could, I would award myself with a medal for being a glorified idiot.
Can you reinstall? If possible, use the whole disk (no dual booting and bootloader to deal with).
I can, already done before coming here and I risk I’m going to do it again because people are telling me to do this and that and I’m feeling way over my head.
But not in the mood to quit. Yet.
I’m running a clean machine. No secondary OS. The only thing more “unusual” that I am doing is partitioning for different parts of the system to exist separately and putting /home on a disk all to itself.
Ah, yes I saw all the comment suggestions and was hoping a fresh reinstall would work for you.
Did you format before reinstall? Definitely seems like fstab issue dropping you into initramfs that would need some manual intervention.
A format and fresh install should totally resolve this (assuming installation options and selections are sound).
What does ‘ls /dev/sd*’ ran from shell show you?
Just in case you end up with reinstallation, I’d suggest using stable release for installation. Then, if you want, you can upgrade that to testing (and have all the fun that comes with it) pretty easily. But if you want something more like rolling release, Debian testing isn’t really it as it updates in cycles just like the stable releases, it just has a bit newer (and potentially broken) versions until the current testing is frozen and eventually released as new stable and the cycle starts again. Sid (unstable) version is more like a rolling release, but that comes even more fun quirks than testing.
I’ve used all (stable/testing/unstable) as a daily driver at some point but today I don’t care about rolling releases nor bleeding edge versions of packages, I don’t have time nor interest anymore to tinker with my computers just for the sake of it. Things just need to work and stay out of my way and thus I’m running either Debian stable or Mint Debian edition. My gaming rig has Bazzite on it and it’s been fine so far but it’s pretty fresh installation so I can’t really tell how it works in the long run.
I’m on track for that, I admit.
As I read this, I’m trying a freshly installed live image.
I have to try… I’m already too invested in this stupidity to just quit at this point.
Why am I interested in a somewhat rolling release of Debian? Because I’m a dreamer with not enough technical capabilities. I like the stability Debian offers and the years I’ve used it as my default distro is a fond memory.
The bare bones mentality, the basic, clean approach to the UI/desktop distro customization and the minimal starting software package was a big plus, especially when using very underpowered machines, like I had then.
What is not a fond memory is having an OS remain static for such a long time span to the extent it feels like jumping into a completely new OS when migrating to the next release and lacking on having newer versions of software. Yes, I do know Backports are a thing but nonetheless.
But the more user friendly distros overcompensate on this, by overloading the starting software package and bloating the distro. Polishing can be too much.
No, I am not about to go and try LFS, Gentoo, or whatever distro that puts me in charge of everything. I have a life. Kind of. But still.
Like you say, I want things to work, I don’t mind doing some work but I really don’t care about nor need the extra bells and whistles the (excessive) polishing carries.
End of rant.
I’m going to torture myself trying to figure whatever might have gone wrong for a bit more.
How is your /home disk plugged in?
Through a cable, to the onboard SATA ports…? But somehow I don’t think that was the answer you were expecting.
Yeah I was thinking you might be using a portable drive for home, which might not be detected early enough in the boot process to mount.
If you haven’t reinstalled yet, swapping the order of the SATA cables might change the order they are detected, so your home disk that was B to the installer will once again be B to the boot drive.
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/fstabNano 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)
Congratulations.
Not exactly the aknowedgement I was aiming for but definetely the one I needed.
Why are you using multiple partitions ?
Linux is not like Windows where you can run programs on any partition or inserted media ; you can only run executables on the primary boot partition. Its therefore pointless IMO to have more than one partition (plus a swap partition).
Have you tried asking ChatGPT or Gemini ?
This is what Bing said :
Fixing “Gave up waiting for root device” error in Debian The error “Gave up waiting for root device” in Debian can be caused by missing modules or incorrect partition references. To fix this issue, you can follow these steps: Boot into a live session and list the UUIDs of all partitions using sudo blkid. Check the /etc/fstab file to ensure the correct UUID is listed for the root partition. If the UUID is missing or incorrect, replace it in the /etc/fstab file. If the error persists, you may need to rebuild the initramfs file by running sudo update-initramfs -u after installing the necessary modules with apt-get install lvm2 cryptsetup if you are using logical volumes. 1
These steps should help you resolve the boot error and restore your system’s functionality.
source :Ubuntu
Have you tried asking ChatGPT or Gemini ?
you can only run executables on the primary boot partition
lol
Have you tried asking ChatGPT or Gemini ?
lmao
Because I like having my disk properly partitioned, to keep things properly separated. Unlike windows.
And no, I haven’t queried any AI. Because why question a machine when I can ask real human beings and learn from them instead?
