Re: bugs 64500 and 64823
Sven LUTHER <luther@debian.org> writes:
> On Sat, Jul 15, 2000 at 07:52:09AM +1000, Anthony Towns wrote:
> > Hello world,
> >
> > After installing b-f 2.2.16, 64500 and 64823 still seem to be
> > open. Are these RC? Are they already fixed? Do they require a 2.2.17 be
> > built? What's the deal?
>
> Hello, ...
>
> I posted a message about it some week ago, but i don't see it anywehere, so i
> suppose it got lost.
>
> The 64500 bug is still there, i don't know how to fix it, and got not very
> much (usefull) response to my call for help mail, on this list, nor really
> from the linux-apus mailing list, so i guess most people there are not so
> interrested in it, ...
>
> It has been confirmed by another apus user (Michel Dänzer), and Erik Andersen
> promised to have a look into the busybox mount, but i didn't hear again from
> him.
>
> The problem is that, using the exactly same kernel, when i do the following :
>
> # mount -r -t vfat -o loop=/dev/loop0 rescue.bin /mnt
>
> when booting from the root image, i get a :
>
> Mounting rescue.bin on /mnt failed : block device required
>
> which naturally hinders the install os kernel & modules menu option.
>
> but when ignoring this option and the configure modules, installing the rest
> of the stuff as usual, and then booting (again with the exact same kernel)
> into the newly installed root partition, the above mentioned command works
> without problem.
>
> Michel Daenzer has reported that when doing :
>
> # mount -r -t vfat -o loop rescue.bin /mnt
>
> from the root image it works ok, and rescue.bin get mounted into the loop0
> device.
>
> naturally i checked that the /dev/loop0 device is available and readable (it
> has the same rights in both root /dev).
>
> Ok, this is the current status. Now, what can we do about it ?
Wait a minnit. Why can't we just change dbootstrap to give the mount
command Michel mentioned, rather than the one which you mentioned?
Assuming taht doesn't break other arches (don't see why it would) then
we have a pretty damn good workaround... no?
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: