Re: 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