[conspire] expanded a partition

[Rick Moen]

Quoting bruce coston (jane_ikari at yahoo.com):

> trying 2get my fedora2dvd off older boxes drive, i
> expanded the partition on my production box 2get more
> space, next time booting, GAG gave me "sector boot not
> found or invalid" i can see that reiserfs w the
> kanotix cd but "grub-install /dev/hda2" didn't fix it.
> wondering if i should try expanding the filesystem
> next or more grub stuff?

First, ObSympathy:  "Bummer."

Second, mini-editorial:  I personally seldom bother with tools that
"expand" or "shrink" filesystems, because they have so many limitations
and failure modes.  For example, suppose you have a one or more filesystem
as logical drives within "extended partition" /dev/hda2:  You want to
make the last of those logical drives bigger, stealing space from
primary partition /dev/hda3.  To the best of my understanding, you
can't.  "Nondestructive" repartitioners won't do that.

And I've seen and heard about too many of those tools blowing up
filesystems while trying to manipulate them.  So, I simply don't trust
them -- particularly since I have an alternative I prefer (about which,
more below).

Third, about your booting problems:  If I understand correctly, you're
trying to use something called "GAG" (http://gag.sourceforge.net/) in
the master boot record + elsewhere in drive track zero, which you have
then handing off control to GRUB (?).  It's difficult to tell what boot
setup you're aiming at, since you don't really specify.  (I'm afraid I
don't know either GAG or GRUB very well, since I use GRUB seldom and GAG
not at all.)

Anyhow, have you considered that GAG's own data within track zero,
rather than GRUB's may have become partially scrambled by your partition
operations?  Let's review the bootloader process on x86 (the version
that applies when using conventional IBM/Microsoft partition tables, as
opposed to BSD or Solaris "slice"-oriented volume labels), as far as I
understand it:

When you turn on the computer, the BIOS's Int13h boot-handler routine
initially has control.  It reads the BIOS CMOS table to find out what
are the boot devices and in what order to query them.  It asks each one,
in the designated boot order, whether it's in a "ready" state.  (For
example, if a CD, floppy, or Zip drive doesn't have media in it, it will
report "not ready".)  The moment the BIOS code finds the first such
device (querying them in order) that reports Ready status, it loads
sector zero (512 bytes) from that device into RAM, and transfers control
of the computer to whatever is in that sector.

In the IBM/Microsoft scheme for partitioning, sector zero on track zero
of a hard drive or similar device has a predefined set of contents, by
byte count:

Byte 0 through 445 (446 bytes):  Space for initial boot code
Byte 446 through 509 (64 bytes):  The partition table:  four 
   fixed-size 16-byte entries.
Byte 510 through 511 (2 bytes):  Recently used by NT Disk Administrator
   for "disk signatures"; traditionally, unused space.

By virtue of being loaded into RAM and being transferred control by the
BIOS boot code, whatever was in the first 446 bytes is now, at this
early point in the boot process, completely in command.  Initially, all
it knows is its program space, i.e., the partition table contents and
pair of bytes at the end.  446 bytes isn't big enough for a very
sophisticated program, but you can put there something that can, as with
GAG, hunt around in, say, the other, normally completely unused sectors
of track zero, to find a secondary bootloader, load _that_ code into
RAM, and once again transfer control.  

I will make a SWAG (Silly Wild-Assed Guess), based on your brief
description, that that's the handoff that's failing -- and that
reinstalling GAG in order to reinstall its secondary bootloader will fix
it.


Now, I'm also obliged to guess (because you weren't very specific) that
GAG's second-stage bootloader is supposed to find some bootable
filesystem of your choosing (picking it on a GAG graphical menu) and
hand off control a third time, this time to GRUB, which in turn finds a
bootable kernel image, root filesystem, and inital RAMdisk.  For all I
know, you might have somehow broken that, too, but you don't really say.


Four, alternative to nondestructive repartitioners:  Since I don't trust
those things, what I do when I need to "resize" filesystems on a machine
is as follows:

1.  Reboot the machine to be resized from a Tom's Root-Boot floppy,
LNX-BBC mini-CD, Knoppix CD, etc.  This is so that one is certain that
the victim machine's filesystems are truly quiescent before operating on
them.

2.  Connect up a second *ix box nearby on the same LAN.  IP both boxen,
so they can communicate.

3.  Use rsync over ssh to copy file trees as needed for safekeeping --
usually, absolutely everything -- over to the second *ix box.

4.  Blow away all filesystems to be resized, using /sbin/fdisk or
/sbin/cfdisk .

5.  Make new filesystems of desired size and layout, using the
appropriate mkfs.* utilities.

6.  Copy back contents using rsync over ssh.

7.  Rewrite bootloader information.  (In my case, this means just
mounting the HD's root filesystem onto the maintenance disk's /mnt, then
doing "lilo -r /mnt".  Done.)

8.  If necessary, correct /etc/fstab, to account for changed filesystem
device names.

9.  Reboot.


Using this regimen, my data are safely backed up at every step, and I
put them onto freshly made-from-scratch filesystems, instead of ones
that have been worked over by resizing utilities.  By preference, I
actually blow away _all_ partitions before remaking any of them, and,
just to make sure everything is clean, do "dd if=/dev/zero of=/dev/hda
bs=512 count=1" to absolutely zero out the entire sector zero contents.
Only _then_ do I lay out a fresh partition table and fresh partitions.

Works for Me.<tm>

-- 
Cheers,                        
Rick Moen                         This .signature intentionally left blank.
rick at linuxmafia.com