failing to boot from mfsroot.gz
Richard P. Williamson
richard.williamson at u4eatech.com
Thu Jul 1 00:48:25 PDT 2004
At 17:24 30/06/2004. epilogue had this to say:
>On Wed, 30 Jun 2004 14:11:07 +0100
>"Richard P. Williamson" <richard.williamson at u4eatech.com> wrote:
>
>> Hello all,
>>
>> I have a 4.8 system that booted from flash using a kernel.gz and
>> mfsroot.gz. The ethernet parts were not fully supported by the fxp driver
>> in 4.8, so I was testing 4.10 to see if they were with that version of
>> the OS.
>>
>> I've replace the kernel.gz with a 4.10 version, and the mfsroot.gz
>> is built using 4.10 objects. If I try to boot it, this is what I
>> get:
>>
>> ...
>> md0: Preloaded mfs_root "/mfsroot> 50331648 bytes at 0xc02b2794
>> md1: malloc disk
>> ...
>> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 in isa0
>> sio0: type 16550A, console
>> sio1 at port 0x2f8-0x2ff irq 3 on isa0
>> sio1: type 16550A
>> vga0: <Generic ISA VGA> at port 0x3b0-0x3bb iomem 0xb0000-0xb7ffff on
>> isa0 ad0: 30MB <SanDisk SDCFB-32> [490/4/32] at ata0-master PI01
>> Mounting root from ufs:/dev/md0c
>>
>> And then nothing. Nada. Zip.
>>
>> No kernel panic message, no prompt, nothing.
>>
>> Which leaves me in a bit of a pickle as to what to try.
>>
>> If I use a 4.10 kernel with a 4.8 mfsroot.gz, it boots,
>> but tells me that proc is out of sync with the kernel.
>
>If i get you correctly, you're trying to run a 4.10 kernel on a 4.8
>system. (?)
That'd be stoopid. No, I'm trying to run a 4.10 kernel with a 4.10
mfsroot.gz. But nothing happens. The kernel inflates the mfsroot.gz
into md0, configures itself, and then attempts to mount the
root filesystem on /dev/md0c . And then that's it. No further
messages on the console, no panic, no nothing.
When I run a 4.8 kernel with a 4.8 system, all ok.
When I (accidently) ran the 4.10 kernel with the 4.8 mfsroot.gz,
it ran (marginally), while complaining about things like proc
size mismatch. But it did come up.
>if i've misunderstand your intention, apologies.
no worries. My second paragraph may have been unclear ;>
What I'm looking for is 'debug methodologies', ie what can
I do to try and trace where it is falling over. Assume I'm
limited to printf. Is there any way to enable bizarre
debugging support in the booting kernel, on a headless,
embedded device...
Thanks for responding,
rip
More information about the freebsd-questions
mailing list