MandrivaThis Forum is for the discussion of Mandriva (Mandrake) Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have been experimenting with SimplyMepis and Libranet on a spare hard drive.
During the experimentation something happened to my Mandrake 9.2 drive and it won't boot from the hard drive anymore except when I choose "hard drive" option from the Mandrake rescue CD that I, thank goodness, prepared some time ago.
When I try to boot from the hard drive (the bootloader is installed in the MBR of /dev/hda), I get the message from BIOS saying "Looking for boot record on IDE1" and a second later it says
"OK," which is normal procedure. But then it just hangs, though it does sound like the hard drive may be churning away---hard to tell.
So I reboot with the rescue CD in the CD-ROM drive, and choose "hard drive" as the boot option and immediately it goes to the screen where you can choose what kernel you want, just as it normally did booting from hard drive in the first place.
What's lacking, and how can I fix it? I tried "upgrade" from the distro set of CD's, which often fixes lots of minor problems, but it had no effect on this one. I tried reinstalling the bootloader after I got booted up, as root:
lilo -v -b /dev/hda
and it made no difference next time I tried to boot.
Out of ideas at this point! I'd rather not do a whole new install because it takes about five hours to get all my apps back and installed correctly every time I do that.
But I'd rather not have to rely on a CD-ROM every time I want to boot, either--though I intend to manufacture a couple more of them now, just in case!
Originally posted by opjose What happens when you merely type lilo while logged in?
Also post the output of
fdisk -l /dev/hda
Output of mount:
[root@bodhisattva jon]# mount
/dev/ide/host0/bus0/target0/lun0/part1 on / type ext3 (rw,noatime)
none on /proc type proc (rw)
none on /proc/bus/usb type usbfs (rw)
none on /dev type devfs (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/ide/host0/bus0/target0/lun0/part6 on /home type ext3 (rw,noatime)
none on /mnt/cdrom type supermount (ro,dev=/dev/scd0,fs=udf:iso9660,--,iocharset=iso8859-1)
/dev/ide/host0/bus0/target1/lun0/part1 on /prime_backup type ext3 (rw,noatime)
/dev/ide/host0/bus0/target1/lun0/part5 on /store_1 type ext3 (rw,noatime)
/dev/ide/host0/bus0/target1/lun0/part6 on /store_2 type ext3 (rw,noatime)
/dev/ide/host0/bus0/target1/lun0/part7 on /store_3 type ext3 (rw,noatime)
/dev/ide/host0/bus1/target1/lun0/part1 on /mnt/libranet type ext3 (rw)
I see nothing unusual in your configuration files or information returned.
On the other hand it appears that the BIOS is not locating Lilo correctly on the drive since you never see the Lilo screen.
This (to me) normally indicates that the bios believes that the MBR is located one place on the drive, when it actually is located elsewhere.
This can happen if the state of LBA mode is toggled differently (accidentally, or by another OS) and then the MBR re-written.
So while the Linux boot from the CD may be getting the actual geometry used when the drive was set up, the BIOS now sees a slightly different configuration and is looking (and finding!) a different MBR record which in turn is erroneous.
Try toggling the LBA states for the drive in the bios then COLD boot after each change.
If this doesn't help, again try running Lilo after setting a different LBA mode, booting to Linux via the CD and running Lilo again.
I've had a situation wherein the drive's geometry block has been modified by a utility when the bios was configured one way, then when the drive was reconfigured (after a dead cmos battery) it was not able to work properly due to the old geometry data.
Nothing I could do would eliminate this problem except a complete drive reformat with a drive vendor utility that would zero out the ENTIRE drive. Since this also took care of the erroneous MBR and sectors things worked again after doing so.
But this was very extreme!
Remember though, that since you can boot into Linux, it's not too difficult to backup your current configuration completely so you do not have to do a lot of work to get everything back to a working state.
Boot up Linux via the CD.
tar off the /etc directory
tar -czvf savedetc.tar.gz /etc/*
Save the contents of your RPM installation...
rpm -qa > rpmfiles.lst
Then boot from a Live CD, and tar off either your entire partition(s) or just tar off your /home directories to another media.
Once done, reformat and re-install your hda drive as close as possible to what you have now.
Then once you have a rudimentary Linux system running first re-install all of your RPM's to exactly the same state using
urpmi < rpmfiles.lst
Next UNTAR the /etc folder back to /etc
tar -xzvf savedetc.tar.gz
And run lilo again and reboot.
Finally restore your home directories from their backups.
I went ahead and tried that tonight. No luck. I did a complete reinstall erasing the entire disk and placing the bootloader in MRB but it still stalls as before. I don't currently have Maxtor's handy-dandy low-level disk utility; I guess I may be able to download it and put it on CD-ROM (don't currently have a floppy drive hooked up, either). However it seems last time I checked, Maxtor only offered one that required a Windows machine. I may be wrong.
Anyway, the urpmi I have on this system won't work from redirection, so I guess I can go and put "urpmi" at the beginning of every one of the 500-some lines of that list and see if it will run that way---or just do things piecemeal as I've done many times before---takes a few hours and lots of frustration.
Got email and browser going, and that's it. Still have to boot from CD-ROM, which is not that much of a deal. Maybe I better just leave it that way, get halfway back to normal, and hope for better days.
Unfortunately I wasn't able to zero out the disk as I lack a suitable utility for that at present. As I mentioned in the prior post, I will probably try to get one from Maxtor's site, but it seems to me they only offered one that required Windows last time I checked!
I'm almost back to normal operations already, though, mainly thanks to the handy tip you gave about restoring the /etc directory. That made a world of difference in ease of getting programs running again such as lm_sensors, power backup monitoring, and others. Thanks!
I already thought of making a script from that list of rpms, and will probably do so tomorrow. There may be no need, though--I'm almost back to where I have everything available and working again. I have a pretty simple system, where email, browsing, word processing, spreadsheet, some graphics, and some system monitoring is all I need. Lucky that way!
I intend to burn (at low speed) three or four more "rescue" disks and keep them carefully so I will presumably always be able to boot SOMEHOW. I'm sure glad I made that one several weeks ago, on the spur of the moment. The first disk of the Mandrake distribution is bootable, of course, but I don't know how you would just boot into an existing Mandrake-Linux system with it. So for me the "rescue" disk was worthy of its name.
Originally posted by opjose I'll bet google will turn up something to zero out a drive which does not need to be maxstor specific, as long as it hits the entire disk... (a maxtor utility would be better though...).
Thanks! You've devoted a lot of time to helping me with this, and I really appreciate it. I didn't even know the /etc directory could be successfully restored and work--probably because my attempts in the past to restore system info after major disasters have turned out to be disasters themselves, and I figured the "volatile" information in /etc was probably at cause!
From recent experiences it looks to me like the only directory that resists restoring is /lib. I suppose because the mechanism I use for restoring it (I've tried both cp and rdiff-backup's restore function) is calling routines from there while it works.