Hey, John. On Monday, June 24, 2013 08:13:09, John Mort wrote: > I had a strange thing happen to me this weekend. I have an old thinkpad > t20/t21 frankenstein that I've been forcing to stay alive by canabalizing > parts from other thinpads of the same model over the years. I initially > set it up as an ubuntu server install, but later added GNOME so I could > remote desktop into it. I run the updates on it regularly, but it doesn't > get rebooted very often. > > This weekend I was doing some work in the room it's in and accidentally > unplugged it. Since the battery on it is shot, it went right down. When I > tried rebooting the initial kernel selected in GRUB--called something like > linux-kernel-pae--failed to boot the machine, and it did that kernel panic > thing where the LEDs start blinking together.
This sounds unusual. One of the ways I've seen this happen is when the booting kernel can't find the root filesystem, and often that happens because of a missing or malformed initrd image, which is supposed to be built (and/or rebuilt) during the kernel package installation. > I kept rebooting, working my way down the list of kernels until one got me > back to my desktop. Ran updates again to see if a new kernel was available > and saw that I was up to date, but a number of packages that shared the > name of that first kernel on the list had been held back. So I manually > used apt-get to ull down that package, hoping it would enable that first > kernel on my list to just work and make any future rebooting not need any > manual intervention. > > Instead, when I rebooted, I got that GRUB 1.99 recovery command line that I > never have any success with. This again is unusual; this sounds like Grub couldn't find the configuration or couldn't understand the filesystem. > So I tried googling and playing with that > command line anyway, and failed as usual, and then checked my notes. In > the past I've booked up with a live CD and used that to fix grub somehow, > but I didn't take good notes on how to do that. Usually you do this to install the boot loader into the MBR, but that doesn't sound like the problem here. [Because it does initially boot.] Here it sounds like there's a configuration error, perhaps concerning the root filesystem UUID, such that Grub can't find the configuration files after it boots up. > So I decided to try that > Boot Repair live CD rather than blowing my whole weekend relearning how to > fix grub. Boot Repair didn't seem to work though, as the display was all > garbled and I couldn't get it to display on an external monitor. Grub can be configured in /etc/default/grub to use a console window rather than a graphical mode, but you need to run 'sudo update-grub' afterwards to get this to be active; this should also rebuild the /boot/grub/grub.cfg configuration file at the same time, which also gives you an opportunity to see if there's an error with that too. > So I popped in the live CD and the screen refused to come up at all. I > tried this several times but I wasn't even getting the BIOS screen, so I > figured the machine was probably dead. I had an old thinkpad R51, and > swapped the harddrive from my T20/T21 into that to see if I could get > lucky. The computer booted up fine, grub came up the way it should, and > the first kernel in the list--the generic-pae thing--worked perfectly. I > just had to change /etc/network/interfaces from starting eth0 to starting > eth1 and everything seems to work fine. The problem with eth0 -> eth1 has to do with udev; you can update this and make the device eth0 again by modifying /etc/udev/rules.d/70-persistent-net.rules usually these rules name ethernet devices based on MAC address of the device, so when the MAC addresses changed that's why the device name changed with it. > So, I thought this was kind of interesting. I didn't really get to do > anything to fix GRUB. Moving the hard drive from one machine to the other > seemed to fix it though. How could failing hardware cause GRUB to boot > into that emergency command line? There's probably a circumstance where this is possible, but there isn't enough information to come to the conclusion that this is specifically what happened here. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) Vassar College Jul 10 - Mad Science Fair - Open Hardware Expo Aug 7 - Scripting Your World with Python Oct 2 - OpenFlow: Open Standard for Networking Hardware
