[Gllug] disk problems

Nix nix at esperi.org.uk
Mon Mar 13 20:05:00 UTC 2006


On Sun, 12 Mar 2006, Sean Burlington suggested tentatively:
> Hi all,
> I have a failing hard disk (my home partition seems fubared var is complaining but the rest seems OK for now)

Join the club. After I lost two disks in a month-long period I went
all-out and have now RAIDed the lot. No more disk death for *me*.

> I've copied all partions except /home to /dev/hdb1 and now want to boot from this.

OK...

> Unfortunately I seem to have ended up in a state where the system thinks /dev/hhdb1 is mounted on /
> 
> but really it's still using /dev/hda1

What is `the system'? /etc/mtab (as used by df(1)) is maintained by
mount(8) and is terribly unreliable; it's confused by mount --bind,
per-process filesystems, chroot(8), mount --move, mount --rmove, subtree
sharing, you name it, it confuses it.

/proc/mounts is maintained by the kernel and is actually reliable. What
does that say is mounted on the root filesystem? (It's the line below
the `rootfs' line, generally; rootfs is *not* the root filesystem but
the filesystem which the initramfs is located on, which the root
filesystem is mounted over the top of.)

On my system, before I had re-educated /etc/fstab, mtab generally said

/dev/sdb1 / ext3 rw,noatime 0 0

But /proc/mounts told the truth:

/dev/raid/root / ext3 rw,data=ordered 0 0

> - and it's read-only
> 
> all I've done is to edit /etc/fstab to mount the second disk as my
> root partition without mounting things like /usr which were sperate
> partitions on hda

That doesn't necessarily change a thing: it only changes what df(1)
*reports* as the root filesystem, and that only if your /etc/mtab
is *not* a symlink to /proc/mounts.

> I then used grub interactively to boot from (hd1, 1) and specified the
> kernel with parameter root=/dev/hdb1

That should have worked. I'd say you're using /dev/hdb1 unless you have
an initrd or initramfs that is ignoring root= (which would be terribly
bad form).

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list