Need a hint about system's verbage at bootup

[grigory]

Hello!

I've got a dual boot W10/Ubuntu 14.04 laptop. I use GRUB2 as a boot loader. In the BIOS I chose "Legacy BIOS" option (the laptop was purchased with EUFI enabled system and W8 OEM). I don't know, maybe it's something wrong that I did during the installation or something else... Right now, I probably won't run and start changing or re-installing stuff, but at least I'd like to know what it's all about. What happens is that when I try to get into Ubuntu, quite often I end up in BusyBox shell environment. Then I re-boot the machine and get to Ubuntu at last. What is even stranger to me is that it doesn't always happen. Sometimes everything is kosher and I get normally to the Ubuntu login screen (it's a desktop environment -- Unity). Now...I would present here the verbage I see on the screen while I try to get to Ubuntu, but end up in shell. sdb being the Ubuntu HDD (usually).

[ 2.978708] usd 1-1.1: string descriptor 0 read error: -22
[ 3.660632] sd 6:0:0:0: [sdb] No Caching mode page found
[ 3.660665] sd 6:0:0:0: [sdb] Assuming drive cache: write through
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/c6d0a763-50c0-4072-a72f-6286ec73709b does not exist.
Dropping to a shell!

BusyBox v1.21.1 (ubuntu...) built-in shell (ash)
(initramfs)_ (curson is blinking here)...

 

[mv2devnull]

"Gave up waiting for root device"

The GRUB loads kernel (and some drivers from initrd/initramfs). Once the kernel is up, it tries to find devices, including the filesystem that contains the '/' (aka root filesystem) that has usually most of the OS installation.

The actual "failed to mount root" error message is usually several lines earlier in the out put than the "dropping to shell". Here it seems that Ubuntu does give some time for the "lets find that disk" routine, but usually not enough.

The final message instructs to check two command line arguments: root= and rootdelay=
Command line arguments are in the GRUB2 config file with the kernel. There is probably root=UUID=c6d0a763-50c0-4072-a72f-6286ec73709b
Perhaps the rootdelay= could be used to force a longer wait, before giving up?


An another question is, why is the HDD / partition / filesystem so slow/hard to find? Is that a configuration error or a hardware malfunction?

 

[grigory]

Thanks for your reply!

I think it's probably a configuration error. Hardware seems to me fine. Moreover I personally have a much better knowledge of computer hardware than of Linux. See, my system's configuration is not typical and I had to re-do it like 10 times. I use dock-station for 3,5" regular desktop HDD that now being used as an external HDD. That's where Ubuntu is. And it connects to my laptop's USB3 port. So I would go with misconfiguration as the most likely version. But the only "small" question is what and where.

 

[Scarpozzi]

So it looks like /dev/disk/by-uuid/c6d0a763-50c0-4072-a72f-6286ec73709b
is somewhere in your configuration and has been removed. It could have been a removable device that was there when Ubuntu was installed.

Ubuntu uses UUIDs these days to identify partitions rather than assigning them sda, sdb, sdc, names since they can change so easily in dynamic environments. The UUID is more of a lock to the actual hardware and they place labels on the device to help make it easier to read.

I'd glance at fstab:
cat /etc/fstab

and see if you see a reference to that UUID.

To list all your system UUIDs, you can try these commands:
sudo blkid


And this command will search your root filesystem to list them.
ls -l /dev/disk/by-uuid/

None of those three commands will hurt your system. They are all just to give you more information.

 

[grigory]

Thanks for your reply!

Those commands are useless when I'm dropped into BusyBox shell. The system doesn't simply see sdb (external disk with Ubuntu on it). And the reason why I have the shell is probably because I put GRUB2 on sda (the internal disk with W10 on it). That's all there's to it!
The only real question is WHY I have to go through the reboot, so the sdb would actually kick in.