xfs
[Top] [All Lists]

Re: XFS and root shell

To: Nathan Scott <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: XFS and root shell
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Tue, 2 Jan 2001 02:01:20 +0100 (CET)
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <10101021059.ZM6627@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Tue, 2 Jan 2001, Nathan Scott wrote:

> On Dec 20, 12:03am, Seth Mos wrote:
> > Subject: XFS and root shell
> > Hi,
> > 
> 
> hi Seth,
> 
> [just catching up on some old mail]
> 
> > If I have an ext2 filesystem that can not be mounted on boot time it will
> > bring up a root shell for system maintenance. How difficult is it to make
> > XFS do the same.
> > 
> 
> i think the consensus was this shouldn't be too hard.
> i'll make xfs_repair install into /sbin by default (from
> its current home in /usr/sbin) shortly.

That would be great, and 2.4.0-pre is out! :-)
 
> > I booted and older kernel (older style log) did a dirty reboot and the
> > newer kernel could not mount /home because of the older log style.
> > Ofcourse xfs_repair nows what to do but i did not notice untill I tried to
> > log in.
> > 
> 
> this is really a bit of an unusual one ... the log format change
> wasn't really corruption (which is what xfs_repair is out to
> fix), it was a premeditated ondisk format change comparable to
> the conversion from little to big endian in some ways (there was
> plenty of mailing-list warnings etc at the time).  It is just a
> coincidence that the new xfs_repair can fix it - it simply blows
> away the entire (clean, old) log & then inserts a new dummy log
> record at the log head (ie. creates a new format log).

I needed a test5 kernel in order to burn CD's. Otherwise I wouldn't even
have noticed it. I sent another post about this as well.

I have had the kernel get kupdate in a D state (BAD I know).
This caused the filesystem to be unable to sync. After that the FS is
dirty and can cause the kernel to not be able to recover it on the next
boot. That's when I noticed that:

1. It does not drop you to a shell.
2. The xfs_repair binary was not in /sbin
3. A bootdisk with a XFS kernel alone would net help get /usr back
4. I was screwed ;-)

In the meanwhile I have taken out 64MB of ram on my home machine and
have been unable to reproduce it since. So It appears that one DIMM is
somewhat schizo. It is somewhere around the room now, I'm not sure where.
I can also rule out power supply problems. (2x300Watt redundant)

The complete system is stable since then. I have been unable to get the
box to fall over. It even survives Quake3 and all ;-)

> these are the joys of working with beta software i guess.  there
> are no further ondisk changes coming (afaik) though, so this sort
> of situation shouldn't arise again.  i guess what i'm getting at
> is that this example doesn't really have much to do with a rescue
> disk after all...

Ehm, if you have faulty RAM you still might want to have that rescue disk
though. Suppose that you have your root as xfs and something funky happens
to your hardware?
There happen to be a lot of rescue disks around that have e2fsck ;-)
That is the one and only reason I have a ext2 root (also holds /boot)


Kind regards and a hacking new year.

Seth



<Prev in Thread] Current Thread [Next in Thread>