linux-apus-devel

Re: bugs 64500 and 64823

[Sven L. <lu...@de...>]

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 ?

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
    times :(((.

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 ...

Friendly,

Sven LUTHER

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@de...> 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....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Sat, Aug 26, 2000 at 08:24:16PM -0400, Adam Di Carlo wrote:
> > 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?
> 

Hello Adam, ...

Nice to see that you are again looking into it, I have to confess that i did
not look more into it, because i really hadn't time to play with boot floppies
anymore, and that the response from the apus community didn't was very high
(well apart from michel i didn't get any response to my call for confirmation
on the apus lists).

That said, yes, please do it. I will gladly try out anything and confirm it's
good work. I will also rewrite the documentation stuff once it is fixed to
show the new state of this stuff. 

I think the apus subarch need a boot loader and kernel upgrade also.

BTW, i suppose this is for woody, or maybe a potato upgrade ?

Friendly,

Sven LUTHER

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> I think the apus subarch need a boot loader and kernel upgrade also.

Ugh.

> BTW, i suppose this is for woody, or maybe a potato upgrade ?

I'm working only on a Potato upgrade.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Tue, Sep 05, 2000 at 09:50:38AM -0400, Adam Di Carlo wrote:
> Sven LUTHER <lu...@dp...> writes:
> 
> > I think the apus subarch need a boot loader and kernel upgrade also.
> 
> Ugh.

No problem i can do a new kernel package, and the boot loader is only one dir
to change. It is not really necessary, since you can use non-debian kernel and
bootloader without problem, but it would be neater.

Docs will need to be updated though.

> > BTW, i suppose this is for woody, or maybe a potato upgrade ?
> 
> I'm working only on a Potato upgrade.

Ok, ...

Any time frame so that i can manage my time for it ?

Friendly,

Sven LUTHER

Re: Bug#64500: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> > I'm working only on a Potato upgrade.
> 
> Ok, ...
> 
> Any time frame so that i can manage my time for it ?

We're shooting for oct 1 I think.  I would say earlier but if we wanna
wait for 2.2.17-1 we have little choice -- there are no idepci and
compact images, not to mention non-i386 architecture kernel upgrades,
and testing all that.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Sat, Aug 26, 2000 at 08:24:16PM -0400, Adam Di Carlo wrote:
> 
> 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, i have seen Ben's call for potato r2, and thought we may solve this, as
well as upgrade the apus port to a more recent kernel (well, still 2.2.10, but
with more work done by the linux-apus folk).

Also i did a CD install on an i386 box recently, and noticed that when
installing the kernel & os, it searches for drivers.tgz and not for
rescue.bin.

Since the apus install is much more akin to a CD install anyway (we just copy
the stuff to the harddisk, and take everything from there) it would make much
more sense to do it in the same way.

Is there somethign special involved when dbootstrap installs from a CD ? how
can we make dbootstrap install think it is installing from a CD when we are on
apus ?

It has been a long time since i looked at boot-floppies, though.

Friendly,

Sven Luther

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> Is there somethign special involved when dbootstrap installs from a CD ? how
> can we make dbootstrap install think it is installing from a CD when we are on
> apus ?

Have it pass the 'cdrom' boot argument is the easiest way.

There's a check in dbootstrap but I don't think that's working
quite, at least, it didn't seem to work properly on i386.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote:
> Sven LUTHER <lu...@dp...> writes:
> 
> > Is there somethign special involved when dbootstrap installs from a CD ? how
> > can we make dbootstrap install think it is installing from a CD when we are on
> > apus ?
> 
> Have it pass the 'cdrom' boot argument is the easiest way.

Err, ...

how do i do that ?

for information, we launch the install process from a bootloader, some variant
of the amiboot used by m68k/amiga. The option of it are the name of the
kernel, the name of the root image and the usual kernel options. 

> There's a check in dbootstrap but I don't think that's working
> quite, at least, it didn't seem to work properly on i386.

Well, i installed potato on a i386 box from a cd, and it worked in the way i
would like it to behave.

Friendly,

Sven Luther

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote:
> > Sven LUTHER <lu...@dp...> writes:
> > 
> > > Is there somethign special involved when dbootstrap installs from a CD ? how
> > > can we make dbootstrap install think it is installing from a CD when we are on
> > > apus ?
> > 
> > Have it pass the 'cdrom' boot argument is the easiest way.
> 
> Err, ...
> 
> how do i do that ?
> 
> for information, we launch the install process from a bootloader, some variant
> of the amiboot used by m68k/amiga. The option of it are the name of the
> kernel, the name of the root image and the usual kernel options. 

Yes, its a kernel boot argument.  surely you're boot loader lets you
pass arguments to the kernel, such that they show up in /proc/cmdline
?

> > There's a check in dbootstrap but I don't think that's working
> > quite, at least, it didn't seem to work properly on i386.
> 
> Well, i installed potato on a i386 box from a cd, and it worked in the way i
> would like it to behave.

Glad to hear that.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Thu, Nov 30, 2000 at 10:17:09AM -0500, Adam Di Carlo wrote:
> Sven LUTHER <lu...@dp...> writes:
> 
> > On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote:
> > > Sven LUTHER <lu...@dp...> writes:
> > > 
> > > > Is there somethign special involved when dbootstrap installs from a CD ? how
> > > > can we make dbootstrap install think it is installing from a CD when we are on
> > > > apus ?
> > > 
> > > Have it pass the 'cdrom' boot argument is the easiest way.
> > 
> > Err, ...
> > 
> > how do i do that ?
> > 
> > for information, we launch the install process from a bootloader, some variant
> > of the amiboot used by m68k/amiga. The option of it are the name of the
> > kernel, the name of the root image and the usual kernel options. 
> 
> Yes, its a kernel boot argument.  surely you're boot loader lets you

ok, ...

> pass arguments to the kernel, such that they show up in /proc/cmdline ?

Yes, usre, i didn't understand how you read it back though, but if you parse
/proc/cmdline, it is easy ...

> > > There's a check in dbootstrap but I don't think that's working
> > > quite, at least, it didn't seem to work properly on i386.
> > 
> > Well, i installed potato on a i386 box from a cd, and it worked in the way i
> > would like it to behave.
> 
> Glad to hear that.

Will ask for a new round of testing, ...
And then upgrade the docs.

BTW, i guess another option would be to look at the place where we read
/proc/cmdline, and then set things up as if the boot arg cdrom was entered if
and only if we are on ppc and on the apus subarch. Which file should i look
for that ? mmm, maybe i should try some grepping, ...

What is the time schedule for potato r2 ? any chance to have this included (at
least the documentation fix telling about the cdrom boot option, but we are
working on a kernel + bootstrapper upgrade for apus also).

Friendly,

Sven Luther

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> BTW, i guess another option would be to look at the place where we read
> /proc/cmdline, and then set things up as if the boot arg cdrom was entered if
> and only if we are on ppc and on the apus subarch. Which file should i look
> for that ? mmm, maybe i should try some grepping, ...

Please, lets solve this generally rather than on an arch-by-arch
basis.

dbootstrap should be clever enough to sense that a given CD-ROM is a
normal, official one and act accordingly, e.g., suck that stuff in
without further prompting.  This should be the case no matter what the
cmdline argument were.  Rigth now this is not working, at least, not
on i386 when I tested it from 2.2r0 or r1 (not sure).

> What is the time schedule for potato r2 ? any chance to have this included (at
> least the documentation fix telling about the cdrom boot option, but we are
> working on a kernel + bootstrapper upgrade for apus also).

This is a 2.2r3 issue... 2.2r2 is going out within a few hours and I'm
not doing any more boot-floppies builds for it.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Thu, Nov 30, 2000 at 01:40:52PM -0500, Adam Di Carlo wrote:
> Sven LUTHER <lu...@dp...> writes:
> 
> > BTW, i guess another option would be to look at the place where we read
> > /proc/cmdline, and then set things up as if the boot arg cdrom was entered if
> > and only if we are on ppc and on the apus subarch. Which file should i look
> > for that ? mmm, maybe i should try some grepping, ...
> 
> Please, lets solve this generally rather than on an arch-by-arch
> basis.
> 
> dbootstrap should be clever enough to sense that a given CD-ROM is a
> normal, official one and act accordingly, e.g., suck that stuff in
> without further prompting.  This should be the case no matter what the
> cmdline argument were.  Rigth now this is not working, at least, not
> on i386 when I tested it from 2.2r0 or r1 (not sure).

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.

> > What is the time schedule for potato r2 ? any chance to have this included (at
> > least the documentation fix telling about the cdrom boot option, but we are
> > working on a kernel + bootstrapper upgrade for apus also).
> 
> This is a 2.2r3 issue... 2.2r2 is going out within a few hours and I'm
> not doing any more boot-floppies builds for it.

Not even a hand update of the install-apus.txt file ? 

Well i guess it is too late anyway, no problem, 

When is r3 scheduled for ?

Friendly,

Sven Luther

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> 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.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>

Re: bugs 64500 and 64823

[Sven L. <lu...@dp...>]

On Sat, Dec 02, 2000 at 02:12:02PM -0500, Adam Di Carlo wrote:
> Sven LUTHER <lu...@dp...> 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

Re: bugs 64500 and 64823

[Adam Di C. <ad...@on...>]

Sven LUTHER <lu...@dp...> writes:

> 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 ?

No problem with it, no.

-- 
.....Adam Di Carlo....ad...@on........<URL:http://www.onShore.com/>