Boot Camp
October 12, 2011 9:44 PM
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.
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.
it is
posted by mannequito at 10:46 PM on October 12, 2011
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
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
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
posted by tylerkaraszewski at 11:02 PM on October 12, 2011
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
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
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
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
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
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
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
posted by devnull at 11:44 PM on October 12, 2011
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
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
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
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
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.
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...
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
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> bootWhere 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> bootThat 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
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
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...
posted by zengargoyle at 9:14 PM on October 13, 2011
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/sda1Would 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/bootBut 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
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
really appreciate your (and everyones) suggestions!
posted by mannequito at 11:05 PM on October 13, 2011
This thread is closed to new comments.
posted by devnull at 10:40 PM on October 12, 2011