passing params to boot readonly

passing params to boot readonly

[Stewart Allen]

I'm in a bit of a pickle and need to find a way to pass boot params to a 
reiserfs rootfs to *prevent* it from replaying the journal on single-user 
boot. This may seem like a strange request, but I've got a degraded RAID array 
that I need to poke around in before deciding whether or not to send a disk 
off to a rehab lab. If the replay occurs, it will potentially destroy the fs 
since I'm using a degraded snapshot of the failed disk in hopes of reclaiming 
*some* of my data. The system is running 2.2.x (can't remember and can't find 
out w/out booting).

Do I have a snowball's chance of pulling this off?

thanks,

stewart

Re: passing params to boot readonly

[Ryan Cumming]

On December 12, 2001 21:50, Stewart Allen wrote:
> I'm in a bit of a pickle and need to find a way to pass boot params to a
> reiserfs rootfs to *prevent* it from replaying the journal on single-user
> boot. This may seem like a strange request, but I've got a degraded RAID
> array that I need to poke around in before deciding whether or not to send
> a disk off to a rehab lab. If the replay occurs, it will potentially
> destroy the fs since I'm using a degraded snapshot of the failed disk in
> hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> remember and can't find out w/out booting).
>
> Do I have a snowball's chance of pulling this off?

Well, kinda. The only thing that can deter ReiserFS from replaying the 
journal is convincing it that the physical media it's on is actually read 
only. Some quick less/grep work revealed that there is no option that makes 
the SCSI subsystem claim its devices are readonly (although it'd be extremely 
useful for situations such as this).

It'd probably be pretty easy to make a boot disk using a hacked version of 
ReiserFS that refuses to replay the journal, by adding a "return 0;" near the 
top of journal_read(struct super_block *) in journal.c. However, you might 
feel more comfortable sending it off for data recovery than testing kernel 
hacks on it ;)

-Ryan

Re: passing params to boot readonly

[Hans Reiser]

Ryan Cumming wrote:

>On December 12, 2001 21:50, Stewart Allen wrote:
>
>>I'm in a bit of a pickle and need to find a way to pass boot params to a
>>reiserfs rootfs to *prevent* it from replaying the journal on single-user
>>boot. This may seem like a strange request, but I've got a degraded RAID
>>array that I need to poke around in before deciding whether or not to send
>>a disk off to a rehab lab. If the replay occurs, it will potentially
>>destroy the fs since I'm using a degraded snapshot of the failed disk in
>>hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
>>remember and can't find out w/out booting).
>>
>>Do I have a snowball's chance of pulling this off?
>>
>
>Well, kinda. The only thing that can deter ReiserFS from replaying the 
>journal is convincing it that the physical media it's on is actually read 
>only. Some quick less/grep work revealed that there is no option that makes 
>the SCSI subsystem claim its devices are readonly (although it'd be extremely 
>useful for situations such as this).
>
>It'd probably be pretty easy to make a boot disk using a hacked version of 
>ReiserFS that refuses to replay the journal, by adding a "return 0;" near the 
>top of journal_read(struct super_block *) in journal.c. However, you might 
>feel more comfortable sending it off for data recovery than testing kernel 
>hacks on it ;)
>
>-Ryan
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
why not just edit the source code directly and recompile?  

Hans

Re: passing params to boot readonly

[stewart]

On Thu, 13 Dec 2001, Hans Reiser wrote:

> Ryan Cumming wrote:
>
> >On December 12, 2001 21:50, Stewart Allen wrote:
> >
> >>I'm in a bit of a pickle and need to find a way to pass boot params to a
> >>reiserfs rootfs to *prevent* it from replaying the journal on single-user
> >>boot. This may seem like a strange request, but I've got a degraded RAID
> >>array that I need to poke around in before deciding whether or not to send
> >>a disk off to a rehab lab. If the replay occurs, it will potentially
> >>destroy the fs since I'm using a degraded snapshot of the failed disk in
> >>hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> >>remember and can't find out w/out booting).
> >>
> >>Do I have a snowball's chance of pulling this off?
> >>
> >
> >Well, kinda. The only thing that can deter ReiserFS from replaying the
> >journal is convincing it that the physical media it's on is actually read
> >only. Some quick less/grep work revealed that there is no option that makes
> >the SCSI subsystem claim its devices are readonly (although it'd be extremely
> >useful for situations such as this).
> >
> >It'd probably be pretty easy to make a boot disk using a hacked version of
> >ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
> >top of journal_read(struct super_block *) in journal.c. However, you might
> >feel more comfortable sending it off for data recovery than testing kernel
> >hacks on it ;)
> >
> >-Ryan
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >
> why not just edit the source code directly and recompile?
>
> Hans


There are a couple of potential problems with this approach:

1. I thought the on-disk structures for ReiserFS changed sometime
   between 2.2.something (the system in question) and now. Since I
   cannot pinpoint the kernel/patch version, I'm not sure this hack
   will work.

2. I have no other systems like this one to test the read-only hack on.
   Without a fairly high degree of confidence that I'm actually booting
   in a no-replay read-only state, I'm not going to take chances with
   this data.

stewart

Re: passing params to boot readonly

[Ryan Cumming]

On December 13, 2001 01:28, Hans Reiser wrote:
> >It'd probably be pretty easy to make a boot disk using a hacked version of
> >ReiserFS that refuses to replay the journal, by adding a "return 0;" near
> > the top of journal_read(struct super_block *) in journal.c. However, you
> > might feel more comfortable sending it off for data recovery than testing
> > kernel hacks on it ;)

> why not just edit the source code directly and recompile?

Just curious, but how would editing the source and recompiling be any 
different from what I suggested?

-Ryan

Re: passing params to boot readonly

[Hans Reiser]

Ryan Cumming wrote:

>On December 13, 2001 01:28, Hans Reiser wrote:
>
>>>It'd probably be pretty easy to make a boot disk using a hacked version of
>>>ReiserFS that refuses to replay the journal, by adding a "return 0;" near
>>>the top of journal_read(struct super_block *) in journal.c. However, you
>>>might feel more comfortable sending it off for data recovery than testing
>>>kernel hacks on it ;)
>>>
>
>>why not just edit the source code directly and recompile?
>>
>
>Just curious, but how would editing the source and recompiling be any 
>different from what I suggested?
>
>-Ryan
>
>
email delay time.  ;-)

Stewart, you can get Edward to create a new option for you by going to 
www.namesys.com/support.html

 $25 and you get a patch and all the additional support you need (sounds 
like you may need some for figuring out what version you have on the 
disk, etc.).

Or you might try what Ryan says, and save $25.

Hans

Re: passing params to boot readonly

[Chris Mason]

On Thursday, December 13, 2001 10:02:21 PM +0300 Hans Reiser
<reiser@namesys.com> wrote:

> Ryan Cumming wrote:
> 
>> On December 13, 2001 01:28, Hans Reiser wrote:
>> 
>>>> It'd probably be pretty easy to make a boot disk using a hacked version
>>>> of ReiserFS that refuses to replay the journal, by adding a "return 0;"
>>>> near the top of journal_read(struct super_block *) in journal.c.
>>>> However, you might feel more comfortable sending it off for data
>>>> recovery than testing kernel hacks on it ;)
>>>> 
>> 
>>> why not just edit the source code directly and recompile?

I posted a path for this a few months ago, hold on I'm rediffing real quick...

-chris

Re: passing params to boot readonly

[Chris Mason]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]


Ok, the patch is attached, it was against 2.4.17-pre8 but should apply to
2.4.16 (let me know if you have problems).

To use, mount the FS with -o noreplay.  If there are transactions that need
to be replayed, it will force the FS readonly, otherwise, you get a normal rw
mount.  So, you might want to use -o ro,noreplay instead.

You'll need a boot disk with the patched 2.4.x kernel (it will be able to
read the 2.2.x reiserfs disk).

Now, with all of that said, I don't think this is the best way to poke around
on the degraded array (RAID5 with one disk dead?).  Grab the 3.x.0j version
of reiserfsprogs, and we can use debugreiserfs to get a look at what metadata
is still usable on the FS.

If the data is important, I'd strongly suggest finding a way to back it up (a
raw copy of the other two drives is better than nothing) before trying
anything fancy.  Even if this means a trip to the computer store and some
extra downtime.

-chris

[-- Attachment #2: noreplay-2.diff.gz --]
[-- Type: application/x-gunzip, Size: 1855 bytes --]

Re: passing params to boot readonly

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> On December 12, 2001 21:50, Stewart Allen wrote:
> > I'm in a bit of a pickle and need to find a way to pass boot params to a
> > reiserfs rootfs to *prevent* it from replaying the journal on single-user
> > boot. This may seem like a strange request, but I've got a degraded RAID
> > array that I need to poke around in before deciding whether or not to send
> > a disk off to a rehab lab. If the replay occurs, it will potentially
> > destroy the fs since I'm using a degraded snapshot of the failed disk in
> > hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> > remember and can't find out w/out booting).
> >
> > Do I have a snowball's chance of pulling this off?
> 
> Well, kinda. The only thing that can deter ReiserFS from replaying the 
> journal is convincing it that the physical media it's on is actually read 
> only. Some quick less/grep work revealed that there is no option that makes 
> the SCSI subsystem claim its devices are readonly (although it'd be extremely 
> useful for situations such as this).
> 
> It'd probably be pretty easy to make a boot disk using a hacked version of 
> ReiserFS that refuses to replay the journal, by adding a "return 0;" near the 
> top of journal_read(struct super_block *) in journal.c. However, you might 
> feel more comfortable sending it off for data recovery than testing kernel 
> hacks on it ;)

Wouldn't it be better to make a backup (dd copy) of the disk volume to another
drive? The raid would not be mounted, so the fs would not be updated.

I would recommend that be done even before sending the disk out.

ALTERNATIVE TO READ-ONLY and this might not be possible.

If the raid is SCSI based, then there is (should be) a read-only switch
in the disk configuration. Most disks do not have a jumper there, and since
they are usually internal only, the option is not used. Putting the jumper
on (or removing one if it is there - depends on the drive) will make the
disk read-only.

Even some IDE drives may have this option, though finding documentation on
it may be difficult to locate.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: passing params to boot readonly

[stewart]

On Thu, 13 Dec 2001, Jesse Pollard wrote:

> ---------  Received message begins Here  ---------
>
> >
> > On December 12, 2001 21:50, Stewart Allen wrote:
> > > I'm in a bit of a pickle and need to find a way to pass boot params to a
> > > reiserfs rootfs to *prevent* it from replaying the journal on single-user
> > > boot. This may seem like a strange request, but I've got a degraded RAID
> > > array that I need to poke around in before deciding whether or not to send
> > > a disk off to a rehab lab. If the replay occurs, it will potentially
> > > destroy the fs since I'm using a degraded snapshot of the failed disk in
> > > hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> > > remember and can't find out w/out booting).
> > >
> > > Do I have a snowball's chance of pulling this off?
> >
> > Well, kinda. The only thing that can deter ReiserFS from replaying the
> > journal is convincing it that the physical media it's on is actually read
> > only. Some quick less/grep work revealed that there is no option that makes
> > the SCSI subsystem claim its devices are readonly (although it'd be extremely
> > useful for situations such as this).
> >
> > It'd probably be pretty easy to make a boot disk using a hacked version of
> > ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
> > top of journal_read(struct super_block *) in journal.c. However, you might
> > feel more comfortable sending it off for data recovery than testing kernel
> > hacks on it ;)
>
> Wouldn't it be better to make a backup (dd copy) of the disk volume to another
> drive? The raid would not be mounted, so the fs would not be updated.
>
> I would recommend that be done even before sending the disk out.
>
> ALTERNATIVE TO READ-ONLY and this might not be possible.
>
> If the raid is SCSI based, then there is (should be) a read-only switch
> in the disk configuration. Most disks do not have a jumper there, and since
> they are usually internal only, the option is not used. Putting the jumper
> on (or removing one if it is there - depends on the drive) will make the
> disk read-only.
>
> Even some IDE drives may have this option, though finding documentation on
> it may be difficult to locate.
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.


 The RAID array uses 3ware's Escalade switch so all the drives are EIDE.
I've used read-only jumpers on SCSI drives in the past and hoped that these
supported it as well, but when I took the array apart, my hopes were dashed.

The drive that crashed will not spin up so I cannot dd back it up. I will be
doing this with two of the other disks, which should comprise a complete (if
degraded) image set.

stewart