CALL FOR HELP : debian boot floppies 2.2.15 on apus still not ok.

[Sven L. <lu...@la...>]

Hello, ...

This is a call for help, i am totally lost here, and if nobody helps me out on
this, i am afraid the apus boot floppies will chip as is, without working
properly.

This is not so big a deal, because it is possible to do a full install in the
current state of things, but still it would be nicer if this was fixed before
the potato release, ...

this morning i did try 2.2.15, and the problem still is there.

The problem (already described in bug 64500, 43 days old as of today) is the
following.

Everything works fine, but when i come to the step where i would normally do :

  * install os kernel & modules

i give the corrct place in the requester, and dbootstrap tries to loop mount
the rescue.bin image to fetch the kernel and the modules, and fail.

I then tried testing by hand, with :

$ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt
Mounting rescue.bin on /mnt failed : block device required

well, i think i found the cause of this error, ...

Now the strange thing, is that when i continue the installation stuff and
reboot with the same kernel on the partition just installed from the base
tarball, i can mount the rescue.bin image with the exact command given above.

Thus i suspsect the problem lie with the root.bin image. or maybe the
dbootstrap mount command.

I have tested to see if loop device is modular or not, (i built the kernel
with loops included) and got :

$ grep loop /proc/ksyms
c016a084 loops_per_ser
c0161278 loopback_dev
c00aeeac loop_register_transfer
c00aeee4 loop_unregister_transfer

this should be ok, since i get the same symbols on my i386 2.3.99-pre8 kernel
here at work.

also i did test the loop0 device :

from the root.bin image :

$ ls -l /dev/loop0
brw-r--r--r 1 root root 7, 0 Jun 6 21:50 /dev/loop0

(didn't change when i chmoded it to be 666 either :((()

from the base installed system :

$ ls -l /dev/loop0

brw-rw---- 1 root disk ...

Any idea of what is going wrong here ? 

Anything else i could test here ?

In particular i would like other apus user to test this (with various kernels)
and report to me about it.

It can be tested in an non partition damaging way by :

 1) booting with the latest debian root.bin image as ramdisk.

 2) respond only to the keyboard question once it has booted.

 3) switch to console 2

 4) type enter to get a prompt

 5) try :

$ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt

And see if it can be mounted ...

Not so difficult isn't it, but if nobody can be worried to confirm on this, i
guess it is not worth for me to waste my time on this, isn't it, anyway, _I_
can install debian without problem with the current boot floppies, ...

Friendly,

Svne LUTHER