LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 06-24-2014, 03:45 PM   #1
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
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
Code:
update-grub
and, when that did not help
Code:
grub-install
update-grub
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.
Code:
root@asus-n56v:~$ lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630M] (rev a1)
03:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
04:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 08)
 
Old 06-25-2014, 04:47 PM   #2
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,886

Rep: Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615
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.
 
1 members found this post helpful.
Old 06-25-2014, 05:50 PM   #3
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Hi Jefro, thanks for your answer.

Quote:
Originally Posted by jefro View Post
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.
How would this fit together with the fact that the issue only occurs with the crunchbang bootloader, not the aptosid one?


Quote:
Originally Posted by jefro View Post
Here is a test maybe. Remove battery and ac adapter, press power button a few times and then see if it boots.
Ok, will try that next time the issue occurs. (It did not today, after another grub-install I ran last night...)
 
Old 06-26-2014, 10:10 AM   #4
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052
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).

Last edited by ondoho; 06-26-2014 at 10:14 AM.
 
1 members found this post helpful.
Old 06-26-2014, 03:51 PM   #5
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,886

Rep: Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615Reputation: 3615
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.
 
1 members found this post helpful.
Old 06-27-2014, 12:10 PM   #6
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Quote:
Originally Posted by jefro View Post
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...
 
Old 06-30-2014, 02:25 PM   #7
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
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...
 
Old 06-30-2014, 02:28 PM   #8
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Quote:
Originally Posted by ondoho View Post
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).
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...
 
Old 06-30-2014, 08:15 PM   #9
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052
Quote:
Originally Posted by joe_2000 View Post
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...
 
Old 07-01-2014, 02:14 PM   #10
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Quote:
Originally Posted by ondoho View Post
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.
 
Old 07-02-2014, 02:37 AM   #11
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052
Quote:
Originally Posted by joe_2000 View Post
As far as I know I have to actually boot into the other system to update its grub loader.
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.
 
Old 07-03-2014, 04:08 PM   #12
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
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...
 
Old 07-07-2014, 03:23 PM   #13
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
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...
 
Old 07-13-2014, 06:12 PM   #14
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052Reputation: 6052
Quote:
Originally Posted by joe_2000 View Post
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.
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.
 
Old 07-14-2014, 03:52 PM   #15
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Quote:
Originally Posted by ondoho View Post
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)
Code:
menuentry "Linux Mint 17 Cinnamon 32-bit, 3.13.0-24-generic (/dev/sda12) (on /dev/sda12)" --class gnu-linux --class gnu --class os {
        insmod part_gpt
        insmod ext2
        set root='(hd0,gpt12)'
        search --no-floppy --fs-uuid --set=root fed6cc73-77f6-43dc-bd18-cc4ae0f73102
        linux /boot/vmlinuz-3.13.0-24-generic root=UUID=fed6cc73-77f6-43dc-bd18-cc4ae0f73102 ro
        initrd /boot/initrd.img-3.13.0-24-generic
}
Non-working Boot Option (Aptosid Grub Config)

Code:
menuentry "Linux Mint 17 Cinnamon 32-bit, 3.13.0-24-generic (/dev/sda12) (on /dev/sda12)" --class gnu-linux --class gnu --class os {
        insmod part_gpt
        insmod ext2
        set root='(hd0,gpt12)'
        search --no-floppy --fs-uuid --set=root fed6cc73-77f6-43dc-bd18-cc4ae0f73102
        linux /boot/vmlinuz-3.13.0-24-generic root=UUID=fed6cc73-77f6-43dc-bd18-cc4ae0f73102 ro
        initrd /boot/initrd.img-3.13.0-24-generic
}
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Loading initial ramdisk freeze cbeyer Debian 4 03-26-2012 03:14 PM
Loading initial ramdisk freeze cbeyer Linux - Newbie 2 03-21-2012 04:22 PM
Loading Initial Ramdisk Hang AsadMoeen Linux - Server 1 02-20-2012 05:53 PM
[SOLVED] Stuck at "loading initial ramdisk" ukernel Linux - Newbie 8 01-08-2012 04:58 AM
Loading initial ramdisk... igsen Debian 1 08-05-2011 06:33 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 05:42 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration