Re: elilo-installer copyright status

[Richard Hirst]

Hey Dann,

Not sure what you want me to say, but "GPL version 2 or later" is
fine with me.  It was a long time ago, but as I recall I just wrote
a shell script and did a bit of packaging work.

Richard


dann frazier wrote:

(Trying a different address for Richard, @debian.org bounces)

On Sat, Sep 29, 2007 at 03:08:36AM -0400, Joey Hess wrote:

Peter Rock wrote:

Hello, I hope I'm contacting the right folks!

I'm trying to find out the copyright status of the elilo-installer
package to see if it qualifies as free software or not. Below is a bit
of a description and I was advised by debian-legal to ask the package
maintainers. Hope someone can help!

Bdale is the original author of elilo-installer, although it's derived
from lilo-installer. rhirst, cjwatson, bubulle, dannf, Jim Lieb, and I
have each made changes that might be substantial enough to be copyrightable
(or not).

Since lilo-installer is licensed under the GPL version 2 or later, I
suggest it's sanest for elilo-installer to have the same license. I
place my modifications to it under this license. Could the listed
people please respond with a similar statement?

Isn't this our _second_ udeb that got past the ftp-masters with no
copyright file? It's not the last one. See upcoming mail for
quik-installer. :-/







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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:

000: 8000 5041 4c4f 0003 00c8 e000 003d fddd  ..PALO...=..
010: 0053 5000 001b e9de 302f 766d 6c69 6e75  .SP.0/vmlinu
020: 7820 7261 6d64 6973 6b5f 7369 7a65 3d38  x ramdisk_size=8
030: 3139 3220 726f 6f74 3d2f 6465 762f 7261  192 root=/dev/ra
040: 6d20 2020 2020 2069 6e69 7472 643d 302f  m  initrd=0/
050: 7261 6d64 6973 6b20 6465 7666 733d 6d6f  ramdisk devfs=mo
060: 756e 742c 6461 6c6c 2069 6e69 743d 2f6c  unt,dall init=/l
070: 696e 7578 7263 2044 4542 434f 4e46 5f50  inuxrc DEBCONF_P
080: 5249 4f52 4954 593d 6869 6768    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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: if something is not done, hppa will not have an installer for sarge

[Richard Hirst]

Including [EMAIL PROTECTED] 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 lates

Re: Why is it so hard to build?

[Richard Hirst]

Hi Willy,
  Basically needs more developer effort to get it working well on hppa.
Unfortunately I've been too busy lately and have dedicated the time I did
have to d-i for ia64.  You need to build on unstable, and I iirc the
QM_MODULES thing was a glibc or kernel headers issue.  I have built it
for hppa in the past, and had some success installing on a B180.  There
was also an issue with mklibs reducing libm to (nearly) nothing, and
that breaking glibc.  Carlos fixed glibc, but I don't know if his fix
is in debian unstable.  I had a hack to mklibs to work round it.

Recently I saw a mail saying anna changes means d-i only works with
di-kernel-image based kernels now, and I don't think hppa is there yet.

Richard


On Tue, Mar 16, 2004 at 09:14:25PM +, Matthew Wilcox wrote:
> 
> I've had three attempts at building d-i for hppa.
> 
> 1. It won't build on a woody system (the packages it wants aren't available).
> 
> 2. Documentation is broken -- build/README does not document
> that "make build_netboot" won't work.  You need to type
> "fakeroot make build_netboot" instead.
> 
> 3. It won't build on this kernel:
> 
>  mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-32-udeb/kernel;
>  if [ -e ./tmp/netboot/tree/boot/System.map ]; then
> depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 
> 2.4.20-32-udeb;
> mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot;
>  else
> depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-32-udeb;
>  fi;
>  mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-64-udeb/kernel;
>  if [ -e ./tmp/netboot/tree/boot/System.map ]; then
> depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 
> 2.4.20-64-udeb;
> mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot;
>  else
> depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-64-udeb;
>  fi;
> depmod: QM_MODULES: Function not implemented
> 
>  willy: QM_MODULES: Function not implemented?
>  joshk: Indeed.
>  known silly bug
>  ... is there a workaround?
>  no, I've been tagged wontfix
> 
> *sigh*
> 
> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- Mark Twain
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: partman-palo template

[Richard Hirst]

On Sat, Mar 06, 2004 at 03:32:59PM +0100, cobaco wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all,
> 
> the partman-palo template states that the palo partition should be in the
> first 2 /Mb/
> 
> Im guessing this needs to be either MB or MiB ?

It would be 2GB (or GiB), not 2MB.

Richard

> - --
> Cheers, cobaco
> 
> 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
> 2. Plain-text mail recommended since I move html and double
> format mails to a low priority folder (they're mainly spam)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFASeEb5ihPJ4ZiSrsRAvPIAJ9dBcEcJ9V71CqWYRPc0nh5iiryNgCbBCWi
> dZJv7fUUM4NiQ5c1vg49WMs=
> =CpqC
> -END PGP SIGNATURE-
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Default partition table type for non i386?

[Richard Hirst]

On Wed, Mar 03, 2004 at 10:05:48AM +0200, Anton Zinoviev wrote:
> Hi!
> 
> Can people working on non-i386 tell how we can find the default
> partition table type.  This is necessary for the autopartitioner of
> partman to work on them and will also simplify the dialog for creation
> of new partition table.
> 
> Currently parted supports the following partition tables: 
> 
> bsd, gpt, mac, dvh, msdos, pc98, sun and amiga.

hppa/parisc uses msdos.
ia64 uses gpt.
m68k is tricky, but the vme subarchs use msdos.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 boot failure - no kernel

[Richard Hirst]

On Tue, Feb 10, 2004 at 04:48:40PM -0800, Aaron Brashears wrote:
> I downloaded, burned, and ran sarge-ia64-netinst.iso, but with no luck. 
> On boot, the box lands in an 'EFI Boot Manager' which allows boot device 
> selection. I point it at the cd (named 'cdrom2' in my configuration) 
> and tell the boot manager to boot from there, and get:
> 
> Loading.: cdrom2
> Starting: cdrom2
> ELILO
> elilo.c(line 70):Kernel file  not found
> Start of cdrom2 failed: Load Error

Looks like you told elilo to load a kernel called 'cdrom2'?  I'd
normally do something like  'fs2:' to switch to device 'fs2', and then
'elilo' which causes it to load elilo.conf from that dir.

> 
> I got the sarge iso from:
> http://gluck.debian.org/cdimage/testing/netinst/ia64/daily/
> 
> 
> Is there any further information I could provide which would help with 
> debugging the ia64 boot for sarge?

Try an image from

http://gluck.debian.org/cdimage/testing/sid_d-i/netinst/ia64/

Those images have fixes to the bootimage layout, which should mean they
can be booted rather more easily.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i doesn't load ext3-modules udeb on ia64

[Richard Hirst]

On Mon, Feb 09, 2004 at 12:54:48PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > This is the daily build for 20040208, netinst iso.
> 
> sid_d-i or the probably broken other one?

http://gluck.debian.org/cdimage/testing/sid_d-i/netinst/ia64/20040208/

> > Also, I selected a local mirror, it prompted with a path of /debian
> > which I accepted.  It then went and tried to access http:/debiandist/...
> > I had to modify the suggested path to be /debian/ for to to work.
> 
> Ok, fixed in CVS.

Thanks
  Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i doesn't load ext3-modules udeb on ia64

[Richard Hirst]

On Mon, Feb 09, 2004 at 02:23:43PM +, Richard Hirst wrote:
> This is the daily build for 20040208, netinst iso.  ext3-modules is on
> the iso, but it is not getting loaded.  I had to manually udpkg -i
> /cdrom/.../ext3-modules*udeb and then modprobe jbd ext3.
> 
> I don't know why ext3-modules isn't automatically loaded; any ideas?
> 
> Also, I selected a local mirror, it prompted with a path of /debian
> which I accepted.  It then went and tried to access http:/debiandist/...
> I had to modify the suggested path to be /debian/ for to to work.
> 
> Finally, it wouldn't come back up on reboot because elilo-3.4-5 is not
> yet in testing - needed to load the initrd on reboot.

I sent this a bit too soon.

elilo wont run because fat-modules is not installed.  Again, the udeb is
on the iso, but not installed by d-i.  In this case, the udeb is
priority extra which I guess is wrong (assuming that matters).

Also, the system did come back up after boot, because the 2.4.22
initrd-based kernel is not yet in testing, so the older 2.4.20 which
doesn't use an initrd was installed.  That one booted ok.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i doesn't load ext3-modules udeb on ia64

[Richard Hirst]

This is the daily build for 20040208, netinst iso.  ext3-modules is on
the iso, but it is not getting loaded.  I had to manually udpkg -i
/cdrom/.../ext3-modules*udeb and then modprobe jbd ext3.

I don't know why ext3-modules isn't automatically loaded; any ideas?

Also, I selected a local mirror, it prompted with a path of /debian
which I accepted.  It then went and tried to access http:/debiandist/...
I had to modify the suggested path to be /debian/ for to to work.

Finally, it wouldn't come back up on reboot because elilo-3.4-5 is not
yet in testing - needed to load the initrd on reboot.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#229465: partman, command_set_flags() breaks if flags added to parted

[Richard Hirst]

Package: partman
Version: 6
Tags: d-i

command_set_flags() depends on PED_PARTITION_LAST_FLAG, and so it breaks
if any extra flags are added to parted.  I am working on adding a new
parted flag to handle hppa boot partitions, and it would be nice if
partman didn't need rebuilding to support it.

The obvious solution is to loop calling ped_partition_flag_next() to
determine how many flags there are, then malloc states[].

Thanks,
  Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i install report, hppa

[Richard Hirst]

On Mon, Jan 19, 2004 at 08:35:11PM +0100, Thorsten Sauter wrote:
> * Richard Hirst <[EMAIL PROTECTED]> [2004-01-19 18:30]:
> | On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote:
> | > * Richard Hirst <[EMAIL PROTECTED]> [2004-01-18 20:48]:
> | > | Initial boot fails due to a SEGV in frontend; this appears to be because
> | > | of a bug in glibc, triggered by libm being reduced to what is effectively
> | > | an empty library.  Bug #228375 filed.  I hacked mklibs to include a symbol
> | > | from libm, so I could build a working image.  text frontend worked ok.
> | > | 
> | > | Kernel hung on reboot when discover tried to load de4x5.o; the kernel
> | > | has the tulip driver compiled in to handle the network i/f.  I renamed
> | > | the module and tried again.  This time it rebooted ok, and base-config
> | > | ran ok.
> | > 
> | > 
> | > very good news.
> | > mklibs is a little bit mystic for me. :-)
> | > 
> | > Should I include this patch on paer as long as we have no updated mklibs
> | > version?
> | 
> | Hmm, the patch is below, but I can't say whether you should hack
> | /usr/bin/mklibs on paer.  Carlos (hppa glibc guy) agrees that I found
> | the bug in glibc, but he is fixing it in a slightly different way.  I'd
> | assumed that we would get a fixed glibc, rather than work round it in
> | mklibs, but I guess a new mklibs is easier to arange.  "log" was just a
> | symbol I picked at random; the requirement is that "objdump -p libm.so.6"
> | shows a non-zero DT_JMPREL value.  As "log" adds about 50K to libm, I
> | suspect other archs would be upset by this mklibs change.
> 
> 
> of course, not hacking the system mklibs binary, but I could use my own
> mklibs app as long as we have no fixed glibc and/or mklibs package. This
> will make the images working for this time.

Sorry, misunderstood.  Yes, that makes sense.

Thanks,
  Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i install report, hppa

[Richard Hirst]

On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote:
> * Richard Hirst <[EMAIL PROTECTED]> [2004-01-18 20:48]:
> | Initial boot fails due to a SEGV in frontend; this appears to be because
> | of a bug in glibc, triggered by libm being reduced to what is effectively
> | an empty library.  Bug #228375 filed.  I hacked mklibs to include a symbol
> | from libm, so I could build a working image.  text frontend worked ok.
> | 
> | Kernel hung on reboot when discover tried to load de4x5.o; the kernel
> | has the tulip driver compiled in to handle the network i/f.  I renamed
> | the module and tried again.  This time it rebooted ok, and base-config
> | ran ok.
> 
> 
> very good news.
> mklibs is a little bit mystic for me. :-)
> 
> Should I include this patch on paer as long as we have no updated mklibs
> version?

Hmm, the patch is below, but I can't say whether you should hack
/usr/bin/mklibs on paer.  Carlos (hppa glibc guy) agrees that I found
the bug in glibc, but he is fixing it in a slightly different way.  I'd
assumed that we would get a fixed glibc, rather than work round it in
mklibs, but I guess a new mklibs is easier to arange.  "log" was just a
symbol I picked at random; the requirement is that "objdump -p libm.so.6"
shows a non-zero DT_JMPREL value.  As "log" adds about 50K to libm, I
suspect other archs would be upset by this mklibs change.

Richard

# 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()


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Beta2 sources.list config

[Richard Hirst]

On Mon, Jan 19, 2004 at 03:26:15AM -0600, Matthew A. Nicholson wrote:
> On two occasions during installations, when the installer gets to apt's 
> sources.list configuration, it keeps asking for sources until the user 
> presses cancel, at which time the installer will drop to expert mode.

This is a known bug, fixed in cvs.

Thanks,
  Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i install report, hppa

[Richard Hirst]

INSTALL REPORT

Debian-installer-version: cvs-head, 20040118, built locally
uname -a:
Date: Sun, 18 Jan 2004 19:28:45 +
Method: netboot of lifimage (netboot-image.img), installing from local
unstable mirror.

Machine: B180L, Merlin L2+ 180 (9000/778/B180L)
Processor: PA7300LC (PCX-L2)
Memory: 256MB
Root Device: SCSI

Root Size/partition table:
  Disk /dev/sda: 4294 MB, 4294816768 bytes
  133 heads, 62 sectors/track, 1017 cylinders
  Units = cylinders of 8246 * 512 = 4221952 bytes
  
 Device Boot  Start End  Blocks   Id  System
  /dev/sda1   1   8   32953   f0  Linux/PA-RISC boot
  /dev/sda2   9 245  977151   83  Linux
  /dev/sda3 246 306  251503   82  Linux swap

Output of lspci:
  [EMAIL PROTECTED]:~$ lspci 
  00:13.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 04)
  00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30)
  [EMAIL PROTECTED]:~$ lspci -n
  00:13.0 Class 0100: 1000:000f (rev 04)
  00:14.0 Class 0200: 1011:0019 (rev 30)
  [EMAIL PROTECTED]:~$ 


Base System Installation Checklist:

Initial boot worked:[E]
Configure network HW:   [O]
Config network: [O]
Detect CD:  [ ]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Create file systems:[O]
Mount partitions:   [O]
Install base system:[O]
Install boot loader:[O]
Reboot: [E]
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Comments/Problems:

Initial boot fails due to a SEGV in frontend; this appears to be because
of a bug in glibc, triggered by libm being reduced to what is effectively
an empty library.  Bug #228375 filed.  I hacked mklibs to include a symbol
from libm, so I could build a working image.  text frontend worked ok.

Kernel hung on reboot when discover tried to load de4x5.o; the kernel
has the tulip driver compiled in to handle the network i/f.  I renamed
the module and tried again.  This time it rebooted ok, and base-config
ran ok.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

PA-RISC/HPPA netboot lifimage generation

[Richard Hirst]

On Sat, Jan 10, 2004 at 07:23:39PM +0100, Thorsten Sauter wrote:
> * Richard Hirst <[EMAIL PROTECTED]> [2004-01-10 17:51]:
> | The SEGV is in "frontend", looks like a null pointer deref.  I switched
> | to text frontend, fixed d-i to actually make a lifimage for netboot (I
> | guess you created yours manually?), and tried again.  I havn't submitted
> | my change yet.
> 
> I have created a new target in boot/arch/linux-hppa caled netboot.lif.
> But I haven't commited it yet. I'm not sure, that this is the right
> place.

I created a 2 line file, build/config/type/netboot-hppa containing


# FLOPPY_SIZE value is not relevant, but it needs to exist so that palo gets run
FLOPPY_SIZE=1440


After that, "make TYPE=netboot" produces a lifimage, from the existing
$(IMAGE) target in make/arch/linux-hppa.  Output is dest/netboot-image.img


Thorsten, shall I submit this, or will it interfere with what you are
doing?

Thanks,
  Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 beta2 install report

[Richard Hirst]

On Fri, Jan 16, 2004 at 12:09:00PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > apt config after booting requires you to hit  to get out of the
> > "add apt source" screen.  I think after adding the first one, it should
> > give you a "do you want to add another" screen.
> 
> This is not specific to the ia64 port. I think I have fixed the logic
> error in apt-setup, but I have still not managed to test it
> satesfactorally.

I replaced the base-config deb on an ia64 beta2 netinst ISO with one
built from cvs a few hours ago and did a test install.  Now it gives me
the "choose an apt source" screen, I select http, and a local mirror, it
loads package files from my mirror and from security.d.o, and then goes
directly to the "install software" screen (offering tasksel, aptitude,
etc).

So it does indeed seem to be fixed.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ia64 beta2 install report

[Richard Hirst]

Tested both netinst and businesscard ISOs, on i2000 prototype (dual
Itanium).  Both worked fine.  Only issues, which are already known are:

elilo udeb works but is English only and spews some unwanted text to the
screen.  Will be fixed in the next upload.

Installed kernel gives "sc()" messages for unimplmented syscalls.
Works fine, but is noisy.  Will be fixed when new kernel debs make their
way in to testing.  Current solution is to install a newer kernel from
unstable.

apt config after booting requires you to hit  to get out of the
"add apt source" screen.  I think after adding the first one, it should
give you a "do you want to add another" screen.

ISO doesn't autoboot because I got the dir structure wrong.  Have to
select the relevant device and type 'elilo'.

Can't install from USB.

Could do with some unaligned access warnings cleaning up.


Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#227114: 20040108 fails on ia64

[Richard Hirst]

On Wed, Jan 14, 2004 at 11:23:49PM +, Richard Hirst wrote:
> Ugh, ignore my recent post saying networking wasn't configured after
> installing from the 20040111 netinst iso.
> 
> What has actually happened, is that the installed system has a
> /etc/network/interfaces file containing:
> 
>  cut ==
> auto lo
> iface lo inet loopback
> 
> # This entry was created during the Debian installation
> auto eth0
> iface eth0 inet dhcp
> on.
>  cut ==
> 
> If I run /etc/init.d/netowrking start, I get an error about an option
> with an empty value on line 7.
> 
> If I delete that line netowrking comes up ok.  I've no idea atm where
> the "on." comes from.

Looks like that is down to the busybox, "cp doesn't truncate target
file" bug I saw mentioned in the last few days.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#227114: 20040108 fails on ia64

[Richard Hirst]

Ugh, ignore my recent post saying networking wasn't configured after
installing from the 20040111 netinst iso.

What has actually happened, is that the installed system has a
/etc/network/interfaces file containing:

 cut ==
auto lo
iface lo inet loopback

# This entry was created during the Debian installation
auto eth0
iface eth0 inet dhcp
on.
 cut ==

If I run /etc/init.d/netowrking start, I get an error about an option
with an empty value on line 7.

If I delete that line netowrking comes up ok.  I've no idea atm where
the "on." comes from.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#227114: 20040108 fails on ia64

[Richard Hirst]

On Wed, Jan 14, 2004 at 09:39:02PM +, Richard Hirst wrote:
> I'm putting this scsi error problem down to dying hardware.  I went back
> to the 20040108 iso that I'm previously used, and am getting similar
> (and worse) symptoms, only on one of the two disks.

Ripped the box apart, blew the dust out, etc, reassembled, and installed
from the 20040111 netinst iso with no problems except for initrd-tools
workaround.

However, d-i never did network configuration, and on reboot base-config
didn't either, so I had no networking :(

Richard


> So, I still think ia64 d-i is ok for beta2, assuming initrd-tools gets
> included on the netinst ISO.  No new ISOs generated since 20040111
> though.
> 
> Richard
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#227114: 20040108 fails on ia64

[Richard Hirst]

On Tue, Jan 13, 2004 at 02:39:47PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > The problem is that initrd-tools is not included on the netinst ISO.
> > The kernel doesn't depend on it, so that is correct.  Unfortunately
> > on ia64 we have do_initrd=yes so kernel-installer wants to install
> > initrd-tools.  Not a problem with the businesscard ISO because it just
> > pulls initrd-tools from the net.
> 
> I belive that I have checked in a fix to debian-cd's
> tools/generate_di+k_list to fix this. Manty will need to cvs up that
> file in his build tree.

Thanks Joey.

> > d-i manages to install a kernel then, but elilo-installer causes (at
> > least) one of my scsi disks to run down, and report 'Not Ready'.
> > 
> > I have two disks, sda (8/0) and sdb (8/16).  The errors are on sdb,
> > which I'm not installing to.  elilo runs
> > 
> > parted /dev/discs/discN/disc print | sed 
> > 
> > when translating /dev/discs/ paths in to /dev/scsi/ paths.
> > 
> > Earlier in the install (partitioning disks) I was able to use parted to
> > print the partition table ok.
> > 
> > I havn't seen this problem with the businesscard ISOs, but the most
> > recent I tested so far was 20040108.
> 
> The ia64 udebs on the netinst CD you used have not been updated since
> then, so I don't know about this.

I'm putting this scsi error problem down to dying hardware.  I went back
to the 20040108 iso that I'm previously used, and am getting similar
(and worse) symptoms, only on one of the two disks.

So, I still think ia64 d-i is ok for beta2, assuming initrd-tools gets
included on the netinst ISO.  No new ISOs generated since 20040111
though.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#227114: 20040108 fails on ia64

[Richard Hirst]

On Tue, Jan 13, 2004 at 07:55:26AM +, Richard Hirst wrote:
> > Install boot loader:[E] - Never got there, couldn't get a kernel installed
> 
> This is odd.  I have the buisnesscard iso here, and it lists 8 kernels,
> not 4 as you got from the netinst iso.  It lists images for itanium and
> mckinley, smp and up, for 2.4.19 and 2.4.20.  I wonder if there is
> something missing from the netinst iso.
> 
> The latest ISOs are now on gluck; I'm currently downloading
> 
> http://gluck.debian.org/cdimage/testing/netinst/ia64/20040111/sarge-ia64-netinst.iso
> 
> and will see what that does for me.

The problem is that initrd-tools is not included on the netinst ISO.
The kernel doesn't depend on it, so that is correct.  Unfortunately
on ia64 we have do_initrd=yes so kernel-installer wants to install
initrd-tools.  Not a problem with the businesscard ISO because it just
pulls initrd-tools from the net.

You can get round this by booting with

debian-installer/kernel/linux/initrd=false

on the kernel command line.

d-i manages to install a kernel then, but elilo-installer causes (at
least) one of my scsi disks to run down, and report 'Not Ready'.

I have two disks, sda (8/0) and sdb (8/16).  The errors are on sdb,
which I'm not installing to.  elilo runs

parted /dev/discs/discN/disc print | sed 

when translating /dev/discs/ paths in to /dev/scsi/ paths.

Earlier in the install (partitioning disks) I was able to use parted to
print the partition table ok.

I havn't seen this problem with the businesscard ISOs, but the most
recent I tested so far was 20040108.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#227114: 20040108 fails on ia64

[Richard Hirst]

Hi Alex,
  Thanks for your report, comments below..

On Fri, Jan 09, 2004 at 02:30:26PM -0700, Alex Williamson wrote:
> Package: installation-reports
> Version: 20040108-ia64
> Severity: grave
> Justification: renders package unusable
> 
> Debian-installer-version: 
> http://people.debian.org/~manty/testing/netinst/ia64/20040108/sarge-ia64-netinst.iso
> uname -a: 2.4.20-ia64 #1 Mon Jan 5 07:53:11 GMT 2004 ia64
> Date: Fri, 09 Jan 2004 13:50:04 -0700
> Method: USB Keychain and IDE CDROM
>
> Machine: hp rx2600
> Processor: 2x Itanium2
> Memory: 6GB
> Root Device: SCSI sda
> Root Size/partition table: GPT 100MB fat16 (not mounted), ~30G ext3 (/), ~2G swap
> Output of lspci: Not available
> 
> Base System Installation Checklist:
> 
> Initial boot worked:[E] - failed to autoboot.  manually running bootloader worked

OK, I'll fix the directory layout after beta2.

> Configure network HW:   [O]
> Config network: [O]
> Detect CD:  [O]
> Load installer modules: [E] - failed to load from USB mass storage, worked fine from 
> CD

I havn't tried to use usb at all on my box.  Hopefully Dannf's new
kernel packages (2.4.22 or 23) will provide that module, and I plan on
adopting those after beta2.  Will have to ensure those modules get
included in the initrd.

> Detect hard drives: [O]
> Partition hard drives:  [O]
> Create file systems:[O]
> Mount partitions:   [O]
> Install base system:[O]
> Install boot loader:[E] - Never got there, couldn't get a kernel installed

This is odd.  I have the buisnesscard iso here, and it lists 8 kernels,
not 4 as you got from the netinst iso.  It lists images for itanium and
mckinley, smp and up, for 2.4.19 and 2.4.20.  I wonder if there is
something missing from the netinst iso.

The latest ISOs are now on gluck; I'm currently downloading

http://gluck.debian.org/cdimage/testing/netinst/ia64/20040111/sarge-ia64-netinst.iso

and will see what that does for me.

In the meantime, if you are bored, you might try the latest buisnesscard
ISO (from http://gluck.debian.org/cdimage/testing/netinst/ia64).

Something else that may not be obvious; when you partition the target
disk you need to use parted to create a FAT16 filesystem on the boot
partition, and set the BOOT flag (set N boot on).

Thanks,
  Richard


> Reboot: [ ]
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Comments/Problems:
> 
>I was hoping to do an install off of a USB keychain.  I'm using a
> 256MB keychain, partitioned as GPT with a 100MB fat16 partition, and the
> rest ext3.  I copied the contents of the el-torito image into the fat16
> partition and the rest of the CD into the ext3 partition.  The system
> failed to autoboot when I selected USB for install (the directory and
> filename layouts are incorrect for autoboot).  I then went to an EFI
> Shell and booted manually by typing elilo (I'm using a VGA console for
> install).  Install went fine till it started looking for a CD.  I got it
> to look for the install media elsewhere, but it got an error that the
> usb-storage module wasn't available.
> 
>   I gave up on the USB keychain and popped in a CD.  In the processes of
> installing the base system, I got some unaligned access errors on the
> console.  These were mainly from main-menu and anna.  Really ought to
> fix these, use prctl to turn them off or maybe just turn down the dmesg
> level to make them not go to the console.  I got the base system
> installed and selected the install kernel option.  It presented a list
> of 4 available kernels.  Selecting any of them immediately brought me
> back to the main menu w/ the "install kernel" option highlighted.  I
> checked the /target drive, and no kernel was installed.  I tried this
> several times before I gave up.
> 
>I have some concerns about using devfs for the install.  I'm told
> that after install you will not end up with a devfs system, but I
> couldn't get that far to verify.  It's confusing to be presented with
> SCSI devices as host/bus/target/lun when you're really just expecting
> sda.  I'm aware of all the naming problems with sdX, but using a
> deprecated interface doesn't seem like the way to work around it.  My 2
> cents.  Thanks,
> 
>   Alex
> 
> -- 
> Alex Williamson HP Linux & Open Source Lab
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: daily images for PA-RISC/HPPA

[Richard Hirst]

On Sat, Jan 10, 2004 at 01:17:56PM +, Richard Hirst wrote:
> On Fri, Jan 09, 2004 at 08:21:17AM +0100, Thorsten Sauter wrote:
> > 
> > Hello debian-installer's :-),
> > 
> > I have setup daily images for the HPPA architecture on paer.debian.org.
> > The images creates cdrom, netboot and a lif image from source. As
> > usually everything is available here:
> > http://people.debian.org/~tsauter/d-i/images-hppa/daily/
> > 
> > I hope, we can build daily cdrom images as well.
> > 
> > I have tested the images on the following machine types (always tftpboot
> > via lif image): 9000/712-60 and 9000/712-80.
> > 
> > Please test the images.
> 
> netboot.lif seems to have a rather strange cmdline:
> 
> TERM=linux console=tty initrd=netboot-initrd.gz ramdisk_size=8192 root=/dev/rd/0 
> initrd=0/linuxrc devfs=mount,all rw
> 
> I couldn't find "initrd=0/linuxrc" anywhwere in the d-i source.
> 
> The crdom-image.img seems to have a more sane cmdline, but I still had
> to use palo to edit it to add "root=/dev/ram devfs=mount,dall" before it
> would get anywhere.  I had to remove TERM=linux as well, because palo
> locked up if I included all those params.  palo has a history of locking
> up when you edit the cmdline, unfortunately.
> 
> Anyway, after that, it booted and mounted the initrd, and then looped
> complaining that it couldn't find various kernel modules, and reporting
> 'segmentation fault'.
> 
> This was on a B180, STI console.

The SEGV is in "frontend", looks like a null pointer deref.  I switched
to text frontend, fixed d-i to actually make a lifimage for netboot (I
guess you created yours manually?), and tried again.  I havn't submitted
my change yet.

Getting further now, currently running debootstrap, installing unstable.

Couldn't partition disks because there is no [c]fdisk udeb installed.
parted won't work for hppa because we need to create a partition of type
'F0' and parted can't do that.  I skipped that step and used my
existing partitions.  IIRC this is a problem with fdisk-udeb priority.
It gets pulled in on i386 anyway because lilo-installer wants it (at
least, that is what I recall), but doesn't get pulled in for hppa.  I
think the easy answer is to include it in the pkg-lists for hppa.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: daily images for PA-RISC/HPPA

[Richard Hirst]

On Fri, Jan 09, 2004 at 08:21:17AM +0100, Thorsten Sauter wrote:
> 
> Hello debian-installer's :-),
> 
> I have setup daily images for the HPPA architecture on paer.debian.org.
> The images creates cdrom, netboot and a lif image from source. As
> usually everything is available here:
>   http://people.debian.org/~tsauter/d-i/images-hppa/daily/
> 
> I hope, we can build daily cdrom images as well.
> 
> I have tested the images on the following machine types (always tftpboot
> via lif image): 9000/712-60 and 9000/712-80.
> 
> Please test the images.

netboot.lif seems to have a rather strange cmdline:

TERM=linux console=tty initrd=netboot-initrd.gz ramdisk_size=8192 root=/dev/rd/0 
initrd=0/linuxrc devfs=mount,all rw

I couldn't find "initrd=0/linuxrc" anywhwere in the d-i source.

The crdom-image.img seems to have a more sane cmdline, but I still had
to use palo to edit it to add "root=/dev/ram devfs=mount,dall" before it
would get anywhere.  I had to remove TERM=linux as well, because palo
locked up if I included all those params.  palo has a history of locking
up when you edit the cmdline, unfortunately.

Anyway, after that, it booted and mounted the initrd, and then looped
complaining that it couldn't find various kernel modules, and reporting
'segmentation fault'.

This was on a B180, STI console.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 install report

[Richard Hirst]

On Thu, Jan 08, 2004 at 07:58:57PM -0500, Joey Hess wrote:
> > b) At some point during loading the installer modules, it spews a load
> > of text over the screen, such as:
> > 
> >  Unknown localized field:
> >  Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte
> > 
> > That doesn't seem to cause a problem though.

