[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: i've grubbed up a machine



On Saturday 19 February 2005 10:58, charlie derr wrote:
>I'm running a relatively recent sarge (upgraded fully within the
> last month - it had been woody for a few years prior)
>
>I thought I'd use grub instead of lilo (because I'm trying to figure
> out some of the more advanced features and took a reboot
> opportunity to install it prior to doing any more new kernels).
>
>Unfortunately I have a large hard disk with a single partition, and
>didn't read carefully enough before proceeding.
>
>After "apt-get install grub; grub-install /dev/hda ; update-grub"  I
>thought I'd be fine (having done this sequence on several other
> machines over the last few weeks).   But when I rebooted I got
> "grub Error 18" which I've learned means that grub doesn't like it
> when there's no support in the BIOS for the large drive.
>
>
>The way my disk is partitioned, hda1 is a small swap partition
> (which I could presumably steal some space from in order to make a
> new boot partition) and hda2 has many Gigs mounted @ /   (or it
> should if I could boot)
>
>
>So I thought I'd re-run lilo (from a rescue CD), but I made a
> mistake there too.  Thinking I had a "salvare" CD in (debian-based)
> I mounted hda2 and then chrooted into it (but didn't mount /proc or
> anything, so it still had info from the boot cd there I presume (or
> none at all?) -- i'm not actually sure how relevant that is).
>
>The rescue CD I actually had in was Trinity (1.1 build98 i think?)
> which looks to be Redhat based.
>
>After running lilo from my chroot (which seemed to find my 6 or so
>kernels in boot properly just as update-grub had previously) I now
> get a kernel panic on reboot.  (seems to be looking for a reiser
> file-system somewhere and dying, don't know what that's about)  
> Maybe there was an issue with mismatched lilo versions, maybe it
> was something else.  I'll transcribe the messages that appear on
> the screen prior to the kernel panic (doesn't matter which of the
> kernels I try, they all seem to die at about the same place) if
> anyone needs it (it seems this post is long enough already though).
>
>I haven't actually changed any info in the partition table (just the
>MBR) with any of this (or at least I'm pretty certain that my hda1
>(swap) and hda2 (ext3) are still fine, as I can still mount hda2
> when I boot from a rescue CD).
>
>My question is, what is the safest way to proceed with repairing
> things (I'd actually be happy to go back to lilo if that's safer,
> but I'm not against splitting a small boot partition our of swap
> space and getting grub to work properly).  But I thought that in
> addition to trying to investigate my options on my own, that since
> there're potential downsides that I don't want to contemplate (lots
> of unbacked-up data on hda2 that i'd prefer not to lose), it seemed
> worth asking some experts.
>
> thanks so much in advance for your time,
>  ~c
>
>of course pointers to relevant docs are just as appreciated as
>straightforward advice (if i'd read more before starting I obviously
>wouldn't be in this quandry)

I'm not 100% sure that fdisk will allow you to delete a partition
that is not the last currently defined partition.  I think what
I'd do is run fdisk, do a 'p' and write down everything it shows
for a backup in case you have to delete hda2 in order to get at hda1.

Then see if you can delete hda1 without effecting hda2.  If you
can't, then its plan B.  Delete hda2 while making offerings to
your favorite Diety.

Setup about 100 megs (anything less will really cramp you if you many
many bootable kernels in there) as hda1, filesystem ext3, then setup
from end+1 as the start of hda2, to the end of the original hda1 as
hda2 & change its filesystem to linux swap.

Then, if you had to destroy hda2, and I suspect you were forced to,
re-create it as hda3 using the identical figures copied from the
original 'p' output for hda2.

Then w(rite) the mbr, exit fdisk, reboot to the rescue cd to sync
the mbr data in memory, mount hda3 as /mnt/slash and go fix your
/etc/fstab so / is now on hda3, and swap is on hda2.

Then mount hda1 as /mnt/boot, copy the contents of the old /boot dir
on hda3 to the /mnt/boot partition.

Then, since you will now have a boot partition, you'll need to re-adjust
grub.conf (menu.lst in debian) to reflect that, meaning that you'll now
need something that looks like this, paying attention to the paths:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda3
#          initrd /initrd-version.img
# boot=/dev/hda1
default=11
fallback=10
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz

# 0
title Red Hat Linux (2.4.18-14)
 root (hd0,0)
 kernel /vmlinuz-2.4.18-14 ro root=LABEL=/ hdc=ide-scsi
 initrd /initrd-2.4.18-14.img

# 1
title Red Hat Linux (2.4.23-pre8)
 root (hd0,0)
 kernel /vmlinuz-2.4.23-pre8 ro root=/dev/hda7 hdc=ide-scsi

# 2
title Red Hat Linux (2.4.22-pre10)
 root (hd0,0)
 kernel /vmlinuz-2.4.22-pre10 ro root=/dev/hda7 hdc=ide-scsi vga=ask

# 3
title Red Hat Linux (2.6.10)
 root (hd0,0)
 kernel /vmlinuz-2.6.10 ro root=/dev/hda7 vga=ask

# 4 
title Red Hat Linux (2.6.11-rc3-V0.7.38-00-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc3-V0.7.38-00-RT ro root=/dev/hda7 vga=ask

# 5
title Red Hat Linux (2.6.11-rc3-V0.7.38-01-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc3-V0.7.38-01-RT ro root=/dev/hda7 elevator=cfq

# 6
title Red Hat Linux (2.6.11-rc3-RT-V0.7.38-03)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc3-RT-V0.7.38-03 ro root=/dev/hda7 elevator=cfq vga=ask

# 7
title Red Hat Linux (2.6.11-rc3-RT-V0.7.38-06)
 root (hd0,0)
 kernel /vmlinuz-2.6.11-rc3-RT-V0.7.38-06 ro root=/dev/hda7 elevator=cfq vga=ask

# 8
title Red Hat Linux (2.6.11-rc3-RT-V0.7.38-09)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc3-RT-V0.7.38-09 ro root=/dev/hda7 vga=ask

# 9
title Red Hat Linux (2.6.11-rc3-RT-V0.7.38-10)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc3-RT-V0.7.38-10 ro root=/dev/hda7 elevator=cfq vga=ask

#10
title Red Hat Linux (2.6.11-rc4-RT-V0.7.39-01)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc4-RT-V0.7.39-01 ro root=/dev/hda7 vga=ask

#11
title Red Hat Linux (2.6.11-rc4-RT-V0.7.39-02)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc4-RT-V0.7.39-02 ro root=/dev/hda7 elevator=cfq vga=ask

#12
title Red Hat Linux (2.6.11-rc2-V0.7.36-03-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc2-V0.7.36-03-RT ro root=/dev/hda7 elevator=cfq vga=ask 

#13
title Red Hat Linux (2.6.11-rc2-V0.7.36-04-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc2-V0.7.36-04-RT ro root=/dev/hda7 elevator=cfq vga=ask

#14
title Red Hat Linux (2.6.11-rc2-V0.7.37-01-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc2-V0.7.37-01-RT ro root=/dev/hda7 elevator=cfq vga=ask

#15
title Red Hat Linux (2.6.11-rc2-V0.7.37-02-RT)
        root (hd0,0)
        kernel /vmlinuz-2.6.11-rc2-V0.7.37-02-RT ro root=/dev/hda7 elevator=cfq vga=ask
#16
 title DOS
 rootnoverify (hd0,1)
 makeactive
 chainloader +1


Thats what I meant by lots of bootable kernels, thats 102 megs worth
in a 250MB partition. :)

As you can see, I'm not using initrd's in my site built
kernels, no real need to here.  And I've not used labels either
as that can get confusing if anything changes.  To use them,
you *will* have to use an initrd.

Caveat: I've done a similar operation once or twice, but don't take
my word as gospel, no guarantees offered, not even if your cat has
a litter of black lab puppies.

Good Luck!

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.33% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.



Reply to: