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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