I ran a text mode install and logged the console:

[ 46.6%][ 46.6%] Unpacking e2fsprogs-udeb
[ 48.3%][ 48.3%] Retrieving libblkid1-udeb
[ 50.0%][ 50.0%] Unpacking libblkid1-udeb
[ 51.7%][ 51.7%] Retrieving libuuid1-udeb
[ 53.4%][ 53.4%] Unpacking libuuid1-udeb
[ 55.2%][ 55.2%] Retrieving elilo-installer
[ 56.9%][ 56.9%] Unpacking elilo-installer
Unknown localized field:
Description-cs.ISO-8859-2: Oblast pro instalaci zavadìèe:
Unknown localized field:
Description-da.ISO-8859-1: Partition at installere opstartsindlæseren på:
Unknown localized field:
Description-fr.ISO-8859-15: Partition où sera installé le chargeur de démarrage :
Unknown localized field:
Description-hu.ISO-8859-2: A rendszerbetöltõ erre a partícióra kerül:
Unknown localized field:
Description-ja.EUC-JP: ¥Ö¡¼¥È¥í¡¼¥À¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó:
Unknown localized field:
Description-pt_BR.ISO-8859-1: Partição a ser usada para a instalação do carregador de 
inicialização :
Unknown localized field:
Description-cs.ISO-8859-2: Nebyly detekovány ¾ádné oblasti
Unknown localized field:
Description-da.ISO-8859-1: Fandt ingen opstartspartitioner
Unknown localized field:
Description-fr.ISO-8859-15: Aucune partition de démarrage détectée
Unknown localized field:
Description-hu.ISO-8859-2: Rendszerbetöltõ partíció felderítése sikertelen
Unknown localized field:
Description-ja.EUC-JP: ¥Ö¡¼¥È¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬¸¡½Ð¤µ¤ì¤Þ¤»¤ó¤Ç¤·¤¿
Unknown localized field:
Description-pt_BR.ISO-8859-1: Nenhuma partição de inicialização (boot) detectada.
[ 58.6%][ 58.6%] Retrieving userdevfs
...
...


I then extracted the templates files from base-installer and elilo-installer
to see if there were any obvious differences:

base-installer:

Template: base-installer/debootstrap-failed
Type: error
Description: Failed to install the base system
 The base system installation into /target/ failed.
 .
 Please check /target/var/log/debootstrap.log and
 /target/var/log/debootstrap.err.log for the details.
Description-bg.UTF-8: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] на 
оÑ~AновнаÑ~Bа Ñ~AиÑ~AÑ~Bема
 [EMAIL PROTECTED] на оÑ~AновнаÑ~Bа Ñ~AиÑ~AÑ~Bема в
 /target/ [EMAIL PROTECTED] неÑ~CÑ~AпеÑ~Hно.
 .
 Ð~\олÑ~O [EMAIL PROTECTED]@еÑ~Bе /target/var/log/debootstrap.log и
 /target/var/log/debootstrap.err.log за [EMAIL PROTECTED]
...
...

elilo-installer:

Template: elilo-installer/bootpart
Type: select
Choices: ${BOOTPARTS}
Description: Partition for boot loader installation:
 Partitions currently available in your system are listed.
 Please choose the one you want elilo to use to boot Debian.
Description-cs.ISO-8859-2: Oblast pro instalaci zavadìèe:
 Vypsány jsou v¹echy dostupné oblasti v systému. Vyberte tu, kterou má
 elilo pou¾ít k zavedení Debianu.
...
...


The obvious difference to me is that in base-installer, all the
Description names are Description-*.UTF-8, while in elilo-installer they
are all .ISO-8859-2, or EUC-JP, or whatever.


I then built a new elilo-installer from head, and its templates file
uses UTF-8, so I conclude that we should build/upload a new
elilo-installer.  So far as beta2 is concerned, I tried an install in
French, and all was well, except the one dialog from elilo was in
English.  I guess we can live with that for now.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 install report

[Richard Hirst]

On Thu, Jan 08, 2004 at 07:58:57PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > a) The iso has kernel-installer_0.045_all.udeb, even though 0.046 is in
> > the archive.  Presumably we are stuck with that until Joeyh forces 0.046
> > in to testing.  As a result, it installed a 2.4.19 kernel for Itanium,
> > rather than choosing Itanium or Mckinley 2.4.20 based on /proc/cpuinfo.
> 
> This is why I want manty to make some cds that use udebs from unstable,
> so we can test this stuff before moving it into testing. I understnad
> he's working on it.
> 
> But a least during proparation for this beta it would probably be ok to
> just force it in, since the stuff in testing is not known to work at
> all. My list of packages that need to go into testing for ia64 is:
> 
> Needs base-installer (0.046) in testing.
> Needs the kernel module udebs from kernel-patch-2.4.20-ia64
> (021210.em20.7) in testing.
> 
> If that is the full set, I will try to get them in before tomorrow's
> dinstall..

Yes, that is the full set,

Thanks!
  Richard


> > b) At some point during loading the installer modules, it spews a load
> > of text over the screen, such as:
> > 
> >  Unknown localized field:
> >  Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte
> > 
> > That doesn't seem to cause a problem though.
> 
> I tried to find this tring in the beta2 tree, but I could not. Anyway,
> it appears to be a French translation that is wrongly encoded; d-i should
> only use utf-8. If you can grep out the relevant udeb in /var/lib/dpkg/info/,
> in the chroot, it should be easy to fix.
> 
> > I checked that the sym53c8xx_2 module jbailey wanted was available, so I
> > think we can say ia64 is ready for beta2.  Would be very nice if someone
> > else could test though.
> 
> That's great news. I am inclined to call beta2 as soon as we have two
> architectures ready. The other two or so architectures could then catch
> up and get their own release announcement.
> 
> -- 
> see shy jo



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 install report

[Richard Hirst]

On Fri, Jan 09, 2004 at 06:58:48AM +0100, Christian Perrier wrote:
> > > I tried to find this tring in the beta2 tree, but I could not. Anyway,
> > > it appears to be a French translation that is wrongly encoded; d-i should
> > > only use utf-8. If you can grep out the relevant udeb in /var/lib/dpkg/info/,
> > > in the chroot, it should be easy to fix.
> > 
> > The back-translation of this string is "No boot partition detected", if
> > that helps track it down.
> 
> This only appears in sparc-installer and elilo-installer.
> 
> Both french translations are originally coded in ISO-8859-15 as we
> usually do. Both package have the correct debian/po/output file so
> that translations are converted to UTF-8 when they are integrated in
> the templates.
> 
> So, I have no idea where this may come from.

It must be elilo-installer then.  I'll try and figure it out.  In any
case, it doesn't cause a problem.

Thanks,
  Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ia64 install report

[Richard Hirst]

INSTALL REPORT

Debian-installer-version: 

http://people.debian.org/~manty/testing/netinst/ia64/daily/sarge-ia64-businesscard.iso
dated 08-JAN-2004 15:02

uname -a: 
Date: Jan 8th 2004, 23:20 GMT
Method: businesscard.iso, specified 'testing', local http mirror
Machine: HP i2000 proto
Processor: Itanium (dual)
Memory: 1G
Root Device: SCSI
Root Size/partition table: 100MB FAT16 for EFI, 1990MB ext3 for '/'.

Output of lspci:

Base System Installation Checklist:

Initial boot worked:[O]
Configure network HW:   [O]
Config network: [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Create file systems:[O]
Mount partitions:   [O]
Install base system:[O]
Install boot loader:[O]
Reboot: [O]
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Comments/Problems:

Two issues:

a) The iso has kernel-installer_0.045_all.udeb, even though 0.046 is in
the archive.  Presumably we are stuck with that until Joeyh forces 0.046
in to testing.  As a result, it installed a 2.4.19 kernel for Itanium,
rather than choosing Itanium or Mckinley 2.4.20 based on /proc/cpuinfo.

b) At some point during loading the installer modules, it spews a load
of text over the screen, such as:

 Unknown localized field:
 Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte

That doesn't seem to cause a problem though.


I checked that the sym53c8xx_2 module jbailey wanted was available, so I
think we can say ia64 is ready for beta2.  Would be very nice if someone
else could test though.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i ia64 install report, with patch

[Richard Hirst]

On Sat, Jan 03, 2004 at 03:24:20PM -0900, Joey Hess wrote:
> Richard Hirst wrote:
> > Still doesn't automatically load ide-probe-mod.o, but joeyh has that
> > change queued waiting for alioth to come back, I believe.  That meant I
> > had to mess about a bit to get the cdrom visible.
> 
> I'm waiting until i386 is frozen in testing before uploading that, just
> because it could cause ugly error messages or something on i386.
> 
> > So, this is what we need for ia64 to be widely useful:
> > 
> > 
> > 1. Fixed parted in the archive and udeb on the iso - presumably that
> >will happen today
> > 
> > 2. hw-detect fixed to modprobe ide-probe-mod (joeyh?)
> > 
> > 3. new 2.4.20 kernel udebs with extra scsi driver modules (bdale/dannf?)
> > 
> > 4. newer 2.4.20 kernel debs in testing would be nice, but not vital
> > 
> > 5. the following patch applied to kernel-installer.  I havn't got round
> > to getting cvs access on alioth yet, so maybe once it is back someone
> > could apply this for me, and upload a new kernel-installer?
> 
> This sounds suspiciously close the the date estimates I asked for
> regarding when each architecture will be ready for the beta. FWIW, I
> have received no estimates at all so far. Would you guys like to make
> one?

Tricky... take the latest of 

i386 frozen in testing
alioth back up
new kernel pkgs uploaded

then allow, say, three days to get ide-probe-mod and kernel-installer
changes uploaded, new d-i build, new iso, quick test.

I can't really speak for when the kernel pkgs will be done, as I don't
know what Bdales commitments are.  I'd hope we would be ready within a
week though, which falls within your 10th-14th Jan proposal.

> > --- base-installer-0.045/debian/kernel-installer.postinst-  2004-01-03 
> > 21:11:09.0 +
> > +++ base-installer-0.045/debian/kernel-installer.postinst   2004-01-03 
> > 21:16:05.0 +
> 
> I'd apply this if alioth were back up yet. I forget, do you have commit
> access on alioth?

Not atm.  I had commit access before the move to alioth, but alioth has
been down since I found time to look at d-i again.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i ia64 install report, with patch

[Richard Hirst]

Using:

p.d.o/~manty/testing/netinst/ia64/20040103/sarge-ia64-buisnesscard.iso

dated 02-JAN-2004 15:02


Still doesn't automatically load ide-probe-mod.o, but joeyh has that
change queued waiting for alioth to come back, I believe.  That meant I
had to mess about a bit to get the cdrom visible.

The fixed parted ia64 build had not made it in to archive for this iso.

/etc/resolv.conf was set up correctly this time.

I was able to install testing this time (previously debootstrap meant I
had to install unstable).

I hand-editted kernel-installer.postinst before it was run, to make it
choose an appropriate kernel for the hardware (patch below).  That made
it load a 2.4.20 kernel which is better than the 2.4.19 it used before.
However, it loaded the 2.4.20 kernel in testing (obviously), which is a
couple of revisions older than the one in unstable, and spews messages
about unimplemented syscalls up the screen (still works, but annoying).

The 2.4.20 kernel udebs work fine for my h/w, but we need the new
packages for people with other scsi cards.


So, this is what we need for ia64 to be widely useful:


1. Fixed parted in the archive and udeb on the iso - presumably that
   will happen today

2. hw-detect fixed to modprobe ide-probe-mod (joeyh?)

3. new 2.4.20 kernel udebs with extra scsi driver modules (bdale/dannf?)

4. newer 2.4.20 kernel debs in testing would be nice, but not vital

5. the following patch applied to kernel-installer.  I havn't got round
to getting cvs access on alioth yet, so maybe once it is back someone
could apply this for me, and upload a new kernel-installer?

Thanks,
  Richard


--- base-installer-0.045/debian/kernel-installer.postinst-  2004-01-03 
21:11:09.0 +
+++ base-installer-0.045/debian/kernel-installer.postinst   2004-01-03 
21:16:05.0 +
@@ -186,6 +186,17 @@
*) log "warning: Unknown $ARCH subarchitecture '$MODEL'." ;;
esac
;;
+ia64)
+   version=2.4.20 #hack, hack!
+   # Running a UP kernel for install atm, so don't know how to detect
+   # whether SMP is needed.  Assume SMP for now.
+   if grep -q Itanium /proc/cpuinfo; then
+   family=itanium
+   else
+   family=mckinley
+   fi
+   trykernel=kernel-image-$version-$family-smp
+   ;;
 *)
 log "warning: Unknown architecture '$ARCH'."
;;



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#225823: mklibs 0.1.13 fails on ia64

[Richard Hirst]

Package: mklibs
Version: 0.1.13
tags: d-i

Trying to build debian-installer-20031230:

...
...
Object: ./tmp/cdrom/tree/lib/libm.so.6.1-so-stripped
Object: ./tmp/cdrom/tree/lib/libdebconfclient.so.0-so-stripped
Object: ./tmp/cdrom/tree/lib/libslang.so.1-UTF8-so-stripped
Object: ./tmp/cdrom/tree/lib/ld-linux-ia64.so.2-so-stripped
557 symbols, 20 unresolved
Moving libresolv.so.2 to libresolv.so.2.
Unlinking libnss_dns.so.2.
Moving libtextwrap.so.1 to libtextwrap.so.1.
Moving libdebian-installer.so.4 to libdebian-installer.so.4.
Moving libresolv-2.3.2.so to libresolv.so.2.
Moving libnss_dns-2.3.2.so to libnss_dns.so.2.
Moving libdiscover.so.1 to libdiscover.so.1.
Moving libc.so.6.1 to libc.so.6.1.
Unlinking libdiscover.so.
Moving ld-linux-ia64.so.2 to ld-linux-ia64.so.2.
Moving libnewt.so.0.51 to libnewt.so.0.51.
Moving libdl.so.2 to libdl.so.2.
Moving libm.so.6.1 to libm.so.6.1.
Moving libdebconfclient.so.0 to libdebconfclient.so.0.
Moving libdiscover.so.1.0.0 to libdiscover.so.1.
Command failed with status 1 : objcopy --strip-unneeded -R .note -R .comment  
./tmp/cdrom/tree/lib/
With output: objcopy: ./tmp/cdrom/tree/lib/: File format not recognized
make[2]: *** [cdrom-tree-stamp] Error 1
make[2]: Leaving directory `/root/debian-installer-20031230'
make[1]: *** [all_images] Error 2
make[1]: Leaving directory `/root/debian-installer-20031230'
make: *** [build-stamp] Error 2
chilly:~/debian-installer-20031230# 



Looking at the end of mklibs.py:

   # Canonicalize library names.
   for lib in regexpfilter(os.listdir(dest_path), "(.*so[.\d]*)$").elems():
   lib_path = dest_path + "/" + lib
   if os.path.islink(lib_path):
   debug(DEBUG_VERBOSE, "Unlinking %s." % lib)
   os.remove(lib_path)
   continue
   soname = extract_soname(lib_path)
   if soname:
   debug(DEBUG_VERBOSE, "Moving %s to %s." % (lib, soname))
   os.rename(dest_path + "/" + lib, dest_path + "/" + soname)
   
   # Make sure the dynamic linker is present and is executable
   ld_file = find_lib(ldlib)
   ld_file_name = os.path.basename(ld_file)
   
   if not os.access(dest_path + "/" + lib, os.F_OK):
   command(target + "objcopy", "--strip-unneeded -R .note -R .comment",
   ld_file, dest_path + "/" + ld_file_name)
   
   os.chmod(dest_path + "/" + ld_file_name, 0755)


That for-loop corrupts global lib_path, which makes find_lib() fail.

That "if not os.access(..." line is testing for 'lib' which never exists
as it just moved it.   I believe it should be using ldlib:

-  if not os.access(dest_path + "/" + lib, os.F_OK):
+  if not os.access(dest_path + "/" + ldlib, os.F_OK):


Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation Report (failure)

[Richard Hirst]

On Thu, Jan 01, 2004 at 03:50:35PM -0500, Joey Hess wrote:
> Erich Waelde wrote:
> > New year, new images, new luck, new exciting features:
> > 
> > used image from ~manty:
> > sarge-i386-netinst-20031231.iso (2003-12-31 17:00)
> > 2c806ec1e53ac891b431ab0a6a84bfab  
> > 
> > 
> > Everything works fine until "Installation of Basesystem"
> > installation returned Error 127
> > 
> >   tail /target/var/log/debootstrap.log
> >   Errors were encountered while processing:
> >libgnutls7
> >exim4-daemon-light
> >mailx
> >at
> >exim4
> 
> This will be fixed in approximatly 1.5 hours.
> 
> > HOWEVER:
> >   /target/bin/sleep is available
> > and
> >   chroot /target
> >   sleep 2
> >   exit
> > works.
> > So
> >   cp /target/bin/sleep /bin
> >   cp /target/lib/librt* /lib
> >   sleep 2
> > now works as well
> 
> I've never tried to work out what is trying to call sleep where and fix
> it; it only happens on error anyway.

It is debootstrap, in file 'functions', in repeat()

We should take that sleep out, or add sleep to busybox - people keep
assuming that their install failed because 'sleep' wasn't found.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i ia64 install report

[Richard Hirst]

On Thu, Jan 01, 2004 at 01:10:53PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote:
> > > Richard Hirst wrote:
> > > > parted seems to be broken.  It doesn't seem able to create filesystems
> > > > anymore.  Havn't looked in to this yet, but "mkpartfs pri ext2 1000
> > > > 2000" just returns to the prompt without apparently doing anything.
> > > > Need to look in to this a bit more and file bug.
> > > 
> > > I've been hearing murmerings about parted for a few days, is this a
> > > more widespread problem? There was a new version uploaded recently.
> > 
> > Serious bug filed on parted 1.6.6-2; the new amiga fs support breaks all
> > filesystem creation.
> 
> Is this specific to ia64, or is it also breaking i386?

I see no reason why it would be ia64 specific.  I assume it is no longer
possible to create filesystems with parted on any arch.  d-i will of
course create filesystems for you, for ext[23], so the fact that parted
can't currently create an fs isn't fatal for i386.  It is fatal for ia64
because we rely on parted to create the FAT boot partition filesystem.

parted can still create partitions, it just can't create filesystems
within those partitions.  mkpart works, mkpartfs and mkfs don't.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i ia64 install report

[Richard Hirst]

On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > parted seems to be broken.  It doesn't seem able to create filesystems
> > anymore.  Havn't looked in to this yet, but "mkpartfs pri ext2 1000
> > 2000" just returns to the prompt without apparently doing anything.
> > Need to look in to this a bit more and file bug.
> 
> I've been hearing murmerings about parted for a few days, is this a
> more widespread problem? There was a new version uploaded recently.

Serious bug filed on parted 1.6.6-2; the new amiga fs support breaks all
filesystem creation.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i ia64 install report

[Richard Hirst]

On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote:
> Richard Hirst wrote:
> > Installing sarge didn't work, because it doesn't have the newest
> > debootstrap, so I used it to install sid.  This is the first time I've
> > tried d-i for a few weeks, and some things have broken in the meantime.
> 
> d-i is supposed to use debootstrap-udeb, which as a udeb is not in
> testing (but just symlined to it along with all the others). So I don't
> understand what you mean by the above. Is it possible debootstrap-udeb
> 0.2.21 has not yet been compiled for ia64?

I think the sid script already pulled in libacl/libattr, while the sarge
script didn't.  0.2.21 fixed the sarge script to pull in those libs too.
So, using an older debootstrap worked for sid, but not sarge.  0.2.21 is
compiled for ia64, but I guess it just didn't make that iso build.  I'm
assuming the debootstrap udeb comes off the iso, not from the archive..

> I've been hearing murmerings about parted for a few days, is this a
> more widespread problem? There was a new version uploaded recently.

I'll try and look closer tomorrow.

> > jbailey has hit problems on his box because the 2.4.20 kernel we boot
> > doesn't have include a module for the 53c1030.
> 
> I understand that Bdale is in the process of fixing this. Of course it
> requires a kernel rebuild and, apparently, a marge. Sigh.

Good to hear; I'm a bit out of touch atm.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i ia64 install report

[Richard Hirst]

This is using the daily build sarge-ia64-buisnesscard.iso, dated
30-DEC-2003 11:02.

Installing sarge didn't work, because it doesn't have the newest
debootstrap, so I used it to install sid.  This is the first time I've
tried d-i for a few weeks, and some things have broken in the meantime.

Issues:

Some char-set issue on language selection, top line has '?', at
least.  Didn't see this problem before.

Failed to detect my cdrom (ide), because it never loaded ide-probe-mod.o
I have to manually modprobe that before d-i loaded the other kernel
modules for cdrom detection to work.  If I modprobed it after d-i failed
to detect the cd, I then had to manually mknod /dev/cdrom b 3 0 and tell
d-i to use that.  Didn't see this problem before.

dhcp network config got an ip address ok, but failed to fill in
/etc/resolv.conf, so it couldn't resolve names.  Had to give ip addr for
my local mirror.  Didn't see this problem before.

Auto kernel selection picked 2.4.19, although there are newer ones
available.  We need code to detect the appropraite one for the h/w
really (smp, itanium, mckinley), and a more recent version.  May be
problems going for the most recent though, as that has switched to
everything modular, and booting via an initrd.  Don't know if elilo
setup will need some tweeks for that.

elilo failed to run because I didn't have a vaild boot partition with a
FAT filesystem on it already on the disk.  Had to run elilo manually
with --format, or mkdosfs first (after chroot-ing to /target).  The
right way to get round that is to use parted to make a fat32 filesystem
on the boot partition when creating it, but:

parted seems to be broken.  It doesn't seem able to create filesystems
anymore.  Havn't looked in to this yet, but "mkpartfs pri ext2 1000
2000" just returns to the prompt without apparently doing anything.
Need to look in to this a bit more and file bug.

jbailey has hit problems on his box because the 2.4.20 kernel we boot
doesn't have include a module for the 53c1030.

Now dannf has done the ia64 work of getting initrd based booting to
work, with everything modular, I think we really should switch to using
his 2.4.22 kernels for d-i, and installing that kernel.  That might
require some elilo setup fixes.

I see the autobuild of d-i fails, re QM_MODULES.  IIRC that was a glibc
problem, and I thought it was fixed.

I'm a bit out of touch with d-i, so it may be some of these issues are
known/inhand.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: architectures status

[Richard Hirst]

On Tue, Dec 09, 2003 at 04:53:10PM -0500, Joey Hess wrote:
> If you're involved in a d-i port, please write back and tell me what the
> current status is (boots to main menu, some successful installs,
> whatever), and what you expect the status to be in approximatly 2 weeks.

I've been working on ia64, and to some extent parisc.  Unfortunatey real
work means I wont do anything else significant on either in the next few
weeks.

parisc worked quite well on my test box (B180) last time I tried, but
that was maybea couple of months ago.  ia64 builds - Jeff Bailey builds
from CVS every day - but I don't know how well the resulting images work
ATM.  It is certainly possible that they work well enough to release,
but someone with some more time than me needs to test them.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs commit to debian-installer/libdebian-installer/src by waldi

[Richard Hirst]

On Tue, Nov 18, 2003 at 06:49:32AM +0100, Bastian Blank wrote:
> On Fri, Nov 14, 2003 at 07:26:21PM +0000, Richard Hirst wrote:
> > Havn't looked closely at this code, but that struct looks like it will
> > end up generating lots of unaligned access traps on ia64, as mem[] will
> > be on a 4 rather than 8 byte binary.
> 
> please explain why the size of size_t is 4 bytes on your ia64, any ia64
> machine i know have 8 byte.

Sorry for the noise.. I see that s/di_ksize_t/size_t/ was done to fix
this problem.

> >   I'm a little confused, because I
> > thought this allocation stuff had been ripped out in favour of plain
> > malloc().
> 
> Not yet, as someone break make demo and therefor the debugging facility.

OK, thanks.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs commit to debian-installer/libdebian-installer/src by waldi

[Richard Hirst]

On Thu, Nov 13, 2003 at 02:29:00PM -0700, [EMAIL PROTECTED] wrote:
> Update of /cvs/debian-boot/debian-installer/libdebian-installer/src
> In directory gluck:/tmp/cvs-serv10695/src
> 
> Modified Files:
>   Makefile.am exec.c hash.c mem.c packages.c parser_rfc822.c 
>   string.c 
> Added Files:
>   mem_chunk.c 
> Log Message:
> - cleanup includes
> - make code more modular
> 
> 
> --- NEW FILE: mem_chunk.c ---
...
> struct di_mem_area
> {
>   di_mem_area *next;   /**< the next mem area */
>   di_mem_area *prev;   /**< the previous mem area */
>   size_t index;/**< the current index into the "mem" array */
>   size_t free; /**< the number of free bytes in this mem area */
>   size_t allocated;/**< the number of atoms allocated from this area */
>   char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
> *   the actual size of this array is determined by
> *   the mem chunk "area_size". ANSI says that it
> *   must be declared to be the maximum size it
> *   can possibly be (even though the actual size
> *   may be less).
> */
> };

Havn't looked closely at this code, but that struct looks like it will
end up generating lots of unaligned access traps on ia64, as mem[] will
be on a 4 rather than 8 byte binary.  I'm a little confused, because I
thought this allocation stuff had been ripped out in favour of plain
malloc().

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-installer images failing on ia64 autobuilder

[Richard Hirst]

On Sun, Nov 09, 2003 at 11:07:28PM -0500, Joey Hess wrote:
> Joey Hess wrote:
> > Joey Hess wrote:
> > > The following packages have unmet dependencies:
> > >   debootstrap-udeb: Depends: mounted-partitions
> > 
> > I see Richard Hirst fixed this, so never mind.
> 
> Nope, spoke too soon, it's still failing on ia64:
> 
> http://buildd.debian.org/fetch.php?&pkg=debian-installer&ver=20031109&arch=ia64&stamp=1068431608&file=log&as=raw
> 
> mkfs.msdos -i deb1 -n "Debian Inst" -C dest/cdrom-image.img.new 8192
> /bin/sh: line 1: mkfs.msdos: command not found
> 
> Well at least the error is different this time. Is this a missing build-dep
> for ia64?

Well, mkfs.msdos comes from dosfstools, which you added, thanks.  Next
line of the script uses mcopy, which comes from mtools, hence my change.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-installer images failing on ia64 autobuilder

[Richard Hirst]

On Sun, Nov 09, 2003 at 11:07:28PM -0500, Joey Hess wrote:
> Joey Hess wrote:
> > Joey Hess wrote:
> > > The following packages have unmet dependencies:
> > >   debootstrap-udeb: Depends: mounted-partitions
> > 
> > I see Richard Hirst fixed this, so never mind.
> 
> Nope, spoke too soon, it's still failing on ia64:
> 
> http://buildd.debian.org/fetch.php?&pkg=debian-installer&ver=20031109&arch=ia64&stamp=1068431608&file=log&as=raw
> 
> mkfs.msdos -i deb1 -n "Debian Inst" -C dest/cdrom-image.img.new 8192
> /bin/sh: line 1: mkfs.msdos: command not found
> 
> Well at least the error is different this time. Is this a missing build-dep
> for ia64?

Yes, just added mtools for ia64.  It nearly completed the build that
time :)

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 install report

[Richard Hirst]

On Sat, Nov 08, 2003 at 12:00:04PM +, Richard Hirst wrote:
> Had to boot with TERM_UTF8=no to avoid issue where bterm dies with
> SIGILL.  Not yet investigated or filed bug.  hadn't seen that before as
> I'd been testing netboot, which doesn't use bterm.

Actually, I think bterm just hangs, when I switch consoles to try and
figure out what happened, bterm gets SIGILL.

> 'Detect hardware' seemed to cause main-menu to die, ps showed a
> main-menu in state Z, one in state S, and no menu displayed.  Killed the
> frontend that was running and got main-menu redisplayed with 'Partition
> a harddrive' highlighted.  Hadn't seen that with my local built
> netboots.  Not investigated yet.

Following 'Detect hardware', I'm left with a blue screen.  Rather than
switching consoles and killing processes, I can just hit ctrl-c to get
back to main-menu.  Running frontend detect-hw by itself doesn't seem to
fail.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ia64 install report

[Richard Hirst]

INSTALL REPORT

Debian-installer-version:


Dated 07-Nov-2003 16:17

uname -a:

Linux (none) 2.4.20-ia64 #1 Tue Oct 14 04:24:27 MDT 2003 ia64 unknown

Date: Sat,  8 Nov 2003 11:40:08 +

Method: cdrom boot, businesscard iso

Machine: ia64 bigsur (i2000 proto)

Processor: 2 off itanium-I @ 667MHz

Memory: 1GB

Root Device: SCSI

Root Size/partition table: 2GB, /dev/sdb4, with /dev/sdb1 as efi boot
partition.

Output of lspci:

Base System Installation Checklist:

Initial boot worked:[O]
Configure network HW:   [E] had to manually modprobe eepro100
Config network: [O] (dhcp)
Detect CD:  [O]
Choose a mirror:[O]
Load installer modules: [O] loaded from CD
Detect hard drives: [O]
Partition hard drives:  [ ] parted ran ok, but I used existing partitions
Create file systems:[O]
Mount partitions:   [O]
Install base system:[O]
Install the kernel: [O]
Install boot loader:[O]
Reboot: [O]
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Comments/Problems:

Manually modprobing eepro100 is because ia64 doesn't have e100.o atm,
and discover-data got changed to specify e100 recently.  Bug 219513
filed, new kernel expected soon.

Had to boot with TERM_UTF8=no to avoid issue where bterm dies with
SIGILL.  Not yet investigated or filed bug.  hadn't seen that before as
I'd been testing netboot, which doesn't use bterm.

'Detect hardware' seemed to cause main-menu to die, ps showed a
main-menu in state Z, one in state S, and no menu displayed.  Killed the
frontend that was running and got main-menu redisplayed with 'Partition
a harddrive' highlighted.  Hadn't seen that with my local built
netboots.  Not investigated yet.

Installed sid, because debootstrap is broken for sarge on ia64
(libreadlin4), bug 219655 filed.

Would have liked to use a local mirror, but fix for that is not in this
build.

When "Downloading packages" the dialog box often (but not for all pkgs)
says "Validating %s".

On reboot, console has lots of non-implemented syscall warnings as a
result of the new glibc - bug 219512.

So, still limping along a bit, unfortunately.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#219503: choose-mirror broken for manual entry

[Richard Hirst]

package: choose-mirror
vesrion: cvs (0.21+)
tags: d-i

If you run choose-mirror and try to "enter information manually", it
doesn't work.  Used to work until recently.

The problem is in choose-mirror.c, where choose_country() ends with:

country = strdup(debconf->value);
debconf_set (debconf, DEBCONF_BASE "country", country);

Then in choose_mirror(), it does:

manual_entry = ! strcmp(debconf->value, "enter information manually");

but by this time, debconf->value has been set to "value set", so the
compare always fails.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fdisk isn't getting installed

[Richard Hirst]

On Sat, Nov 01, 2003 at 10:01:49PM +0100, Goswin von Brederlow wrote:
> Hi,
> 
> when trying out images on alpha today I noticed that fdisk is not
> getting installed.
> 
> Two things can be done:
> 
> 1. raise fdisks priority so anna installs it
> 2. have partitioner depend on it
> 
> The 2. thing needs to happen but I think the first should also
> happen. Some other archs fdisks have priority standard and only
> fdisk-udeb has a lower one. Also on archs or setups without
> partitioner frontend you still need to partition your disk.
> 
> Any objections against me fileing bugs against partitioner and fdisk
> to implement this?

Sounds like this might help for hppa also, so that cfdisk gets installed
automatically, see #213773.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [powermac] installation report gluck image from october 31

[Richard Hirst]

On Sat, Nov 01, 2003 at 04:51:24PM +0100, Sven Luther wrote:
> On Sat, Nov 01, 2003 at 02:59:38PM +0000, Richard Hirst wrote:
> > On Sat, Nov 01, 2003 at 02:18:45AM +0100, Arnaud Vandyck wrote:
> > > Hi all! 
> > > 
> > > Many progress! Many thanks for the good job. 
> > > 
> > > Now the problems I faced:
> > > 
> > > - debootstrap stopped with error code 127.  I read the 
> > >   /target/var/log/debootstrap.log:
> > > ln: /target/usr/bin/awk: File exists
> > > 
> > > So I deleted the symlink in a shell (I cannot go to another console :(),
> > > then exit and re-run install the  base system. A lot of packages seem to
> > > have been installed but I got a debootstrap error code 1. In the log:
> > > Errors were encountered while processing:
> > >   amiga-fdisk
> > 
> > You need to look farther back in the log to see what the problem was
> > processing amiga-fdisk.  It's likely your install used a version of
> > debootstrap that doesn't install libreadline4, which amiga-fdisk needs.  
> > libreadline4 was removed from debootstrap in a recent version, breaking
> > m68k (since fixed, except libreadline4 is now included twice in sarge)
> > and ia64 (bug filed).  It seems it broke powerpc as well.
> 
> BTW, there is a libreadline-less version of amiga-fdisk, called
> amiga-fdisk-bf. Maybe it is this one that needs to be used here ?

We're not trying to use amiga-fdisk at this point; debootstrap is trying
to install the base system on to the target filesystem.  It would seem
odd to me if the target system ended up with amiga-fdisk-bf installed
rather than the full package.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [powermac] installation report gluck image from october 31

[Richard Hirst]

On Sat, Nov 01, 2003 at 02:18:45AM +0100, Arnaud Vandyck wrote:
> Hi all! 
> 
> Many progress! Many thanks for the good job. 
> 
> Now the problems I faced:
> 
> - debootstrap stopped with error code 127.  I read the 
>   /target/var/log/debootstrap.log:
> ln: /target/usr/bin/awk: File exists
> 
> So I deleted the symlink in a shell (I cannot go to another console :(),
> then exit and re-run install the  base system. A lot of packages seem to
> have been installed but I got a debootstrap error code 1. In the log:
> Errors were encountered while processing:
>   amiga-fdisk

You need to look farther back in the log to see what the problem was
processing amiga-fdisk.  It's likely your install used a version of
debootstrap that doesn't install libreadline4, which amiga-fdisk needs.  
libreadline4 was removed from debootstrap in a recent version, breaking
m68k (since fixed, except libreadline4 is now included twice in sarge)
and ia64 (bug filed).  It seems it broke powerpc as well.

> /usr/sbin/debootstrap: 1: sleep: not found

IIRC debootstrap uses sleep, but busybox-cvs doesn't provide it.  Seems
relatively harmless.

Richard


> I'll try tomorrow (heu...  well, later today ;)) with
> DEBCONF_PRIORITY=normal
> 
> Cheers and many thanks for the good job! 
> 
> -- 
>   .''`.   ** Debian GNU/Linux **
>  : :' :  Arnaud   Vandyck
>  `. `'   http://people.debian.org/~avdyk/
>`-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment

[Richard Hirst]

On Sun, Oct 12, 2003 at 11:48:07PM +0200, Falk Hueffner wrote:
> First, IMHO we should drop this stuff and just use malloc. I don't see
> any point in increasing code size and introducing new bugs thereby.
> 
> Anyway:
> 
> > struct di_mem_area
> > {
> >   di_mem_area *next;   /**< the next mem area */
> >   di_mem_area *prev;   /**< the previous mem area */
> >   di_ksize_t index;/**< the current index into the "mem" array */
> >   di_ksize_t free; /**< the number of free bytes in this mem area */
> >   di_ksize_t allocated;/**< the number of atoms allocated from this area */
> >   char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
> > *   the actual size of this array is determined by
> > *   the mem chunk "area_size". ANSI says that it
> > *   must be declared to be the maximum size it
> > *   can possibly be (even though the actual size
> > *   may be less).
> > */
> > };
> > 
> > 
> > I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
> > didn't dig in to the code far enough to see if it should be 8 on 64
> > bit platforms.
> 
> Just use long mem[] there, we can assume a C99 compiler, and it will
> ensure alignment (at least for all Linux platforms).

Really?  I thought the code later referenced something like

&foo->mem[bar]

which will surely break if you just s/char/long/

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215455: ddetect needs to modprobe ide-floppy.o on ia64

[Richard Hirst]

package: ddetect
version: 0.44
tags: d-i

On ia64 we have ide-floppy.o, and not floppy.o.  I'm not sure what the
right way is to make ddetect modprobe ide-floppy.o... we could just add

  echo "ide-probe-mod:Linux IDE probe Driver"
  echo "ide-detect:Linux IDE detection Driver"
+ echo "ide-floppy:Linux IDE Floppy Driver"
  echo "ide-disk:Linux ATA DISK Driver"
  echo "ide-cd:Linux ATAPI CD-ROM Driver"
  echo "isofs:Linux ISO 9660 Filesystem Driver"
  #echo "i82365:Linux Unknown"


to get_hw_info(), unless anyone has a better idea.  Only drawback would
appear to be that there will be a low priority prompt to load it from a
floppy if you want the driver, on other archs.  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215453: ddetect, bad pattern match on module search

[Richard Hirst]

package: ddetect
version: 0.44
tags: d-i

The following line from hw-detect.sh

if find /lib/modules/`uname -r`/ | grep -q ${module}\\.o

is broken.  On ia64 we don't have floppy.o but we do have ide-floppy.o.
When trying to load the floppy module, the above grep matches
ide-floppy.o and consequently it does a modprobe floppy and throws up an
error dialog.  Fix will be something like:


-   if find /lib/modules/`uname -r`/ | grep -q ${module}\\.o
+   if find /lib/modules/`uname -r`/ | grep -q /${module}\\.o$


I'll file a seperate bug to get ddetect to probe for ide-floppy as well.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment

[Richard Hirst]

package: libdebian-installer
version: cvs
tags: d-i

di_mem_chunk_alloc() returns 4 byte aligned areas, even on 64 bit
platforms.  This is bad, when the caller is going to lay some struct
containing longs or pointers over the alloc-ed memory.  On ia64 it
results in loads of unaligned access exceptions flooding dmesg.

Alloc-ed memory comes from the mem[] array in the following struct
(from src/mem.c):

struct di_mem_area
{
  di_mem_area *next;   /**< the next mem area */
  di_mem_area *prev;   /**< the previous mem area */
  di_ksize_t index;/**< the current index into the "mem" array */
  di_ksize_t free; /**< the number of free bytes in this mem area */
  di_ksize_t allocated;/**< the number of atoms allocated from this area */
  char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
*   the actual size of this array is determined by
*   the mem chunk "area_size". ANSI says that it
*   must be declared to be the maximum size it
*   can possibly be (even though the actual size
*   may be less).
*/
};


given:

include/debian-installer/types.h:typedef uint32_t di_ksize_t

the above array comes out at 4 byte alignment.

We need to make mem[] aligned(MEM_ALIGN).

I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
didn't dig in to the code far enough to see if it should be 8 on 64 bit
platforms.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215404: di_check_dir() missing

[Richard Hirst]

package: libdebian-installer
version: cvs

debug builds of kbd-chooser call di_check_dir() but versions of
libdebian-installer beyond 0.15 do not provide it.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215403: debconf_capb definition broken

[Richard Hirst]

package: cdebconf
version: cvs

debconfclient.h has

#define debconf_capb(_client, _capb...) \
_client->command(_client, "CAPB", ##_capb)

which should probably have a ", NULL" included to match similar defines
in that file.

kbd-chooser gives SEGV on ia64, probably because of that missing NULL.


- _client->command(_client, "CAPB", ##_capb)
+ _client->command(_client, "CAPB", ##_capb, NULL)


Alternatively, things calling debconf_capb() need to include a NULL as
the last arg.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: why kernel-image.udeb

[Richard Hirst]

On Sat, Oct 11, 2003 at 07:55:24PM +0200, Geert Stappers wrote:
> On Sat, Oct 11, 2003 at 07:06:02PM +0200, Steinar H. Gunderson wrote:
> > Hi,
> > 
> > The businesscard .iso is now about ~60MB, which probably won't even fit on
> > most "businesscard"-sized CDs. Could somebody please answer:
> 
>  [several questions why the image is so large]
> I afford myself the luxury that some team member will answer.
> 
> > 
> > - Really, what do you need the kernel-image udebs for at all?
> That is where I can help.
> 
> The "d-i-boot-kernel" does not has to be the "base-config-boot-kernel",
> e.g. network boot, run d-i, reboot from harddisk and run base-config.
> It is the modular concept of Debian Installer.

Do we really need kernel-image udebs on the iso?  I can see that we
might want some kernel module udebs.  We might consider a kernel-image
deb (not udeb), but I don't see the point, when it is supposed to be a
_net_ install.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 testers wanted for sarge cds

[Richard Hirst]

On Tue, Oct 07, 2003 at 11:07:18PM +0200, Santiago Garcia Mantinan wrote:
> Peter, please reply to the lists, I don't know a thing about ia64 and people
> on the lists can help us with this kind of things ;-)
> 
> On Oct 07 2003, Peter Chubb wrote:
> > > "Santiago" == Santiago Garcia Mantinan <[EMAIL PROTECTED]> writes:
> > 
> > Santiago> to see if they boot, the installer is started, and if that
> > 
> > The credit card image doesn't boot on I2000; it appears not to have a
> > DOS EFI filesystem on it to boot off.
> 
> So, what is this DOS EFI filesystem?
> 
> Is it really needed? I mean, others have booted it, or are there several
> booting methods and depending on the maker we have to implement a different
> one?

I'm away from home and unable to actually try your ISOs this week.
However, the ISOs will boot the same way on all ia64 boxes.  The d-i
build produces a cdrom-image.img which is basically a large "floppy"
image (8MB, iirc), containing a FAT filesystem.  On that filesystem is
the kernel and initrd images, elilo.efi, and elilo.conf.  This floppy
image is what is being referred to as a DOS EFI filesystem.  debian-cd
creates the ISO, specifying that floppy image as the boot image.  When
you put the CD in the ia64 box, and from the EFI Shell change to the
relevant device, and issue "ls" you should see those files.  You can
then invoke 'elilo' to start the install process.  I suppose it is
possible one of your ISO images is broken, and all success reports were
for the other one, but it seems unlikely.

Peter, can you give us any more info on what you did to determine that
the CD didn't appear to be bootable?

Thanks,
  Richard


> Ideas on how to fix this?
> 
> Regards...
> -- 
> Manty/BestiaTester -> http://manty.net
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: First HPPA test

[Richard Hirst]

On Sun, Oct 05, 2003 at 08:42:34PM +0200, Thorsten Sauter wrote:
> 
> Hi all,
> 
> Yesterday, I have tried to install a fresh Debian system on my hppa
> 712/60 using the new debian-installer. Attached are my notes about this
> process. In short: most of the stuff is working, and you can using d-i
> on hppa. (debconf priority high)
> 
> 1. kbd-chooser is in the mainmenu between (!) dhcp and static network
>configuration
> 2. kbd-chooser segfaults everytime (manually edited the status file)
>imho. if something does wrong tree time, it should never displayed to
>the user.
> 3. anna display cdrom-checker/cdrom-detect/network-ppp during a network
>installation. Hmmm.
> 4. anna, only display udebs with a menuitem. So I can't install any
>fdisk program (this makes partitioner unusable)

There is a bug filed on that; problem is fdisk-udeb is priority extra.
Don't know what the answer is.

> 5. the hardware detection always told me, I need more modules
>(floppy, ide, isofs, ...) But everything is alread in the kernel
> 6. palo-installer doesn't make the disc-bootable.

Has worked for me, although it seems to report the standard verbose palo
output as 'error ouput'.

Richard


> Hardware: PA-RISC/HPPA 712/60, 32MB RAM, 60MHz :)
> 
> Notes: I have created an new lif image (which contains both 32 and 64
> bit kernels). Boot method was netboot (dhcp/tftp).
> 
> 
> Bye
> Thorsten
> 
> 
> -- 
> Thorsten Sauter
> <[EMAIL PROTECTED]>
> 
>   (Is there life after /sbin/halt -p?)
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ia64 testers wanted for sarge cds

[Richard Hirst]

Hi Khalid,
On Mon, Oct 06, 2003 at 03:31:44PM -0600, Khalid Aziz wrote:
> I tried the netinstall CD image on an HP zx2000 and didn't get very far.
> Here are the two problems I saw that prevented me from going any
> further:
> 
> 1. Selecting "Detect a keyboard and select layout" causes:
> 
> An error or warning message was logged while running kbd-chooser
> SIGSEGV

Was a problem with old kbd-chooser udeb.  CVS works ok for me, not sure
of current archive status.  Note also I havn't tried on a usb k/b box,
only on a bigsur with ps2 k/b.

> 2. "Detect CDROM" results in 
> 
> Unable to load module 'ide-probe-mod' for 'Linux IDE probe
> Driver'.

Bug Bdale, waiting on new kernel udebs ;-)  Bugs are filed with patches.

See http://www.debian.org/devel/debian-installer/ports-status for what I
had to do to make a working ia64 ISO a few days ago.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i - subarchitecture stuff

[Richard Hirst]

On Fri, Oct 03, 2003 at 11:44:19AM +0200, Wouter Verhelst wrote:
> Op vr 03-10-2003, om 10:04 schreef Richard Hirst: 
> > On Fri, Oct 03, 2003 at 08:12:59AM +0200, Wouter Verhelst wrote:
> > > I'll hereby specify for m68k:
> > > - mac
> > > - amiga
> > > - atari
> > > - vme
> > > - unknown
> > 
> > Well, as we currently have three different vme kernels (mvme147,
> > mvme16x, bvme6000), that might mean three different subarchs.
> 
> Separating kernels from eachother is done by the XB-Kernel-Version field
> in a kernel-image-udeb. Unless you're telling me that some of the VME
> boards can only boot with vmelilo, while others can only boot with
> m68k-vme-tftplilo, that won't be necessary.

No, that is not the case.  They all boot via vmelilo, and all but
mvme147 boot via tftplilo.  Sounds like they are all just 'vme' then.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i - subarchitecture stuff

[Richard Hirst]

On Fri, Oct 03, 2003 at 08:12:59AM +0200, Wouter Verhelst wrote:
> I'll hereby specify for m68k:
> - mac
> - amiga
> - atari
> - vme
> - unknown

Well, as we currently have three different vme kernels (mvme147,
mvme16x, bvme6000), that might mean three different subarchs.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Installer, ia64 status update

[Richard Hirst]

On Thu, Oct 02, 2003 at 07:58:49AM -0700, Matt Kraai wrote:
> On Thu, Oct 02, 2003 at 07:46:44AM -0700, Matt Kraai wrote:
> > On Thu, Oct 02, 2003 at 12:56:23PM +0100, Richard Hirst wrote:
> > > Ugh, just seen it in action.  Very ugly, IMHO, with the window jumping
> > > up and down the screen, changing height, and wrapping in the middle of
> > > the package name (which is really the only interesting bit of
> > > information in that text).
> > > 
> > > I think it would look much nicer to abbreviate the line somehow (as in
> > > my exapmle above) rather than wrap it.  Maybe we do that in the front
> > > end, or maybe we make debootstrap do it, working on some assumption such
> > > as progress text should not be longer than 70 chars.
> > 
> > I'd prefer the latter.
> 
> Actually, since the package name is the only interesting part, why
> not have debootstrap display only that?

Sounds like a good idea to me.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Thu, Oct 02, 2003 at 04:19:21PM +0200, Sven Luther wrote:
> On Thu, Oct 02, 2003 at 02:47:37PM +0100, Richard Hirst wrote:
> > Yes, and having the auto-partitioner understand to create an f0
> > partition for hppa, and a small efi boot partition for ia64, etc, would
> > be very nice.  I just havn't had chance to look at that yet.
> 
> Do you think you will find the time for this nextly, or someone else
> should start to look into this ?

Probably in the next few weeks, for ia64 anyway.  But if someone wants
to beat me to it, that's fine.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Thu, Oct 02, 2003 at 03:37:26PM +0200, Sven Luther wrote:
> On Thu, Oct 02, 2003 at 01:53:22PM +0100, Richard Hirst wrote:
> > To fix this issue, I'd need to expose a new flag through the parted i/f,
> > so you could "set palo on", or similar.  For msdos tables it would know
> 
> Adding a flag is almost trivial to do, no ?

Sure, it was when I added hp_service, anyway.

> > that meant to set type=f0.  For other partition table types it would
> > have no effect.  Alternatively I could introduce a new command
> > completely for setting a partition table 'type' to some user-specified
> > hex value.  But what would that do for non-msdos tables?  Having an
> > interface where you can type in 32 byte GUIDs seems silly to me.
> 
> Notice that libparted already knows how to do that, but does it only
> when writing filesystem. There is no way currently to tell libparted to
> set a given partition type, and use another tool to create the
> filesystem. I have also been playing with the thought of adding some
> kind of attribute setting for partitions, which could accept, in
> addition to boolean flags, also other kind of values (which are needed
> to set the filesystem block type on amiga partition/filesystems for
> example, as well as the boot priority).

Sounds good, parted does need some feature like that, IMHO.

> > As to why I havn't done anything about this.. there really hasn't been
> > any incentive as we have cfdisk on hppa which works fine and has a nice
> > easy to understand interface.  If d-i ends up dictating that I have to
> > use parted, or eventually presents a nicer interface to parted than its
> > current cli one, then it'll be worth worrying about.
> 
> Well, libparted is not only used by parted proper, but also by a bunch
> of other tools in d-i.

Yes, and having the auto-partitioner understand to create an f0
partition for hppa, and a small efi boot partition for ia64, etc, would
be very nice.  I just havn't had chance to look at that yet.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Thu, Oct 02, 2003 at 09:51:08AM +0200, Sven Luther wrote:
> On Wed, Oct 01, 2003 at 12:41:49AM +0100, Richard Hirst wrote:
> > On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote:
> > > On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote:
> > > >> Make it depend on "partitioning-program", and make both fdisk-udeb and
> > > >> parted-udeb "Provide[s]:" that. Should solve the problem.
> > > > No, it won't.  anna could still install just parted-udeb since
> > > > that would satisfy the dependency.  If partitioner depends on a
> > > > particular udeb, it needs to Depend on the particular udeb.
> > > 
> > > If parted-udeb is unusable on a particular platform, I'd take it it was never
> > > built/uploaded for that platform at all...?
> > 
> > I didn't mean to say that parted was unusable on hppa.  It exists
> > and probably works ok.  But parted cannot be used for creating the 
> > 'f0' partition that palo needs.
> 
> Have you ever considered asking the parted upstream author or filling a
> bug report against the parted debian package, for this particular
> feature request.
> 
> I have been doing some parted work, but know nothing about the hppa
> specific needs, but if you explain it to me, i may be willing to add the
> needed support to libparted or something.

I've put quite a bit of effort in on parted in the past too, relating to
GPT partition tables.  The issue is that parted tends to identify
partition types by their content, and not by the 'type' byte in an msdos
partition table.  This is partly because parted handles many different
partition table formats, they don't all have a 'type' byte, and parted
tries to present a uniform interface.  GPT tables, for example, have a
32 byte GUID instead.  So parted lets you say "this partition is for
linux swapspace", and for msdos tables it knows to set the type to 82
and for GPT it knows to use some specific GUID.  Some special types or
GUIDs are exposed to the parted interface as 'flags' you can set.  e.g.
if you set the hp_service 'flag', it will write the
PARTITION_HPSERVICE_GUID in a GPT table.

To fix this issue, I'd need to expose a new flag through the parted i/f,
so you could "set palo on", or similar.  For msdos tables it would know
that meant to set type=f0.  For other partition table types it would
have no effect.  Alternatively I could introduce a new command
completely for setting a partition table 'type' to some user-specified
hex value.  But what would that do for non-msdos tables?  Having an
interface where you can type in 32 byte GUIDs seems silly to me.

As to why I havn't done anything about this.. there really hasn't been
any incentive as we have cfdisk on hppa which works fine and has a nice
easy to understand interface.  If d-i ends up dictating that I have to
use parted, or eventually presents a nicer interface to parted than its
current cli one, then it'll be worth worrying about.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#213669: cdebconf-newt-udeb: progress bar dialog changes size all the time, which is ugly

[Richard Hirst]

On Thu, Oct 02, 2003 at 05:48:42AM -0700, Matt Kraai wrote:
> On Wed, Oct 01, 2003 at 10:55:17PM +0200, Steinar H. Gunderson wrote:
> > With the "progress bar status text wrapping" patch that was made at
> > debcamp, the dialog changes size all the time (it changes height) to
> > make room for the new text. When the text changes frequently (like
> > installing packages from a fast source) this makes the dialog box change
> > size back and forth all the time, which flickers and is really really
> > ugly.
> > 
> > I'd propose keeping it at a fixed height (say, three lines) and simply
> > cropping the text if it is larger than that -- alternatively, make the
> > minimum height three lines and making it expand above that, which at
> > least reduces the flickering considerably.
> 
> This isn't such a problem on my 128-column console.  :)
> 
> I'd prefer to only let it grow, rather than truncate the text.
> Here's the patch I'll commit if it passes testing.

It'll still look ugly, as it flickers between


Retrieving: http://beast/debian/pool/main/e/ef/ef_0.3_ia64.udeb


Retrieving:
http://beast/debian/pool/main/e/efi-reader/efi-reader_0.3_ia64.udeb


Retrieving: 
http://beast/debian/pool/main/l/long-efi-reader/long-efi-reader_0.3
_ia64.udeb



I accept that it isn't a problem for your wide console, which is why I
originally suggested that the frontend, which presumably knows the space
it has available, should truncate the start of the path name.  Giving
something like:


Retrieving: http://beast/debian/pool/main/e/ef/ef_0.3_ia64.udeb
Retrieving: ...debian/pool/main/e/efi-reader/efi-reader_0.3_ia64.udeb
Retrieving: ...l/main/l/long-efi-reader/long-efi-reader_0.3_ia64.udeb


where the one interesting bit on information, the package name, is in a
fairly consistent position on the screen.

It is a bit ugly from a technical pov having the frontend know it has to
truncate the start of the second component of the string, but it'll look
a whole lot nicer.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Installer, ia64 status update

[Richard Hirst]

On Sun, Sep 28, 2003 at 10:05:20AM +0200, Matt Kraai wrote:
> On Sat, Sep 27, 2003 at 01:12:18PM +0100, Richard Hirst wrote:
> > I'm using the newt frontend, which looks pretty good, except for some
> > package names running off the edge of the screen during base install.
> > Maybe the frontend code could cut down the start of the filepath,
> > keeping the first word of the line intact, so it looks like:
> > 
> >Retrieving: ...ebian/pool/main/f/foobar_1.2_ia64.deb
> > 
> > Frotend-specific, of course, because the frontend is the bit that knows
> > how wide the window is.
> 
> There is code in CVS to wrap long progress bar information.

Ugh, just seen it in action.  Very ugly, IMHO, with the window jumping
up and down the screen, changing height, and wrapping in the middle of
the package name (which is really the only interesting bit of
information in that text).

I think it would look much nicer to abbreviate the line somehow (as in
my exapmle above) rather than wrap it.  Maybe we do that in the front
end, or maybe we make debootstrap do it, working on some assumption such
as progress text should not be longer than 70 chars.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote:
> On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote:
> >> Make it depend on "partitioning-program", and make both fdisk-udeb and
> >> parted-udeb "Provide[s]:" that. Should solve the problem.
> > No, it won't.  anna could still install just parted-udeb since
> > that would satisfy the dependency.  If partitioner depends on a
> > particular udeb, it needs to Depend on the particular udeb.
> 
> If parted-udeb is unusable on a particular platform, I'd take it it was never
> built/uploaded for that platform at all...?

I didn't mean to say that parted was unusable on hppa.  It exists
and probably works ok.  But parted cannot be used for creating the 
'f0' partition that palo needs.

Anyway, for any arch where you are going to partition manually, you'll
surely want to use cfdisk rather than cmdline parted, if possible.

(ia64 is an exception, as parted is the only thing that can create GPT
partition tables).

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Tue, Sep 30, 2003 at 03:09:25PM -0700, Matt Kraai wrote:
> On Tue, Sep 30, 2003 at 06:59:05PM +0100, Richard Hirst wrote:
> >   For hppa I need fdisk-udeb pulled in when d-i runs.  parted cannot be
> > used to partition for hppa because we need a partition for palo of type
> > 'f0', and parted doesn't let you specify partition types (didn't last
> > time I looked anyway).  At the moment I have to specifically request
> > that installer module in the "load installer modules" menu item.
> > 
> > How should I make fdisk-udeb get pulled in automatically?  I could make
> > palo-installer depend on it, I guess, but that doesn't sound very
> > logical as palo doesn't really care which partitioner is used provided
> > it creates the right partitions.
> 
> I think the Depends field for partitioner should be
> 
>  Depends: cdebconf-udeb, fdisk-udeb, hw-detect-full
> 
> on hppa and left as
> 
>  Depends: cdebconf-udeb, parted-udeb, hw-detect-full
> 
> on other architectures.  I'm not sure how to do this, though.

According to partitioner/scripts/* there are many archs that want
*fdisk.  I can see lilo-installer depends on it, so I guess it is pulled
in for i386, but for no-one else.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i, pulling in fdisk-udeb

[Richard Hirst]

On Tue, Sep 30, 2003 at 11:07:37PM +0200, Geert Stappers wrote:
> On Tue, Sep 30, 2003 at 06:59:05PM +0100, Richard Hirst wrote:
> > Hi,
> >   For hppa I need fdisk-udeb pulled in when d-i runs.  parted cannot be
> > used to partition for hppa because we need a partition for palo of type
> > 'f0', and parted doesn't let you specify partition types (didn't last
> > time I looked anyway).  At the moment I have to specifically request
> > that installer module in the "load installer modules" menu item.
> > 
> > How should I make fdisk-udeb get pulled in automatically?  I could make
> > palo-installer depend on it, I guess, but that doesn't sound very
> > logical as palo doesn't really care which partitioner is used provided
> > it creates the right partitions.
> 
> In build/Makefile is this code:
> 
> |# Build the driver floppy image
> |$(EXTRA_TARGETS) : %-stamp : $(TYPE)-get_udebs-stamp
> |mkdir -p  ${TEMP}/$*
> |for file in $(shell grep --no-filename -v ^\#  pkg-lists/$*/common \
> |`if [ -f pkg-lists/$*/$(DEB_HOST_ARCH) ]; then echo 
> pkg-lists/$*/$(DEB_HOST_ARCH); fi` \
> || sed -e 's/^\(.*\)$${kernel:Version}\(.*\)$$/$(foreach 
> VERSION,$(KERNELIMAGEVERSION),\1$(VERSION)\2\n)/g' ) ; do \
> |cp $(EXTRAUDEBDIR)/$$file* ${TEMP}/$*  ; \
> |echo $$file >> ${TEMP}/$*/udeb_include; \
> |done
> |touch $@
> 
> It generates "udeb_include" from files under build/pkg-lists
> I have not yet played with it, but that is where I would start
> adding udebs.

Hmm, I could add fdisk-udeb to pkg-lists/*/hppa, but that would include
the udeb in the initrd image, rather than downloading it from the cdrom
or mirror at runtime along with the other d-i modules.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i, pulling in fdisk-udeb

[Richard Hirst]

Hi,
  For hppa I need fdisk-udeb pulled in when d-i runs.  parted cannot be
used to partition for hppa because we need a partition for palo of type
'f0', and parted doesn't let you specify partition types (didn't last
time I looked anyway).  At the moment I have to specifically request
that installer module in the "load installer modules" menu item.

How should I make fdisk-udeb get pulled in automatically?  I could make
palo-installer depend on it, I guess, but that doesn't sound very
logical as palo doesn't really care which partitioner is used provided
it creates the right partitions.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian Installer, ia64 status update

[Richard Hirst]

Installing from cdrom works, although my build system has local fixes
for a few bugs where I'm waiting for new versions of packages:

210570 - discover-data, fix module used for various QLogic cards
210359 - kernel-patch-2.4.20-ia64, CONFIG_TR kernel headers problem,
 breaks busybox-cvs
212328 - kernel-patch-2.4.20-ia64, include ide-probe-mod.o
211088 - module-init-tools, fails to install because arch/generic missing

I know Bdale is travelling, and will get to the kernel-patch bugs soon.

There may be changes in d-i cvs that havn't uploaded yet, as well.

There is an issue with a recent debootstrap change which removed
libperl5.8 from the required list.  That breaks things for sarge
installs because the corresponding change to perl packaging isn't in
sarge yet.  I assume that'll sort itself out in time.  I've reverted
that change in my local debootstrap for now.

Outstanding issues:

A couple of menu items (cdrom detect, and h/w detect full version, iirc)
give me dialogs complaining that something went wrong with "modprobe
floppy".  ia64 needs to modprobe ide-floppy instead, and hppa has no
floppy support atm.  Not sure of the best way to make this arch
specific.

Configure partitions option throws up a dialog about failing to load the
xfs module - I don't have one, so it should not try to load it, or
should fail silently.  I have priority=medium atm.

I've also tested installing from the net successfully (actually loading
the kernel and initrd from a floppy, but using the TYPE=netboot image).

I'm using the newt frontend, which looks pretty good, except for some
package names running off the edge of the screen during base install.
Maybe the frontend code could cut down the start of the filepath,
keeping the first word of the line intact, so it looks like:

   Retrieving: ...ebian/pool/main/f/foobar_1.2_ia64.deb

Frotend-specific, of course, because the frontend is the bit that knows
how wide the window is.

I'm not a d-d, so I assume I can't update the d-i status page.. if
someone could do that I'd appreciate it.

Thanks,
  Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: d-i experiences

[Richard Hirst]

On Tue, Sep 16, 2003 at 12:58:40AM +0100, Daniel Silverstone wrote:
> It seems debootstrap barfed on an id call, something to do with [ and

I see this on ia64 too.  'id' in busybox doesn't work in the d-i
environment, but does work in a normal system environment.  That
particular error seems to be non-fatal.  debootstrap does 'id -u' and
gets "id: unknown group: 0" or similar.  As it is in something like

  if [ `id -u` != "0" ]; then

the shell complains.  My guess was that 'id' might require more
libraries (*nss* stuff), but I havn't invesigated further yet.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Initial d-i success on alpha

[Richard Hirst]

On Wed, Sep 17, 2003 at 11:40:47PM -0500, Steve Langasek wrote:
>  - debootstrap fails with an error ',: applet not found' (IIRC -- I
>don't have the log in front of me right now).  That's game,set,match;
>can't do much if you can't start the actual install. :)

Had this on ia64 also.  Turned out the busybox-cvs build was broken,
'tr' existed as a link to busybox, but tr functionality was not in
busybox.  The cause was broken glibc headers.. linux/config.h was
getting included and that does "#undef CONFIG_TR" (no token ring), which
overrode the CONFIG_TR in busybox.  Bug filed on krnel-patch_2.4.20-ia64.

HTH,
  Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i, kernel-img.conf and {link,image}_in_boot

[Richard Hirst]

Hi,
link_in_boot is just the new name for image_in_boot.
rootskel/debian/templates-arch defined link_in_boot, which is used in
tools/base-installer/debian/kernel-installer.postinst when creating
/etc/kernel-img.conf.  However, that script writes

image_in_boot = yes
link_in_boot = $link_in_boot

which confuses elilo, at least.  elilo looks for either of those values
set to 'yes' to decide what to do, and for ia64 link_in_boot = no.

So should we set them both to $link_in_boot, or should we just delete
the old image_in_boot entry?  If no-one says different, I'll delete the
old image_in_boot entry.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR

[Richard Hirst]

package: busybox-cvs
version: 0.60.99.cvs20030819

On ia64 the kernel has CONFIG_TR undefined (token ring).  The busybox
build pulls in /usr/include/linux/autoconf.h, which includes the line

#undef CONFIG_TR

That results in the 'tr' applet being disabled in the config-udeb build.

The include sequence to pull in autoconf.h is

/usr/include/linux/autoconf.h
/usr/include/linux/config.h:4,
/usr/include/asm/param.h:11,
/usr/include/linux/param.h:4,
/usr/include/sys/param.h:24,
include/busybox.h:111,
applets/applets.c:32:

This stops debian-installer (actually debootstrap) working on ia64.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian installer on ppc/pegasos

[Richard Hirst]

On Wed, Aug 27, 2003 at 05:44:45PM +0200, Sven Luther wrote:
> On Wed, Aug 27, 2003 at 01:41:06AM -0700, Chris Tillman wrote:
> > On Wed, Aug 27, 2003 at 08:16:07AM +0200, Sven Luther wrote:
> > > RAMDISK: Compressed image found at block 0
> > > Freeing initrd memory: 2028k freed
> > > VFS: Mounted root (ext2 filesystem) readonly.
> > > Mounted devfs on /dev
> > > Freeing unused kernel memory: 320k init 40k pmac 8k prep
...
> Nope, nothing more. I think it is definitively related to the 206531
> bug.

Similar problem on ia64 last night; I copied a full libc6 in to my
initrd and things were much better - I got the d-i main menu displayed.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Status for reiser support in d-i

[Richard Hirst]

On Tue, Aug 26, 2003 at 04:57:36PM +0400, Yury Umanets wrote:
> On Tue, 2003-08-26 at 16:34, Richard Hirst wrote:
> > On Tue, Aug 26, 2003 at 01:39:05PM +0400, Yury Umanets wrote:
> > > On Tue, 2003-08-26 at 13:22, Petter Reinholdtsen wrote:
> > > > [Yury Umanets]
> > > > > But when I said, about improving parted interface, I meant, that
> > > > > somebody should write a patch exactly to making parted to use
> > > > > ncurses or something like this. I've not meant to write another
> > > > > front end. Actually there is one called qtparted.
> > > > 
> > > > Area you aware of nparted,
> > > > http://www.laespiral.org/proyectos/nparted/>?
> > > No, thanks,
> > > > 
> > > > It seem to be dead upstream, but was a nice start. :)
> > 
> > There is also cparted <ftp://ftp.parisc-linux.org/src/cparted/> which I
> > started some time ago.  It looks similar to cfdisk, but handles msdos
> > and efi partition tables via libparted.
> > 
> > One problem with it is that as you make changes via the user interface,
> > they are committed to disk directly.  You don't have an oppertunity to
> > abort after playing with your partition table, as the disk is already
> > modified.  That seems to be the way parted works, and is not very suited
> > to an installer.  Someone once said it was possible to make libparted
> > work with an in-memory image of a partition table, and avoid commiting
> > to disk until you were happy with all your changes.  Havn't investigated
> > that though, and I'm not sure how it would work w.r.t. the parted
> > approach of examining a partition content to decide what type it was.
> 
> What about filesystems? Suppose you have created partition. And suppose
> also, that you're going to create filesystem on it. But filesystem
> cannot be created without partition being initialized first and
> filesystem cannot be created in memory.

I agree, that is a problem.  One approach would be to have a front end
that used libparted to get the existing partition configuration, and
then modified that data internally based on user interaction.  Once the
user was happy, the frontend could use libparted to implement whatever
partition scheme the user finally settled on (including creating
filesystems).  I don't like the idea though; sounds like you would be
reimplementing parts of parted in the frontend to manage the partition
data while the user was interacting with it.  Hence you really do want
to use libparted to manipulate the partition table, but you don't want
it to commit changes to disk until you say so.  I guess you delay making
filesystems until after the point where you commit to disk.  Then you
end up with libparted keeping track of the proposed partition layout,
and the frontend keeping track of the proposed filesystem types, which
is also a little ugly.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Status for reiser support in d-i

[Richard Hirst]

On Tue, Aug 26, 2003 at 01:39:05PM +0400, Yury Umanets wrote:
> On Tue, 2003-08-26 at 13:22, Petter Reinholdtsen wrote:
> > [Yury Umanets]
> > > But when I said, about improving parted interface, I meant, that
> > > somebody should write a patch exactly to making parted to use
> > > ncurses or something like this. I've not meant to write another
> > > front end. Actually there is one called qtparted.
> > 
> > Area you aware of nparted,
> > http://www.laespiral.org/proyectos/nparted/>?
> No, thanks,
> > 
> > It seem to be dead upstream, but was a nice start. :)

There is also cparted  which I
started some time ago.  It looks similar to cfdisk, but handles msdos
and efi partition tables via libparted.

One problem with it is that as you make changes via the user interface,
they are committed to disk directly.  You don't have an oppertunity to
abort after playing with your partition table, as the disk is already
modified.  That seems to be the way parted works, and is not very suited
to an installer.  Someone once said it was possible to make libparted
work with an in-memory image of a partition table, and avoid commiting
to disk until you were happy with all your changes.  Havn't investigated
that though, and I'm not sure how it would work w.r.t. the parted
approach of examining a partition content to decide what type it was.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdebconf upload

[Richard Hirst]

On Wed, Mar 12, 2003 at 07:59:12AM +0800, John Summerfield wrote:
> On Tue, 11 Mar 2003, Erik Andersen wrote:
> 
> > On Mon Mar 10, 2003 at 11:00:32PM -0500, Joey Hess wrote:
> > > - switch to a smaller libc, such as uclibc
> > 
> > The only downside to this is that I currently do not support all
> > the architectures that are supported by Debian.  Adding support
> > for a new arch to uClibc is really not very hard, and most of the
> > needed bits can be directly swiped from glibc, but it does take
> > someone that is familiar with the architecture and willing to put
> > in a bit of time.
> > 
> > Debian arches not currently supported by uClibc:
> > hppa, hurd, ia64, s390
> > 
> > Working but need some additional polish and ldso support:
> > alpha, sparc, m68k 
> > 
> > Fully supported:
> > arm, i386, mips, mipsel, powerpc, sh
>  
>  
>  Does d-i need a trim libc for all these architectures? For S/390, for
>  example, if you can get a bootable kernel/initrd in place, you can get
>  as bulky an installer as you could wish too.

Likewise hppa and ia64 don't have a 1.4MB floppy limitation.  Some hppa
boxes have 1.4MB floppies, but we don't have kernel driver, and have
managed ok so far with CD and network booting.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Preparation of Boot-Floppies release 3.0.24

[Richard Hirst]

On Wed, Dec 18, 2002 at 07:55:46PM +0100, Eduard Bloch wrote:
> ( first semi-official call-for-helpers, see also:
> http://people.debian.org/~blade/bf3024/ )
> 
> Preparation of Boot-Floppies release 3.0.24
> ===

hppa b-f built from cvs Dec 21th are available here:

http://gluck.debian.org/~rgh/bf-cvs-hppa/

Now using 2.4.19 kernel.  I've tested them on a B180, serial console,
network boot, so far.

Further test reports most welcome, especialy 64 bit, as I can't easily
test that.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Preparation of Boot-Floppies release 3.0.24

[Richard Hirst]

On Wed, Dec 18, 2002 at 07:55:46PM +0100, Eduard Bloch wrote:
> ( first semi-official call-for-helpers, see also:
> http://people.debian.org/~blade/bf3024/ )
> 
> Preparation of Boot-Floppies release 3.0.24
> ===

ia64 b-f built from cvs Dec 20th are available here:

http://gluck.debian.org/~rgh/bf-cvs-ia64/

Now using 2.4.19 kernel.  I've tested them on an HP i2000, both with
serial and graphical console, and with dhcp and manual network config.
In both cases booting from 120MB floppy and installing from the net.

Further test reports most welcome.

The only issue I have is xlp.tgz which appears in the .changes file; I'm
not sure if it should, or if it should be part of bf-misc.tar.gz, or
what.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [cdebconf] helper macros, i18n, backup, etc

[Richard Hirst]

On Mon, Dec 16, 2002 at 10:09:16PM -0800, Randolph Chung wrote:
> sorry for the late reply, i was out of town for a few days.
> 
> > 1. The helper macros recently introduced do break several packages
> > under debian-installer/tools/ which used to declare their own
> > debconf_input function.  Maybe we could remove these macros, I
> > wonder whether they are that useful.
> 
> i thought you asked for them? :-)
> 
> unless i hear otherwise i'll commit a patch tomorrow to wrap them inside
> a #ifdef WITH_DEBCONF_HELPER_MACROS or something like that.

I believe I fixed all resulting breakage a few days ago, with a global
s/debconf_input/my_debconf_input/.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cdebconf/src/debconfclient.h rev 1.3 breaks things

[Richard Hirst]

"add commandf() api and helper macros per request" defined macro
debconf_input(), which breaks everything that has a local
debconf_input() function and includes that header, for example,
netcfg.c, ethdetect.c

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cvs main-menu bust?

[Richard Hirst]

This change:

@@ -304,20 +306,21 @@
int ret, i;
struct package_t *dep;
 
+   if (di_pkg_is_virtual(p)) {
+   if (!satisfy_virtual(p))
+   return 0;
+   }
+
for (i = 0; p->depends[i] != 0; i++) {
if ((dep = p->depends[i]->ptr) == NULL)
continue;
if (dep->status == installed)
continue;
-   if (di_pkg_is_virtual(dep)) {
-   if (!satisfy_virtual(dep))
-   return 0;
-   } else {
-   /* Recursively configure this package */
-   if (!config_package(dep))
-   return 0;
-   }
+   /* Recursively configure this package */
+   if (!config_package(dep))
+   return 0;
}
+
asprintf(&configcommand, DPKG_CONFIGURE_COMMAND " %s", p->package);
ret = SYSTEM(configcommand);
free(configcommand);


breaks main-menu for me.  Execute a Shell still works, but the other
entries on that first menu all just result in the main menu being
redisplayed, preceeded by

"Package libdebconf1 is already installed and configured"

This in on hppa.  Anyone else see this problem, or is it just me?

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: loading the initrd

[Richard Hirst]

On Thu, Dec 12, 2002 at 03:47:58PM -0500, Noah L. Meyerhans wrote:
> On Wed, Dec 11, 2002 at 10:14:03PM -0500, Joey Hess wrote:
> > This is something of a shot in the dark, but try using a filesystem that
> > is not cramfs. I vaguely remember some problems along these lines being
> > due to cramfs, maybe its use is not supported on a second floppy.
> 
>   Luser error.  I was using the generic kernel-image package,
> which compiles floppy support as a module.  That has been corrected.
> 
> At this point, the installer system will boot and run on my AlphaServer
> 4100.  I still have to manually load the modules for my NIC, and need to
> include the SCSI modules in the initrd.
> 
> One problem I've noticed that may be a bug is that when I tell the
> installer to "Detect hard drives and load modules for them", it only
> detects the NCR SCSI controller, which only controls my CD-ROM drive.  I
> have to manually load the qlogicisp module to be able to access my hard
> drives.
> 
> Also, when trying to partition the hard disks, I get:
> /var/lib/dpkg/info/di-utils-partitioner.postinst 51: 
>/dev/scsi/host1/bus0/target4/lun0/disc: Permission denied
> 
> This just happened, so I haven't had time to investigate it.  I'm going
> to do that now, but if this is a known issue I'd be happy to hear about
> it.

You need to fix the partitioner udeb to define FDISK for your platform.
Script does

$FDISK /dev/scsi/host1/bus0/target4/lun0/disc

buf FDISK is null.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: working on the Alpha port

[Richard Hirst]

On Thu, Dec 12, 2002 at 09:52:18AM +0100, Denis Barbier wrote:
> On Thu, Dec 12, 2002 at 05:31:41AM +0300, Alexander Kotelnikov wrote:
> [...]
> > Dec 12 02:19:35 (none) user.info init: Starting pid 882, console /dev/console: 
>'/sbin/debian-installer' 
> > Cannot open template file /var/lib/cdebconf/templates.dat
> > Cannot open template file /var/lib/cdebconf/templates.dat

I hit a similar problem when I started the hppa port; turned out that I
was mounting '/' read-only.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Default disk partition table type?

[Richard Hirst]

On Tue, Dec 10, 2002 at 12:41:23PM +0100, Petter Reinholdtsen wrote:
> 
> The current autopartkit contains the following code:
> 
>   /* Need to define on a per arch basis */
>   #if defined(__i386__)
>   #define DISK_LABEL "msdos"
>   #else /* not __i386__ */
>   #error "Default DISK_LABEL is not known on this platform"
>   #endif /* not __i386__ */
> 
> What is the partition table type on other platforms/architectures?  I
> believe the available values are "bsd", "loop", "mac", "msdos", "pc98"
> and "sun".  I got the values from the parted documentation.

hppa used msdos.

ia64 uses gpt (which parted does support) these days, but has use msdos
in the past.

m68k uses different ones on different h/w; the mvme boards use msdos.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i hppa support update

[Richard Hirst]

Currently builds a net-boot image, 32 bit only, which I have
successfully used to install on a B180, via serial and graphical
consoles.  Install ran right through to login prompt fairly smoothly.
If you want to build it, you need a kernel udeb, which you can find
here:



along with my latest boot image.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-i on hppa semi-working

[Richard Hirst]

Hi,
  I have d-i semi-working on hppa; currently breaks on 'partition hard
drive' because it doesn't know which partitioner to use.  I will commit
changes, or file bugs, as appropriate in the next day or two.

My current build (net-bootable image) is at

ftp.parisc-linux.org:/home/ftp/d-i/lifimage-32-20021202.gz


Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: todo?

[Richard Hirst]

On Wed, Nov 06, 2002 at 12:21:56AM +0100, Tollef Fog Heen wrote:
> Getting d-i to work on other arches than i386 is high-priority.

I know talk is cheap, but I do intend to work on d-i for hppa and ia64.
Just a matter of finding time to get started.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: woody install for hppa

[Richard Hirst]

On Wed, Oct 02, 2002 at 11:01:30PM -0400, Neal Robinette wrote:
> Hi, I am trying to install woody on a 735/99 with 320 megs of RAM and
> a 2.4 GB HP FW SCSI hard drive. I have downloaded copies of the
> install disks. Installationgoes just fine, but the install program
> can't detect my harddrive. I had thought that the problem with the FW
> SCSI on the 735 had been resolved; is there a certain setting I need

Sorry, FW disks on 735 still don't work under linux.

> to change, etc., to get the install program to "see" my harddrive? I
> am using an external NEC scsi cd-rom drive to install from, and have
> no floppy or other removable media for this machine. Is this still an
> active problem, or is there a fix not included with the woody distro?

It's one of those problems that gets worked on every now and then when
someone has time/interest/hardware.  Don't know when it is likely to be
resolved.

Some people are using 735 by adding a narrow SE drive to the interface
with the CDROM.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-i] debconf, partitioning widget?

[Richard Hirst]

On Wed, Jul 17, 2002 at 09:21:51AM +0200, Tollef Fog Heen wrote:
> * Richard Hirst 
> 
> | Current status is that it can handle msdos and gpt table creation, and
> | partition creation and deletion.  Tested only on ia64.  Not touched it
> | since March, but I can certainly make the code available.
> 
> yes please.

<ftp://ftp.parisc-linux.org/src/cparted/>

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-i] debconf, partitioning widget?

[Richard Hirst]

On Tue, Jul 16, 2002 at 10:14:36PM +0200, Eduard Bloch wrote:
> #include 
> Philip Blundell wrote on Tue Jul 16, 2002 um 09:03:29PM:
> 
> > Ah, I just noticed that there is already a newt-based parted frontend
> > (nparted), which will do for "dialog" mode.  The standard parted should
> > suffice for "readline" mode; I think it should be easy enough to put
> 
> I tested nparted. Buggy like hell.

It was when I looked too, but that was some time ago.  I started work on
something I called cparted a while ago, which was a cfdisk-like front end
to parted.  It doesn't yet support all the flashy features of parted
(partition moving, resizing), but it has the advantage that it is a
familiar interface.

Current status is that it can handle msdos and gpt table creation, and
partition creation and deletion.  Tested only on ia64.  Not touched it
since March, but I can certainly make the code available.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#152804: boot-floppies: framebuffer causes Mobile Radeons to lock

[Richard Hirst]

On Sun, Jul 14, 2002 at 01:13:20AM +0100, Philip Blundell wrote:
> On Sat, 2002-07-13 at 17:21, Chris Tillman wrote:
> > It was already documented by Richard. But, I added some more details about
> > what the problems look like and what machines have reported problems.
> 
> Okay, cool.  I wonder if's worth explaining the distinction between
> problems caused by framebuffer itself and problems caused by bogl /
> LANG_CHOOSER lossage.  In the former case, using "nolangchooser" won't
> help.  Equally, "video=vga16:off" is hardware specific, so that isn't
> ideal either, sigh.

Actually, I came across code in drivers/video/fbmem.c (2.4 kernel) the
other day, which indicates video= works for all frame buffers.  It
supports the 'off' parameter itself, and for any other parameters it
calls the framebuffer specific code if that code has a setup function.
So, for the atari, for example, you might use "video=atafb:off", or for
hppa "video=stifb:off".  I havn't tested this, and don't know if it
applies to 2.2. kernels.  Where 'nolangchooser' just stops bterm
running, this would disable the framebuffer driver itself.  As I say,
untested.

Richard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: i18n second stage...

[Richard Hirst]

On Thu, Jun 13, 2002 at 06:54:39PM +0200, Michael Bramer wrote:
> gluck.d.o (aka ddtp) is down. Know someone the problem?

That's hosted at HP, isn't it?  they are having some internal routing
problems the last day or so.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs commit to boot-floppies by rhirst

[Richard Hirst]

On Wed, May 15, 2002 at 03:36:19PM -0500, Christian T. Steigies wrote:
> On Wed, May 15, 2002 at 09:03:13PM +0100, Richard Hirst wrote:
> > On Wed, May 15, 2002 at 09:39:22PM +0200, Pierre Machard wrote:
> > > On Wed, May 15, 2002 at 12:31:47PM -0700, Debian Boot CVS Master wrote:
> > > > Repository: boot-floppies
> > > > who:rhirst
> > > > time:   Wed May 15 12:31:46 PDT 2002
> > > > Log Message:
> > > >   add "nolangchooser" boot option to disable framebuffer;  video=vga16:off
> > > >   doesn't work on all systems (e.g. m68k, hppa)
> > > 
> > > Doesn't il also imply an update of scripts/rescue/messages ?
> > 
> > Done.  Added entry to f7.txt.
> 
> How do you read that on machines that can not boot from CD or floppy?
> Is this also mentioned in the documentation?

Will be shortly.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs commit to boot-floppies by rhirst

[Richard Hirst]

On Wed, May 15, 2002 at 09:39:22PM +0200, Pierre Machard wrote:
> On Wed, May 15, 2002 at 12:31:47PM -0700, Debian Boot CVS Master wrote:
> > Repository: boot-floppies
> > who:rhirst
> > time:   Wed May 15 12:31:46 PDT 2002
> > Log Message:
> >   add "nolangchooser" boot option to disable framebuffer;  video=vga16:off
> >   doesn't work on all systems (e.g. m68k, hppa)
> 
> Doesn't il also imply an update of scripts/rescue/messages ?

Done.  Added entry to f7.txt.

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: coordinating b-f 3.0.23 release

[Richard Hirst]

On Wed, May 15, 2002 at 12:01:22PM -0500, Christian T. Steigies wrote:
> On Wed, May 15, 2002 at 12:23:59PM -0400, Adam Di Carlo wrote:
> > 
> > For coordinating, can we agree to perhaps tag and start it building
> > tonight?  I don't see anything blocking 3.0.23 release.
> 
> Do we now have an option to switch the language chooser off? Something that
> works on framebuffers as well (VGA=off is not an option on m68k, hppa).
> Currently woody boot-floppies are not usable on monochrome macs and ataris,
> which is already creating a lot of pain...

I've commited my change so booting with 'nolangchooser' stops it using
bterm and hence the framebuffer. Undocumented as yet..

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]