Using xfsdump On Linux With IRIX Version 1 FS?
Hi all,
While I am aware that the current kernel implementation of XFS doesn't support mounting an IRIX filesystem with version 1 directories, I'm not so sure whether xfsdump/xfsrestore will support the dumping of an IRIX filesystem with version 1 directories. To be more specific, I am dealing with an old disk from an Indigo2, running IRIX 6.5.6m with version 1 (0x1094) directories. I was hoping it had version 2 directories, but after finding an old SCSI card I could put in a Linux box with XFS support, I found just the opposite, obviously. I had the old SCSI card back in its donor system (which was up-and-running) when it occurred to me that xfsdump/xfsrestore *might* be a possibility, and I can't take it (the donor system) down again unless I know I can make this work.
If anyone can give me an answer to this question, I would certainly appreciate it. I didn't see anything in the man pages, and my Google searches have proven fruitless thus far, but I've been known to be blind on occasion. :-) Thanks, in advance.
Signature · 14 lines
+------------------------------------------------- | Sean Elble | Virginia Tech, Class of 2009 | E-Mail: [email protected] | Web: http://www.sessys.com/~elbles/ | Cell: 860.946.9477 +------------------------------------------------- _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 14 lines · Sean Elble
Hi all,
While I am aware that the current kernel implementation of XFS doesn't support mounting an IRIX filesystem with version 1 directories, I'm not so sure whether xfsdump/xfsrestore will support the dumping of an IRIX filesystem with version 1 directories. To be more specific, I am dealing with an old disk from an Indigo2, running IRIX 6.5.6m with version 1 (
0x1094) directories. I was hoping it had version 2 directories, but after finding an old SCSI card I could put in a Linux box with XFS support, I found just the opposite, obviously. I had the old SCSI card back in its donor system (which was up-and-running) when it occurred to me that xfsdump/xfsrestore *might* be a possibility, and I can't take it (the donor system) down again unless I know I can make this work.
Quoted 5 lines
If anyone can give me an answer to this question, I would certainly appreciate it. I didn't see anything in the man pages, and my Google searches have proven fruitless thus far, but I've been known to be blind on occasion. :-) Thanks, in advance.
linux used to work with v1 dirs, though there were some problems. It never got fixed, was not critical for 99.9% of users, and got taken out.
But it might work well enough to do what you need. Go through the
changelogs or google, and try an older Linux kernel, perhaps ....
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 21 lines · Eric Sandeen
Quoted 14 lines · Sean Elble
Hi all,
While I am aware that the current kernel implementation of XFS doesn't support mounting an IRIX filesystem with version 1 directories, I'm not so sure whether xfsdump/xfsrestore will support the dumping of an IRIX filesystem with version 1 directories. To be more specific, I am dealing with an old disk from an Indigo2, running IRIX 6.5.6m with version 1 (
0x1094) directories. I was hoping it had version 2 directories, but after finding an old SCSI card I could put in a Linux box with XFS support, I found just the opposite, obviously. I had the old SCSI card back in its donor system (which was up-and-running) when it occurred to me that xfsdump/xfsrestore *might* be a possibility, and I can't take it (the donor system) down again unless I know I can make this work.Quoted 5 lines
If anyone can give me an answer to this question, I would certainly appreciate it. I didn't see anything in the man pages, and my Google searches have proven fruitless thus far, but I've been known to be blind on occasion. :-) Thanks, in advance.
Quoted 7 lines
linux used to work with v1 dirs, though there were some problems. It never got fixed, was not critical for 99.9% of users, and got taken out.
But it might work well enough to do what you need. Go through the
changelogs or google, and try an older Linux kernel, perhaps ....-Eric
Thanks for the reply, Eric, I appreciate it. I'll take a look and see what I can find, being sure to post back the latest version of the kernel with version 1 support. Think it was removed during the 2.5.x period, or could it possibly have made it to the 2.6 era?
-Sean
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 21 lines · Eric Sandeen
Quoted 14 lines · Sean Elble
Hi all,
While I am aware that the current kernel implementation of XFS doesn't support mounting an IRIX filesystem with version 1 directories, I'm not so sure whether xfsdump/xfsrestore will support the dumping of an IRIX filesystem with version 1 directories. To be more specific, I am dealing with an old disk from an Indigo2, running IRIX 6.5.6m with version 1 (
0x1094) directories. I was hoping it had version 2 directories, but after finding an old SCSI card I could put in a Linux box with XFS support, I found just the opposite, obviously. I had the old SCSI card back in its donor system (which was up-and-running) when it occurred to me that xfsdump/xfsrestore *might* be a possibility, and I can't take it (the donor system) down again unless I know I can make this work.Quoted 5 lines
If anyone can give me an answer to this question, I would certainly appreciate it. I didn't see anything in the man pages, and my Google searches have proven fruitless thus far, but I've been known to be blind on occasion. :-) Thanks, in advance.
Quoted 7 lines
linux used to work with v1 dirs, though there were some problems. It never got fixed, was not critical for 99.9% of users, and got taken out.
But it might work well enough to do what you need. Go through the
changelogs or google, and try an older Linux kernel, perhaps ....-Eric
Looks like the version 1 directory code was removed as of June 15th, 2006, per this:
http://oss.sgi.com/archives/xfs/2006-06/msg00067.html
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.
-Sean
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 36 lines · Sean Elble
Quoted 21 lines · Eric Sandeen
Quoted 14 lines · Sean Elble
Hi all,
While I am aware that the current kernel implementation of XFS doesn't support mounting an IRIX filesystem with version 1 directories, I'm not so sure whether xfsdump/xfsrestore will support the dumping of an IRIX filesystem with version 1 directories. To be more specific, I am dealing with an old disk from an Indigo2, running IRIX 6.5.6m with version 1 (
0x1094) directories. I was hoping it had version 2 directories, but after finding an old SCSI card I could put in a Linux box with XFS support, I found just the opposite, obviously. I had the old SCSI card back in its donor system (which was up-and-running) when it occurred to me that xfsdump/xfsrestore *might* be a possibility, and I can't take it (the donor system) down again unless I know I can make this work.Quoted 5 lines
If anyone can give me an answer to this question, I would certainly appreciate it. I didn't see anything in the man pages, and my Google searches have proven fruitless thus far, but I've been known to be blind on occasion. :-) Thanks, in advance.
Quoted 7 lines
linux used to work with v1 dirs, though there were some problems. It never got fixed, was not critical for 99.9% of users, and got taken out.
But it might work well enough to do what you need. Go through the
changelogs or google, and try an older Linux kernel, perhaps ....-Eric
Looks like the version 1 directory code was removed as of June 15th, 2006, per this:
Quoted 8 lines
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/shadowso 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.
Bis denn
Signature · 9 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 15 lines · Matthias Schniedermeyer
Quoted 6 lines
Looks like the version 1 directory code was removed as of June 15th, 2006, per this:
Quoted 8 lines
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/shadowso 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.
Quoted 7 lines
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.
-Sean
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 25 lines · Sean Elble
Quoted 15 lines · Matthias Schniedermeyer
Quoted 6 lines
Looks like the version 1 directory code was removed as of June 15th, 2006, per this:
Quoted 8 lines
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/shadowso 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.
Quoted 7 lines
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.
Quoted 6 lines
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...
Exactly.
Quoted 3 lines
Then, I could use hexedit in the following manner to edit the disk:
hexedit -d -f
/dev/sda
Don't know hexedit. Last time i used a hex editor it was "khexedit", worked good enough.
Quoted 11 lines
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/shadowfile by doing something like the following:
xfs_ncheck/dev/sda| grep/etc/shadowI'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_dbconvert command to get something usable as an offset. Something like the following, perhaps?
xfs_db-c convert inode <inode fromxfs_ncheckcommand> daddr/dev/sda
2GB is small enough to just use "brute force".
- Make a backup-copy of the image
- Open the image in a/the hexeditor
- Search for something that appears in the shadow file it should be pretty obvious if the hit is inside the shadow file.
- Make the changes, (Remember filesize has to stay the same!)
- dd the image back to the HDD.
Not very complicated and it still shouldn't take too long. :-)
Bis denn
Signature · 9 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 42 lines · Matthias Schniedermeyer
Quoted 11 lines · Sean Elble
Quoted 8 lines · Matthias Schniedermeyer
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.
Quoted 6 lines
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...
Exactly.
Quoted 3 lines
Then, I could use hexedit in the following manner to edit the disk:
hexedit -d -f
/dev/sdaDon't know hexedit. Last time i used a hex editor it was "khexedit", worked good enough.
Quoted 11 lines
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/shadowfile by doing something like the following:
xfs_ncheck/dev/sda| grep/etc/shadowI'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_dbconvert command to get something usable as an offset. Something like the following, perhaps?
xfs_db-c convert inode <inode fromxfs_ncheckcommand> daddr/dev/sda2GB is small enough to just use "brute force".
Quoted 9 lines
- Make a backup-copy of the image
- Open the image in a/the hexeditor
- Search for something that appears in the shadow file it should be pretty obvious if the hit is inside the shadow file.
- Make the changes, (Remember filesize has to stay the same!)
- dd the image back to the HDD.Not very complicated and it still shouldn't take too long. :-)
Yeah, that's probably what I'll do then. I figure the disk will thrash for a while during the search for a string in /etc/shadow, but hopefully it'll work. Thanks for all the advice!
-Sean
Signature · 7 lines
+------------------------------------------------- | Sean Elble | Virginia Tech, Class of 2009 | E-Mail: [email protected] | Web: http://www.sessys.com/~elbles/ | Cell: 860.946.9477 +-------------------------------------------------
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Sean Elble
Yeah, that's probably what I'll do then. I figure the disk will thrash for a while during the search for a string in
/etc/shadow, but hopefully it'll
Instead of working on the (old, slow) disk, you could just work on the backup (located on faster disk, I presume), maybe even set up a blockdevice for it:
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.
Christian.
Signature · 8 lines
BOFH excuse #378: Operators killed by year 2000 bug bite. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Christian Kujau
Quoted 2 lines · Sean Elble
Yeah, that's probably what I'll do then. I figure the disk will thrash for a while during the search for a string in
/etc/shadow, but hopefully it'llInstead of working on the (old, slow) disk, you could just work on the backup (located on faster disk, I presume), maybe even set up a blockdevice for it:
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.
Which has what advantage over directly changing the image?
And the old disc may be slow, but the relative speed (Speed in relation to total capacity) is much better than modern discs. IOW it only takes minutes to read/write it completly.
Some month ago i backed up some old HDDs (biggest was 4GB), it nearly took longer to switch on/off the computer and change the HDDs, than the actual time to copy the HDDs.
Even with just 10MB/s it's less than 4 Minutes for 2GB.
In comparison it takes over 3 hours to copy a modern 1TB HDD @ 80MB/s.
Bis denn
Signature · 9 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Matthias Schniedermeyer
Quoted 2 lines
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.Which has what advantage over directly changing the image?
Sean mentioned the "thrashing of the old disk" and I figured I'd be worried not only by that but that the old disk might die anytime soon. So I wanted to present an alternative to do the search - I don't know too much about his setup, so it's up to him to follow this advice or not.
Quoted 2 lines
Even with just 10MB/s it's less than 4 Minutes for 2GB.
In comparison it takes over 3 hours to copy a modern 1TB HDD @ 80MB/s.
?? (what kind of comparison is that?)
C.
Signature · 8 lines
BOFH excuse #443: Zombie processes detected, machine is haunted. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Christian Kujau
Quoted 4 lines · Matthias Schniedermeyer
Quoted 2 lines
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.Which has what advantage over directly changing the image?
Sean mentioned the "thrashing of the old disk" and I figured I'd be worried not only by that but that the old disk might die anytime soon. So I wanted to present an alternative to do the search - I don't know too much about his setup, so it's up to him to follow this advice or not.
I meant: What is the advantage of using the a loop-device (of the image) instead of directly using the image?
Quoted 4 lines
Quoted 2 lines
Even with just 10MB/s it's less than 4 Minutes for 2GB.
In comparison it takes over 3 hours to copy a modern 1TB HDD @ 80MB/s.?? (what kind of comparison is that?)
That you can read/write whole "ancient" discs without having to wait for hours?
Bis denn
Signature · 9 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Matthias Schniedermeyer
I meant: What is the advantage of using the a loop-device (of the image) instead of directly using the image?
Some tools don't like to act on flat files, i.e. mkfs.reiserfs won't create a filesystem on a file without -forcing it, dunno about all the xfsprogs though, or "hexedit", or....
Signature · 8 lines
BOFH excuse #5: static from plastic slide rules _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Christian Kujau
Quoted 3 lines · Matthias Schniedermeyer
Quoted 2 lines
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.
Quoted 8 lines
Quoted 1 line
Which has what advantage over directly changing the image?
Sean mentioned the "thrashing of the old disk" and I figured I'd be worried not only by that but that the old disk might die anytime soon. So I wanted to present an alternative to do the search - I don't know too much about his setup, so it's up to him to follow this advice or not.
I think (and hope, considering its age) that the disk is OK. My concern was more with the speed that hexedit could traverse the drive searching for a string, as opposed to dd'ing the drive to disk, editing the image, and then dd'ing the image back to disk.
Using the loopback driver is definitely a thought, but I don't know if the kernel on my spare box supports it or not. I'll definitely take it into consideration, depending on how it goes, so thanks for the info.
Quoted 6 lines
Quoted 2 lines
Even with just 10MB/s it's less than 4 Minutes for 2GB.
In comparison it takes over 3 hours to copy a modern 1TB HDD @ 80MB/s.?? (what kind of comparison is that?)
C.
Signature · 7 lines
+------------------------------------------------- | Sean Elble | Virginia Tech, Class of 2009 | E-Mail: [email protected] | Web: http://www.sessys.com/~elbles/ | Cell: 860.946.9477 +-------------------------------------------------
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Christian Kujau
Quoted 4 lines · Matthias Schniedermeyer
Quoted 2 lines
# losetup -r /dev/loop0 /path/to/IRIXbackup # hexedit /dev/loop0 ...or whatever tool you'll be using.Which has what advantage over directly changing the image?
Sean mentioned the "thrashing of the old disk" and I figured I'd be worried not only by that but that the old disk might die anytime soon. So I wanted to present an alternative to do the search - I don't know too much about his setup, so it's up to him to follow this advice or not.
Well, I ended up dd'ing the old SCSI disk to a file on a spare Linux box I have laying around for just this sort of purpose. I then opened the resulting file up with hexedit, switched to ASCII mode, did a search for the root password hash, and replaced it with a known hash for "blah."
DD'ed the image back to the disk, threw it back in the Indigo2, and booted. I entered maintenace mode, ran sash, and cat'ed the /etc/shadow file. It still had the old password. So, back to the image file I went. The password string was in there multiple times, to the point where I lost count. I should have thought of that the first time around, but I figured once was good enough. Searched and replaced the string until the old string wasn't in there anymore, reimaged the drive, put it back in the SGI, booted, and voila: I can log in again.
The loopback method was a moot point, as the box I was using didn't have the loopback driver compiled in or available as a module, so I never even tried it. I'll definitely keep it in mind (and in my inbox) should another few years go by and I can't remember the password again. :-)
Thanks so much for all the help guys, I really appreciate it.
-Sean
Signature · 7 lines
+------------------------------------------------- | Sean Elble | Virginia Tech, Class of 2009 | E-Mail: [email protected] | Web: http://www.sessys.com/~elbles/ | Cell: 860.946.9477 +-------------------------------------------------
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Sean Elble
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/shadowso I can login to a 150 MHz box again, so who knows if I'll even try at this point, hah.
If you just want to modify /etc/shadow I would just search for the strings on the raw disk and then edit them directly with some hex editor. You'll need to fill in something with the same length, presumably another encrypted password. Just make sure you generate it with the same algorithm as Irix.
-Andi
Signature · 6 lines
[email protected] -- Speaking for myself only. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs