boot sometimes process gets stuck after loading initial ramdisk
 

My Laptop sometimes won't boot any linux distro. Let me try to summarize all information that seems relevant.

The Laptop (Asus N56V, see lscpi output at the end of this post) has an UEFI Bios without Secure Boot. I have several distros installed on it (Crunchbang 11, Aptosid, Mint 17, Slackware, openSUSE) and a Windows partition. I have a working UEFI Bootloader configuration from the Windows install (preinstalled) as well as for Aptosid and Crunchbang (installed by me).

The main boot loader I am using is the Crunchbang one, since Crunchbang is my main system. Im a using the grub-efi-amd64 package and grub recognizes all Linux distros just fine.
The same is true for the UEFI Bootloader installed from within the Aptosid System.

So far so good. No comes my problem. Sometimes, when I boot from the Crunchbang bootloader the screen will just go black after selecting the menu entry in the grub menu and stay like that forever. No booting. Strangely this is true for ALL distros in the grub menu. None of them will boot. The only thing I see before the screen goes black is a split second where it says "loading initial ramdisk". When this happens, it happens reproducibly. So resetting (either hard reset or Ctrl-alt-del) the computer a couple of times and trying different grub menu entries will always end up with the same result. However, when I try again the next day it might work again... or not.
If however I boot from the Aptosid UEFI boot loader ... no problem for any of the distros. Also the Windows boot loader will work fine.

After a failed boot attempt from the crunchbang boot loader and a subsequent boot from the aptosid boot loader into the crunchbang system there are no log files in /var/log from the previous (failed) attempt.

The only ideas I had to fix this where running
and, when that did not help
as root in Crunchbang. The second attempt fixed it yesterday, but the issue came back today.

I have no idea what else I could try to debug this, any help appreciated. I would really like to keep using the crunchbang bootloader as I don't want to have to boot into aptosid to run update-grub after every kernel update.

In case it's relevant see lscpi output below, do let me know if any information is missing.

If you say it fails and then sometimes the next day it works then I'd suspect esd damage or some saved state in some or many gates.

Some device is being locked electronically.

Here is a test maybe. Remove battery and ac adapter, press power button a few times and then see if it boots.

Hi Jefro, thanks for your answer.

How would this fit together with the fact that the issue only occurs with the crunchbang bootloader, not the aptosid one?


Ok, will try that next time the issue occurs. (It did not today, after another grub-install I ran last night...)

is aptosid also using grub2?

compare their versions and config files, maybe you find the culprit.

generally "sometimes" is always hard to troubleshoot and people tend to shout hardware related.

apart from that, i know you'd like to know what's going on, but if it's not broken don't fix it, right? just use the aptosid bootloader. kernel updates aren't that frequent on debian stable (=crunchbang).

I can't predict what gates can have a state held.

The fact that you can have it correct by waiting is the clue to esd.

Ok, thanks for the additional info. Will report back next time when this occurs with the results of removing battery etc... For the moment it seems to behave itself. Apparently the second grub-install fixed something that the first did not...

Ok, so removing the battery and power cable and pressing the power button for a couple of times did not help. However, a grub-install and update-grub again fixed the issue immediately. Again the aptosid bootloader had no problems...

Hi ondoho, sorry for answering to your post late, I had overlooked it previously.
Good idea to compare grub versions / config files, I'll take a closer look.

Note I am using a self-compiled kernel on crunchbang and I recompile it for every patch, which is pretty often. So I definitely want to get the crunchbang bootloader working correctly again...

it seems to me that editing a file on another partition is peanuts compared to compiling your own kernel...

As far as I know I have to actually boot into the other system to update its grub loader. While that is certainly not difficult, it's still annoying to do.
In contrast, the kernel compilation process is fully automated by scripts I made for that purpose.

not with grub.
as i said, you simply edit the grub.cfg on that partition.
and i guess that you have to do some check-up after the kernel compilation anyway, so...

but of course i can understand that you want to get that solved.

I am digging into the whole grub logic at the moment. The funny thing is that both grub installs are done with the same packages, and the created menu entries contain the same commands. So it seems to be something with the efi executable, not the grub.cfg. (which also fits with the finding that grub-install helped a couple of times)

Now, there is another reason why I can't stick with the Aptosid bootloader. I have another distro (Mint) on that laptop which isn't properly booted by the aptosid bootloader. It ends up in software rendering. The crunchbang bootloader boots it properly, if it boots at all. I use Mint for online TV, so I definitely need graphics working right in there.
I short, I really want to use the crunchbang bootloader.
Or, as an alternative, I might try to install yet another bootloader from within Mint. We'll see how that goes...

I found a solution to the first part of my problem. The update-grub command is just a shell script in /usr/sbin.
In Crunchbang I added a line that copies the resulting grub.cfg from /boot/grub/ to the same directory on the aptosid partition. Now the Aptosid grub menu is using the same config as the crunchbang one, and is updated when I run update-grub from within crunchbang.
Just to be on the safe side I also modified the update-grub script in the aptosid system to do nothing except writing a warning to stdout that it is disabled to protect the grub.cfg written by crunchbang.

So now I could use the Aptosid bootloader without ever having to boot Aptosid to update the menu after kernel updates.
The part I am still struggling with is that the Aptosid bootloader is unable to boot Mint properly. It only boots into recovery mode, with Hardware rendering not working. It doesn't even load the drivers to get the mouse working. I scanned the log files in /var/log for error messages but couldn't find anything. (Any ideas what I should look for appreciated).
One suspicion I have is that this might be an architecture issue. This is a 64bit machine, and the Mint install is a 32bit one. (I found some wine applications to be easier to get to work if you don't have to mess with multilib)
But then again the crunchbang boot loader doesn't have any issues with that.
I also tried installing an efi bootloader through the Mint install itself. I tried both packages gruf-efi-ia32 and grub-efi-amd64. The efi executable produced by the first one does nothing at all. When I select it in the efi menu nothing happens... The second (grub-efi-amd64) lets me boot Mint, but again only into recovery mode.

Very weird all this...

again i would guess that the solution lies within mint's own grub.cfg - it probably uses some kernel command line options that aptosid cannot reconstruct.

The boot loader I installed from within Mint does not do it properly. The only one that does is the Crunchbang bootloader. And I copy pasted the grub.cfg it uses to the Aptosid /boot/grub/ directory. So it's identical:

Working Boot Option (Crunchbang Grub Config)
Non-working Boot Option (Aptosid Grub Config)