[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: beta4 status



joeyh@debian.org (Joey Hess) writes:

> What we have right now in the sarge_d-i CDs and in unstable is very
> close to the final release. Only for powerpc and sparc are there
> possibly some changes in the initrds that are still building. For all
> the other architectures, there should be no changes, and so we need to
> do any final testing we can.
>
> Please test the images in unstable/main/installer-<arch>/current/ and in
> http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i

Tried hppa and ia64.  Results as follows.

  cdimage-testing/sarge_d-i/hppa/current/sarge-hppa-netinst.iso

This fails to boot, because the palo command line is too long.  The fixes I
made last week to d-i's config files along with the kernel udeb update to 0.54
wasn't sufficient, we also needed to update the debian-cd sarge/post-boot-hppa
to trim the palo command line.  I have done so, and the change is in debian-cd
CVS.  I'll be happy to try again as soon as we get a fresher image with this
fixed.

  cdimage-testing/sarge_d-i/ia64/current/sarge-ia64-netinst.iso

The file overlap between libc6.1 and initscripts is still causing a fatal error
during the debootstrap run.  I assume that means the fixed debootstrap wasn't
used, and/or one of the libc6.1 or initscripts packages is out of date?  What
do we need to do to fix this?

Additionally, I note that the CDROM driver modules aren't loading right.  On
a zx6000 I was able to shell out and modprobe both cdrom and ide-cd, at which
point CD detection worked and things progressed ok until debootstrap failed.
I've studied the cdrom-detect source, but it looks like it only tries to load
the 'cdrom' module and that only after it fails to find anything and interacts
with the user.  What do I need to change to get the likely modules loaded
before cdrom-detect's postinst does its thing?  I'd like to fix this for beta4.

And finally, ia64 systems use EFI for firmware, and it needs a FAT partition
to hold the elilo bootloader, etc.  If I use the manual partitioning to create
one, but don't give it a mount point (in Debian we don't mount this partition
routinely), I get a complaint about the lack of a specified mount point and the
text would confuse an inexperienced ia64 user.  How should I address this?  Do
I need to add a partman-elilo method, or is there some other hack I can use to
keep the install process from complaining about a FAT partition not having a
mount point assigned?  This qualifies as errata-only for beta4.

Finally, automatic partitioning for both hppa and ia64 is, of course, useless 
until #244736 is addressed after beta4.

Bdale



Reply to: