Monday, July 18, 2011

The Continuing Adventure of Mint 11

I should have left "well enough" alone.  Mint 11 Katya (AMD 64 bit version) was running well on my Acer Inspire home PC, other than one little annoyance: when I booted, before and after the grub menu, my monitor would nag about a suboptimal resolution (and tell me that 1440x900 at 60Hz was optimal).  So I decided to change the screen resolution used by the boot loader (Control > Startup-Manager).  Now I can't swear that was the cause (cf. "post hoc ergo propter hoc fallacy"), but ever since then normal boots freeze, sometimes after the battery state is reported as OK and sometimes before.  I'm still able to get Linux up and running, but by one of a couple of circuitous routes:
  • booting into recovery mode, starting in the failsafe X mode, then rebooting normally seems to work;
  • booting into recovery mode, then using the option to reboot with a file system check routinely works, even though the file system check appears to find no problems.
I also tried the dpkg repair option after booting into recovery mode.  It found no packages but did give me the option to upgrade the system core (which I did -- another slow process).  That proved to be no help either.

Channeling my inner Sherlock Holmes, I review the facts: a change to display parameters immediately preceded the problems; booting in failsafe X mode appears to help bypass the problem.  So perhaps something in the display subsystem  is the culprit (although that does not explain why a mandated disk check gets the machine to boot properly).

A search of the Internet shows that I'm not alone in experience the boot problem, although it is unclear that what's going splat on my system is the same as what's going splat on other systems.  The author of this post, for instance, appears to have encountered multiple maladies, sufficient that he abandoned the attempt to use Mint. Someone experiencing the same symptoms with an earlier release had some success hiding the xorg.conf file.  I tried moving it (and eventually deleted it), but to no avail. Another user found success by deleting and reinstalling the nVidia driver.  I tried that (strangely slow to uninstall, very slow to download and reinstall!), but no joy for me.  At least I think not.  My first reboot after reinstalling the nVidia driver failed to make it even as far as the battery check.  So I rebooted, again in normal mode, and the system started properly.  Previously, rebooting repeatedly in normal mode failed (every boot attempt got stuck in the same place).  Is this progress? Will the beast boot normally from now on?  Only time will tell.  Meanwhile, I have to go back to doing actual work.  If anything changes or I find new information, I'll update this post.

Update #1: The day after I reloaded the nVidia driver, the machine booted normally.  So I was cautiously optimistic that maybe the reload had fixed the problem, and the hang immediately after the reload (previous paragraph) was just a last gasp of the bug.  No such luck.  The first boot this morning hung somewhere around the line saying that flushing the log to disk had stopped. I did a plain reboot, and the second attempt made it to the battery status ok line.  I did a third plain boot, and lo and behold it booted properly.  So the bug is still there, but either unsuccessful boots make some sort of progress now (write something to disk?) or else it's just stochastic (race condition?).

Update #2: Thinking that perhaps I'd messed up something in grub, I reinstalled grub and reverted something (a config file? a script?) to the package maintainer's version when asked. The next couple of boots went fine, but the bug then reappeared. So no joy there. However, after a few days of win some/lose some boots, my AMD box has gone on a tear of 30 straight successful boots. I can't think of anything I did that could account for this, and none of the updates pushed down to the machine appear to be related to booting.  So maybe Loki just remembered he had business elsewhere. My laptop, however, continues to occasionally conk out during a boot, which is probably an entirely different bug.

Update #3: See this post and this later post for additional nVidia-related issues (and possible cures).

2 comments:

  1. any luck? Same experience here - just messing up a good think I changed the startup manager display resolution to match my monitor and now on reboot I get a whole bunch of text bootup information and then it hangs... can't get into GUI linux mint 11 at all...

    ReplyDelete
    Replies
    1. The problem never reappeared after those 30 straight wins I mentioned in update #2, and I don't know why (although updating the NVidia driver might be the reason -- but then again it might not).

      I ran into a different, but possibly related, problem later on where the X server would spontaneously reboot, but then I was at least getting into X and seeing my desktop on a consistent basis. I wrote that one up here. The solution was a script I downloaded to facility updating the NVidia drivers.

      If you can download that script on another machine, copy it over, and run it in a shell, it might help.

      You might also have a look at this thread, where someone got lucky by editing the grub config file (/boot/grub/grub.cfg). I just took a look at my grub file. The first (default) entry in my grub menu is covered by a section of the config file that starts with

      menuentry 'Linux Mint 11 64-bit, 2.6.38-10-generic (/dev/sda5)'.

      The boot command for that entry is

      linux /boot/vmlinuz-2.6.38-10-generic root=UUID=4716d78a-8a55-4d0a-a5a1-115ea1938dfd ro quiet vga=769 quiet splash nomodeset nouveau.modeset=0 vt.handoff=7

      which, lo and behold, has the nomodeset option mentioned in the thread. I don't recall putting it there, but something apparently did. If you don't mind voiding your warranty, you might try that hack and see what happens.

      Good luck.

      Delete

Due to intermittent spamming, comments are being moderated. If this is your first time commenting on the blog, please read the Ground Rules for Comments. In particular, if you want to ask an operations research-related question not relevant to this post, consider asking it on Operations Research Stack Exchange.