[parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

Including parisc-linux@parisc-linux.org as that is where the hppa
developers tend to hang out.

I just had a quick try with 

http://gluck.debian.org/cdimage/testing/daily/hppa/20040411/sarge-hppa-businesscard.iso

I burnt an ISO, and it wouldn't boot on my B180.  It stopped after
'choosing a 32 bit kernel', which I assume indicates some palo
issue.  I believe the ISO was burnt ok, because I later loaded
the udebs from it.

Next I copied the 32 bit kernel and initrd.gz from the ISO and
generated a lifimage, using:

/sbin/palo -k vmlinux-2.4.25-32 -r initrd.gz -c 'ramdisk_size=8192 root=/dev/ram initrd=0/ramdisk devfs=mount,dall' -s di.lifimage -f /dev/null

That netbooted and the kernel started ok, but gave continual segfaults
in frontend, as we saw before.

Next I loopback mounted the initrd and copied the libm-2.3.2.so from
my (not very uptodate) sid system to the initrd overwriting the
libm.so.6 on there (which had been reduced to about 1200 bytes).
A workaround for the glibc issue is to avoid reducing libm to the
point where it has no symbols at all.

I gzipped the initrd again and reran palo.  The new lifimage booted
ok, used framebuffer, and looks fine.  I didn't try modifying any
disk partitions but it found the existing ones ok, including the
palo boot partition which was correctly recognised.

It may be relevant that my palo is 1.3, while the ISO was using
palo 1.4.

It may be relevant that the ISO had a rather long kernel commandline,
relative to the 127 char limit that palo claims.  I'm never sure
whether that 127 char limit is before or after palo adds all the
console and sti related parameters though.

As the ISO I burnt was still in the drive, d-i found that and loaded the
udebs from it.  I then went on to select a remote mirror for loading
the debs.

The install completed successfully, although it installed a 2.4.20
kernel (I guess that is the most recent in testing).

baseconfig worked, although I saw a message in the apt setup stage
briefly that looked like some shell complaint about '['.

Perhaps we should 'fix' mklibs on the system that builds the images to
not reduce libm completely.  Then we need to figure out what the palo
issue is.

This is what i currently have in my mklibs (which I guess worked
round the issue when I last worked on hppa d-i):

    # to be the only one and including it on alpha as well
    # doesn't hurt. I guess all archs can live with this.
    needed_symbols.add(("sys_siglist", 1))
    # This is a hack to stop libm being reduced to nothing
+   # RGH.
+   needed_symbols.add(("log", 1))

    # calculate what symbols are present in small_libs
    present_symbols = Set()

I was surprised to see seperate kernel images, initrd, and iplboot
files on the ISO.  I'd say most people netbooted their hppa boxes,
and we should include a complete lifimage rather than the individual
components.  It may be that this initrd wouldn't have worked if it
had needed to pull udebs from the net though.

Many thanks to the hppa developers that got us a 2.4.25 kernel for
d-i, and to Jeff for the daily images.

Richard


On Sun, Apr 11, 2004 at 01:46:29PM -0400, Joey Hess wrote:
> Kyle McMartin wrote:
> > [Instead of directly CC'ing you Joey, I'm cross-posting to debian-boot]
> > 
> > On Sun, Apr 11, 2004 at 12:54:59PM -0400, Joey Hess wrote:
> > > I just want to make sure that you hppa folk realise that hppa is further
> > > from having a working installer for sarge than any architecture aside
> > > from perhaps s390. AFAIK only one person is working on it at all (and
> > > he's currently away, and his time is split amoung other ports anyway).
> > > The d-i port really needs more than one person working on it, if it's
> > > going to ship with beta 4 of d-i. That's in two weeks.
> > > 
> > > Note that hppa basically worked in mid-January, but it's not been kept
> > > up.
> > > 
> > 
> > The problem with hppa now, seems to be the same as what Richard Hirst
> > reported in January. The initrd issues seem to have been taken care of,
> > and now it's simply a segmentation fault causing problems.
> > 
> > VFS: Mounted root (ext2 filesystem) readonly.                                   
> > Mounted devfs on /dev                                                           
> > Freeing unused kernel memory: 252k freed                                        
> > Setting up filesystem, please wait ...                                          
> > umount: /initrd: Invalid argument                                               
> > Segmentation fault                                                              
> > Segmentation fault
> > [...]
> > 
> > Is what I get when booting the latest netboot build on my 715/100XC.
> 
> There is a patch in the bts for this problem, #228375. I assme that a
> fixed libc6 will be uploaded eventually, but in the meantime I'd hope
> the workaround also in there, which Richard Hirst used, is enough to let
> things be tested and let everything else be gotten working. Basically,
> don't let this issue block you from working on the hppa port!
> 
> -- 
> see shy jo

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[James Bottomley]

On Mon, 2004-04-12 at 06:12, Richard Hirst wrote:
> It may be relevant that the ISO had a rather long kernel commandline,
> relative to the 127 char limit that palo claims.  I'm never sure
> whether that 127 char limit is before or after palo adds all the
> console and sti related parameters though.

That limit is absolute and may not be overrun.  The co-ordinates of the
64 bit kernel lie immediately after the 128 char buffer.  Usually the
system is unbootable if you overrun this limit.

Unfortunately, palo is rather poor about checking this limit when
installing the image or modifying the command line...

James

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

On Mon, Apr 12, 2004 at 09:19:27AM -0500, James Bottomley wrote:
> On Mon, 2004-04-12 at 06:12, Richard Hirst wrote:
> > It may be relevant that the ISO had a rather long kernel commandline,
> > relative to the 127 char limit that palo claims.  I'm never sure
> > whether that 127 char limit is before or after palo adds all the
> > console and sti related parameters though.
> 
> That limit is absolute and may not be overrun.  The co-ordinates of the
> 64 bit kernel lie immediately after the 128 char buffer.  Usually the
> system is unbootable if you overrun this limit.

Unbootable, or unbootable on 64 bit h/w?

> Unfortunately, palo is rather poor about checking this limit when
> installing the image or modifying the command line...

and last time I tried building palo on a sid system to investigate
these hangs on boot, the result didn't work at all :(

Richard

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[James Bottomley]

On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
> Unbootable, or unbootable on 64 bit h/w?

It seems to be unbootable entirely, but for 32 bit kernels that's random
(sometimes it will, sometimes it won't).

> > Unfortunately, palo is rather poor about checking this limit when
> > installing the image or modifying the command line...
> 
> and last time I tried building palo on a sid system to investigate
> these hangs on boot, the result didn't work at all :(

I think just reducing the command line would be the best option.  Why's
it so long?

James

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

On Mon, Apr 12, 2004 at 10:15:46AM -0500, James Bottomley wrote:
> On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
> > Unbootable, or unbootable on 64 bit h/w?
> 
> It seems to be unbootable entirely, but for 32 bit kernels that's random
> (sometimes it will, sometimes it won't).
> 
> > > Unfortunately, palo is rather poor about checking this limit when
> > > installing the image or modifying the command line...
> > 
> > and last time I tried building palo on a sid system to investigate
> > these hangs on boot, the result didn't work at all :(
> 
> I think just reducing the command line would be the best option.  Why's
> it so long?

This is the cmdline when booting from the aforementioned ISO:

Command line for kernel: 'ramdisk_size=8192 root=/dev/ram      devfs=mount,dall 
init=/linuxrc DEBCONF_PRIORITY=high console=tty0 sti=8/24 sti_font=VGA8x16 TERM=
linux palo_kernel=0/vmlinux'

Looks like 162 chars to me.

You can deduce how much of that comes from the d-i build process and how
much is manufactured by palo on boot from the start of the ISO:

0000000: 8000 5041 4c4f 0003 00c8 e000 003d fddd  ..PALO.......=..
0000010: 0053 5000 001b e9de 302f 766d 6c69 6e75  .SP.....0/vmlinu
0000020: 7820 7261 6d64 6973 6b5f 7369 7a65 3d38  x ramdisk_size=8
0000030: 3139 3220 726f 6f74 3d2f 6465 762f 7261  192 root=/dev/ra
0000040: 6d20 2020 2020 2069 6e69 7472 643d 302f  m      initrd=0/
0000050: 7261 6d64 6973 6b20 6465 7666 733d 6d6f  ramdisk devfs=mo
0000060: 756e 742c 6461 6c6c 2069 6e69 743d 2f6c  unt,dall init=/l
0000070: 696e 7578 7263 2044 4542 434f 4e46 5f50  inuxrc DEBCONF_P
0000080: 5249 4f52 4954 593d 6869 6768 0000 0000  RIORITY=high....

I don't know what default ramdisk size we build the kernel for, but
it needs to be over 6MB (initrd is 6449152 bytes this time).

Note palo has added at least
"console=tty0 sti=8/24 sti_font=VGA8x16 TERM=linux palo_kernel=0/vmlinux"

which looks like 71 of our 127 chars - hence my comment about
whether or not the 127 char limit is supposed to include the
bits added by palo.

If we just take the part that is passed to palo when the ISO is
mastered, I guess that is

"ramdisk_size=8192 root=/dev/ram      initrd=0/ramdisk devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high"

which is well under 127.

Richard

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

On Mon, Apr 12, 2004 at 10:15:46AM -0500, James Bottomley wrote:
> On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
> > Unbootable, or unbootable on 64 bit h/w?
> 
> It seems to be unbootable entirely, but for 32 bit kernels that's random
> (sometimes it will, sometimes it won't).
> 
> > > Unfortunately, palo is rather poor about checking this limit when
> > > installing the image or modifying the command line...
> > 
> > and last time I tried building palo on a sid system to investigate
> > these hangs on boot, the result didn't work at all :(
> 
> I think just reducing the command line would be the best option.  Why's
> it so long?

This is the cmdline when booting from the aforementioned ISO:

Command line for kernel: 'ramdisk_size=8192 root=/dev/ram      devfs=mount,dall 
init=/linuxrc DEBCONF_PRIORITY=high console=tty0 sti=8/24 sti_font=VGA8x16 TERM=
linux palo_kernel=0/vmlinux'

Looks like 162 chars to me.

You can deduce how much of that comes from the d-i build process and how
much is manufactured by palo on boot from the start of the ISO:

0000000: 8000 5041 4c4f 0003 00c8 e000 003d fddd  ..PALO.......=..
0000010: 0053 5000 001b e9de 302f 766d 6c69 6e75  .SP.....0/vmlinu
0000020: 7820 7261 6d64 6973 6b5f 7369 7a65 3d38  x ramdisk_size=8
0000030: 3139 3220 726f 6f74 3d2f 6465 762f 7261  192 root=/dev/ra
0000040: 6d20 2020 2020 2069 6e69 7472 643d 302f  m      initrd=0/
0000050: 7261 6d64 6973 6b20 6465 7666 733d 6d6f  ramdisk devfs=mo
0000060: 756e 742c 6461 6c6c 2069 6e69 743d 2f6c  unt,dall init=/l
0000070: 696e 7578 7263 2044 4542 434f 4e46 5f50  inuxrc DEBCONF_P
0000080: 5249 4f52 4954 593d 6869 6768 0000 0000  RIORITY=high....

I don't know what default ramdisk size we build the kernel for, but
it needs to be over 6MB (initrd is 6449152 bytes this time).

Note palo has added at least
"console=tty0 sti=8/24 sti_font=VGA8x16 TERM=linux palo_kernel=0/vmlinux"

which looks like 71 of our 127 chars - hence my comment about
whether or not the 127 char limit is supposed to include the
bits added by palo.

If we just take the part that is passed to palo when the ISO is
mastered, I guess that is

"ramdisk_size=8192 root=/dev/ram      initrd=0/ramdisk devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high"

which is well under 127.

Richard

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Thiemo Seufer]

Richard Hirst wrote:
[snip]
> > I think just reducing the command line would be the best option.  Why's
> > it so long?
> 
> This is the cmdline when booting from the aforementioned ISO:
> 
> Command line for kernel: 'ramdisk_size=8192 root=/dev/ram      devfs=mount,dall 
> init=/linuxrc DEBCONF_PRIORITY=high console=tty0 sti=8/24 sti_font=VGA8x16 TERM=
> linux palo_kernel=0/vmlinux'

> Note palo has added at least
> "console=tty0 sti=8/24 sti_font=VGA8x16 TERM=linux palo_kernel=0/vmlinux"
> 
> which looks like 71 of our 127 chars - hence my comment about
> whether or not the 127 char limit is supposed to include the
> bits added by palo.
> 
> If we just take the part that is passed to palo when the ISO is
> mastered, I guess that is
> 
> "ramdisk_size=8192 root=/dev/ram      initrd=0/ramdisk devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high"

I doubt all of these are needed. At least root= and devfs= aren't
in use any more on other d-i arches, same for linuxrc.

The TERM=linux mentioned above looks a bit weird to me, shouldn't
it be default anyway?


Thiemo

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Thiemo Seufer]

Richard Hirst wrote:
[snip]
> > I think just reducing the command line would be the best option.  Why's
> > it so long?
> 
> This is the cmdline when booting from the aforementioned ISO:
> 
> Command line for kernel: 'ramdisk_size=8192 root=/dev/ram      devfs=mount,dall 
> init=/linuxrc DEBCONF_PRIORITY=high console=tty0 sti=8/24 sti_font=VGA8x16 TERM=
> linux palo_kernel=0/vmlinux'

> Note palo has added at least
> "console=tty0 sti=8/24 sti_font=VGA8x16 TERM=linux palo_kernel=0/vmlinux"
> 
> which looks like 71 of our 127 chars - hence my comment about
> whether or not the 127 char limit is supposed to include the
> bits added by palo.
> 
> If we just take the part that is passed to palo when the ISO is
> mastered, I guess that is
> 
> "ramdisk_size=8192 root=/dev/ram      initrd=0/ramdisk devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high"

I doubt all of these are needed. At least root= and devfs= aren't
in use any more on other d-i arches, same for linuxrc.

The TERM=linux mentioned above looks a bit weird to me, shouldn't
it be default anyway?


Thiemo

Re: [parisc-linux] Re: if something is not done, hppa will not havean installer for sarge

[Andy Walker]

> On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
>> Unbootable, or unbootable on 64 bit h/w?
>
> It seems to be unbootable entirely, but for 32 bit kernels that's random
> (sometimes it will, sometimes it won't).
>
>> > Unfortunately, palo is rather poor about checking this limit when
>> > installing the image or modifying the command line...
>>
>> and last time I tried building palo on a sid system to investigate
>> these hangs on boot, the result didn't work at all :(
>
> I think just reducing the command line would be the best option.  Why's
> it so long?
>
> James

Well, palo adds a whole bunch of stuff to the command line automatically.
If, for example, your /boot directory is on the root partition and you're
testing a kernel called vmlinux-2.6.5-rc1-pa5, then you get at least:

kernel=0/boot/vmlinux-2.6.5-rc1-pa5
root=/dev/sda1
console=tty0
sti=8/24
palo_kernel=0/boot/vmlinux-2.6.5-rc1-pa5

In fact I think there is more (the B132L is offline right now and
the C180 is boostrapping Gentoo so I can't check). Then you only
need to add another parameter, like the very reasonable:

stifb=bpp:32

and you're screwed. Been there, done that!

-Andy

Re: [parisc-linux] Re: if something is not done, hppa will not havean installer for sarge

[Andy Walker]

> On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
>> Unbootable, or unbootable on 64 bit h/w?
>
> It seems to be unbootable entirely, but for 32 bit kernels that's random
> (sometimes it will, sometimes it won't).
>
>> > Unfortunately, palo is rather poor about checking this limit when
>> > installing the image or modifying the command line...
>>
>> and last time I tried building palo on a sid system to investigate
>> these hangs on boot, the result didn't work at all :(
>
> I think just reducing the command line would be the best option.  Why's
> it so long?
>
> James

Well, palo adds a whole bunch of stuff to the command line automatically.
If, for example, your /boot directory is on the root partition and you're
testing a kernel called vmlinux-2.6.5-rc1-pa5, then you get at least:

kernel=0/boot/vmlinux-2.6.5-rc1-pa5
root=/dev/sda1
console=tty0
sti=8/24
palo_kernel=0/boot/vmlinux-2.6.5-rc1-pa5

In fact I think there is more (the B132L is offline right now and
the C180 is boostrapping Gentoo so I can't check). Then you only
need to add another parameter, like the very reasonable:

stifb=bpp:32

and you're screwed. Been there, done that!

-Andy

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[James Bottomley]

On Mon, 2004-04-12 at 10:05, Richard Hirst wrote:
> Unbootable, or unbootable on 64 bit h/w?

It seems to be unbootable entirely, but for 32 bit kernels that's random
(sometimes it will, sometimes it won't).

> > Unfortunately, palo is rather poor about checking this limit when
> > installing the image or modifying the command line...
> 
> and last time I tried building palo on a sid system to investigate
> these hangs on boot, the result didn't work at all :(

I think just reducing the command line would be the best option.  Why's
it so long?

James

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

On Mon, Apr 12, 2004 at 09:19:27AM -0500, James Bottomley wrote:
> On Mon, 2004-04-12 at 06:12, Richard Hirst wrote:
> > It may be relevant that the ISO had a rather long kernel commandline,
> > relative to the 127 char limit that palo claims.  I'm never sure
> > whether that 127 char limit is before or after palo adds all the
> > console and sti related parameters though.
> 
> That limit is absolute and may not be overrun.  The co-ordinates of the
> 64 bit kernel lie immediately after the 128 char buffer.  Usually the
> system is unbootable if you overrun this limit.

Unbootable, or unbootable on 64 bit h/w?

> Unfortunately, palo is rather poor about checking this limit when
> installing the image or modifying the command line...

and last time I tried building palo on a sid system to investigate
these hangs on boot, the result didn't work at all :(

Richard

Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[James Bottomley]

On Mon, 2004-04-12 at 06:12, Richard Hirst wrote:
> It may be relevant that the ISO had a rather long kernel commandline,
> relative to the 127 char limit that palo claims.  I'm never sure
> whether that 127 char limit is before or after palo adds all the
> console and sti related parameters though.

That limit is absolute and may not be overrun.  The co-ordinates of the
64 bit kernel lie immediately after the 128 char buffer.  Usually the
system is unbootable if you overrun this limit.

Unfortunately, palo is rather poor about checking this limit when
installing the image or modifying the command line...

James

[parisc-linux] Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

Including parisc-linux@parisc-linux.org as that is where the hppa
developers tend to hang out.

I just had a quick try with 

http://gluck.debian.org/cdimage/testing/daily/hppa/20040411/sarge-hppa-businesscard.iso

I burnt an ISO, and it wouldn't boot on my B180.  It stopped after
'choosing a 32 bit kernel', which I assume indicates some palo
issue.  I believe the ISO was burnt ok, because I later loaded
the udebs from it.

Next I copied the 32 bit kernel and initrd.gz from the ISO and
generated a lifimage, using:

/sbin/palo -k vmlinux-2.4.25-32 -r initrd.gz -c 'ramdisk_size=8192 root=/dev/ram initrd=0/ramdisk devfs=mount,dall' -s di.lifimage -f /dev/null

That netbooted and the kernel started ok, but gave continual segfaults
in frontend, as we saw before.

Next I loopback mounted the initrd and copied the libm-2.3.2.so from
my (not very uptodate) sid system to the initrd overwriting the
libm.so.6 on there (which had been reduced to about 1200 bytes).
A workaround for the glibc issue is to avoid reducing libm to the
point where it has no symbols at all.

I gzipped the initrd again and reran palo.  The new lifimage booted
ok, used framebuffer, and looks fine.  I didn't try modifying any
disk partitions but it found the existing ones ok, including the
palo boot partition which was correctly recognised.

It may be relevant that my palo is 1.3, while the ISO was using
palo 1.4.

It may be relevant that the ISO had a rather long kernel commandline,
relative to the 127 char limit that palo claims.  I'm never sure
whether that 127 char limit is before or after palo adds all the
console and sti related parameters though.

As the ISO I burnt was still in the drive, d-i found that and loaded the
udebs from it.  I then went on to select a remote mirror for loading
the debs.

The install completed successfully, although it installed a 2.4.20
kernel (I guess that is the most recent in testing).

baseconfig worked, although I saw a message in the apt setup stage
briefly that looked like some shell complaint about '['.

Perhaps we should 'fix' mklibs on the system that builds the images to
not reduce libm completely.  Then we need to figure out what the palo
issue is.

This is what i currently have in my mklibs (which I guess worked
round the issue when I last worked on hppa d-i):

    # to be the only one and including it on alpha as well
    # doesn't hurt. I guess all archs can live with this.
    needed_symbols.add(("sys_siglist", 1))
    # This is a hack to stop libm being reduced to nothing
+   # RGH.
+   needed_symbols.add(("log", 1))

    # calculate what symbols are present in small_libs
    present_symbols = Set()

I was surprised to see seperate kernel images, initrd, and iplboot
files on the ISO.  I'd say most people netbooted their hppa boxes,
and we should include a complete lifimage rather than the individual
components.  It may be that this initrd wouldn't have worked if it
had needed to pull udebs from the net though.

Many thanks to the hppa developers that got us a 2.4.25 kernel for
d-i, and to Jeff for the daily images.

Richard


On Sun, Apr 11, 2004 at 01:46:29PM -0400, Joey Hess wrote:
> Kyle McMartin wrote:
> > [Instead of directly CC'ing you Joey, I'm cross-posting to debian-boot]
> > 
> > On Sun, Apr 11, 2004 at 12:54:59PM -0400, Joey Hess wrote:
> > > I just want to make sure that you hppa folk realise that hppa is further
> > > from having a working installer for sarge than any architecture aside
> > > from perhaps s390. AFAIK only one person is working on it at all (and
> > > he's currently away, and his time is split amoung other ports anyway).
> > > The d-i port really needs more than one person working on it, if it's
> > > going to ship with beta 4 of d-i. That's in two weeks.
> > > 
> > > Note that hppa basically worked in mid-January, but it's not been kept
> > > up.
> > > 
> > 
> > The problem with hppa now, seems to be the same as what Richard Hirst
> > reported in January. The initrd issues seem to have been taken care of,
> > and now it's simply a segmentation fault causing problems.
> > 
> > VFS: Mounted root (ext2 filesystem) readonly.                                   
> > Mounted devfs on /dev                                                           
> > Freeing unused kernel memory: 252k freed                                        
> > Setting up filesystem, please wait ...                                          
> > umount: /initrd: Invalid argument                                               
> > Segmentation fault                                                              
> > Segmentation fault
> > [...]
> > 
> > Is what I get when booting the latest netboot build on my 715/100XC.
> 
> There is a patch in the bts for this problem, #228375. I assme that a
> fixed libc6 will be uploaded eventually, but in the meantime I'd hope
> the workaround also in there, which Richard Hirst used, is enough to let
> things be tested and let everything else be gotten working. Basically,
> don't let this issue block you from working on the hppa port!
> 
> -- 
> see shy jo