Try booting it with: boot: bz2bzImage floppy=thinkpad
see if that helps. The detection process is probably very different between kernel 2.0.x and 2.2.x, I don't know how, though. It should be safe to mount ext3 rw with ext2 as long as you cleanly unmount it. -Tom On Mon, 11 Aug 2003, John Lumby wrote: > Date: Mon, 11 Aug 2003 22:40:28 -0400 > From: John Lumby <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Robert de Bath <[EMAIL PROTECTED]>, > John Lumby <[EMAIL PROTECTED]> > Subject: Re: [tomsrtbt] hang during boot on 2.0.103 (not tomsrtbt's fault > but anyway ...) > > Thanks to both of you who replied. Very helpful ineed. > > On Thu, 7 Aug 2003, Robert de Bath wrote: > > > > On Thu, 7 Aug 2003, Tom Oehser wrote: > > > > > > > > > AFAIK even 1.7.361 is able to mount any ext2/3 filesystem, > however, it > > > > > > I think ext2 can only mount *clean* ext3 filesystems, if there is > > > journalling to apply, doesn't it set a bit that stops it? [...] > >> The 1.7.361 should be able to mount it if it is clean. > > > > Oh yes, "couldn't mount because of unsupported optional features"; > > and you need tune2fs to remove that flag. > > > > Or debugfs: > > I can confirm that 1.7.361 is able to mount an ext3 filesystem that is > clean. I have one question on this - is it safe to mount it rw? I > tried it (on a not-very-precious fs) and it appeared ok but mount said > it was ext2. I suppose it is "at your own risk". Anyway, ro is all > I need for the particular filesystem I am trying to recover. I didn't > try the debugfs/tune2fs/e2fsck ideas. I was lucky that I was able to > run a complete cycle of boot, fsck-st-start, shutdown on the dodgy disk. > > On Thu, 7 Aug 2003, Tom Oehser wrote: > > > > > How about moving the dodgy disk to the machine that 2.0.103 boots in? > > > > Ah - the dodgy-disk machine is a thinkpad with little itty-bitty disk > drives that would rattle around to no useful effect in my old PII > workstation. > > On Thu, 7 Aug 2003, Tom Oehser wrote: > > > > > One thing to try is pulling out spurious hardware, such as network > > cards and sound cards and such, and see if it will boot then, in case > > one of them is what is locking up on the probe. > > > > Don't think I can in a thinkpad (not safely anyway). > > Going back to 2.0.103 tomsrtbt - I tried this again on the thinkpad with > a new, clean, /dev/hda drive and (of course) it still hung after that > FDC 0 is a National Semi... > line. I am quite keen to get a 2.0.103 that works on the thinkpad. > Do you suppose that's possible? Well, of course it's possible - I > mean, can you offer any suggestions for debugging/fixing? > > > > > The problem is there are a lot of auto-detects happening here, any one > > > of them could be upsetting some piece of hardware and most of them say > > > nothing if they find nothing. > > > As I mentioned in my original note: > > The old 1.7.361 gets past that point and (with a slight difference in > that > > it prints only a single line for the hda) continues on with messages > about: > > scsi: 0 hosts > > scsi: detected xxx > > Can you confirm (or tell me how to confirm) that the kernel in 2.0.103 > auto-detects devices in the same order as the one in 1.7.361? Which > would then imply that the problem is definitely with the scsi > detection. I am roughly thinking along the lines of - > . unpack.s > . replace the scsi piece of the kernel with the equivalent piece from > the thinkpad's own kernel (I did say "roughly") > . buildit.s > > John > > >
