1

This morning I did something stupid. On my Debian 8 I ran apt-get update and apt-get upgrade. In the middle of the unpacking and installation of the updates (approx 500MB) I had to leave fast. As a habit I tend to hibernate my system and sadly I did it this time too.

Now when I try to boot my system right after the OS selection menu (I have only a Debian 8 on my notebook) I go straight to initframs with the following message:

Gave up waiting for root device. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay- (did the system wait long enough?)
   - Check root- (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)

ALERT! /dev/disk/by-uuid/87f8d463-bb91-4eb0-866c-8189f8ea6afb does not exist. Dropping to a shell!
modprobe: module ehci-orion not found in modules.dep

BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1) build-in shell (ash)
Enter 'hel' for a list of build-in commands.

/bin/sh: can't access tty; job control turned off
(initframs) _

Before that (as usual) I can see "Loading from ramdisk" on the screen since I hibernated the system.

Now my guess is that during the update some critical part of the system was in the process of being updated and the hibernation interrupted all this (why was I even allowed to do that if something that critical was being installed is a different topic).

I have never experienced such a problem and all the information I was able to find was about people having RAID problems, which in my case is not the case. Others say that it has something to do with encryption, which I have none.

I can boot from a live USB and provide more information.

Using an old Live CD (sadly 32bit while my Debian is 64bit) I did check /etc/fstab and the device listed in the ALERT! is indeed /dev/sda2 where both my root filesystem as well as /boot/grub are.

|improve this question
1

You need to try to make that update finish.

If you have Live CD/DVD/USB boot into that, then try {blkid | more} to list all your {UUID=xxxxxxxx.xxxxxxxxxxx.xxxxxxxx.xxxxxxxx} numbers. It's strange that update messes that data up. See whether UUID value matches the previous one (it should).

Then connect to internet and try to {chroot} your way into damaged Debian and make that update restart and this time be aware of what you're doing.

Your issue will be fixed when either:

1) You restart update and let it complete properly.

2) You find all files which that update has altered and return them to their value(s) from before you tried to update (by hand).

|improve this answer
  • In the morning I will try to get my hands on a 64bit live USB (it seems that chroot doesn't really like when you go from 32bit to a 64bit system) and try out what you've suggested. – rbaleksandar Feb 20 '18 at 23:12
  • Worked like a charm. It seems that a lot of important things had to be upgraded including the kernel image. After I chrooted (I also had to mount bind the /etc/resolv.conf so that I have Internet connection) I had to fix a bunch of packages, remove some, but all in all it went pretty smoothly. After a reboot (I used Xubuntu 17.10 64bit) Debian made another attempt to load from ramdisk. It failed and rebooted again, followed by terminal output, where I was able to see clearing orphaned nodes etc., which I was so happy about, since it just indicates an dirty shutdown. After that it was ok. – rbaleksandar Feb 21 '18 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.