From: Sven L. <lu...@la...> - 2000-07-05 11:15:27
|
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 |
From: Michel <da...@re...> - 2000-07-05 12:58:51
|
Sven LUTHER wrote: > 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. Should drivers.tgz be in rescue.bin? It's not. If the config.gz in rescue.bin is the config of the kernel you use, it does indeed include the loopback device and vfat. > 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. That's a strong indication. BTW what's the fs type of root.bin supposed to be? I can't mount it here. Michel -- Apologies are so hard to give. Would you accept some potatoes instead? ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: Sven L. <lu...@dp...> - 2000-07-05 14:39:08
|
On Wed, Jul 05, 2000 at 02:53:48PM +0200, Michel Dänzer wrote: > Sven LUTHER wrote: > > > 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. > > Should drivers.tgz be in rescue.bin? It's not. No it is supposed to be in driver-1.bin. > If the config.gz in rescue.bin is the config of the kernel you use, it does > indeed include the loopback device and vfat. thought so also, ... > > 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. > > That's a strong indication. BTW what's the fs type of root.bin supposed to be? > I can't mount it here. root.bin is just a compressed ext2 root image. dbootstrap does some gunzip & piping magic to mount it, but mv root.bin root.bin.gz && gunzip root.bin.gz will do also. Do you have the same problem as me with the mounting of the rescue.bin image (it is a vfat image) ? Friendly, Sven LUTHER |
From: Michel <da...@re...> - 2000-07-05 14:50:06
|
Sven LUTHER wrote: > > BTW what's the fs type of root.bin supposed to be? I can't mount it here. > > root.bin is just a compressed ext2 root image. > > dbootstrap does some gunzip & piping magic to mount it, but mv root.bin > root.bin.gz && gunzip root.bin.gz will do also. Aaah it worked now, thanks. > Do you have the same problem as me with the mounting of the rescue.bin image > (it is a vfat image) ? I can only test it on the i386 SuSE 6.4 here at work, and it mounts without problems. Michel -- It's not a bug, it's tradition! ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: Michel <dae...@st...> - 2000-07-09 20:30:00
|
Sven LUTHER wrote: > 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. Confirm that. ("Roger that" ;) Messages from VT 3 I consider relevant: running cmd 'mount -r -t ext2 /dev/loop0 /floppy' Mounting /dev/loop0 on /floppy failed: invalid argument Looks like it tries to use /dev/loop0 as a fake floppy drive and fails. > 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 It has just worked for me with just '-o loop', and I notice that it seems to be mounted from /dev/loop1 (df output). > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > And see if it can be mounted ... It works if I omit the '=/dev/loop0' , and now on the second try (after getting back to the installer main menu) df shows /dev/loop0 . So the problem must be elsewhere, any ideas? Michel -- Software is like sex; it's better when it's free - Linus Torvalds ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: Daniel J. <da...@de...> - 2000-07-09 20:42:20
|
On Sun, Jul 09, 2000 at 10:24:36PM +0200, Michel Dänzer wrote: > > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > > > And see if it can be mounted ... > > It works if I omit the '=/dev/loop0' , and now on the second try (after > getting back to the installer main menu) df shows /dev/loop0 . > > So the problem must be elsewhere, any ideas? Oho! Now that is interesting. Is /dev/loop0 created properly (I think someone doublechecked that earlier...)? If so, then I would blame the APUS kernel patches. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | da...@de... | | dm...@an... | \--------------------------------/ \--------------------------------/ |
From: Sven L. <lu...@dp...> - 2000-07-10 08:31:26
|
On Sun, Jul 09, 2000 at 01:36:41PM -0700, Daniel Jacobowitz wrote: > On Sun, Jul 09, 2000 at 10:24:36PM +0200, Michel Dänzer wrote: > > > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > > > > > And see if it can be mounted ... > > > > It works if I omit the '=/dev/loop0' , and now on the second try (after > > getting back to the installer main menu) df shows /dev/loop0 . > > > > So the problem must be elsewhere, any ideas? > > Oho! Now that is interesting. Is /dev/loop0 created properly (I think > someone doublechecked that earlier...)? If so, then I would blame the > APUS kernel patches. Huh ??? Ok, but remember, when i install the base tarball by hand, the above works without problem, with the exact same kernel. But then modules are installed, that is the only difference, but the loop module is builtin. Could there be another module that has soime influence on this ? i append here a ls -lR of the modules of this kernel : .: total 16 drwxr-xr-x 2 root root 4096 mai 2 19:26 block drwxr-xr-x 2 root root 4096 mai 2 19:26 fs drwxr-xr-x 2 root root 4096 mai 2 19:26 misc drwxr-xr-x 2 root root 4096 mai 2 19:26 net ./block: total 36 -rw-r--r-- 1 root root 34568 mai 2 19:26 amiflop.o ./fs: total 180 -rw-r--r-- 1 root root 7980 mai 2 19:26 binfmt_misc.o -rw-r--r-- 1 root root 96819 mai 2 19:26 hfs.o -rw-r--r-- 1 root root 41083 mai 2 19:26 minix.o -rw-r--r-- 1 root root 5388 mai 2 19:26 nls_cp437.o -rw-r--r-- 1 root root 4516 mai 2 19:26 nls_cp850.o -rw-r--r-- 1 root root 3652 mai 2 19:26 nls_iso8859-1.o -rw-r--r-- 1 root root 4236 mai 2 19:26 nls_iso8859-15.o ./misc: total 48 -rw-r--r-- 1 root root 2884 mai 2 19:26 joy-amiga.o -rw-r--r-- 1 root root 13568 mai 2 19:26 joystick.o -rw-r--r-- 1 root root 4460 mai 2 19:26 lp_intern.o -rw-r--r-- 1 root root 7328 mai 2 19:26 lp_m68k.o -rw-r--r-- 1 root root 9736 mai 2 19:26 lp_mfc.o ./net: total 160 -rw-r--r-- 1 root root 9164 mai 2 19:26 a2065.o -rw-r--r-- 1 root root 9676 mai 2 19:26 ariadne.o -rw-r--r-- 1 root root 6528 mai 2 19:26 bsd_comp.o -rw-r--r-- 1 root root 6940 mai 2 19:26 hydra.o -rw-r--r-- 1 root root 41096 mai 2 19:26 ppp.o -rw-r--r-- 1 root root 46828 mai 2 19:26 ppp_deflate.o -rw-r--r-- 1 root root 7396 mai 2 19:26 slhc.o -rw-r--r-- 1 root root 16860 mai 2 19:26 slip.o I did not see anything that could cause a problem, or could it ? Friendly, Sven LUTHER |
From: Michel <da...@re...> - 2000-07-10 08:45:36
|
Sven LUTHER wrote: > > On Sun, Jul 09, 2000 at 01:36:41PM -0700, Daniel Jacobowitz wrote: > > On Sun, Jul 09, 2000 at 10:24:36PM +0200, Michel Dänzer wrote: > > > > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > > > > > > > And see if it can be mounted ... > > > > > > It works if I omit the '=/dev/loop0' , and now on the second try (after > > > getting back to the installer main menu) df shows /dev/loop0 . > > > > > > So the problem must be elsewhere, any ideas? > > > > Oho! Now that is interesting. Is /dev/loop0 created properly (I think > > someone doublechecked that earlier...)? If so, then I would blame the > > APUS kernel patches. > > Ok, but remember, when i install the base tarball by hand, the above works > without problem, with the exact same kernel. But then modules are installed, > that is the only difference, but the loop module is builtin. > > Could there be another module that has soime influence on this ? You can find out very easily: lsmod will tell after you have mounted the image. What really caught my eye in the log though was that dbootstrap doesn't even use the -o loop[=...] mount option, it apparently uses losetup to initialize the loop device and then mounts from it directly. I feel the problem might be there somewhere. Michel -- ...and that is how we know the Earth to be banana-shaped. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: Sven L. <lu...@dp...> - 2000-07-10 08:54:48
|
On Mon, Jul 10, 2000 at 10:40:10AM +0200, Michel Dänzer wrote: > Sven LUTHER wrote: > > > > On Sun, Jul 09, 2000 at 01:36:41PM -0700, Daniel Jacobowitz wrote: > > > On Sun, Jul 09, 2000 at 10:24:36PM +0200, Michel Dänzer wrote: > > > > > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > > > > > > > > > And see if it can be mounted ... > > > > > > > > It works if I omit the '=/dev/loop0' , and now on the second try (after > > > > getting back to the installer main menu) df shows /dev/loop0 . > > > > > > > > So the problem must be elsewhere, any ideas? > > > > > > Oho! Now that is interesting. Is /dev/loop0 created properly (I think > > > someone doublechecked that earlier...)? If so, then I would blame the > > > APUS kernel patches. > > > > Ok, but remember, when i install the base tarball by hand, the above works > > without problem, with the exact same kernel. But then modules are installed, > > that is the only difference, but the loop module is builtin. > > > > Could there be another module that has soime influence on this ? > > You can find out very easily: lsmod will tell after you have mounted the > image. > > > What really caught my eye in the log though was that dbootstrap doesn't even > use the -o loop[=...] mount option, it apparently uses losetup to initialize > the loop device and then mounts from it directly. I feel the problem might be > there somewhere. Yes, it does some funny piping and other stuff, should look in the dbootstrap code to get the exact command. Friendly, Sven LUTHER |
From: Sven L. <lu...@dp...> - 2000-07-10 08:25:46
|
On Sun, Jul 09, 2000 at 10:24:36PM +0200, Michel Dänzer wrote: > Sven LUTHER wrote: > > > 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. > > Confirm that. ("Roger that" ;) > > Messages from VT 3 I consider relevant: > > running cmd 'mount -r -t ext2 /dev/loop0 /floppy' > Mounting /dev/loop0 on /floppy failed: invalid argument > > Looks like it tries to use /dev/loop0 as a fake floppy drive and fails. > > > > 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 > > It has just worked for me with just '-o loop', and I notice that it seems to > be mounted from /dev/loop1 (df output). Ok, nice to know that, will try this evening, ... If that is true, it must most definitvely be related to the mount program, ... > > $ mount -r -t vfat -o loop=/dev/loop0 resceu.bin /mnt > > > > And see if it can be mounted ... > > It works if I omit the '=/dev/loop0' , and now on the second try (after > getting back to the installer main menu) df shows /dev/loop0 . well, i confirm this works on my i386 box (changing resceu to rescue naturally), as well as on apus, when i boot into the base install (with the true mount) Erik, what do you think about it ? Friendly, Sven LUTHER |