On Mar 23, 2006, at 13:11, Frans Pop wrote:
This actually is expected, as before the Beta 2 release we only had
time
to implement sbus support in d-i itself (which seems to have worked)
and
not the code needed to make sure detected devices are also included in
the initrd. See the changelog for hw-detect 1.33.
If you're willing to test the needed modifications, it should not be
hard
to implement this.
We have encountered this bug on a similar machine, and tried working
around it by adding the esp module to the initrd image using a x86
host. The original initrd was 1410553 bytes, and the new initrd 1430659
bytes. Slightly bigger. When booting this new image, the boot fails
with the following message:
"
...
RAMDISK: Compressed image found at block 0
input: Sun Type 5 keyboard as /class/input/input0
input: Sun Mouse as /class/input/input1
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
<0>Press Stop-A (L1-A) to return the boot prom
"
Does this mean the initrd is corrupt? Possibly because of endian
differences between the sparc and the x86 host, or special demands on
the initrd format, which are not met when using cpio and gzip manually.
The interesting question is really, where is the initrd generated by
d-i? Where would it be a good idea to try making the needed
modifications? It wouldn't be enough just adding a register-module
command to the hw-detect script, would it?
---
Markus Ingvarsson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]