Gave up waiting for root device...

nobody0 · 2016-03-08 18:42:06

I wrote about this matter here, https://forums.bunsenlabs.org/viewtopic … 341#p21341 thinking about Puppy Linux, but when I searched about this in the net, it looks like a serious problem, for which no one appears to have found an answer. I saw how the booting went on killing off pids until it came to that info, "Gave up waiting for root device..." and never booting. It may have something to do with systemd, I don't know. I'm glad I had Puppy Linux. My pal would most probably go back to Windows, even though he'd keep the copy of Puppy Linux with him.

Has anyone ever had this problem before? I really hope I'd never get into such a situation. Grub was there and you could choose which distro to boot, only it never booted. Some app (or apps) were eating out all the memory.

tknomanzr · 2016-03-09 01:30:15

Are you sure it wasn't an /etc/fstab issue, like the uuids got changed or something? It sounds to me like there was trouble mounting root.

Last edited by tknomanzr (2016-03-09 01:30:37)

PackRat · 2016-03-09 02:05:07

^ This happened to me once. I had to edit the /etc/fstab - from Puppy live session no less - to use /dev/sda1 as the root partition. On reboot, system mounted root and booted to completion. I got the correct UUIDs for the partitions and edited fstab. All was well after that.

Last edited by PackRat (2016-03-09 12:47:56)

nobody0 · 2016-03-09 08:19:06

^ I really don't know. I wouldn't want that to happen to me at all, but if it happens, I'd remember your advice. I watched the laptop taking so much time to come to that "gave up waiting for root device." It (Linux) was actually eating up memory and looking for more.

unklar · 2016-03-09 09:53:18

ostrolek wrote:

...
ALERT! /dev/disk/by-uuid/0c89a9d3-a736613-aa98-16fd1219ceb9 does not exist.
...

I guess this error when installing Debian:

The GRUB boot loader was previously on a disk that is not available at
System is in place or the unique identifier for some
Basic has been changed, installed. It is important to ensure that
the installed GRUB core image in sync with the GRUB modules and
grub.cfg remains. Please check again to make sure that GRUB
is written to the appropriate boot device.
If you are not sure which device uses the BIOS to boot,
it is often a good idea to install GRUB on all devices.

measures:
notice in the BIOS, which HDD "up" position and the "boot flag" has;
comparing my main system;
Puppy Linux or Debian or bunsenlabs > / > sdaX > grub >> mbr/sda
and in addition this grub >> mbr/sdb >> mbr/sdc etc.

Here is a small script from the German ubuntu forum to determine where GRUB
is installed on your system anywhere?
Please to $HOME; make it executable; start as root.

grub_search.sh

#!/bin/bash
# auf welchem Datenträger ist GRUB installiert?

 bold=$(echo -e "\e[1m")
 norm=$(echo -e "\e[0m")
  red=$(echo -e "\e[1;31m")
green=$(echo -e "\e[1;32m")

if [[ `whoami` != root ]]; then
  echo "Please with$bold sudo $(basename $0)$norm launch".
  exit 1
fi

fdisk -l | egrep -o "/dev/[[:alnum:]]+" | sort | uniq |
while read part; do
  egrep -q [[:digit:]] <<< $part || echo "----------------------------------"
  echo -en "$part\t"
  dd if=$part bs=1 count=512 | grep -aq GRUB && echo -n "$green" || echo -n "${red}no "
  echo "GRUB found$norm"
done 2>/dev/null
echo "----------------------------------"

apacus11 · 2016-03-09 15:09:00

PackRat wrote:

^ This happened to me once. I had to edit the /etc/fstab - from Puppy live session no less - to use /dev/sda1 as the root partition. On reboot, system mounted root and booted to completion. I got the correct UUIDs for the partitions and edited fstab. All was well after that.

That makes sense to me.

I get rid of changing UUIDs (always testing distros on my netbook) so I decided to use /dev/sda* qualifiers instead.

tknomanzr · 2016-03-09 20:53:23

I would personally chroot into / on the drive in question, from a live usb, then use blkid to get the uuid for / and compare it to /etc/fstab. If different, fix it up, then run sudo update-grub from the command line. You should also update-initramfs. At least when migrating from ext4 to btrfs and fixing up /etc/fstab, it was recommended to run both. This should fix things for you.

Last edited by tknomanzr (2016-03-09 20:55:32)

Head_on_a_Stick · 2016-03-09 22:04:12

Moved to Help & Support (Other)

nobody0 · 2016-03-10 16:23:06

tknomanzr wrote:

I would personally chroot into / on the drive in question, from a live usb, then use blkid to get the uuid for / and compare it to /etc/fstab. If different, fix it up, then run sudo update-grub from the command line. You should also update-initramfs. At least when migrating from ext4 to btrfs and fixing up /etc/fstab, it was recommended to run both. This should fix things for you.

To chroot into... you first need to boot in... right?

Head_on_a_Stick · 2016-03-10 18:58:57

^ No, as @tknomanzr says you just boot up the live session of the ISO image and use `chroot` from there

You can even just run `blkid` from the live environment to get the device identifiers and then modify /etc/fstab in the installed system from there as well.

Of course, `update-grub` && `update-initramfs` would still require a chroot:

mount /dev/sdXY /mnt
for i in /proc /sys /dev;do mount --bind $i /mnt$i;done
chroot /mnt

(If you have a separate /boot partition, mount that as well before `chroot`ing)

tknomanzr · 2016-03-11 02:53:10

Here is my initial post on setting up a chroot environment, along with some input by @HoaS and others.

Rescue Your System Using Chroot and a Live Environment

I have been considering building a bash script to set this all up via one command. However, having said that, I do feel it is important to understand how and why this works when all other methods fail. The original post I made was in regards to fixing broken sid systems but the concepts still apply to any fundamentally broken Linux system. When I actually have the chance to sit down for awhile I will work a bash script up for this. Life has not been conducive to Linuxing here lately.

nobody0 · 2016-03-11 07:39:07

Head_on_a_Stick wrote:

^ No, as @tknomanzr says you just boot up the live session of the ISO image and use `chroot` from there

You still have to boot up the live session. None of the known distros did, except Puppy Linux.

Eraph · 2016-03-11 09:33:37

Is it possible there could be a problem with your RAM? Maybe worth running a memory check?

#1 2016-03-08 18:42:06

Gave up waiting for root device...

#2 2016-03-09 01:30:15

Re: Gave up waiting for root device...

#3 2016-03-09 02:05:07

Re: Gave up waiting for root device...

#4 2016-03-09 08:19:06

Re: Gave up waiting for root device...

#5 2016-03-09 09:53:18

Re: Gave up waiting for root device...

#6 2016-03-09 15:09:00

Re: Gave up waiting for root device...

#7 2016-03-09 20:53:23

Re: Gave up waiting for root device...

#8 2016-03-09 22:04:12

Re: Gave up waiting for root device...

#9 2016-03-10 16:23:06

Re: Gave up waiting for root device...

#10 2016-03-10 18:58:57

Re: Gave up waiting for root device...

#11 2016-03-11 02:53:10

Re: Gave up waiting for root device...

#12 2016-03-11 07:39:07

Re: Gave up waiting for root device...

#13 2016-03-11 09:33:37

Re: Gave up waiting for root device...

Board footer