[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