Can't boot anymore (goes to initramfs prompt)

[ygbss]

Hi everyone,

My problem is kinda messy, so I thank you in advance for reading through this...

I own a HP ZBook 17 G2 with a dual boot Windows 10/Linux Mint 17.3. I've had no problem so far, but suddenly this morning I wasn't able to boot into my Linux Mint anymore (but still could boot into Linux). The only thing I got was a black screen, so I got into recovery mode to try to hopefully have some more information. I apologize because my memory is a bit vague, but I seem to remember at least one (of possibly many) worrying message saying something like "Failed to load /boot/efi, press ... etc etc".

Not knowing what to do, I booted my "boot-repair-disk" USB Live key, and let it do its usual thing (which saved me a couple of times in the past). I should mention that "boot-repair" had me typing a couple of commands in the terminal during the procedure, which seemed quite unusual to me... In any case, here is the "boot-repair" report : http://paste.ubuntu.com/25989656/ . A few things about the various paritions that appear in the report :
_ sda1 is Windows Recovery partition that I've had for a while, and came with the installation of Win10
_ sda2 is my "EFI" partition as far as I understand
_ not sure what this sda3 partition is, but I think it has been here for a while
_ sda4 is my Win10 partition
_ sda5 : this one is weird : it's a ntfs partition about ~1GB big, but I don't remember it being around... and it has those weird flags (like "hidden") ; but it might be completely unrelated to my current problem...
_ sda6 is my Linux Mint partition
_ sda7 is my swap partition
_ sdbXX are partition from a second hard drive I installed a couple months ago, which actually is a hard drive from a older laptop ; it also contains several partitions, as I had a dual boot on that laptop
_ sdc1 is just my USB stick

This first "boot-repair" didn't solve the problem (still couldn't boot), but it changed a few things : I got ton of new entries in my Grub at startup (starting like "/EFI/ubuntu/....." and "/EFI/HP/...." ones), and the error messages at boot became different, something like this :

Gave up waiting for root device. Common problem :
- Boot args ....
- Check rootdelay ....
- missing modules ...
ALERT! /dev/disk/by-uuid/<big-serial-number> does not exist. Dropping to a shell !

which then brings me to this BusyBox shell....

I thought for a second that the problem might be somehow related to my second hard drive being there, and having all those partitions inside, so I removed it and reran "boot-repair", and got the following report : http://paste.ubuntu.com/25989722/

But still, no luck with my problem, I still got the errors and still couldn't boot...
One last thing : interestingly enough, after exploring, and choosing the "Advances options for Linux Mint" in my Grub, I noticed that I could boot two different kernels, which I don't think (again, fuzzy memory...) was not the case at the very beginning of this ordeal... Might have been the result of one of the command that "boot-repair" made me type ! In any case, here are the two kernel options I got :
_ Linux 3.19.0-32-generic
_ Linux 3.13.0-135-generic
So the first one is the default one that I cannot boot in... but surprisingly I can boot into the second one ! After a couple of minutes of checking, everything seems to work fine... except that I cannot access internet :-/ I tested both Wi-fi and ethernet, the laptop appears to connect to my router just fine, but I cannot reach any webpage...

And here I am, out of ideas... Thanks in advance for your help !

[JeremyB]

See the wireless script link in my signature and post results.
I would rather have you using that 3.13 kernel as 3.19 hasn't been supported for over a year now

[ygbss]

Hi JeremyB !

Thanks a lot for the quick answer !

I rebooted in Mint using the 3.13 kernel and ran your script ; I attached the output to this message.

Thanks also for the heads-up concerning the kernels ! I naively though that "bigger number is better", but it seems like it's not the case here....

[rene]

While reverting to 3.13 may be a solution, for a likely quicker one I'd run sudo update-grub while booted into 3.13 and reboot.

[ygbss]

Hi rene,

Thanks for your suggestion ! Unfortunately, I followed it and it didn't solve the issue, I still cannot boot the 3.19 kernel...

In the meantime, while booted into 3.13, I followed these instructions : https://askubuntu.com/questions/622470/ ... untu-14-04 , which allowed me to get back my internet access !

However, I am still unsure on how to proceed now... Should I just use the 3.13 kernel ? Should I remove the 3.19 kernel and forget about it ? (if yes, how do I do that ?) Should I keep trying to fix it ? (if yes, how ?) In the end, it's probably not a Grub issue right ? (since the 3.13 kernel boots fine ?)

[JeremyB]

I would delete the 3.19 kernel so then it will automatically use the 3.13
What does

Code: Select all

cat /etc/resolv.conf

result with now?

[jimallyn]

I naively though that "bigger number is better", but it seems like it's not the case here....

Some kernels are LTS "Long Term Support" and some aren't. 3.19 isn't LTS, 3.13 is.

[ygbss]

I would delete the 3.19 kernel so then it will automatically use the 3.13
What does

Code: Select all

cat /etc/resolv.conf

result with now?

I get this :

Code: Select all

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search home

[JeremyB]

That looks better than what was in the script results as I think that showed nameserver 127.0.0.53

[ygbss]

That looks better than what was in the script results as I think that showed nameserver 127.0.0.53

I see... I'll trust you on this one !

Well, I guess I just have to remove the 3.19 kernel now... This whole thing was pretty weird :-/

Thanks for all the help !

[rene]

Unfortunately, I followed it and it didn't solve the issue, I still cannot boot the 3.19 kernel...

That is fairly unexpected; the "/dev/disk/by-uuid/<big-serial-number> does not exist" error that you got made it look like a simple parameter error that update-grub would've fixed whatever the reason for it appearing in the first place may have been. If you still have the 3.19.0-32 kernel installed you can regenerate the initrd with sudo update-initramfs -u -k 3.19.0-32-generic and see if things improve upon reboot. If you do not, reinstalling that kernel through the Update Manager (View -> Linux kernels) would do so as well.

3.13 was the kernel for the original Mint 17 (although not 3.13.0-135) and 3.19.0-32 for the original 17.3. If everything works for you using 3.13 there's no pressing need to use anything else, but I would myself find it to be a bit overly old at this point. Yes, staying on 3.19 is not the best choice but Mint 17.3 also has the 4.4 kernel series available which is also LTS. Personally I would (and do) install the latest 4.4 kernel on 17.3. As of now that is 4.4.0-98-generic from October 11. Not sure why Jeremy's suggesting 3.13 instead of 4.4 though; he may have a reason so allow for him to disagree.

[ygbss]

That is fairly unexpected; the "/dev/disk/by-uuid/<big-serial-number> does not exist" error that you got made it look like a simple parameter error that update-grub would've fixed whatever the reason for it appearing in the first place may have been.

Yeah, that was my impression too ! But the fact that the other kernel works without problem is strange... The grub entries of the two kernels in /boot/grub/grub.cfg are nearly identical, the only differences being the version number of the kernel (obviously) and the fact that the 3.13 kernel has ".efi.signed" appended to the vmlinuz filename :

Code: Select all

 linux   /boot/vmlinuz-3.13.0-135-generic.efi.signed root=UUID=e8ed0146-836a-4fa2-9c59-2a39707e191b ro  quiet splash $vt_handoff 

while the 3.19 hasn't :

Code: Select all

 linux   /boot/vmlinuz-3.19.0-32-generic root=UUID=e8ed0146-836a-4fa2-9c59-2a39707e191b ro  quiet splash $vt_handoff 

If you still have the 3.19.0-32 kernel installed you can regenerate the initrd with sudo update-initramfs -u -k 3.19.0-32-generic and see if things improve upon reboot. If you do not, reinstalling that kernel through the Update Manager (View -> Linux kernels) would do so as well.

I tried your suggestion of running the "update-initramfs" command, but it didn't correct the problem... I'll try to reinstall the kernel !

3.13 was the kernel for the original Mint 17 (although not 3.13.0-135) and 3.19.0-32 for the original 17.3. If everything works for you using 3.13 there's no pressing need to use anything else, but I would myself find it to be a bit overly old at this point. Yes, staying on 3.19 is not the best choice but Mint 17.3 also has the 4.4 kernel series available which is also LTS. Personally I would (and do) install the latest 4.4 kernel on 17.3. As of now that is 4.4.0-98-generic from October 11. Not sure why Jeremy's suggesting 3.13 instead of 4.4 though; he may have a reason so allow for him to disagree.

How can I install the 4.4 kernel ? Should I simply use Synaptic ? It seems like there are many versions of the 4.4 kernel available (manly the last two digits), is there one in particular I should pickup ?

Thanks a lot rene !

[rene]

( ... ) and the fact that the 3.13 kernel has ".efi.signed" appended to the vmlinuz filename

It's fairly hard to read past that without alarm bells going of, but I sort of expect you'd have found the solution already if you had changed something regarding secure boot in your BIOS just before things bombed, so let me assume this to not in fact be related. Must say I'm foggy on what the issue could be. Clearly the UUID does exist or 3.13 wouldn't boot in the same manner, and if the update-initramfs completed without error for 3.19.0-32 it should moreover know it to exist.

Both removing and reinstalling 3.19.0-32 and the latest available 4.4 kernel you'd preferably do via Update Manager (the shield-icon in your systray). If you left-click it and chose the "View -> Linux kernels" menu entry you'll be presented a long list of available kernels, those two among them. Any currently installed kernels you can remove via the button below the list, any non-installed ones you can install via same. On reboot the newest installed kernel will be default (4.4.0-98-generic if you install that one) and you can pick earlier ones from that same "advanced options" entry in the grub menu that you've been using to boot 3.13 -- although if you're on a single-boot system and if things fix themselves you may not got that choice automatically; to get the Grub menu to appear you'd generally hold down left-shift while booting.

[hrmcrm]

Just before this problem occurred, did Windows 10 do the update to version 1709? On 2 of 2 of my dual-boot laptops, this update changed to fast startup enabled, which makes Linux boots fail. The fix for me was to boot Windows and do the following from https://in.answers.acer.com/app/answers ... st-startup

Fast startup is a feature in Windows that helps your computer start faster. You can use the following steps to disable fast startup.

Type Control Panel in the search box.
Click Control Panel.
Click Power Options.
Click Choose what the power buttons do.
Click Change settings that are currently unavailable.
Scroll down to Shutdown settings and uncheck Turn on fast startup.
Click Save changes.

Regards,
Howard

[ygbss]

It's fairly hard to read past that without alarm bells going of, but I sort of expect you'd have found the solution already if you had changed something regarding secure boot in your BIOS just before things bombed, so let me assume this to not in fact be related.

Indeed, I didn't touch any BIOS setting before this problem happened...

Thanks for the instructions for installing/reinstalling a kernel ! Reinstalling the 3.19 kernel made it possible to boot it again ! And installing the 4.4 kernel went fine, I'm using it right now and so far everything seems ok.

Just before this problem occurred, did Windows 10 do the update to version 1709? On 2 of 2 of my dual-boot laptops, this update changed to fast startup enabled, which makes Linux boots fail.

Yeah, I somehow suspect that it is related to a recent big Win10 update (the "Fall creators" update or something ?), especially since my win10 did an update the day before and I noticed this weird ntfs partition that I'm pretty sure was not here before... I've seen post on various forums about people with a similar problem that you described, but it never seemed to be exactly like my problem...

[kukamuumuka]

Yeah, I somehow suspect that it is related to a recent big Win10 update (the "Fall creators" update or something ?), especially since my win10 did an update the day before and I noticed this weird ntfs partition that I'm pretty sure was not here before... I've seen post on various forums about people with a similar problem that you described, but it never seemed to be exactly like my problem...

Windows 10 updates used to break something every now and then, so if wanting to use Windows and linux as dual-boot, the safe options for Windows are 8,1 and 7.

viewtopic.php?t=222137#p1167801

[rene]

Yeah, I somehow suspect that it is related to a recent big Win10 update (the "Fall creators" update or something ?), especially since my win10 did an update the day before and I noticed this weird ntfs partition that I'm pretty sure was not here before... I've seen post on various forums about people with a similar problem that you described, but it never seemed to be exactly like my problem...

I believe the usual issue with recent Windows updates is an additional recovery partition being created automatically, causing later partition numbers to shift up; if your Linux partitions are after the Windows ones this invalidates the grub setup. In your case this doesn't look to have been the problem; while you being able to boot into 3.13 may have been a result of the boot-repair things you did, it seems that a reinstall of the 3.19 kernel working whereas a simple update-grub nor update-initramfs did earlier means that your 3.19 kernel image was somehow corrupted.

Well, as best as I can imagine at least. Good to know things are working; I would (and, again, do) stay on 4.4 on 17.3. As to administrollaattori's advise: Windows 7 okay, Windows 8 I wouldn't, but certainly Windows 1 I'd consider to be a bit old at this point. I mean, that probably even predates kernel 3.13...

[ygbss]

I believe the usual issue with recent Windows updates is an additional recovery partition being created automatically, causing later partition numbers to shift up; if your Linux partitions are after the Windows ones this invalidates the grub setup.

I actually think that this is exactly what happened to me : if you remember my first post, the first error I got was different that the kernel problem that happened afterwards, something about the EFI and something "not being found"... Moreover, I managed to find a grub backup on my laptop and confirmed that my linux partition was originally on sda5, not sda6 : this seems to confirm the theory of the new Windows recovery partition messing things up...

As for the second problem that showed up after the boot-repair... Your guess is as good as mine ! Could have been caused by boot-repair itself, could have been an entirely different thing... The mystery remains ! In any case, thanks a ton for all your help and advice !

As to administrollaattori's advise: Windows 7 okay, Windows 8 I wouldn't, but certainly Windows 1 I'd consider to be a bit old at this point. I mean, that probably even predates kernel 3.13...

Although I do have found memories of my childhood using Windows 3.1, but I don't think the nostalgia is strong enough for me to go back to it (or even older versions of Windows) any time soon