Re: bugs 64500 and 64823
On Sat, Dec 02, 2000 at 02:12:02PM -0500, Adam Di Carlo wrote:
> Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
>
> > Well, the problem is that it is not an official CDROM, but a copy of the
> > archive on harddisk. There is no sense to generate rescue.bin on apus, since
> > it is only used for getting the modules out of it. The kernel stays in the
> > native partition anyway, and it is not the one from rescue.bin who is used.
> >
> > And it did work for potato r0 when i did an install (are we speaking about the
> > same thing, i booted on the cdrom, and installed potato as normal. When it
> > should have mounted rescue.bin, it unpacked drivers.tgz instead.
>
> Well, I can't reproduce this problem on i386. maybe I don't
> understand the report. Please try booting with 'debug', filing a bug
> report, and include the installer log in the report.
Huh, ...
i think we are not speaking about the same thing here, this is a solution to
solve the bug 64500, which is that the potato boot floppies on the ppc/apus
subarch have a problem when doing the install os kenrel & modules.
The main problem of it is that the boot-floppies consider the install as using
floppies, which is a non-sense on apus, unless you want to to make 720Kb boot
floppies. Anyway, the kernel installed as part of the process would never be
used, since there is no lilo equivalent on apus.
I discovered that it is possible to use not rescue.bin, but the kernel (a file
called linux) and the driver tarball directly (a file called drivers.tgz).
This is achieved by passing the cdrom option to the kernel.
All apus installs are done from a copy of the files from the harddisk, or
maybe from a CD (altough i don't think the ppc cdroms are bootable on apus
anyway, but you can launch a install program from the cdrom).
All in all, what i would want to happen is that when dbootstrap detects it is
running on an apus subarch, it does the same thing as if cdrom was supplied,
in case it was forgotten. It would be a 3 lines patch or so, surrounded by a
#ifd __powerpc__ or something such, thus not affecting i386 at all.
Do you still have any problem with it ?
Friendly,
Sven Luther
Reply to: