MEPIS Community Forum

Looking for knowledge, or opinions.

I currently have Mepis 11, Squeeze, and two installs of Wheezy—I use one of them for real, and the other for testing.

The problem: For the last few days both Wheezies take over a full minute to load the kernel. Once that's done, things proceed as they normally should, and everything works fine. There's nothing in the logs about it because obviously logging doesn't start until the kernel takes over.

I have successfully evaded GRUB2 up to this point. I boot all distros from a small Mepis boot partition on sda16. Some of the updates to Wheezy this week were for GRUB2, and that's when the problem started. I mention that because I'm suspicious that GRUB2 may be the problem with my current boot scheme, and since the upcoming M12 is going to use GRUB2, perhaps my boot scheme is going to become untenable. BTW, my Wheezies are ext4, everything else is ext3.

Thoughts?

My sid install, which started out as a Mepis 11 install, is still using the original grub and I'm not experiencing slow boots.

It might also be related to updates to sysvinit (http://packages.debian.org/source/sid/sysvinit) though the latest updates (to initscripts) that caused problems for some sid users haven't yet moved into Wheezy.


edit: I should clarify about the grub I'm using. I'm still using a legacy type of grub (aka GRUB1, grub-legacy, whatever you want to call it).

I have two grub related packages installed:


The grub-common package that's installed is the sid version


The grub-gfxboot package is from the M11 install I started with.

Thanks.

I apparently have 1.99.2 0 at the moment.

Maybe GRUB isn't even the culprit. It just seemed like a good place to start.

I use Wheezy at sda13 to see if updates break anything. If all is well I go ahead and update Wheezy at sda7. About ten days ago this boot hangup happened after an update on sda13. I didn't like it, but decided to just go ahead with sda7, but that one did not malfunction, so I copied it to sda13. They've both been fine until now. Now they're both doing it.

You could analyse the boot process by installing bootchart (and bootchart-view) so you can then see what it is that is taking all this time. I doubt it has anything to do with Grub or Grub 2, which I've been using for ages without issue..My guess is the recent upgrade to insserv from the sysv init system. You might also consider adding Sid to your sources.list as there can often be some level of interdependency between the two although I can't find any documentation to support this right now!

I upgraded one of my Wheezy installs to Sid last night to see what would happen. Once Sid is up and running, it's quite nice, and significantly faster than Wheezy here. However, the long delay in loading the kernel remains.
Bootchart sounds interesting, but I suspect it won't tell me anything useful since the issue is happening before control is handed off to the kernel. I may try it anyway though. Thanks.

[Edit]

I tried Bootchart. That's a very interesting app, but as I feared it tells me nothing about what's going on prior to the kernel's assuming control.

My guess is that something in the initrd.img is hanging up. You might try rebuilding it.
This could be related to any upgraded app that builds a kernel module (such as vbox), or an upgraded video driver, which then tries to update the initrd. That doesn't always go well and it's easy to miss the error message that tells you about the failure.

You are right, of course. There have been a couple of recent kernel updates to Wheezy, and I do have vbox installed in Wheezy and Sid.

Here's what I've done, with mixed success:

• Installed dkms (I had thought it was already there).
• Updated Nvidia driver to 295.59.
• Ran /etc/init.d/vboxdrv setup.
• Rebuilt initrd.img.

This worked great for Sid, but the same steps did not work with Wheezy. I'll keep looking....

Wheezy was updated today, at least partially, to 4.8.3. I then rebuilt initrd.img (yet again) and this time it worked. The 75-second delay in loading the kernel has disappeared. I just thought I'd mention it to close out this thread.

GRUB2, which I originally suspected, is apparently innocent.

I'm marking this "solved."

i believe the problem with the slow boot was caused by DHCPD timing out trying to obtain a ip address off the network through ethernet, when the ethernet cable was unplugged. i have Debian Wheezy (testing) xfce desktop installed on a hp laptop. i do not have a "Splash" screen, so i can actually watch the booting process. up until a couple of updates ago, i had that long boot problem because the boot process was being held up because the DHCP demon could not obtain a ip address off the network through the ethernet cable. after 6 timeouts, DHCPD exited & wireless network got configured. then the boot continued from there.
it no longer does that now after the recent round of updates

That indeed can delay boot process, but in this case was not the issue.