Re: bugs 64500 and 64823
- To: firstname.lastname@example.org
- Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: bugs 64500 and 64823
- From: Sven LUTHER <firstname.lastname@example.org>
- Date: Fri, 21 Jul 2000 10:28:45 +0200
- Message-id: <[🔎] 20000721102845.A6389@lambda.u-strasbg.fr>
- Mail-followup-to: Sven LUTHER <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Reply-to: firstname.lastname@example.org
- In-reply-to: <[🔎] 20000715075209.A28667@azure.humbug.org.au>; from email@example.com on Sat, Jul 15, 2000 at 07:52:09AM +1000
- References: <[🔎] 20000715075209.A28667@azure.humbug.org.au>
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?
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
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
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
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 ?
It is possible to install debian/ppc/apus in the current state of things, but
a newbie would need further help about this, and i best would provide that
help before the release, if we cannot fix the problem.
I preconize the following possible solution :
* We decide not to support ppc/apus officially, :(((
* We ship in the current status, but in this case, i would remove the
"install os kernel & modules" as well as the "configure modules" menu
options. The documentation would need to be updated to show the propper
install procedure. Ideally, we could just install and configure by hand
the kernel-image-2.2.10-apus kernel package after the install.
* We install the modules from the provided apus/drivers.tgz tarball, thus no
need for mounting the rescue disk (as anyway, the kernel is not needed on
the linux partition, since we have no lilo-like boot option). I tried to
do this, but didn't want to mess with the dbootstrap stuff who did this,
that i didn't understand. dbootstrap code can be particularly obscure at
In any way, please keep me informed about this issue, so i can update the docs
accordingly before the release.
Hope this is helpful information ...