Boot Camp
October 12, 2011 9:44 PM   Subscribe

I have a Toshiba laptop that seems to no longer like booting various linux os's. Ideas for how to fix it?

So about a month ago this computer, which had been happily running Kubuntu for years, wouldn't boot. I believe the message was something along the lines of 'no init found, try bootarg'. I googled around and it seemed that other people had had this problem with that particular version (it was an old disc of Karmic Koala). So I finally had time earlier this week to burn a copy of the latest Kubuntu - same problem. Now I've also tried regular Ubuntu as well as Debian Squeeze. In all 3 cases, the os's install and work fine, but when I reboot I get a variation on the same message.

I guess I could try something that's not Debian based but I'm really not interested in relearning Linux. And if its a choice between Windows or a new computer, I'll happily drop the $ on a new machine.

The laptop itself is approaching 4 years and has seen a lot of use and travel, so its entirely possible that its just at the end of its life, just looking for suggestions of what I could try before giving up. Thanks guys.
posted by mannequito to Technology (16 answers total)
 
Check that your bios is set to boot from the hard disk.
posted by devnull at 10:40 PM on October 12, 2011


Response by poster: it is
posted by mannequito at 10:46 PM on October 12, 2011


Can you take a photo of the full error message and post it somewhere?
posted by devnull at 10:57 PM on October 12, 2011


Quite a few people seem to be suggesting running disk verification/fix tools. You can see one solution here. Seems to be fairly common on Ubuntu variants.
posted by sophist at 10:59 PM on October 12, 2011


init is the process that the kernel starts up as soon as it loads which is responsible for starting all other processes. Being unable to find it seems to indicate some sort of disk or filesystem error. Being unable to find it repeatedly across a variety of installs seems like it could be a bad hard disk. A more complete error message might be more useful.
posted by tylerkaraszewski at 11:02 PM on October 12, 2011


Best answer: To elaborate on my previous answer:
Suppose all your debian-based installers are basically the same, at least as far as where they put their 'init' binary on the disk (or where the save the location for where to look for it). Suppose there is a bad sector on the disk in that location.

Now, when you first install, you will run an 'init' binary that's on a CD. That will install a whole OS that works correctly, and everything seems pretty much ok. Because the disk is mostly fine, you haven't yet run into your problem.

Then you reboot, and no longer using the CD, you have to find that init file, but it's gone missing or is unreadable.

I am speculating wildly, but it doesn't seem unreasonable. I'd try installing to a different hard disk if one's available, or at least running some sort of check on the disk you have. There's probably a linux live CD available with tools to do that.
posted by tylerkaraszewski at 11:08 PM on October 12, 2011


To address sophist and tylerkaraszewski's answers: please don't boot from a different live cd.

Instead boot from the installer cd, and choose "rescue broken system". Then after it has finished, make sure you remove the cd from the computer.

I would also post the exact error here though.
posted by devnull at 11:11 PM on October 12, 2011


Response by poster: Thanks. I'm trying the rescue system idea now (it appears to be reinstalling, but what the hell nothing much to lose).

If it doesn't work I will post more details on the error message. Thanks for all the answers so far
posted by mannequito at 11:16 PM on October 12, 2011


Response by poster: well, the rescue mode didn't work, but it did give me a weirder error message - basically just huge strings of numbers haha

it's late here so will probably just give one more shot at a fresh install tomorrow, and if that doesn't work screw it. thanks for everything guys.
posted by mannequito at 11:36 PM on October 12, 2011


Really though - post error messages. Randomly reinstalling is a sledgehammer approach. You probably just need to tweak the grub boot parameters.
posted by devnull at 11:44 PM on October 12, 2011


Response by poster: Sure but whatever the resue operation did changed it, it really is just a long string of numbers that drops me down to command line. From there I tried the fsck suggestion in the blog linked above and it says the drive is clean.

I always try and avoid the reinstallation option as well, but in this case I have the time and there's nothing at all to lose since it was already a fresh install. Might as well try again, either it works or I'll be able to report the exact msg.
posted by mannequito at 12:54 AM on October 13, 2011


Response by poster: In case anyone is still reading this, a new installation of Debian produced more or less the same problem. Exact msg:

Loading Linux 2.6.32-5-686...
error: couldn't read file.
Loading initial ramdisk...
error: you need to load the kernel first.

Press any key to continue..._


And pressing any key bring me back to the Debian splash screen ... so I don't know, given the various problems across distros makes me thnk it is an actual problem with the hard disk, but I'm obviously far from an expert. Thanks for all the suggestions either way.
posted by mannequito at 1:26 PM on October 13, 2011


Best answer: Are you using a USB stick or USB cdrom when installing? It almost sounds like your BIOS is doing some funky drive re-mapping causing the installation process to think that it is installing on a second drive and thus configuring GRUB to look in the wrong place. (I've noticed on occasion when booting from my netbook's SD reader that the boot media gets mapped to sda). You might try resetting your BIOS to factory defaults (might help, might not).

Assuming there isn't a real hardware problem somewhere it may be possible to recover from a messed up GRUB configuration, but it may be a bit tricky. Assuming you still have the Debian install...

When it first boots and the menu displays hit the up/down arrows a couple of times to stop it from automatically booting the first menu entry. Read the notes at the bottom of the screen and press 'c' (I think) for a command line. You should get a 'grub>' prompt. Now the fun begins.

Since you saw the 'Loading Linux 2.6.32-5-686...' message, grub was able to find your '/boot/grub/grub.cfg' file, so at least that works. If you're lucky what follows will work as well.
grub> ls
(hd0) (hd0,msdos5) (hd0,msdos1)
That is the output of my default-ish Debian install. One hard disk (hd0), one real partition (hd0,msdos1), and one swap (hd0,msdos5). You can also try 'ls <TAB> <TAB>' and it should spew out a bit about the partitions it finds. If everything is in order...
grub> ls /
bin boot dev etc ...
Just like in a Terminal, 'ls /' should show you the root of the files system. Now this is from a *working* GRUB install, so this is where your install may fall apart.... If so, try doing things like...
grub> ls (hd0,msdos1)/
grub> ls (hd0,msdos2)/
grub> ls (hd1,msdos1)/
Until you find a partition that has a 'boot' directory, or if you somehow installed with a separate boot partition, you should find a partition that has 'vmlinuz-2.6.32-5-686', 'initrd-2.6.32-5-686', and so forth, and a different partition with 'bin', 'etc', 'dev' that is your root file system. (Confused yet?)

What you want to do is give the proper commands and locations to GRUB that are needed to actually boot your system. For me it is simple...
grub> linux /boot/vmlinuz-3.0.0-2-486 root=/dev/sda1 ro
grub> initrd /boot/initrd-3.0.0-2-486
grub> boot
Where the 'root=/dev/sda1' tells the kernel that the '/' file system is on the 1st partition of the 1st hard disk (sda) and 'ro' is read-only (don't worry about that part). What you might have to do would be more like this...
grub> linux (hd0,msdos1)/boot/vmlinuz-2.6.32-5-686 root=/dev/sda1 ro
grub> initrd (hd0,msdos1)/boot/initrd-2.6.32-5-686
grub> boot
That is the bog standard one hard disk, one partition boot incantation.

This is much easier than it sounds, especially if GRUB is working enough for the TAB completion is working. You just need to find the '(hd#,msdos#)/somewhere' that has a 'vmlinuz' and 'initrd' of matching versions to pass to the linux/initrd commands, an the 'root=/dev/XXX' to pass to the kernel that tells it where the '/' of the file system will be found.

If you can get the 2 commands 'linux', 'initrd' all sorted out with the right 'root' device, your system should boot right up. Then you can probably re-install GRUB somehow, 'grub-setup' or maybe 'update-grub2' and hope that it gets configured correctly from the running system.

GRUB2 is a really fucked up beast of a bootloader with over-complicated by the OS distro configuration system (because it tries to support every fucking thing under the sun like finding and booting windows partitions, supporting bizarre file system formats, pretty splash screens, graphics modes, fonts, and other random crap). I think it's getting confused when installing and building a configuration that is trying to find the vmlinuz/initrd/root on the hard disk as it's re-ordered drive number when booted from some sort of installation media. (looking for sdb instead of sda for example).
posted by zengargoyle at 7:11 PM on October 13, 2011 [1 favorite]


Response by poster: wow, appreciate that zengargoyle

looks like you were right in your commands, but when I tried this:
grub> linux (hd0,msdos1)/boot/vmlinuz-2.6.32-5-686 root=/dev/sda1 ro
i received error:couldn't read file
then, trying this:
grub> initrd (hd0,msdos1)/boot/initrd-2.6.32-5-686
i get error: you need to load the kernel first

so basically something is going wrong with the kernel on install, and its not finding it afterward? that's my amateur assessment.

anyways .... oh linux, just when I thought I had you figured out.
ps I did try resetting the bios to defaults, no dice
posted by mannequito at 8:15 PM on October 13, 2011


If you could TAB complete that vmlinuz file path and it failed then you're pretty much at the bad hard disk stage. (grub has loaded configuration and file system files, can find the kernel's entry in the file system, but can't read the actual data properly.) The initrd line wouldn't work unless the kernel was loaded, so that particular error is expected. I'm surprised and a bit miffed that the installer didn't fail or throw up some errors somewhere, but they've been so user-friendly-ified that they're just plain stupid.

The Debian installer *might* have an option in the disk partitioning stage to check for bad blocks. I would find a system diagnostics CD to do a real testing of the disk. Or just drop into the installers CLI shell (usually you can hit Alt-F2 or some other key to get a root prompt), or use a LiveCD to get a prompt. Then you can check by formatting with the "check for bad blocks" option...
# mkfs.ext2 -c -c /dev/sda1
Would do a slow read-write-read test during a format and complain if it had problems. Before that I'd probably try mounting the disk and poking around...
# mount /dev/sda1 /mnt
# ls -l /mnt/boot
But it's looking more like hardware now that several different distros have failed in slightly different ways (depending on which part of the boot process hit bad information and croaked). And just loading a kernel (that could be found) failed. It's probably a bad disk.
posted by zengargoyle at 9:14 PM on October 13, 2011


Response by poster: well so it goes. not such a disappointment, I suspected that when the multiple installations were failing.

really appreciate your (and everyones) suggestions!
posted by mannequito at 11:05 PM on October 13, 2011


« Older How do I cope with an injury?   |   Help me print a poster for cheap Newer »
This thread is closed to new comments.