On 7/24/09 3:30 AM, "Matthias Schniedermeyer" <ms@xxxxxxx> wrote:
>> Looks like the version 1 directory code was removed as of June 15th, 2006,
>> per this:
>> But another post <http://oss.sgi.com/archives/xfs/2003-07/msg00495.html> has
>> a 2.4.21 kernel being used with a patch, so I'm not sure if I want to try a
>> 2.6 kernel, or see if I can patch together a 2.4.x kernel on an old FC4 box
>> I have laying around. Truth be told, it's a lot of work just to blank the
>> entries in /etc/shadow so I can login to a 150 MHz box again, so who knows
>> if I'll even try at this point, hah.
>> In any event, thanks a lot for the pointers in the right direction.
> I'd guess the disc isn't very big.
> You just dd it completly (for backup).
> Then search for the content of the shadow-file and blank out the entry
> with a hex-editor. Make sure that you don't change the filesize, pad
> the previous/following entry with any character you have to remove.
Right, the disk is only 2 GB. Presumably, to back the disk up, all I'd have
to do would be something like:
dd if=/dev/sda of=IRIXbackup
Correct? No need to specify bs or count, I presume...
Then, I could use hexedit in the following manner to edit the disk:
hexedit -d -f /dev/sda
I suppose I could search for the encrypted password string itself, but as
Chris Wedgwood suggested, I might be better off finding the offset of the
/etc/shadow file by doing something like the following:
xfs_ncheck /dev/sda | grep /etc/shadow
I'm not sure if I can use the inode number directly as an offset or not, but
I *think* I could use it in conjunction with a xfs_db convert command to get
something usable as an offset. Something like the following, perhaps?
xfs_db -c convert inode <inode from xfs_ncheck command> daddr /dev/sda
My apologies for all the questions, but I've never tried this before, and I
don't particularly feel like messing it up, even with a backup of the FS
available. Many thanks to Andi Kleen and Chris Wedgwood, in addition to
Eric Sandeen and Matthias Schniedermeyer.
Description: S/MIME cryptographic signature