Re: [Question] Integrating the debian installer in live-build - DVD, multi-arch, custom, etc.

2020-04-15 Thread Ian Campbell
On Wed, 2020-04-15 at 18:56 +, dbgr wrote:
> Is there any way that you know of to integrate any of this installer 
> options (or even a 'custom' one) in live-build? Is there a plan to do so 
> in the future as an option?

Is this what Calamares is supposed to be for? TBH all I know about it
is what I read at 
https://jonathancarter.org/2019/10/17/calamares-plans-for-debian-11/
via planet Debian some time ago, but maybe it's something to
investigate...

See also https://packages.debian.org/buster/calamares

Ian.




Re: Default security sources are slow very much.

2020-02-06 Thread Ian Campbell
On Thu, 2020-02-06 at 07:41 +, Andy Simpkins wrote:
> It isn't safe to mirror security patches because we can not assure
> the integrity of the updates on a mirror server.

The security mirrors are secured by by apt using the same cryptographic
signatures as the other suites, so that's not true, they can be
mirrored just fine (at least in principal, I don't know how much of the
mirror network actually carries them).

I think the real reason the default security sources are the
main/central one is to reduce the latency in getting critical/urgent
fixes out (i.e. no need to wait for a mirror pulse), but if that
doesn't work for a given setup there's no reason not to change to use a
mirror, it looks like deb.debian.org supports security so presumably
that's a good bet.

Ian.



Re: Comments on live-build, vmdebootstrap, bootstrap-vz, and live-wrapper

2016-08-23 Thread Ian Campbell
On Tue, 2016-08-23 at 18:40 +1000, Adam Bolte wrote:
> 
> I'm not sure if it would be possible to use pygrub if your assigned
> volume is partitioned, which may be a problem if you don't control
> the Dom0.

pygrub has supported devices with partition tables for many years (like
at least a decade).

EC2 uses pvgrub, not pygrub, although AFAICT pvgrub has also never had
a problem with partitions.

Ian.



Re: Bug#812236: CD-Image does not boot with Libreboot/GRUB

2016-01-25 Thread Ian Campbell
On Thu, 2016-01-21 at 23:48 +, Steve McIntyre wrote:

Getting a bit OT for the bug.

> In fact, I've seen this exact problem myself on a Libreboot machine
> when trying to install Jessie a few weeks back. What I did in the end
> was drop to a grub command prompt and start the installer by hand that
> way. It looks like a (design?) bug that Libreboot won't do normal boot
> sector booting like a conventional BIOS.

I think for that case you want (or need) to use seabios as your coreboot
payload, since it provides the necessary "conventional BIOS" part of the
puzzle.

Ian.



Re: Bug#812236: CD-Image does not boot with Libreboot/GRUB

2016-01-25 Thread Ian Campbell
On Mon, 2016-01-25 at 13:06 +, Ian Campbell wrote:
> On Thu, 2016-01-21 at 23:48 +, Steve McIntyre wrote:
> 
> Getting a bit OT for the bug.
> 
> > In fact, I've seen this exact problem myself on a Libreboot machine
> > when trying to install Jessie a few weeks back. What I did in the end
> > was drop to a grub command prompt and start the installer by hand that
> > way. It looks like a (design?) bug that Libreboot won't do normal boot
> > sector booting like a conventional BIOS.
> 
> I think for that case you want (or need) to use seabios as your coreboot
> payload, since it provides the necessary "conventional BIOS" part of the
> puzzle.

I should say, I've no personal experience of doing so, but I've seen people
trying it on the seabios devel list which I happen to follow for other
reasons.

Ian.



Re: Suggestions for CD images - following CD talk at Debconf

2015-08-31 Thread Ian Campbell
On Sat, 2015-08-22 at 11:34 +, Andrew M.A. Cater wrote:
> On Sat, Aug 22, 2015 at 08:41:36AM +0100, Ian Campbell wrote:
> > On Fri, 2015-08-21 at 22:26 +, Andrew M.A. Cater wrote:
> > > 
> > > [Off topic for _this_ list: I've got UEFI netboot working with 
> > > bootnetx64.efi which is different from the grub etc. for CD/DVD - 
> > > which is iikely to continue?
> > 
> > I'm not sure what the question is, are you asking if UEFI netboot is
> > likely to continue to be supported? I think so, yes.
> > 
> [Extended to debian-efi list because this overlaps]
> 
> Sorry, I wasn't being clear:
> 
> "Legacy" PXE boot over the network and UEFI boot don't appear to work 
> together well.
> 
> If the PXE server is set up to serve pxelinux.0 and you switch your
> computers boot mechanism to UEFI rather than CSM compatible/legacy
> mode then the process will fail silently and you are left wondering
> what you did wrong.

The DHCP server should be configured to serve the right thing (~= PXE
payload) for the machine, this can (apparently) be done automatically
using the arch option according to e.g. https://access.redhat.com/docum
entation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1
-netboot-pxe-config-efi.html 

> 
> This is now becoming more important with some motherboards not supporting
> "legacy" settings, with the Bay Trail machines having 32 bit UEFI and 64
> bit processors - thanks for the fact that this now just works, Sledge.
> 
> Different distributions handle this UEFI net booting differently:

This is partly because unlike with Legacy boot there is no de facto
standard for the PXE payload (which is what pxelinux.0 is for Legacy
world).

So each distro ends up building its own grub image to use as the PXE
payload, and that grub requires its own corresponding set of modules in
the PXE dir. Note that one distros "bootnetx64.efi" may not be anything
like another distros "bootnetx64.efi".

In theory you can put your own grub image into your PXE infra and use
each distros grub.cfg (ignoring their grub modules etc) via that,
hoping that the distro isn't relying on features of their own specific
grub binary.

The only real solution here is for a new de facto standard for PXE
payload to arise for the UEFI world or for someone to proactively talk
to all the distros and define such a thing.

> CentOS 6 _ought_ to work with bootnetx64.efi - but doesn't appear to 
> for me.
> 
> Debian 8 Jessie can use bootnetx64.efi - serve that from your TFTP 
> server
> with all the other files from the default debian-installer available 
> in /srv/tftp and you get
> a text mode install which actually works quite well. 
> 
> Ubuntu 14.04 LTS uses grubnetx64.efi.signed and a special grub.conf 
> file. This produces a minimal
> install but you can then add e.g. ubuntu-desktop.
> 
> CentOS 7 can also use a grubnetx64 and a similar grub.conf file. If 
> you invoke the right parameters
> you end up in a full graphical install.
> 
> UEFI installation media - the Jesie netinst.iso, for example, appears 
> to use grub - not bootnetx

"bootnetx" _is_ grub, I think you are assuming it is something else
because of the name? It's not, it's just grub, configured/built for
network booting. (I'm not sure if the name scheme comes from UEFI spec,
which does define BOOT$ARCH.EFI for non-network boot, or if someone
just made it up at some point).

BTW the "x" in bootnetx64 binds to the 64, i.e. it is "bootnet" for the
"x64" architecture. Likewise in grubnetx64.

> Are we likely to move to the grubnetx64.efi / grub.conf method for 
> UEFI network booting?

Given that bootnetx64.efi _is_ grub other than the name of the file to
be delivered as the PXE payload what exactly are you asking to change?

The the client system the name is irrelevant anyway, it just sees the
pxe payload.

Ian.



Re: Suggestions for CD images - following CD talk at Debconf

2015-08-22 Thread Ian Campbell
On Fri, 2015-08-21 at 22:26 +, Andrew M.A. Cater wrote:
 
 [Off topic for _this_ list: I've got UEFI netboot working with 
 bootnetx64.efi which is different from the grub etc. for CD/DVD - 
 which is iikely to continue?

I'm not sure what the question is, are you asking if UEFI netboot is
likely to continue to be supported? I think so, yes.

If you are asking if the grub used for CD/DVD is likely you continue to
differ from the one used for network boot then I'm not sure. It might
be possible to combine them into one larger grub with all the relevant
modules, but at the moment they have different prefixes (the place
where they search for grub.cfg) encoded in the binary, one defaults to
on the disk (indirectly via a memdisk) and the other looks to the
network. Combining them would be the subject of some investigation to
determine if this can be avoided (perhaps using some more advanced
scripting). I had a brief look at one point and it seemed non-trivial
(plus I was worried about breaking existing uses)

Ian.

 Ubuntu and CentOS 7 appear to use grubnetx64.efi at the moment for 
 UEFI netboot - on topic for debian-efi?]
 
 Happy to help write web page, build images, volunteer or do whatever 
 I can :)
 
 All the best,
 
 AndyC
 
 



Re: What package is in charge for bugs in netboot/mini.iso ?

2015-08-21 Thread Ian Campbell
On Fri, 2015-08-21 at 18:10 +0200, Thomas Schmitt wrote:
 Hi,
 
 is it known that these two images do not boot on qemu
 of Jessie ?
   http://ftp.debian.org/debian/dists/unstable/main/installer
 -amd64/current/images/netboot/mini.iso
   http://ftp.debian.org/debian/dists/unstable/main/installer
 -i386/current/images/netboot/mini.iso
 
 The BIOS obviously finds isolinux.bin via El Torito or MBR
 but this immediately gets stuck after the first SYSLINUX message.
 Last word is ETCD or EHDD, depending on qemu -cdrom or -hda.
 
 
 If not known: Towards which package to report ?

Assuming it isn't thought to be a qemu but then against the debian
-installer package please. I've not heard of it but please check the
buglist first (reportbug will prompt you do to so anyway).

Cheers,
Ian.



Re: Bug#788532: grub-efi-ia32-bin should be shipped on install DVD

2015-06-12 Thread Ian Campbell
Control: reassign -1 debian-cd

This is actually the responsibility of the debian-cd package,
reassigning.

On Fri, 2015-06-12 at 15:17 +0200, Gregor Riepl wrote:
 Package: grub-efi-ia32-bin
 Version: 2.02~beta2-22
 Severity: important
 Tags: d-i
 
 Dear Maintainer,
 
 When installing Debian 8 on a system with a x86_64 CPU, but with a 32bit UEFI,
 debian-installer correctly identifies the system as requiring a 32bit EFI 
 Grub,
 and thus tries to install grub-efi-ia32-bin.
 
 However, this package is not contained on the amd64 installation DVD, 
 requiring
 an active internet connection to get the package from a package server. This
 may not always be possible, for example when the network hardware is not
 supported by the installed Linux kernel and no alternative network connection
 is available.
 
 Please add this package to the installation DVD so an internet connection is
 not required during installation.
 
 Thank you.
 
 
 
 -- Package-specific info:
 
 *** WARNING grub-setup left core.img in filesystem
 
 *** BEGIN /proc/mounts
 /dev/dm-0 / ext4 rw,noatime,discard,errors=remount-ro,data=ordered 0 0
 /dev/sda1 /boot vfat 
 rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
  0 0
 *** END /proc/mounts
 
 *** BEGIN /boot/grub/device.map
 (hd0) /dev/disk/by-id/ata-SAMSUNG_MZ7TD256HAFV-000L7_S16GNEAD601136
 (hd1) /dev/disk/by-id/usb-SanDisk_Cruzer_Pattern_3109330F0440D127-0:0
 *** END /boot/grub/device.map
 
 *** BEGIN /boot/grub/grub.cfg
 #
 # DO NOT EDIT THIS FILE
 #
 # It is automatically generated by grub-mkconfig using templates
 # from /etc/grub.d and settings from /etc/default/grub
 #
 
 ### BEGIN /etc/grub.d/00_header ###
 if [ -s $prefix/grubenv ]; then
   set have_grubenv=true
   load_env
 fi
 if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
 else
set default=0
 fi
 
 if [ x${feature_menuentry_id} = xy ]; then
   menuentry_id_option=--id
 else
   menuentry_id_option=
 fi
 
 export menuentry_id_option
 
 if [ ${prev_saved_entry} ]; then
   set saved_entry=${prev_saved_entry}
   save_env saved_entry
   set prev_saved_entry=
   save_env prev_saved_entry
   set boot_once=true
 fi
 
 function savedefault {
   if [ -z ${boot_once} ]; then
 saved_entry=${chosen}
 save_env saved_entry
   fi
 }
 function load_video {
   if [ x$feature_all_video_module = xy ]; then
 insmod all_video
   else
 insmod efi_gop
 insmod efi_uga
 insmod ieee1275_fb
 insmod vbe
 insmod vga
 insmod video_bochs
 insmod video_cirrus
   fi
 }
 
 if [ x$feature_default_font_path = xy ] ; then
font=unicode
 else
 insmod part_gpt
 insmod fat
 set root='hd0,gpt1'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 
 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  200E-9FE4
 else
   search --no-floppy --fs-uuid --set=root 200E-9FE4
 fi
 font=/grub/unicode.pf2
 fi
 
 if loadfont $font ; then
   set gfxmode=auto
   load_video
   insmod gfxterm
   set locale_dir=$prefix/locale
   set lang=C
   insmod gettext
 fi
 terminal_output gfxterm
 if [ ${recordfail} = 1 ] ; then
   set timeout=-1
 else
   if [ x$feature_timeout_style = xy ] ; then
 set timeout_style=menu
 set timeout=5
   # Fallback normal timeout code in case the timeout_style feature is
   # unavailable.
   else
 set timeout=5
   fi
 fi
 ### END /etc/grub.d/00_header ###
 
 ### BEGIN /etc/grub.d/05_debian_theme ###
 insmod part_gpt
 insmod fat
 set root='hd0,gpt1'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 
 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  200E-9FE4
 else
   search --no-floppy --fs-uuid --set=root 200E-9FE4
 fi
 insmod png
 if background_image /grub/.background_cache.png; then
   set color_normal=white/black
   set color_highlight=black/white
 else
   set menu_color_normal=cyan/blue
   set menu_color_highlight=white/blue
 fi
 ### END /etc/grub.d/05_debian_theme ###
 
 ### BEGIN /etc/grub.d/10_linux ###
 function gfxmode {
   set gfxpayload=${1}
 }
 set linux_gfx_mode=
 export linux_gfx_mode
 menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
 --class os $menuentry_id_option 
 'gnulinux-simple-c4db752c-876c-403f-9197-ccf5f677265f' {
   load_video
   insmod gzio
   if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
   insmod part_gpt
   insmod fat
   set root='hd0,gpt1'
   if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 
 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  200E-9FE4
   else
 search --no-floppy --fs-uuid --set=root 

Re: Draft for D-I Jessie RC2

2015-03-28 Thread Ian Campbell
On Fri, 2015-03-27 at 17:10 +, Steve McIntyre wrote:
 On Thu, Mar 26, 2015 at 10:40:26PM +0100, Cyril Brulebois wrote:
 Ian Campbell i...@debian.org (2015-03-26):
  On Thu, 2015-03-26 at 19:44 +0100, Karsten Merker wrote:
   due to https://bugs.debian.org/773645 offline hd-media installations do
   not work for arm platforms. It is disputable whether this is a debian-cd
   or d-i (no hard dependency on u-boot-tools in d-i/flash-kernel, cf.
   https://bugs.debian.org/780994) issue, but it should perhaps be noted
   in the errata if it cannot be taken care of during building the d-i RC2
   disk images.
  
  I was in two minds about fixing #780994 for Jessie vs. leaving it until
  Stretch, but #773645 makes it a no-brainer IMHO, I'll prepare an upload
  to Jessie soon.
 
 Yeah, I witnessed that.
 
  I assume a recommends will cause d-cd to do the desired thing?
 
 ISTR that it should. Steve will probably (co|i)nfirm.

 Yes, it should do.

Super, thanks for confirming.

NB I didn't do anything with #773645 since it is assigned to d-cd, but
it could probably now be closed, or at least reduced severity?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1427536907.1320.37.ca...@debian.org



Bug#781305: unblock: flash-kernel/3.34

2015-03-27 Thread Ian Campbell
Package: release.debian.org
Severity: normal
Tags: d-i
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package flash-kernel both deb and udeb.

flash-kernel-installer will automatically install u-boot-tools as needed, so
installation via the installer works fine, however users who do things manually
(i.e. with debootstrap) are frequently caught out by the lack of u-boot-tools.
Since u-boot-tools is needed on the majority of systems these days and in any
case is quite small bump the Suggests into a Recommends.

I believe that this will also fix #773645 in debian-cd since it considers
Recommends when deciding to include stuff on CD1.

diff -Nru flash-kernel-3.33/debian/changelog flash-kernel-3.34/debian/changelog
--- flash-kernel-3.33/debian/changelog  2015-03-05 06:56:52.0 +
+++ flash-kernel-3.34/debian/changelog  2015-03-26 21:37:26.0 +
@@ -1,3 +1,11 @@
+flash-kernel (3.34) unstable; urgency=medium
+
+  * Update u-boot-tools to Recommends. In practice it is needed on most systems
+but having it installed only by flash-kernel-installer means it is missed
+in manual configurations. (Closes: #780994)
+
+ -- Ian Campbell i...@debian.org  Thu, 26 Mar 2015 21:37:16 +
+
 flash-kernel (3.33) unstable; urgency=medium
 
   [ Karsten Merker ]
diff -Nru flash-kernel-3.33/debian/control flash-kernel-3.34/debian/control
--- flash-kernel-3.33/debian/control2015-03-05 06:56:52.0 +
+++ flash-kernel-3.34/debian/control2015-03-26 21:37:26.0 +
@@ -18,7 +18,7 @@
  initramfs-tools (= 0.92f),
  linux-base (= 3.2),
  ucf
-Suggests: u-boot-tools
+Recommends: u-boot-tools
 Description: utility to make certain embedded devices bootable
  flash-kernel is a script which will put the kernel and initramfs in
  the boot location of embedded devices that don't load the kernel and


unblock flash-kernel/3.34

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150327100114.12349.91218.report...@dagon.hellion.org.uk



Re: Draft for D-I Jessie RC2

2015-03-26 Thread Ian Campbell
On Thu, 2015-03-26 at 19:44 +0100, Karsten Merker wrote:
 due to https://bugs.debian.org/773645 offline hd-media installations do
 not work for arm platforms. It is disputable whether this is a debian-cd
 or d-i (no hard dependency on u-boot-tools in d-i/flash-kernel, cf.
 https://bugs.debian.org/780994) issue, but it should perhaps be noted
 in the errata if it cannot be taken care of during building the d-i RC2
 disk images.

I was in two minds about fixing #780994 for Jessie vs. leaving it until
Stretch, but #773645 makes it a no-brainer IMHO, I'll prepare an upload
to Jessie soon.

I assume a recommends will cause d-cd to do the desired thing?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1427405940.1320.31.ca...@debian.org



Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?

2015-03-05 Thread Ian Campbell
On Thu, 2015-03-05 at 12:25 +0100, Cyril Brulebois wrote:
  OK. Assuming amd64 is working OK, I should check the rsync has not
  broken - that seems to be the most likely cause right now. Thinking:
  it would also be lovely to verify the versions of vmlinuz and the
  kernel udebs in debian-cd at build time, and (optionally?) abort the
  build if we know we're going to be making broken images. What do you
  think?
 
 There's no way for us to know a breakage is going to happen. In this
 particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is
 embedded in kernel udeb package names, so if the ABI matches, udebs are
 supposed to be compatible with the kernel. I'm not sure why that is not
 the case here (maybe the ABI doesn't cover or not completely udebs?). We
 really shouldn't enforce using the very same revision for kernel and
 module udebs, IMHO.

Caveat: I might be talking out my a**e here...

I think the ABI only guarantees you can load old modules into a newer
vmlinuz. In particular I think it doesn't guarantee that you can load
newer modules into an older vmlinuz (even if the ABI is the same).

The ABI is there to stop your existing modules from breaking when you
update the kernel.

IOW it is permissible for a module to gain a dependency on a new symbol
provided by a newer vmlinuz.

This is why local netboot pxe infra sometimes breaks -- they have a
vmlinuz downloaded locally but are pulling udebs off the network, which
might therefore be newer.

Please reread my caveat now though ;-)

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1425568787.25940.233.ca...@debian.org



Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader

2015-02-01 Thread Ian Campbell
On Tue, 2015-01-27 at 17:03 +0100, Thomas Schmitt wrote:

Thank you (again?) for all the excellent info you've provided here and
in your followups.

 I did not guess too bad with my repacking experiment.
 
 But this does not explain how the empty FAT partition
 got to the end of mini.iso
 I see in
   
 http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg#n347
 
   geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO)
 
 So obviously the appended partition was not intended for EFI
 but for additional firmware.

Ah yes, that would seem to make sense.

Given that I don't really understand how this additional firmware
partition stuff is supposed to fit together (i.e. what impact changing
its partition number or adding another VFAT partition etc would have on
the code which finds/loads from it) I'm very reluctant to be the one to
suggest that we should change things here for Jessie given we've had the
beta and are frozen etc. Perhaps we should park this until Stretch?
(Kibi, any thoughts on that?)

It's not really clear to me who the intended audience of these
mini.iso's are:

It seems (IMHO only) that mini.iso is mostly useful for d-i developers
to dev test the netboot installer images without needing to rebuild the
full netinst images (so both legacy and EFI capabilities are useful
there).

But I think most end users would be better off being directed to the
proper netinst images instead, they are more polished and better tested
etc (since they share code with the larger ISO images and what have
you).

At some point it seems like improving mini.iso more for end users would
simply be duplicating effort with the CD team.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1422785352.15317.20.ca...@debian.org



Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader

2015-01-27 Thread Ian Campbell
On Tue, 2015-01-27 at 09:15 +0100, Cyril Brulebois wrote:
 I've just grabbed mini.iso in both (respectively used for Beta 2 and RC
 1), and both seem to have efi bits inside (at least according to a loop
 mount).

Not speaking of bootarch.efi but -- there was no useful grub.cfg on
the x86 mini.iso until the 20150107 release (see #762618). So 20150107
is certainly necessary for a useful EFI boot from mini.iso and
everything was present and correct when I was looking at #762618.

It's possible I suppose that the lack of grub.cfg might look a bit like
a lack of bootarch.efi under some circumstances.

  I don't know much about EFI Partition etc. therefore I'm not
 sure how they're related to an ISO9660 image. :/

(Feel free to skip this bit if you don't care about the details!)

The EFI System Partition (ESP) is on the ISO as /boot/grub/efi.img,
which is a file with a suitable FAT partition for EFI to read (it's also
referenced by various ISO headers, el-torito/*mumble* etc).

AFAICT the beta release (20141002) had everything needed apart from the
grub.cfg:

$ wget 
http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20141002/images/netboot/mini.iso
$ isoinfo -i mini.iso -RJ -x /boot/grub/efi.img  efi.img
$ mdir -i efi.img ::efi/boot
 Volume in drive : has no label
 Volume Serial Number is FF65-0EDB
Directory for ::/efi/boot

.DIR 2014-09-27   0:08 
..   DIR 2014-09-27   0:08 
bootx64  efi392192 2014-09-27   0:08 
3 files 392 192 bytes
 10 240 bytes free
$

The remainder of the grub bits are then on the ISO (outside the ESP)
in /boot/grub/..., except as noted, that the grub.cfg in 20141002 was
empty.

$ isoinfo -i mini.iso -fRJ | grep /boot/grub
/boot/grub
/boot/grub/efi.img
/boot/grub/font.pf2
/boot/grub/grub.cfg
/boot/grub/x86_64-efi
/boot/grub/x86_64-efi/acpi.mod
[...lots more...]

 It'd be nice to start by telling us the full URL to the mini.iso you
 downloaded.

Yes, please.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1422348131.29309.13.ca...@debian.org



Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader

2015-01-27 Thread Ian Campbell
On Tue, 2015-01-27 at 15:57 +0100, Thomas Schmitt wrote:
[...]

Thanks for all the excellent information, I still have fully absorbed it
all...

 Regrettably there is no file /.disk/mkisofs in the ISO which
 tells the used xorriso -as mkisofs options.
 I guess that /boot/grub/efi.img got marked by an option like

The code is at:
http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg#n335

and has:

xorriso -as mkisofs -r -J -b isolinux.bin -c boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-eltorito-alt-boot \
--efi-boot boot/grub/efi.img -no-emul-boot \
-o $(TEMP_MINIISO) $(TEMP_CD_TREE); \

   -e boot/grub/efi.img

I guess -e is short for --efi-boot?

 To mark this file in MBR and GPT, one may add option
 
   -isohybrid-gpt-basdat
 
 directly after -e and its argument.

I don't suppose I can tempt you into sending a patch against the above
git repo, can I? ;-)

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1422371143.25294.40.ca...@debian.org



Re: Providing (armhf) u-boot images together with d-i images?

2015-01-07 Thread Ian Campbell
On Fri, 2015-01-02 at 14:51 +0100, Karsten Merker wrote:
 On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote:
  On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
  
  Talking about other compression schemes or providing multiple versions
  of the same file will just confuse users. It looks like someone has
  commented on the duplicated concat examples in v3 too.
 
 Ok, I'll change the wording for V4. My intention was to provide a
 generic README that works regardless of which compression options
 one chooses in the makefile, so that switching from .gz to .xz
 would be simple without having to think of updating documentation
 elsewhere.
 
 If I now change the README to explicitly mention only one
 compression type, on which one shall we settle for all installer
 images on armhf?  Everything compressed by gzip or by xz?  As
 usual, this is a trade-off between compression ratio, CPU cycles
 and memory requirements on the build hosts.

I'd say go for gzip for maximum compatibility, e.g. for people making
images from Windows.

   The previous patch produces hd-media builds for use with CD/DVD
   iso images (equivalent to the i386/amd64 hd-media
   boot.img.gz). This patch produces a netboot SD card (equivalent to
   the i386/amd64 netboot mini.iso), plus a netboot.tar.gz which
   contains everything needed to be put onto a tftp server for
   tftp-booting the installer (equivalent to the i386/amd64
   PXE netboot.tar.gz).
  
  netboot.tar.gz sounds fine. What I don't get (see my reply to Vagrant)
  is what the practical difference to the user is between the hd-media
  builds and the netboot mini.iso ones, given that for ARM each is just
  an sd-card image.
 
 The netboot and hd-media versions contain different installer
 builds - the list of udebs in them and the order of the udebs
 being executed is different between the two (see
 http://d-i.alioth.debian.org/doc/internals/ch02.html).  The
 netboot image has to have network access to work, it loads all
 additional udebs it needs and all regular packages from the
 network.  The hd-media one is for installing from local media and
 can work completely offline.  This distinction is made on all
 platforms supported by d-i and unifying those two does not seem
 to work (sorry, I do not remember the details; IIRC it had
 something to do with different and conflicting anna
 implementations for the two variants).

Got it, thanks (I had a question in my reply to Vagrant, I won't repeat
it here).

For the tftpboot part, u-boot supports standard pxelinux.cfg
syntax configuration files -- would it be better to just
generate a suitable one of those?
   
   I have not in detail checked the pxelinux.cfg support in u-boot
   yet, but as we unfortunately have to build special-casing into the
   boot script for several platform (such as the i.MX6 console
   baudrate issue), I do not see how to implement that with the
   pxelinux.cfg syntax. Pointers welcome :).
  
  IMHO we should be moving towards using this way of doing things, which
  might mean fixing things like the i.MX6 issue at source. Too late for
  Jessie of course.
  
  BTW our kernel now supports the /chosen/stdout-path property in fdt and
  will automatically put a console on it.
 
 Just to make sure that I understand that correctly: with the
 u-boot and kernel versions currently in Jessie, there is no need
 to ever pass a console parameter to the kernel on any platform?
 Or is this something that was introduced after the u-boot v2014-10
 release in Jessie?

/chosen/stdout-path is more a function of the kernel and the dtb, I
don't think u-boot is involved much at all, at it need not be. I suppose
on platforms where there is a choice of consoles it might auto update
the stdout-path to reflect where u-boot is outputting it's stuff, but
you'll get some sort of sane default for the platform either way
(assuming the dtb is sane).

 If the former, using pxelinux.cfg should indeed work everywhere; if the
 latter, we would have to keep using boot.scr for Jessie.

I think it's the former.

   Inside the existing hd-media and netboot directories, a
   subdirectory SD-card-images gets created, which then contains
   the created images. These have the following sizes:
   
   option netboot full image:
   18568 A10-OLinuXino-Lime.img.gz
   18572 A20-OLinuXino-Lime.img.gz
   18572 BananaPi.img.gz
   18640 BeagleBoneBlack.img.gz
   18572 Cubieboard2.img.gz
   18568 Cubieboard.img.gz
   18572 Cubietruck.img.gz
   18564 MX53LOCO.img.gz
   18568 MX6_Cubox-i.img.gz
   18560 PandaBoard.img.gz
   18552 Wandboard_Quad.img.gz
   
  
  So around 200M in total? I haven't checked but I would imagine that was
  an order of magnitude more than d-i produces for any other arch in the
  d-i builds.
 
 As I wrote in my previous mail, we could squash that down to
 18M once + ~200kB per platform if we manage to unify the boot
 process

Re: Providing (armhf) u-boot images together with d-i images?

2015-01-07 Thread Ian Campbell
On Fri, 2015-01-02 at 22:13 +0100, Karsten Merker wrote:
 On Fri, Jan 02, 2015 at 02:51:18PM +0100, Karsten Merker wrote:
  On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote:
 
   BTW our kernel now supports the /chosen/stdout-path property in fdt and
   will automatically put a console on it.
  
  Just to make sure that I understand that correctly: with the
  u-boot and kernel versions currently in Jessie, there is no need
  to ever pass a console parameter to the kernel on any platform?
  Or is this something that was introduced after the u-boot v2014-10
  release in Jessie?
 
 Hello,
 
 I have in the meantime run some tests and this functionality does
 not seem to be available with the current versions in Jessie. If
 I do not explicitly set bootargs to include a console parameter,
 I get no console output, although u-boot has a valid ${console}.

The support is in linux 3.16.7-ckt2-1, which is in Jessie right now but
I don't know if it is in the kernel used by the current d-i, probably
not since that is in the process of being updated.

 Even if we cannot use that functionality at the moment, I am
 interested in how it works: does u-boot just copy the content of
 ${console} into the /chosen/stdout-path property, or is there
 some additional mechanism to hand over a baudrate for serial
 connections to the kernel?

I think it comes from the fdt, u-boot needn't be involved at all,
although it could be if the platform demanded it.

The stdout-path property is a device-tree path to the device to use, so
it is e.g. /smb/motherboard/iofpga@3,/uart@09 (or an
equivalent alias), it's not e.g. ttyS0 or ttyAMA0 etc.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420654688.11796.24.ca...@debian.org



Re: Providing (armhf) u-boot images together with d-i images?

2015-01-07 Thread Ian Campbell
On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
 Karsten Merker mer...@debian.org (2015-01-02):
   (Do your patches end up adding the correct Built-Using on u-boot?)
  
  No, they don't, but d-i does not do that for similar components
  on other platforms (syslinux/isolinux/grub) as well. Probably we
  should do that, but then it would have to be done for all
  platforms. Kibi?
 
 ISTR having proposed a patch to #700026 / #696418, but that wasn't
 commented upon.

FWIW the patch in #700026 looks good to me as a starting point...

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420655029.11796.25.ca...@debian.org



Re: Providing (armhf) u-boot images together with d-i images?

2015-01-07 Thread Ian Campbell
On Wed, 2015-01-07 at 10:41 -0800, Vagrant Cascadian wrote:
 On 2015-01-07, Ian Campbell wrote:
  And therefore aren't they more usefully built along with
  that iso? Otherwise how do you know how big to make the partition to
  contain the iso at d-i build time given the varied sizes of .iso and
  sd-card you can buy?
 
 It would also be nice to have media with the .iso file built-in, but I
 don't think a requirement for it to be useful without that.

Having a second external media isn't very common on the sorts of device
we are talking about, is it?

 I definitely see the case for moving some of the code into debian-cd, or
 another utility.
 
 I've considered making such a utility and shipping it in u-boot-tools,
 but didn't get around to it for jessie.  The sd-card offsets in this
 patchset duplicate information in the various u-boot* README.Debian
 files, and it would make sense to move that into a script. This script
 could also generate SD images with a vmlinuz, initrd, bootscript, dtb,
 .iso, etc. and would be useful outside the context of debian-installer.
 Then, if debian-installer, debian-cd, or some other utility wanted to
 use it, then they could depend on u-boot-tools...

That sounds pretty sensible.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420656404.11796.33.ca...@debian.org



Re: Providing (armhf) u-boot images together with d-i images?

2015-01-07 Thread Ian Campbell
On Fri, 2015-01-02 at 08:59 -0800, Vagrant Cascadian wrote:
 On 2015-01-02, Ian Campbell wrote:
  On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
  On 2014-12-30, Ian Campbell wrote:
  
  I think the difference is one is a set of netboot images, and the other
  is a set of hd-media images.
 
  But what is the difference between these two things in this context?
  Aren't they functionally identical from the users perspective?
 
 Differnt initrd with different modules, and defaults to loading a
 different set of udebs. The hd-media scans for .iso files, the netboot
 initrd requires to download remaining udebs using network...
 
 Technically, both images could be made to do either based on bootprompt
 options or something, but that probably would require rewriting a bit
 more of d-i.
[...]

 They're both typically used with sd-card, yes. But they differ in how
 they load the remaining portions of the installer, and have different
 modules and udebs in the initrds appropriate to the install
 media. Hopefully that's clear now? :)

Much, thanks.

But I still have a question about the hd-media sd-card images -- aren't
they only useful in concert with something which adds the .iso etc to
the image too? And therefore aren't they more usefully built along with
that iso? Otherwise how do you know how big to make the partition to
contain the iso at d-i build time given the varied sizes of .iso and
sd-card you can buy?

I think I'm probably just being dense here...

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420653663.11796.15.ca...@debian.org



Re: Providing (armhf) u-boot images together with d-i images?

2015-01-02 Thread Ian Campbell
On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
 On 2014-12-30, Ian Campbell wrote:

 
  0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
 ...
  It seems to be creating a copy of dtbs again, please lets try
  and keep it to one set of these files in the top level
  component.
 
 Well, all the dtb files need to be on the concatenateable images so that
 simply dd'ing the right u-boot files onto the card will be able to
 boot. If the image was only made for a specific system, then it would be
 possible to only include the relevent dtb files.

I thought these were being copied into the output dir, rather than (or
as well as) being encapsulated into the image, doing the latter is fine.
Sounds like I misread the patch and it is infact only doing the latter.
  
 
  0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch
 
  What is this providing? Is it a mini.iso like netboot sd image?
 
 I think it is basically like the mini.iso on i386/amd64, yes.
 
 
  I'm not sure how this is different from what the previous
  patches introduced.
 
 I think the difference is one is a set of netboot images, and the other
 is a set of hd-media images.

But what is the difference between these two things in this context?
Aren't they functionally identical from the users perspective?


  For the tftpboot part, u-boot supports standard pxelinux.cfg
  syntax configuration files -- would it be better to just
  generate a suitable one of those?
 
 Boot scripts allow the use of ${fdtfile}. As far as I understand, the
 pxelinux.cfg syntax unfortunately lacks the ability to use u-boot
 variables, and thus requires a different pxelinux.cfg for each system
 that uses a different .dtb. Which doesn't seem particularly useful for
 a single config for network booting...

pxelinux.cfg stanzas can include an fdtdir directory which is a path
which u-boot will search for ${fdtfile} under.

This isn't terribly well documented, but
http://patchwork.ozlabs.org/patch/423507/ improves things a lot.

Speaking of which, does the extlinux.conf stuff (which also supports
fdtdir) help with the multiple images problem at all?

extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
that it can offer multiple options (graphical vs text etc etc).

 I also think more systems support booting boot scripts than u-boot's
 PXE emulation at this point.

That's true.

Going forward we should try and make it our default option though I
think -- it was basically put together this way by the Fedora guys to
support exactly this sort of scenario.

 
  I suppose my main overall concern is that this seems to be providing the
  same thing 3 or 4 times and I'm not sure what the difference between
  each of those things is (or perhaps as likely I've misunderstood what is
  going on somewhere along the line). I was already concerned about the
  proliferation of images which taking this approach was implying in
  general and adding a multiplier to that just makes me more
  uncomfortable.
 
 If I'm reading it correctly(perhaps partly based on earlier descriptions
 of the goal), there are several images produced:
 
 1 u-boot only for each supported platform
 
 2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
   each platform
 
 3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
 
 4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
   each platform (like mini.iso)
 
 5 netboot concatenateable with kernel + initrd + dtbs + bootscript
 
 6 netboot boot script for use with TFTP

(I've switched your bullets to numbers for ease of reference).

Are 2+4 and 3+5 not essentially the same things with different names (on
x86 the distinction is iso image vs a f/s image, but on ARM both are
sd-card images).

 
 The netboot/hd-media without u-boot are meant to be concatenated
 together with the appropriate u-boot only images... so yes, there is
 significant overlap between the image types.
 
 The full images are obviously easier for the users to use, as it
 requires writing a single image, but obviously proliferate the number of
 images for each new supported platform.
 
 The concatenateable images obviously save a lot of space, at the expense
 of the user having to do additional steps and more complicated
 documentation (and might be difficult on non-unix-like platforms?).
 
 It probably doesn't make sense to ship both the concatenateable and full
 images.  I think Karsten wanted to enable both so that they could be
 tested in the daily images, and then later pick which would ship with
 Jessie?

I'm not so much worried about concatenatable vs non as netboot vs
hd-media, but perhaps I just haven't grokked the difference.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420194515.2030.47

Re: Providing (armhf) u-boot images together with d-i images?

2015-01-02 Thread Ian Campbell
On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
  0001-Add-boot-arm-u-boot-image-config.patch
  
  Seems fine.
  
  0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch
 
  I think this isn't actually publishing the u-boot binaries, but
  rather sd-card images with the u-boot inlined, is that right? Is
  there any use in shipping the raw binaries too?
 
 It provides both

Sorry, I must have misread.

  0003-Add-utils-gen-hd-image.patch
  
  I didn't review in detail, but perhaps the functionality of
  patch 0002 could be folded in? TBH I'm not sure what the
  distinction is between what 0002 does and what this script would
  produce (except I can see the script clearly has more
  functionality)
 
 It depends :-).
 
 gen-hd-image can provide different types of images - full images
 (SD card image including partition table, u-boot, kernel, initrd
 and dtbs) and concatenateable images, which is effectively a
 full image split up into a device-specific part (containing the
 partition table and u-boot) and a device-independent part
 (containing kernel, initrd and dtbs).
 
 If one decides to build concatenateable images, the
 device-specific part is mostly the same as the ready-to-copy SD
 card image generated by patch 2, with the difference that it
 contains a filled partition table with a predefined geometry and
 medium size.
 
 My original idea was to build u-boot-only images from patch 2 for
 people who want to install by TFTP or from USB-Stick using the
 existing hd-media tarball.  This was the first thing I
 implemented.  Vagrant proposed also building full images (u-boot,
 kernel, initrd and dtbs) similar to the images we build for
 i386/amd64, so I implemented that.  As full images need a bit of
 space, the idea of providing concatenateable images instead of
 full images came up, but doing that is dependent on solving the
 one boot script for all platforms issue, for which we do not
 yet have a proper solution, therefore I implemented that as an
 option for testing this approach.

Does using the extlinux.conf stuff (mentioned in my reply to Vagrant)
help here?

  0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
  
  I don't think we need all of (.gz|.bz2|.xz) (like the README
  suggests, although it's not clear these are all actually
  present). Just one would do IMHO.
 
 Only the gzipped variant is actually built, the README just
 covers the possible options (when calling gen-hd-image with
 -z/-j/-J).

This README is installed in the output directory, I think? IMHO it
should document only the compression type actually used in that
directory and we should provide at most one version of each file (either
compressed or not) using a single consistent compression algorithm for
all such files.

Talking about other compression schemes or providing multiple versions
of the same file will just confuse users. It looks like someone has
commented on the duplicated concat examples in v3 too.

  
  It seems to be creating a copy of dtbs again, please lets try
  and keep it to one set of these files in the top level
  component.
 
 The dtbs are only inside the generated images, they are not
 copied elsewhere as files.

My mistake, I thought they were ending up unpacked in the output too.

   Having all of them inside the image
 is a necessity if we want to have the option of using
 concatenateable builds as in this case they are in the
 device-independent part. The size of the dtbs inside the
 image is less than 900kB, so I do not think that is much of
 an issue size-wise.

Agreed.

 The previous patch produces hd-media builds for use with CD/DVD
 iso images (equivalent to the i386/amd64 hd-media
 boot.img.gz). This patch produces a netboot SD card (equivalent to
 the i386/amd64 netboot mini.iso), plus a netboot.tar.gz which
 contains everything needed to be put onto a tftp server for
 tftp-booting the installer (equivalent to the i386/amd64
 PXE netboot.tar.gz).

netboot.tar.gz sounds fine. What I don't get (see my reply to Vagrant)
is what the practical difference to the user is between the hd-media
builds and the netboot mini.iso ones, given that for ARM each is just
an sd-card image.

  For the tftpboot part, u-boot supports standard pxelinux.cfg
  syntax configuration files -- would it be better to just
  generate a suitable one of those?
 
 I have not in detail checked the pxelinux.cfg support in u-boot
 yet, but as we unfortunately have to build special-casing into the
 boot script for several platform (such as the i.MX6 console
 baudrate issue), I do not see how to implement that with the
 pxelinux.cfg syntax. Pointers welcome :).

IMHO we should be moving towards using this way of doing things, which
might mean fixing things like the i.MX6 issue at source. Too late for
Jessie of course.

BTW our kernel now supports the 

Re: Providing (armhf) u-boot images together with d-i images?

2014-12-30 Thread Ian Campbell
On Sat, 2014-12-27 at 00:00 +0100, Karsten Merker wrote:
 attached is V2 of the patchset. Changes since V1:

I should start by saying that I'm not personally particularly interested
in this functionality, but I don't want to be a blocker for people who
are so since I've been asked I'll give my 2pence...

I've been wondering if this image generation should be in debian
installer or if it should be a separate project (similar to how
debian-cd is separate). The advantage of doing it separately would be
that the images can be rev'd or expanded (e.g. to add a new platform)
independently from the installer releases, plus we don't need to worry
so much about exploding the size of the main installer releases as much.
Just an idle thought really.

Please could you post the diff in the lists of files generated by the
build, including the sizes of the new stuff.

FWIW review would be a lot easier if the patches were patchbombed to the
list in the normal git send-email way rather than as multiple
attachments on a single mail (people can kill-thread if they aren't
interested), but here we go:

0001-Add-boot-arm-u-boot-image-config.patch

Seems fine.

0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch

There would be a lot less shell-in-make quoting faff if there
was a helper under util/ with the bulk of the code in.

I think this isn't actually publishing the u-boot binaries, but
rather sd-card images with the u-boot inlined, is that right? Is
there any use in shipping the raw binaries too?

0003-Add-utils-gen-hd-image.patch

I didn't review in detail, but perhaps the functionality of
patch 0002 could be folded in? TBH I'm not sure what the
distinction is between what 0002 does and what this script would
produce (except I can see the script clearly has more
functionality)

0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch

I don't think we need all of (.gz|.bz2|.xz) (like the README
suggests, although it's not clear these are all actually
present). Just one would do IMHO.

It seems to be creating a copy of dtbs again, please lets try
and keep it to one set of these files in the top level
component.

The README should describe how to actually do the concatenation.

0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch

What is this providing? Is it a mini.iso like netboot sd image?
I'm not sure how this is different from what the previous
patches introduced.

For the tftpboot part, u-boot supports standard pxelinux.cfg
syntax configuration files -- would it be better to just
generate a suitable one of those?

0006-Add-additional-dependencies-needed-for-building-boot.patch

Seems ok. But by having this last at least half the previous
patches won't work in isolation. Better IMHO to add each
dependency as the dependency is introduced.

I suppose my main overall concern is that this seems to be providing the
same thing 3 or 4 times and I'm not sure what the difference between
each of those things is (or perhaps as likely I've misunderstood what is
going on somewhere along the line). I was already concerned about the
proliferation of images which taking this approach was implying in
general and adding a multiplier to that just makes me more
uncomfortable.

Perhaps a summary of the new toplevel output directories (i.e. things
added alongside netboot, hd-media, network-console etc) describing what
each one is would help?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1419953311.13595.190.ca...@debian.org



Re: Aw: Re: preseed with netboot ISO

2014-12-19 Thread Ian Campbell
On Fri, 2014-12-19 at 11:05 +0100, Lars-Daniel Weber wrote:
  Gesendet: Freitag, 19. Dezember 2014 um 10:23 Uhr
  Von: Philip Hands p...@hands.com
  An: Lars-Daniel Weber lars-daniel.we...@gmx.de, 
  debian-cd@lists.debian.org
  Betreff: Re: preseed with netboot ISO
 
 
  I guess you're doing this?
  
https://wiki.debian.org/DebianInstaller/Preseed/EditIso
 
 No, that way it works. I've just tried it out. If you bake the preseed into 
 the initrd, 
 anything works as expected.
 
 I've put the preseed.cfg to the root of the ISO and passed it by APPEND 
 settings to the kernel:
 neither file=/cdrom/preseed.cfg, nor file=/hd-media/preseed.cfg, nor 
 file=preseed.cfg works.
 
 Exactly the same style (using file=/cdrom/preseed.cfg) works for 
 net*installer*, but not
 for net*boot*.

AFIAIK the netboot mini.iso images are basically all the bits of PXE
boot, but in an ISO. As such there is nothing of interest (e.g. no
packages) on the ISO once the kernel + initrd are loaded and I wouldn't
necessarily expect it to bother trying to mount it in the installer
environment.

By contrast a netinst image includes the base system on the CD, so it
would be mounted.

 The funny thing: for self-built net*boot* images (about 10 MB), it works with 
 a seperated
 preseed.cfg outside initrd without a problem. But building the installer on 
 my own takes
 lots of dependencies... I wonder, what went wrong on the automatic build of 
 mini.iso :(

What do you mean by a outside the initrd? How are you self-building
these netboot images?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418995678.20028.39.ca...@hellion.org.uk



Re: Aw: Re: Re: preseed with netboot ISO

2014-12-19 Thread Ian Campbell
On Fri, 2014-12-19 at 14:49 +0100, Lars-Daniel Weber wrote:
  Gesendet: Freitag, 19. Dezember 2014 um 14:27 Uhr
  AFIAIK the netboot mini.iso images are basically all the bits of PXE
  boot, but in an ISO. As such there is nothing of interest (e.g. no
  packages) on the ISO once the kernel + initrd are loaded and I wouldn't
  necessarily expect it to bother trying to mount it in the installer
  environment.
 
 Trust me, it works great for doing quick installs in virtualbox etc.
 When baking the preseed in intrd, you can get a full install in about
 3 minutes. Okay, there are snapshots... but I like to have it quick and
 small.

Baking the preseed in the initrd is a different case to having an
preseed in the iso directly though, one working would imply very little
about the other.

TBH you are chopping and changing between so many different scenarios
that I'm not really sure what you are saying works and doesn't any more.

  What do you mean by a outside the initrd?
 
 outside means: preseed.cfg lies in root and LINUXISO has:
 APPEND file=/cdrom/preseed.cfg
 
 inside means: packed inside initrd.gz (like done ine Philip's turorial)
 
  How are you self-building these netboot images?
 
 I've simply downloaded the source of the debian-installer and rebuild it:
 git clone http://anonscm.debian.org/git/d-i/debian-installer.git --branch 
 wheezy --single-branch
 make build_netboot or make rebuild_netboot.
 
 These netboot-images work, but the official mini.iso doesn't.

For mini.iso you are using
http://ftp.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/mini.iso
 ? That's the Wheezy image, whereas if you build from git you are picking up 
the Sid/Jessie version of things, which corresponds to what is under 
http://d-i.debian.org/daily-images/.

Perhaps Wheezy didn't support what you are trying to do and Jessie does?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418997665.20028.43.ca...@hellion.org.uk



Re: Aw: Re: Re: Re: preseed with netboot ISO

2014-12-19 Thread Ian Campbell
On Fri, 2014-12-19 at 15:10 +0100, Lars-Daniel Weber wrote:
  Gesendet: Freitag, 19. Dezember 2014 um 15:01 Uhr
  Von: Ian Campbell i...@hellion.org.uk
 
  TBH you are chopping and changing between so many different scenarios
  that I'm not really sure what you are saying works and doesn't any more.
 
 Let me give a summary:
 [1] official netboot ISO ( 20 MB)
 a) preseed isn't detected when it's in the root of ISO and kernel parameters 
 are passed in ISOLINUX,
[...]
 [3] inofficial homebrewn netboot ISO
 a) preseed is detected when it's in the root of ISO and kernel parameters are 
 passed in ISOLINUX,
[...]
 git clone http://anonscm.debian.org/git/d-i/debian-installer.git --branch 
 wheezy --single-branch

In that case I can't explain the difference between the two, sorry,

Good luck.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418998393.20028.44.ca...@hellion.org.uk



Re: Aw: Re: Re: Re: Re: preseed with netboot ISO

2014-12-19 Thread Ian Campbell
On Fri, 2014-12-19 at 15:18 +0100, Lars-Daniel Weber wrote:
  Gesendet: Freitag, 19. Dezember 2014 um 15:13 Uhr
  Von: Ian Campbell i...@hellion.org.uk
  An: Lars-Daniel Weber lars-daniel.we...@gmx.de
 
  In that case I can't explain the difference between the two, sorry,
 
 Do you know the process, how mini.iso gets built on the server?

I've a vague idea for d-i.debian.org/daily-images/, which involves the
daily-build script in the repo, driven by
https://buildd.debian.org/git/di-autobuild.git/

But I'm not entirely sure for the official images, I'd have assumed that
they were the contents of debian-installer-images-VERSION_ARCH.tar.gz
which is produced when building the installer source as a package (e.g
with debuild or sbuild or whatever), iow they come from the buildds in
the normal way binaries do for any package, but I don't know that for
sure.

BTW, despite the name mini.iso is produced by the installer team
(debian-boot@) not the cd team.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418999821.12824.8.ca...@hellion.org.uk



Re: [PATCH 1/2] Force MKISOFO=xorriso for arm64 too

2014-10-05 Thread Ian Campbell
On Sat, 2014-10-04 at 10:48 +0100, Ian Campbell wrote:
 ---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/Makefile b/Makefile
 index 54393a7..5413e87 100755
 --- a/Makefile
 +++ b/Makefile
 @@ -21,7 +21,7 @@ ifndef TASK
  TASK=Debian-generic
  endif
  ifndef MKISOFS
 -ifneq (,$(filter i386 amd64,$(ARCHES)))
 +ifneq (,$(filter i386 arm64 amd64,$(ARCHES)))

This got pushed as i386 amd64 amd64 (i.e. amd64 twice...)

And the header now says Do install stuff for xarm64 (a vi error?)

This should fix them up:

From 450c1a7a96d65fdf2f8d6ea4c06f8092d4ea2efd Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@debian.org
Date: Sat, 4 Oct 2014 10:46:12 +0100
Subject: [PATCH] Fix a couple of typos.

Listing amd64 twice in the xorriso selection rune in Makefile, one should be
arm64.

s/xarm64/arm64/
---
 Makefile | 2 +-
 tools/boot/jessie/boot-arm64 | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index b0b1dad..5413e87 100755
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,7 @@ ifndef TASK
 TASK=Debian-generic
 endif
 ifndef MKISOFS
-ifneq (,$(filter i386 amd64 amd64,$(ARCHES)))
+ifneq (,$(filter i386 arm64 amd64,$(ARCHES)))
 export MKISOFS=xorriso
 export MKISOFS_OPTS=-as mkisofs -r -checksum_algorithm_iso md5,sha1
 else
diff --git a/tools/boot/jessie/boot-arm64 b/tools/boot/jessie/boot-arm64
index d3cbc4e..052e15c 100755
--- a/tools/boot/jessie/boot-arm64
+++ b/tools/boot/jessie/boot-arm64
@@ -1,8 +1,8 @@
 #!/bin/bash
 
-# Based on boot-x86
+# Based on boot-x86.
 #
-# Do install stuff for xarm64, including making bootable CDs
+# Do install stuff for arm64, including making bootable CDs
 # Works with debian-installer
 #
 # $1 is the CD number
-- 
2.1.0




-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1412494428.12707.8.ca...@debian.org



[PATCH 1/2] Force MKISOFO=xorriso for arm64 too

2014-10-04 Thread Ian Campbell
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 54393a7..5413e87 100755
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,7 @@ ifndef TASK
 TASK=Debian-generic
 endif
 ifndef MKISOFS
-ifneq (,$(filter i386 amd64,$(ARCHES)))
+ifneq (,$(filter i386 arm64 amd64,$(ARCHES)))
 export MKISOFS=xorriso
 export MKISOFS_OPTS=-as mkisofs -r -checksum_algorithm_iso md5,sha1
 else
-- 
2.1.0


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412416138-17077-1-git-send-email-...@debian.org



[PATCH 2/2] Do not truncate grub.cfg on arm64

2014-10-04 Thread Ian Campbell
The d-i supplied grub.cfg has the correct entries in it already.
---
 tools/boot/jessie/boot-arm64 | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/tools/boot/jessie/boot-arm64 b/tools/boot/jessie/boot-arm64
index 43f290c..3021467 100755
--- a/tools/boot/jessie/boot-arm64
+++ b/tools/boot/jessie/boot-arm64
@@ -89,13 +89,6 @@ if [ -d boot$N/grub ] ; then
 mv boot$N/grub/* $CDDIR/boot/grub/
 rmdir boot$N/grub
 
-# TODO: setup grub.cfg
-# Create grub menu entries to match the isolinux ones
-sed -i '/^menuentry/Q' $CDDIR/boot/grub/grub.cfg;
-#$BASEDIR/tools/boot/$DI_CODENAME/parse_isolinux \
-#boot$N/isolinux $CDDIR $BASEDIR/data/$DI_CODENAME/grub-theme.in 
$DISKINFO_DISTRO $DEBIAN_KERNEL $DEBVERSION \
-# $CDDIR/boot/grub/grub.cfg
-
 # Stuff the EFI boot files into a FAT filesystem, making it as
 # small as possible.  24KiB headroom seems to be enough;
 # (x+31)/32*32 rounds up to multiple of 32.
-- 
2.1.0


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412416138-17077-2-git-send-email-...@debian.org



[PATCH] Update header comments in boot-arm64

2014-10-04 Thread Ian Campbell
---
 tools/boot/jessie/boot-arm64 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/boot/jessie/boot-arm64 b/tools/boot/jessie/boot-arm64
index 3021467..e67773b 100755
--- a/tools/boot/jessie/boot-arm64
+++ b/tools/boot/jessie/boot-arm64
@@ -1,8 +1,8 @@
 #!/bin/bash
 
-# This script gets sourced from boot-i386 and boot-amd64.
+# Based on boot-x86.
 #
-# Do install stuff for x86, including making bootable CDs
+# Do install stuff for arm64, including making bootable CDs
 # Works with debian-installer
 #
 # $1 is the CD number
-- 
2.1.0


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412416320-17332-1-git-send-email-...@debian.org



Re: Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode

2014-09-28 Thread Ian Campbell
On Sun, 2014-09-28 at 10:26 +0100, Steve McIntyre wrote:
 On Sun, Sep 28, 2014 at 08:48:11AM +0200, Wouter Verhelst wrote:
 On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote:
   If the user wants to continue, we could even suggest blanking the
   partition table(s) and starting again with GPT, but I don't think
   we currently have a blank partition table option exposed within
   d-i?
  
  What do people think of this plan? What have I missed?
 
 Isn't it better to run this test in partman-efi's isinstallable script?
 Then if things are set up in the described way, grub-efi just won't be
 installed, but the normal grub will, and the system will continue to
 boot in BIOS fallback as before.
 
 That was my initial thought, but then someone pointed out: what
 happens to a user who explicitly *wants* to replace their existing
 legacy system with a new UEFI one?

Is isinstallable allowed to ask debconf question?

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411903149.23482.13.ca...@hellion.org.uk



Re: Time for Jessie Beta 2?

2014-09-28 Thread Ian Campbell
On Fri, 2014-09-26 at 21:05 +0200, Cyril Brulebois wrote:
 Cyril Brulebois k...@debian.org (2014-09-10):
  as you might have seen, a number of uploads happened lately and the d-i
  BoF notes from DebConf kindly provided by Steve (thanks!) reminded me
  about uploading d-i more often. So I think I'll try and achieve that as
  soon as linux 3.16 reaches testing (it was just uploaded to unstable,
  and FTBFSes on several architectures, so not this week ;)).
 
 linux/linux-latest are now ready, baring nvidida (#762977).
 
  Some things got set into motion, like syslinux menu overhaul (mainly
  discussion around the switch to graphical by default, didn't see any
  patch yet) or tasksel changes (alternative desktops, blends support).
  I'm unsure they're going to be ready at that point, so I guess it would
  make sense not to wait for them and publish another release in the
  meanwhile. I'll probably gather opinions when linux is ready, this mail
  is mainly meant to be a heads-up.
 
 I'll probably skip syslinux vs. multi-arch this time, mostly due to lack
 of time and other large ongoing changes: let's see if we can get
 debian-cd to cope with latest tasksel changes soon.

Should we do anything about #762007 (user-params breakage due to kernel
changes) or can it wait?

WRT #762618 (empty grub.cfg in x86 mini.iso, used on EFI systems only) I
didn't push that patch because of the pending beta (and it touches x86
which I didn't want to mess with unannounced).

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411905547.23482.19.ca...@hellion.org.uk



Re: Time for Jessie Beta 2?

2014-09-28 Thread Ian Campbell
On Sun, 2014-09-28 at 15:47 +0200, Cyril Brulebois wrote:
 Ian Campbell i...@hellion.org.uk (2014-09-28):
  Should we do anything about #762007 (user-params breakage due to
  kernel changes) or can it wait?
 
 I might be mistaken but I think it can wait a bit until we agree on a
 solution and have some time to get it tested.

Ack.

  WRT #762618 (empty grub.cfg in x86 mini.iso, used on EFI systems only)
  I didn't push that patch because of the pending beta (and it touches
  x86 which I didn't want to mess with unannounced).
 
 Same story. Filed as a normal bug so I'm tempted to let it wait until
 after Beta 2.

Filed as normal because I didn't know if it was minor or important (or
worse) ;-) I suspect it's more on the minor end of things, so Ack.

Ian.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411923267.17796.9.ca...@hellion.org.uk



Re: Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode

2014-09-28 Thread Ian Campbell
On Sun, 2014-09-28 at 18:54 +0200, Wouter Verhelst wrote:
 On Sun, Sep 28, 2014 at 10:26:20AM +0100, Steve McIntyre wrote:
  On Sun, Sep 28, 2014 at 08:48:11AM +0200, Wouter Verhelst wrote:
  On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote:
If the user wants to continue, we could even suggest blanking the
partition table(s) and starting again with GPT, but I don't think
we currently have a blank partition table option exposed within
d-i?
   
   What do people think of this plan? What have I missed?
  
  Isn't it better to run this test in partman-efi's isinstallable script?
  Then if things are set up in the described way, grub-efi just won't be
  installed, but the normal grub will, and the system will continue to
  boot in BIOS fallback as before.
  
  That was my initial thought, but then someone pointed out: what
  happens to a user who explicitly *wants* to replace their existing
  legacy system with a new UEFI one?
 
 If that is a warning (as opposed to error) message saying something
 along the lines of note that with this setup you won't be able to boot
 your current system anymore, then that isn't an actual problem. A user
 who is planning to replace a system shouldn't be worried about the
 installer warning them that they can't boot the (to be replaced) old
 system anymore, and can safely ignore that message.

I was thinking more along the lines of a yes/no question which would
either cause partman-efi.isinstallable to fail or not. Allowing
selection between the wants to convert to EFI and wants to stick with
regular grub not grub-efi cases.

Ian.
 
 -- 
 It is easy to love a country that is famous for chocolate and beer
 
   -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
 
 



-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411923732.17796.11.ca...@hellion.org.uk



Re: Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode

2014-09-28 Thread Ian Campbell
On Sun, 2014-09-28 at 18:14 +0100, Steve McIntyre wrote:
 On Sun, Sep 28, 2014 at 06:02:12PM +0100, Ian Campbell wrote:
 I was thinking more along the lines of a yes/no question which would
 either cause partman-efi.isinstallable to fail or not. Allowing
 selection between the wants to convert to EFI and wants to stick with
 regular grub not grub-efi cases.
 
 That sounds better to me too, assuming we can sensibly do a question
 at that point. Is that allowed? I honestly don't know... :-/

It just occurred to me to look, and it seems that a handful of them do
to some extent, e.g. grub-installer's isinstallable does db_get
grub-installer/skip.  On the other hand I don't see any uses of
db_go/db_input so it may only be usable for preseeded answers.

an


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411928345.17796.13.ca...@hellion.org.uk



Re: Report from the first tests of d-i beta 1 candidate images

2012-07-17 Thread Ian Campbell
On Tue, 2012-07-17 at 14:45 +0200, Cyril Brulebois wrote:
 Cyril Brulebois k...@debian.org (17/07/2012):
  some time to try kde/xfce/lxde/server installations, and possibly report
  some more bugs. Given the images are going to be re-built at some point,
  I think the pointer to the (known broken) images will be kept somewhere
  in #debian-boot's topic, to avoid confusion with later builds.
 
 Thankfully cdimage has a HEADER.html mechanism, so I've added a warning
 there, here's the URL:
   http://cdimage.debian.org/cdimage/.wheezy_di_beta1_build1/

Installing from debian-wheezy-DI-b1-amd64-i386-netinst.iso in a Xen
guest I get:
  ┌─┌┤ [!!] Configure the package manager ├┐┐
  │ │  │
  │ │  apt configuration problem   │
  │ │ An attempt to configure apt to install additional packages from the  │
  │ │ CD failed.   │
  │ │  │
  │ │ Go Back Continue │
  │ │  │
  └─└──┘

Looking in /var/log/syslog I see:
Jul 17 15:46:42 apt-setup: 'Debian GNU/Linux wheezy-DI-b1 _Wheezy_ - Official 
Snapshot Multi-architecture amd64/i386 NETINST #1 20120715-10:55'
Jul 17 15:46:42 apt-setup: Copying package lists...
Jul 17 15:46:42 apt-setup: ^MReading Package Indexes... 0%  ^M
Jul 17 15:46:42 apt-setup: ^MReading Package Indexes... Done^M
Jul 17 15:46:42 apt-setup: 
Jul 17 15:46:42 apt-setup: ^MReading Translation Indexes... 0%^M
Jul 17 15:46:42 apt-setup: ^MReading Translation Indexes... Done^M
Jul 17 15:46:42 apt-setup: 
Jul 17 15:46:42 apt-setup: E
Jul 17 15:46:42 apt-setup: : 
Jul 17 15:46:42 apt-setup: Failed to link /var/lib/apt/cdroms.list to 
/var/lib/apt/cdroms.list~ - link (17: File exists)
Jul 17 15:46:42 apt-setup: 
Jul 17 15:48:58 apt-setup: /usr/lib/apt-setup/generators/40cdrom backed up

/var/lib/apt doesn't seem to exist in the installer environment.
But /target/var/lib/apt does so I guess this refers to that:
~ # ls /target/var/lib/apt -l
-rw-r--r--1 root root   321 Jul 17 15:46 cdroms.list
-rw-r--r--1 root root   321 Jul 17 15:53 cdroms.list.new
-rw-r--r--1 root root   321 Jul 17 15:45 cdroms.list~
-rw-r--r--1 root root   658 Jul 17 15:46 extended_states
drwxr-xr-x3 root root 16384 Jul 17 15:53 lists
drwxr-xr-x3 root root  4096 Jul 17 15:43 mirrors
drwxr-xr-x2 root root  4096 Jun 29 14:00 periodic

This doesn't seem to be anything Xen specific here.

Ian.
-- 
Ian Campbell
Current Noise: Wolves In The Throne Room - Thuja Magus Imperium

It is not best to swap horses while crossing the river.
-- Abraham Lincoln


--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342540582.16704.9.ca...@zakaz.uk.xensource.com



Re: [PATCH] support Xen installation from Blu-Ray

2012-04-26 Thread Ian Campbell
On Wed, 2012-04-25 at 20:15 +0100, Steve McIntyre wrote:
 On Mon, Apr 23, 2012 at 10:21:09AM +0100, Ian Campbell wrote:
 I can't think of any reason not to do this, I assume there is tons of
 room.
 
 I confess I haven't tested the patch since my mirror is woefully out of
 date, I'm not even 100% sure this is the right place to put it, but it
 seems correct by inspection of the CD/DVD cases.
 
 No problem, applied now.

Cool, thanks!

 Should we also do the same for the normal DVDs? At the moment it's
 just set for the multi-arch DVD.

That would be great, if there is space and/or it won't knock something
important off DVD1. IIRC the original concern which lead to Xen only
being on multi-arch images was about blowing up the netinst CD where the
fractional increase was a more significant %age, I think the same
concern doesn't really extend to the DVD images though?

On i386 I think we now include the pae kernel packages on the DVD1 by
default anyway (for native usage) so the increase would be only +~20M
for the PAE installer kernel and initrd to support Xen

On amd64 there is no real size increase, since Xen uses the regular
kernel and the cdrom/xen installer is actually just a symlink (for
consistency with 32 bit). It's ~12K, which, I suspect, is mostly
rounding slop in the ISO format.

Ian.
-- 
Ian Campbell


In matters of principle, stand like a rock; in matters of taste, swim with
the current.
-- Thomas Jefferson


signature.asc
Description: This is a digitally signed message part


[PATCH] support Xen installation from Blu-Ray

2012-04-23 Thread Ian Campbell
I can't think of any reason not to do this, I assume there is tons of
room.

I confess I haven't tested the patch since my mirror is woefully out of
date, I'm not even 100% sure this is the right place to put it, but it
seems correct by inspection of the CD/DVD cases.

I'm updating my mirror now, so I ought to be able to test in a week or
so.

Thanks,
Ian

diff --git a/cronjob.weekly b/cronjob.weekly
index c9170a0..5d0d400 100755
--- a/cronjob.weekly
+++ b/cronjob.weekly
@@ -116,6 +116,7 @@ if lockfile -r0 $TOPDIR/.debian-cd.lock ; then
build_started BD
 INSTALLER_CD=9 TASK=Debian-all \
 KERNEL_PARAMS='desktop=all' \
+VARIANTS=xen \
 ./testingcds $arch 
 ;;
 *)
-- 
1.7.8.3


-- 
Ian Campbell
Current Noise: Crippled Black Phoenix - Faced With Complete Failure, Utter 
Defiance Is The Only Response

My uncle was the town drunk -- and we lived in Chicago.
-- George Gobel


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1335172869.30700.18.ca...@zakaz.uk.xensource.com



Re: Renaming xm-debian.cfg to just debian.cfg

2011-08-19 Thread Ian Campbell
On Thu, 2011-08-18 at 21:19 +0100, Steve McIntyre wrote:
 On Tue, Aug 16, 2011 at 12:55:10PM +0100, Ian Campbell wrote:
 diff --git a/tools/boot/wheezy/boot-x86 b/tools/boot/wheezy/boot-x86
 index 1b23b1b..2cc090b 100644
 --- a/tools/boot/wheezy/boot-x86
 +++ b/tools/boot/wheezy/boot-x86
 @@ -257,7 +257,7 @@ rm -f boot$N/isolinux/isolinux.cfg.with*
  if variant_enabled xen ; then
  extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
  extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
 -extra_image xen/debian.cfg
 +extra_image xen/debian.cfg || extra_image xen/xm-debian.cfg
  fi
  
  # Modify win32-loader.ini for the current arch
 
 I'm trying that now as a fallback, the images have been failing to build.

I was doing the same and it seemed to work.

Thanks,
Ian.

-- 
Ian Campbell
Current Noise: Kylesa - Don't Look Back

Arithmetic:
An obscure art no longer practiced in the world's developed countries.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1313739866.5010.324.ca...@zakaz.uk.xensource.com



Re: Renaming xm-debian.cfg to just debian.cfg

2011-08-16 Thread Ian Campbell
On Tue, 2011-08-16 at 11:55 +0100, Steve McIntyre wrote:
 On Mon, Aug 15, 2011 at 09:26:46PM +0100, Ian Campbell wrote:
 Hi,
 
 I'd quite like to rename the xm-debian.cfg shipped by d-i to just
 debian.cfg. The xm came from the previous Xen toolstack's (xend) cli
 name, the modern one is called xl. (it all seems a bit like pedantry,
 but, you know...)
 
 It's slightly tricky due to the need to change both d-i and the
 debian-cd stuff. IIRC the daily/weekly CD builds are made using the
 daily installer builds and therefore all that is needed is to check the
 two changes in at (roughly) the same time.
 
 Or do I need to worry about non-daily/weekly builds too? I suppose that
 if an alpha/beta release is made there will necessarily be a d-i upload
 first (with this change)?
 
 Patches to both are attached, I can checkin the d-i one myself if
 debian-cd are happy with the approach.
 
 Hmmm. It'll break the daily wheezy CD images that use the last
 testing release instead of the dailt d-i builds. But at the moment I
 think they're broken already... :-(

Hopefully they fail in the omit that one file way rather than
completely. I suppose we could go with an interim solution (untested,
debmirror is playing up so I don't have a proper mirror at the
moment :-( ):

diff --git a/tools/boot/wheezy/boot-x86 b/tools/boot/wheezy/boot-x86
index 1b23b1b..2cc090b 100644
--- a/tools/boot/wheezy/boot-x86
+++ b/tools/boot/wheezy/boot-x86
@@ -257,7 +257,7 @@ rm -f boot$N/isolinux/isolinux.cfg.with*
 if variant_enabled xen ; then
extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
-   extra_image xen/debian.cfg
+   extra_image xen/debian.cfg || extra_image xen/xm-debian.cfg
 fi
 
 # Modify win32-loader.ini for the current arch

 Go ahead, I'll commit the change now.

Thanks, I've pushed the d-i change too.

Ian.

-- 
Ian Campbell
Current Noise: Amon Amarth - The Last Stand Of Frej

I'm rated PG-34!!


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1313495710.5010.75.ca...@zakaz.uk.xensource.com



Renaming xm-debian.cfg to just debian.cfg

2011-08-15 Thread Ian Campbell
Hi,

I'd quite like to rename the xm-debian.cfg shipped by d-i to just
debian.cfg. The xm came from the previous Xen toolstack's (xend) cli
name, the modern one is called xl. (it all seems a bit like pedantry,
but, you know...)

It's slightly tricky due to the need to change both d-i and the
debian-cd stuff. IIRC the daily/weekly CD builds are made using the
daily installer builds and therefore all that is needed is to check the
two changes in at (roughly) the same time.

Or do I need to worry about non-daily/weekly builds too? I suppose that
if an alpha/beta release is made there will necessarily be a d-i upload
first (with this change)?

Patches to both are attached, I can checkin the d-i one myself if
debian-cd are happy with the approach.

Ian.
-- 
Ian Campbell


It's ten o'clock... Do you know where your AI programs are?  -- Peter Oakley

From 0a221313303a0037078d72b6306dc256babe7098 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Mon, 15 Aug 2011 08:31:17 +0100
Subject: [PATCH] xm-debian.cfg is now debian.cfg

---
 tools/boot/squeeze/boot-x86 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index b772027..4c34919 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -253,7 +253,7 @@ rm -f boot$N/isolinux/isolinux.cfg.with*
 if variant_enabled xen ; then
 	extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
 	extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
-	extra_image xen/xm-debian.cfg
+	extra_image xen/debian.cfg
 fi
 
 # Modify win32-loader.ini for the current arch
-- 
1.7.5.4

From 70329aad5f27ae32aa147b3ddc68ea478716e99d Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Thu, 28 Jul 2011 18:16:37 +0100
Subject: [PATCH] xen: Rename xm-debian.cfg to just debian.cfg

xm is a reference to the xend based toolstack but this file also works with
the new xl toolstack.
---
 build/boot/x86/xen/{xm-debian.cfg = debian.cfg} |0
 build/config/x86.cfg |4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename build/boot/x86/xen/{xm-debian.cfg = debian.cfg} (100%)

diff --git a/build/boot/x86/xen/xm-debian.cfg b/build/boot/x86/xen/debian.cfg
similarity index 100%
rename from build/boot/x86/xen/xm-debian.cfg
rename to build/boot/x86/xen/debian.cfg
diff --git a/build/config/x86.cfg b/build/config/x86.cfg
index 39b4a1c..a593185 100644
--- a/build/config/x86.cfg
+++ b/build/config/x86.cfg
@@ -17,7 +17,7 @@ SPLASH_PNG=boot/common/pics/spacefun-isolinux.png
 BOOT_SCREEN_DIR = 
 
 # Location for Xen example configuration.
-XENCFG = $(SOME_DEST)/$(EXTRANAME)xm-debian.cfg
+XENCFG = $(SOME_DEST)/$(EXTRANAME)debian.cfg
 
 # Create syslinux config.
 .PHONY: x86_syslinux
@@ -342,7 +342,7 @@ xen_config:
 	sed -e s/@ARCH@/$(ARCH)/g \
 	-e s/@XEN_INSTALL_METHOD@/$(XEN_INSTALL_METHOD)/g \
 	-e s/@DEBIAN_RELEASE@/$(DEBIAN_RELEASE)/g \
-	boot/x86/xen/xm-debian.cfg $(XENCFG)
+	boot/x86/xen/debian.cfg $(XENCFG)
 	chmod 644 $(XENCFG)
 	update-manifest $(XENCFG) $(MANIFEST-XENCFG)
 
-- 
1.7.5.4



signature.asc
Description: This is a digitally signed message part


[PATCH] s/686-bigmem/686-pae in wheezy exclude-udebs

2011-07-28 Thread Ian Campbell
This appears to have been missed in r2264.
---
 data/wheezy/exclude-udebs-i386 |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/data/wheezy/exclude-udebs-i386 b/data/wheezy/exclude-udebs-i386
index 893aa34..8602305 100644
--- a/data/wheezy/exclude-udebs-i386
+++ b/data/wheezy/exclude-udebs-i386
@@ -27,8 +27,8 @@ speakup-modules-*
 usb-modules-*
 usb-serial-modules-*
 usb-storage-modules-*
-# 686-bigmem kernel udebs are only used for the Xen netboot image
-*-686-bigmem-di !xen
+# 686-pae kernel udebs are only used for the Xen netboot image
+*-686-pae !xen
 # Not used on i386
 console-keymaps-acorn
 console-keymaps-amiga
-- 
1.7.5.4


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1311844790-11707-1-git-send-email-...@hellion.org.uk



Bug#622622: Priority of i386 kernel flavours

2011-05-02 Thread Ian Campbell
On Sat, 2011-04-30 at 23:22 +0100, Steve McIntyre wrote:
 On Wed, Apr 13, 2011 at 02:12:27PM +0100, Ben Hutchings wrote:
 Package: debian-cd
 
 (Not sure which version is actually used for squeeze.)
 
 On i386 machines with RAM above the 4GB physical address, either PAE or
 LM (Long Mode, 64-bit) must be used to access that RAM.  The preferred
 kernel flavour is '686-bigmem', with 'amd64' also being an option.
 
 However the amd64 flavour is on DVD 1 but the 686-bigmem flavour is on
 DVD 2.  This means a single-DVD install with no network access will get
 the amd64 flavour if the system supports LM and the 686 flavour if it
 does not.  The former is somewhat undesirable as third-party installers
 (and users) can get confused by a 64-bit kernel with 32-bit userland.
 The latter is extremely undesirable as some RAM is then inaccessible.
 
 Similarly the amd64 flavour is currently on CD 5 but the 686-bigmem
 flavour is on CD 10.  The 686-bigmem flavour should be increased in
 priority, certainly above the amd64 flavour, and should ideally be on CD
 1 or 2 (but I realise that there is tough competition for CD 1).
 
 I've added linux-image-686-bigmem to
 tasks/squeeze/interesting-fromcd23, which means that the -bigmem
 kernels will get pulled in before packages from popcon. A test build
 looks good, and I've back-ported the fix back to the squeeze branch of
 debian-cd so that 6.0.2 should be correct.

Doest this have an impact (i.e. perhaps make it obsolete) the
VARIANT_xen stuff e.g. in tools/generate_di+k_list? I suppose the
variant stuff is orthogonal to this issue, even if the net result is the
same and so it's worth having both by way of explicitly asking for what
is required in both cases.

Ian.

-- 
Ian Campbell

I am currently transitioning to a new OpenPGP key, please see:
http://www.hellion.org.uk/key-transition-2011-04-27-2F6BCD59-to-79074FA8.txt

If you have to think twice about it, you're wrong.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH/RFC] Enable Xen PVHVM installation from ISO

2011-03-07 Thread Ian Campbell
Does anybody have any comments on this RFC?

On Sun, 2011-02-20 at 22:12 +, Ian Campbell wrote:
 Hi,
 
 In the Squeeze release we added support for Xen PV installation from
 certain ISO images which have the Xen variant enabled in Debian CD (the
 multiarch x86 ISOs) which includes a suitable installer image as well as
 the kernel binaries (686-bigmem flavour on i386).
 
 Since then the kernel has grown additional functionality which allows
 the PV drivers to be used for disk and network in an HVM (fully
 virtualised) guest, in Xen-land we call this PVHVM.
 
 For various reasons this PVHVM support is contingent on Xen PV support
 also being enabled in the kernel and hence it is limited to the
 686-bigmem flavour on i386 as well. Long term we hope to address this
 but I don't think it will happen too soon...
 
 The following patches to d-i and debian-cd add a menu item to the
 isolinux menu for images with the Xen variant enabled e.g. it simply
 creates an entry for images when the appropriate installer + kernel is
 already present anyway.
 
 I think manually duplicating the entire non-Xen menu hierarchy by hand
 would be a terrible idea, and although I think I could probably make
 something work automatically by processing the existing cfg files (e.g.
 with sed or something) I suspect the result would be rather fragile, so
 I've just implemented the basic install menu item for 32 and 64 bit.
 Anyone got any cunning ideas on how to do this better?
 
 Any opinions on where to put the Xen toplevel menu etc? I put it in the
 first screen but I could see an argument for putting it under advanced
 for example.
 
 Ian.
 
 PS: Is there some trick to quickly testing the isolinux menus? I've been
 doing:
 #!/bin/sh
 
 set -ex
 
 export PATH=util:${PATH}:/usr/sbin:/sbin
 
 rm -rf tmp/cdrom_isolinux/cd_info tmp/cdrom_gtk/cd_info
 make SUBARCH= MEDIUM=cdrom FLAVOUR=isolinux 
 dest/cdrom/debian-cd_info.tar.gz
 
 ARCH=`dpkg --print-architecture`
 
 cp -v dest/cdrom/debian-cd_info.tar.gz 
 ~/development/debian/debian-installer/dest/${ARCH}/cdrom/debian-cd_info.tar.gz
 for both amd64 and i386 and then rebuilding a BC image against that
 installer, which takes several minutes and is a bit fiddly.
 

-- 
Ian Campbell
Current Noise: Lair Of The Minotaur - Blood From The WItch's Vein

Killing is stupid; useless!
-- McCoy, A Private Little War, stardate 4211.8


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1299495316.17339.141.ca...@zakaz.uk.xensource.com



[PATCH/RFC] Enable Xen PVHVM installation from ISO

2011-02-20 Thread Ian Campbell
Hi,

In the Squeeze release we added support for Xen PV installation from
certain ISO images which have the Xen variant enabled in Debian CD (the
multiarch x86 ISOs) which includes a suitable installer image as well as
the kernel binaries (686-bigmem flavour on i386).

Since then the kernel has grown additional functionality which allows
the PV drivers to be used for disk and network in an HVM (fully
virtualised) guest, in Xen-land we call this PVHVM.

For various reasons this PVHVM support is contingent on Xen PV support
also being enabled in the kernel and hence it is limited to the
686-bigmem flavour on i386 as well. Long term we hope to address this
but I don't think it will happen too soon...

The following patches to d-i and debian-cd add a menu item to the
isolinux menu for images with the Xen variant enabled e.g. it simply
creates an entry for images when the appropriate installer + kernel is
already present anyway.

I think manually duplicating the entire non-Xen menu hierarchy by hand
would be a terrible idea, and although I think I could probably make
something work automatically by processing the existing cfg files (e.g.
with sed or something) I suspect the result would be rather fragile, so
I've just implemented the basic install menu item for 32 and 64 bit.
Anyone got any cunning ideas on how to do this better?

Any opinions on where to put the Xen toplevel menu etc? I put it in the
first screen but I could see an argument for putting it under advanced
for example.

Ian.

PS: Is there some trick to quickly testing the isolinux menus? I've been
doing:
#!/bin/sh

set -ex

export PATH=util:${PATH}:/usr/sbin:/sbin

rm -rf tmp/cdrom_isolinux/cd_info tmp/cdrom_gtk/cd_info
make SUBARCH= MEDIUM=cdrom FLAVOUR=isolinux 
dest/cdrom/debian-cd_info.tar.gz

ARCH=`dpkg --print-architecture`

cp -v dest/cdrom/debian-cd_info.tar.gz 
~/development/debian/debian-installer/dest/${ARCH}/cdrom/debian-cd_info.tar.gz
for both amd64 and i386 and then rebuilding a BC image against that
installer, which takes several minutes and is a bit fiddly.

-- 
Ian Campbell

Immature artists imitate, mature artists steal.
-- Lionel Trilling
diff --git a/tools/boot/wheezy/boot-x86 b/tools/boot/wheezy/boot-x86
index a7ea2c2..547ad97 100644
--- a/tools/boot/wheezy/boot-x86
+++ b/tools/boot/wheezy/boot-x86
@@ -252,6 +252,9 @@ if variant_enabled xen ; then
 	extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
 	extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
 	extra_image xen/xm-debian.cfg
+else
+	# Remove Xen configuration is Xen is not enabled
+	rm -f boot$N/isolinux/*xen.cfg
 fi
 
 # Modify win32-loader.ini for the current arch
diff --git a/build/boot/x86/amdtxt.cfg b/build/boot/x86/amdtxt.cfg
index e347679..afd9e48 100644
--- a/build/boot/x86/amdtxt.cfg
+++ b/build/boot/x86/amdtxt.cfg
@@ -1,6 +1,4 @@
-default64 amd64-install
 label amd64-install
 	menu label ^64 bit install
-	menu default64
 	kernel ${AMD_KERNEL}
 	append desktop=%desktop% ${VIDEO_MODE} initrd=${AMD_INITRD} -- quiet ${CONSOLE}
diff --git a/build/boot/x86/amdtxtxen.cfg b/build/boot/x86/amdtxtxen.cfg
new file mode 100644
index 000..25a091f
--- /dev/null
+++ b/build/boot/x86/amdtxtxen.cfg
@@ -0,0 +1,4 @@
+label amd64-install-xen
+	menu label ^64 bit Xen PVHVM install
+	kernel ${AMD_KERNEL_XEN}
+	append desktop=%desktop% ${VIDEO_MODE} initrd=${AMD_INITRD_XEN} -- quiet ${CONSOLE}
diff --git a/build/boot/x86/menu.cfg b/build/boot/x86/menu.cfg
index f1be77f..e030043 100644
--- a/build/boot/x86/menu.cfg
+++ b/build/boot/x86/menu.cfg
@@ -7,6 +7,7 @@ include ${SYSDIR}txt.cfg
 include ${SYSDIR}amdtxt.cfg
 include ${SYSDIR}gtk.cfg
 include ${SYSDIR}amdgtk.cfg
+include ${SYSDIR}menuxen.cfg
 menu begin advanced
 	menu title Advanced options
 	include ${SYSDIR}stdmenu.cfg
diff --git a/build/boot/x86/menuxen.cfg b/build/boot/x86/menuxen.cfg
new file mode 100644
index 000..6ab4000
--- /dev/null
+++ b/build/boot/x86/menuxen.cfg
@@ -0,0 +1,10 @@
+menu begin xen
+	menu title Xen PVHVM options
+	include ${SYSDIR}stdmenu.cfg
+	label mainmenu
+		menu label ^Back..
+		menu exit
+	include ${SYSDIR}txtxen.cfg
+	# Truncated due to 8.3...
+	include ${SYSDIR}amdtxtxe.cfg
+menu end
diff --git a/build/boot/x86/txtxen.cfg b/build/boot/x86/txtxen.cfg
new file mode 100644
index 000..5ae0708
--- /dev/null
+++ b/build/boot/x86/txtxen.cfg
@@ -0,0 +1,4 @@
+label install-xen
+	menu label ^Xen PVHVM install
+	kernel ${KERNEL_XEN}
+	append desktop=%desktop% ${VIDEO_MODE} initrd=${INITRD_XEN} -- quiet ${CONSOLE}
diff --git a/build/config/x86.cfg b/build/config/x86.cfg
index c95cd30..e231a28 100644
--- a/build/config/x86.cfg
+++ b/build/config/x86.cfg
@@ -178,11 +178,15 @@ arch_cd_info_dir: x86_syslinux
 			DEBIAN_VERSION $(DEBIAN_VERSION) \
 			BUILD_DATE $(BUILD_DATE) \
 			KERNEL /%install%/vmlinuz \
+			KERNEL_XEN /%install%/xen/vmlinuz \
 			INITRD

Re: [RFH] Test of RC1 images prior to announce

2011-01-17 Thread Ian Campbell
On Mon, 2011-01-17 at 14:51 +, Steve McIntyre wrote: 
 On Sun, Jan 16, 2011 at 01:42:13AM +, Ian Campbell wrote:
 On Sun, 2011-01-09 at 17:29 -0200, Otavio Salvador wrote: 
  Hello,
  
  Please give it a try:
  
  http://cdimage.debian.org/cdimage/.squeeze_di_rc1/
 
 A bit late but I tested the images from
 http://cdimage.debian.org/cdimage/squeeze_di_rc1/, which I guess are the
 same, under Xen.
 
 debian-sq-di-rc1-amd64-i386-powerpc-netinst.iso is missing the i386 and
 amd64 di kernel modules. This has happened before on and off and AFAIK
 is simply due to the overall size of the stuff on the CD so I'm not sure
 what to suggest.
 
 debian-sq-di-rc1-i386-amd64-source-DVD-1.iso works fine under Xen.
 
 OK, thanks very much for the testing. As I suggested a while back, I
 don't see a useful way for the m-a netinst to continue with powerpc
 support. I'm going to drop that and make it just amd64/i386 from this
 point forward, unless anybody has any bright ideas for an alternative.

I tested the daily build (sid) debian-testing-amd64-i386-netinst.iso as
32 and 64 Xen guests and all was well.

 That'll also mean that the m-a netinst should work as an isohybrid
 image then; previously it was impossible due to conflicts in the space
 needed for both Mac and PC booting (sector 0).

That's a nice bonus I guess!

Ian.

-- 
Ian Campbell

Sometimes a man who deserves to be looked down upon because he is a
fool is despised only because he is a lawyer.
-- Montesquieu




signature.asc
Description: This is a digitally signed message part


Re: [RFH] Test of RC1 images prior to announce

2011-01-15 Thread Ian Campbell
On Sun, 2011-01-09 at 17:29 -0200, Otavio Salvador wrote: 
 Hello,
 
 Please give it a try:
 
 http://cdimage.debian.org/cdimage/.squeeze_di_rc1/

A bit late but I tested the images from
http://cdimage.debian.org/cdimage/squeeze_di_rc1/, which I guess are the
same, under Xen.

debian-sq-di-rc1-amd64-i386-powerpc-netinst.iso is missing the i386 and
amd64 di kernel modules. This has happened before on and off and AFAIK
is simply due to the overall size of the stuff on the CD so I'm not sure
what to suggest.

debian-sq-di-rc1-i386-amd64-source-DVD-1.iso works fine under Xen.

Ian.
-- 
Ian Campbell

You are a wish to be here wishing yourself.
-- Philip Whalen


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-07-30 Thread Ian Campbell
On Thu, 2010-07-29 at 10:39 +0100, Steve McIntyre wrote:
 On Wed, Jul 28, 2010 at 08:52:25AM +0100, Ian Campbell wrote:
 I just checked debian-testing-amd64-i386-powerpc-netinst.iso vs
 firmware-testing-amd64-i386-powerpc-netinst.iso from
 http://cdimage.debian.org/cdimage/daily-builds/squeeze_d-i/current/multi-arch/iso-cd/
 and they have all the same files on them modulo the additional firmware
 -- did you already fix the problem? or has time been the best cure?
 
 The squeeze image fits for now, but the sid image is the one that
 doesn't.

A size comparison of yesterdays squeeze vs sid images didn't suggest any
packages which have suddenly grown or anything.

  * event-modules-*-di added ~6k per kernel flavour
  * btrfs-modules-*-di added ~200k per kernel flavour
  * partman-btrfs udeb added ~9k per arch
  * dhcp3-client-udeb added ~160k per arch

Overall it looks like + ~0.8M for each arch for quite reasonable
reasons.

 The firmware image is currently 648M so it's pretty close to the limit.
 
 The sid equivalent would be ~650.5 MB. I can raise the maximum size of
 the image, but I'm reluctant to do that unless there's no other option.

Other than drastic measures like dropping an arch or increasing the
image size I don't see anything. Even if I could I have a feeling it
would just be putting off the inevitable by a few more weeks.

Ian.
-- 
Ian Campbell
Current Noise: Ozzy Osbourne - Now You See It (Now You Don't)

In 1962, you could buy a pair of SHARKSKIN SLACKS, with a Continental
Belt, for $10.99!!


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1280482856.24292.1906.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-28 Thread Ian Campbell
On Tue, 2010-07-27 at 11:12 +0100, Steve McIntyre wrote:
 On Mon, Jul 19, 2010 at 10:49:18AM +0100, Ian Campbell wrote:
 On Mon, 2010-07-19 at 10:43 +0100, Steve McIntyre wrote:
  On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote:
  On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote:
   On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote:
   After struggling for a bit due to CONF.sh overwriting my settings (I've
   figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid 
   m-a
   netinst build without perl and deps on it and it looks as if everything
   necessary fits on CD1 now, without excluding the 486 kernel or anything
   like that.
   
   Disk usage is 643M here so pretty close to the edge still.
   
   Still not seeing that here yet, but of course it'll take time for the
   changes to hit testing.
  
  That's right, it's 5/10 days old at the moment, I was building a sid iso
  just to see if it helped.
  
  And it looks like things are fixed in testing now. \o/
 
 Awesome, thanks for letting me know!
 
 And now things have broken again for the image including firmware. :-(

:-(

I just checked debian-testing-amd64-i386-powerpc-netinst.iso vs
firmware-testing-amd64-i386-powerpc-netinst.iso from
http://cdimage.debian.org/cdimage/daily-builds/squeeze_d-i/current/multi-arch/iso-cd/
and they have all the same files on them modulo the additional firmware
-- did you already fix the problem? or has time been the best cure?

The firmware image is only 5M larger than the non-firmware one so if
firmware one breaks the regular one must be pretty close to the
precipice too.

 Another option is to increase the size of the ISO a little, but we're
 already very close to the limit of what will fit on a 650 MB CD.
 
 I've suggested raising the CD size from 650 to 700 MB in the past and
 people didn't like it, but that was quite a while ago. I can't find
 any 650MB CD-R blanks available anywhere these days...

Google shopping finds them if you explicitly ask for 74mins but if you
are just looking for CD-R then it's 80mins across the board.

The firmware image is currently 648M so it's pretty close to the limit.

Ian.
-- 
Ian Campbell

Law of the Jungle:
He who hesitates is lunch.


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-07-19 Thread Ian Campbell
On Mon, 2010-07-19 at 10:43 +0100, Steve McIntyre wrote:
 On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote:
 On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote:
  On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote:
  After struggling for a bit due to CONF.sh overwriting my settings (I've
  figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a
  netinst build without perl and deps on it and it looks as if everything
  necessary fits on CD1 now, without excluding the 486 kernel or anything
  like that.
  
  Disk usage is 643M here so pretty close to the edge still.
  
  Still not seeing that here yet, but of course it'll take time for the
  changes to hit testing.
 
 That's right, it's 5/10 days old at the moment, I was building a sid iso
 just to see if it helped.
 
 And it looks like things are fixed in testing now. \o/

Awesome, thanks for letting me know!

-- 
Ian Campbell
Current Noise: Dinosaur Jr. - Start Choppin'

Package sold by weight, not volume.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1279532958.5872.1291.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-14 Thread Ian Campbell
On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote:
 On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote:
 After struggling for a bit due to CONF.sh overwriting my settings (I've
 figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a
 netinst build without perl and deps on it and it looks as if everything
 necessary fits on CD1 now, without excluding the 486 kernel or anything
 like that.
 
 Disk usage is 643M here so pretty close to the edge still.
 
 Still not seeing that here yet, but of course it'll take time for the
 changes to hit testing.

That's right, it's 5/10 days old at the moment, I was building a sid iso
just to see if it helped.

Ian.

-- 
Ian Campbell

I found out why my car was humming.  It had forgotten the words.


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-07-11 Thread Ian Campbell
On Fri, 2010-07-09 at 13:51 +0100, Ian Campbell wrote:
 On Fri, 2010-07-09 at 12:50 +0100, Steve McIntyre wrote:
  On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote:
  On Thu, 2010-07-08 at 15:23 +0100, Steve McIntyre wrote:
   On Thu, Jul 08, 2010 at 10:00:38AM +0100, Ian Campbell wrote:
   I don't think libuuid-perl really needs perl and I have filed
  #588427 to
   that effect.
   
   Cool.
  
  It's tagged as pending already in the perl team's VCS, very fast
  turnaround.
  
  /me likes the perl team, they're very good. :-) 
 
 It's even uploaded now! I'm just waiting for the ppc buildd to upload
 and it to propagate to mirrors and I'll try an ISO build against sid to
 make sure the perl package goes away.

After struggling for a bit due to CONF.sh overwriting my settings (I've
figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a
netinst build without perl and deps on it and it looks as if everything
necessary fits on CD1 now, without excluding the 486 kernel or anything
like that.

Disk usage is 643M here so pretty close to the edge still.

Ian.
-- 
Ian Campbell

Yes, but every time I try to see things your way, I get a headache.


signature.asc
Description: This is a digitally signed message part


[PATCH] Do not set VARIANTS in CONF.sh by default

2010-07-09 Thread Ian Campbell
Specifying VARIANTS in CONF.sh seems to stop command lines such as 
VARIANTS=blah ./build.sh from working because it overrides the command
line supplied value. Commenting out the variable is consistent with how
other such variables are treated.

I suspect the only reason VARIANTS=xen has been working in the daily
cronjobs is because the CONF.sh in debian-cd/setup SVN is out of date
WRT that in debian-cd/trunk SVN and so doesn't include the VARIANTS line
at all.

--- a/CONF.sh
+++ b/CONF.sh
@@ -205,7 +205,7 @@ export DISKTYPE=CD
 export TASK_LANGLIST=tasksel_d-i.languages
 
 # Extra variants to enable. See docs/README.variants for more information.
-export VARIANTS=
+#export VARIANTS=
 
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude

-- 
Ian Campbell

Pray to God, but keep rowing to shore.
-- Russian Proverb


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-07-09 Thread Ian Campbell
On Fri, 2010-07-09 at 12:50 +0100, Steve McIntyre wrote:
 On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote:
 On Thu, 2010-07-08 at 15:23 +0100, Steve McIntyre wrote:
  On Thu, Jul 08, 2010 at 10:00:38AM +0100, Ian Campbell wrote:
  I don't think libuuid-perl really needs perl and I have filed
 #588427 to
  that effect.
  
  Cool.
 
 It's tagged as pending already in the perl team's VCS, very fast
 turnaround.
 
 /me likes the perl team, they're very good. :-) 

It's even uploaded now! I'm just waiting for the ppc buildd to upload
and it to propagate to mirrors and I'll try an ISO build against sid to
make sure the perl package goes away.

Ian.

-- 
Ian Campbell
Current Noise: Decapitated - Revelation Of Existence (The Trip)

NOTICE: anyone seen smoking will be assumed to be on fire and will be
summarily put out.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1278679883.28432.630.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-09 Thread Ian Campbell
On Fri, 2010-07-09 at 14:28 +0100, Steve McIntyre wrote:
 What I've done for now is drop the -486 kernel flavour from the m-a
 netinst. From a test build I've just done, everything fits on a single
 CD again, even with firmware included. If people want to install from
 a netinst onto a pre-686 machine then they'll need to use the separate
 i386 netinst instead of the multi-arch version.
 
 How does that sound?

In light of Frans' concern perhaps consider dropping 686 instead of 486?
I think that will result in 686-bigmem being installed on systems which
would have previously got 686 (I can confirm if necessary). This isn't
necessarily a bad thing -- it enables NX support for one thing which is
generally desirable.

FWIW RHEL 6 (the beta at least) ships with only a PAE (aka 686-bigmem)
kernel, I guess things are heading that way generally.

Ian.

-- 
Ian Campbell

I have five dollars for each of you.
-- Bernhard Goetz


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1278689669.28432.677.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-08 Thread Ian Campbell
(dropped powerpc for this subthread)

On Thu, 2010-07-08 at 01:09 +0100, Steve McIntyre wrote:
 
 Do you have any idea where perl (not perl-base) comes from? python
  (not python-minimal) doesn't seem to be in the base system but is on
  the CD as well. Similarly nothing seems to pull in binutils or
  doc-linux-text deliberately. (I'm picking on these packages because
  they are the largest components under pool/main/*)
 
 Hmmm. At the very least, debconf needs perl-base. linux-base then
 pulls in the main perl package later (via libapt-pkg-perl).

I think you mean via libuuid-perl? 
  Looking at adding libuuid-perl to satisfy dep
libuuid-perl Dep: ( OR perl-base )
libuuid-perl Dep: perl
libuuid-perl Dep: libc6
libuuid-perl Dep: libuuid1
linux-base Dep: ( OR debconf cdebconf cdebconf-udeb debconf )
linux-base Dep: ( OR util-linux udev )
linux-image-2.6.32-5-486 Dep: ( OR initramfs-tools dracut initramfs-tools )
linux-image-2.6.32-5-486 Dep: ( OR debconf cdebconf cdebconf-udeb debconf )
  Looking at adding libapt-pkg-perl to satisfy dep
libapt-pkg-perl Dep: perl-base
libapt-pkg-perl Dep: ( OR perl-base )
libapt-pkg-perl Dep: ( OR apt )
libapt-pkg-perl Dep: libc6
libapt-pkg-perl Dep: libgcc1
libapt-pkg-perl Dep: libstdc++6

I don't think libuuid-perl really needs perl and I have filed #588427 to
that effect.

  As for
 python, I'm not seeing that on the current m-a netinst CD. We then
 have linux-headers-$foo - gcc-4.3 - binutils.

Ah, I didn't think to check transitive dependencies.

I was wondering why linux-headers were on the CD in the first place and
find that tools/generate_di+k_list says:
/* Note that we do not have to include every optimised kernel flavor for
 * i386, but this does control what kernels are available on the 
netinst CD.
 * Kernel headers are included as third party modules are commonly
 * used on this architecture.
 */
so it's only for amd64 and i386 but it is on all ISO images. Could we
consider making this only for certain image types? It would save 10M.

 I don't see doc-linux-text in the log either.

There was a popcon update in debian-cd SVN recently -- does that effect
this sort of thing?

All I see in my logs are
+ Trying to add doc-linux-text...
  @dep before checklist = doc-linux-text
  @dep after checklist = doc-linux-text
  $output_size = 49686668, $size = 7814144

Also my mirror was only updated at the end of June so I guess something
there may have changed?

It 7.5M but I guess maybe this was selected from popcon to fill the
slack left by things which were bumped?

 (Looking at the log files make_disc_tree.log and sort_deps.i386.log
 for this info...)

Thanks for the pointer.

Ian.

-- 
Ian Campbell
Current Noise: Pendulum - Plastic World (feat. Fats  TC)

Man is the only animal that can remain on friendly terms with the
victims he intends to eat until he eats them.
-- Samuel Butler (1835-1902)


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1278579638.28432.409.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-08 Thread Ian Campbell
On Thu, 2010-07-08 at 12:45 +0100, Steve McIntyre wrote:
 On Thu, Jul 08, 2010 at 12:49:52AM +0100, Steve McIntyre wrote:
 On Tue, Jun 29, 2010 at 07:16:59AM +0100, Ian Campbell wrote:
 
 Hardlinks are used in preference to symlinks since these are expected to
 work better with isolinux and the Xen tools.
 
 Signed-off-by: Ian Campbell i...@hellion.org.uk
 
 diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
 
 Cool, applied now.
 
 And now fixed slightly so it works. :-)

Oops, sorry. Looks like I made the naive change from symlinks to
hardlinks without properly testing.

Ian.

-- 
Ian Campbell
Current Noise: Dinosaur Jr. - Blowing It

Cleanliness becomes more important when godliness is unlikely.
-- P. J. O'Rourke


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1278591299.28432.583.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-07-08 Thread Ian Campbell
On Thu, 2010-07-08 at 15:23 +0100, Steve McIntyre wrote:
 On Thu, Jul 08, 2010 at 10:00:38AM +0100, Ian Campbell wrote:
 I don't think libuuid-perl really needs perl and I have filed #588427 to
 that effect.
 
 Cool.

It's tagged as pending already in the perl team's VCS, very fast
turnaround.

 I was wondering why linux-headers were on the CD in the first place and
 find that tools/generate_di+k_list says:
 /* Note that we do not have to include every optimised kernel flavor 
  for
  * i386, but this does control what kernels are available on the 
  netinst CD.
  * Kernel headers are included as third party modules are commonly
  * used on this architecture.
  */
 so it's only for amd64 and i386 but it is on all ISO images. Could we
 consider making this only for certain image types? It would save 10M.
 
 Yes we could, but I don't see it as such an issue elsewhere. It's the
 m-a netinst CD I'm really trying to cut down as a priority.

By only for certain image types I guess I really meant not for the
m-a netinst CD ;-)

Ian.
-- 
Ian Campbell
Current Noise: Karma to Burn - Five

When you dig another out of trouble, you've got a place to bury your own.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1278599723.28432.591.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-06-29 Thread Ian Campbell
On Mon, 2010-06-28 at 22:43 +0100, Steve McIntyre wrote:

 
 Is this list part of the output somewhere when I do a local build
 either
 with easy-build.sh or by replicating the invocation from
 debian-cd-setup
 SVN?
 
 It's an excerpt from make_disc_tree.log, produced when
 make_disc_trees.pl is laying out packages into the temporary trees. It
 logs into the temporary directory where debian-cd is working.

Thanks.

 Subject: boot-x86: detect duplicates in the extra images used for
 installation
 
 Several files included under install.{386,amd} are actually identical
 to
 others. Rather than duplicating them attempt to detect this and
 symlink
 them.
 
 I don't think sym-links are going to work - the filesystem code in
 isolinux is very simple (e.g. it only supports basic 8.3 filenames!)
 and I doubt it'll work. Hard links *might*, however. 

OK, that's a one character change...

The files under install.{486,amd}/xen/ don't need to be readable by
isolinux, only by the xen tools. I've just had a quick look and they
appear to support hardlinks but not symlinks so that's another argument
for hardlinks. If we think isolinux would be a problem then we could
restrict this to files under install.*/xen/.

Ian.
---
Subject: boot-x86: detect duplicates in the extra images used for installation

Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and hardlink
them.

Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.

I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.

Hardlinks are used in preference to symlinks since these are expected to
work better with isolinux and the Xen tools.

Signed-off-by: Ian Campbell i...@hellion.org.uk

diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index c0a5bdc..2189cbf 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -133,6 +133,8 @@ fi
 
 extra_image () {
image=$1
+   doppelgangers=$2
+
dir=$(dirname $image)
 
mkdir -p $CDDIR/$INSTALLDIR/$dir
@@ -146,6 +148,15 @@ extra_image () {
wget $DI_WWW_HOME/cdrom/$image -O 
$CDDIR/$INSTALLDIR/$image
fi
fi
+
+   for doppelganger in $doppelgangers ; do
+   if [ -f $CDDIR/$INSTALLDIR/$dir/$doppelganger ] 
+  cmp -s $CDDIR/$INSTALLDIR/$image 
$CDDIR/$INSTALLDIR/$dir/$doppelganger ; then
+   echo   $image identical to $doppelganger. Linking
+   ln -nf $doppelganger $CDDIR/$INSTALLDIR/$image
+   break
+   fi
+   done
 }
 
 # If multiple desktops are to be supported, set the default one
@@ -231,7 +242,8 @@ if [ $THISTYPE = isolinux ]; then
fi
 
if [ -e boot$N/isolinux/f3.txt.withgtk ]; then
-   extra_image gtk/initrd.gz
+   extra_image gtk/vmlinuz ../vmlinuz
+   extra_image gtk/initrd.gz   ../initrd.gz
mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt
mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
@@ -243,8 +255,8 @@ if [ $THISTYPE = isolinux ]; then
rm -f boot$N/isolinux/isolinux.cfg.with*
 
if variant_enabled xen ; then
-   extra_image xen/vmlinuz
-   extra_image xen/initrd.gz
+   extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
+   extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
extra_image xen/xm-debian.cfg
fi
 


-- 
-- 
Ian Campbell

Generic Fortune.


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-29 Thread Ian Campbell
On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote:
 On Wed, Jun 23, 2010 at 03:45:31PM +0200, Goswin von Brederlow wrote:
 Steve McIntyre st...@einval.com writes:
 
  The netinsts are meant to have the base system, yes. I can't see
  anything obvious myself that we can drop. Maybe time to give up on
  powerpc on that image, like we've done on the m-a DVD. Shame, but
  there's only so much stuff we can accommodate here. Anybody else have
  an opinion here? Frans/Joey?
 
 Just a crcy idea: Could the plain i386 kernel be droped instead? That
 would loose support for i486 and i586 cpus on the m-a CD. But is that
 needed there?
 
 That's an option, yes. We could strip out the kernels for  686
 systems here, but I'd like to keep them on if at all possible to make
 this image as universally useful as possible. I'd be more convinced to
 simply drop powerpc instead, like we already did for the multi-arch
 DVD.

Sounds reasonable to me, but then I'm not a powerpc user...

Does the CD image need powerpc, powerpc-smp and powerpc64 kernels?
Perhaps one of powerpc and powerpc-smp could be dropped (presuming that
the smp variant still works on a UP system dropping the UP could well be
reasonable).

Do you have any idea where perl (not perl-base) comes from? python (not
python-minimal) doesn't seem to be in the base system but is on the CD
as well. Similarly nothing seems to pull in binutils or doc-linux-text
deliberately. (I'm picking on these packages because they are the
largest components under pool/main/*)

I have a feeling I'm misunderstanding the technical definition of base
system. I thought it was Priority: important or higher but perl, python
and binutils are all Priority: standard.

Ian.

-- 
Ian Campbell

Your happiness is intertwined with your outlook on life.


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-29 Thread Ian Campbell
On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote:
 the multi-arch DVD. 

Another random thought, would we be better off enabling the xen variant
on the m-a DVD rather than CD?

Ian.

-- 
-- 
Ian Campbell

Pull the trigger and you're garbage.
-- Lady Blue


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-28 Thread Ian Campbell
On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote:
 The following packages are falling off onto a second disk now:
 
 i386:main:linux-image-2.6.32-5-686-bigmem:27213342
 i386:main:linux-image-2.6-686-bigmem:3036
 i386:main:linux-headers-2.6.32-5-686-bigmem:516338
 i386:main:linux-headers-2.6-686-bigmem:2930

Is this list part of the output somewhere when I do a local build either
with easy-build.sh or by replicating the invocation from debian-cd-setup
SVN?

On Fri, 2010-06-25 at 21:51 +0100, Ian Campbell wrote:
 One thing to note is that the amd64 xen images should by symlinks to
 the regular vmlinuz+gtk/initrd.gz images (since no special kernel is
 needed on 64 bit, the intention was to symlink just for consistency in
 the path to the kernel for convenience) so there is an immediate 18.3M
 saving to be made which I will look into. 

This was inconvenienced a little because the images can be fetched from
the web and hence the symlinks aren't directly detectable, but here is
what I arrived at. However even with this a bunch of stuff gets punted
to CD2, in my case it is:
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686-bigmem_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686-bigmem_2.6.32+27_i386.deb
which is less than ideal.

This is with the Xen initrd pared down to the non-GTK version too -- I'm
not sure what else can be done to fit stuff on CD1 now...

Ian.

---
Subject: boot-x86: detect duplicates in the extra images used for installation

Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and symlink
them.

Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.

I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.

(it's not clear if hardlinks or symlinks should be preferred. I chose
symlinks largely arbitrarily but I don't know if this has implications
for compatibility with other, non-symlink supporting, OSes which may
wish to read the CD)

Signed-off-by: Ian Campbell i...@hellion.org.uk

diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index c0a5bdc..ef8aa5e 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -133,6 +133,8 @@ fi
 
 extra_image () {
image=$1
+   doppelgangers=$2
+
dir=$(dirname $image)
 
mkdir -p $CDDIR/$INSTALLDIR/$dir
@@ -146,6 +148,15 @@ extra_image () {
wget $DI_WWW_HOME/cdrom/$image -O 
$CDDIR/$INSTALLDIR/$image
fi
fi
+
+   for doppelganger in $doppelgangers ; do
+   if [ -f $CDDIR/$INSTALLDIR/$dir/$doppelganger ] 
+  cmp -s $CDDIR/$INSTALLDIR/$image 
$CDDIR/$INSTALLDIR/$dir/$doppelganger ; then
+   echo   $image identical to $doppelganger. Linking
+   ln -nsf $doppelganger $CDDIR/$INSTALLDIR/$image
+   break
+   fi
+   done
 }
 
 # If multiple desktops are to be supported, set the default one
@@ -231,7 +242,8 @@ if [ $THISTYPE = isolinux ]; then
fi
 
if [ -e boot$N/isolinux/f3.txt.withgtk ]; then
-   extra_image gtk/initrd.gz
+   extra_image gtk/vmlinuz ../vmlinuz
+   extra_image gtk/initrd.gz   ../initrd.gz
mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt
mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
@@ -243,8 +255,8 @@ if [ $THISTYPE = isolinux ]; then
rm -f boot$N/isolinux/isolinux.cfg.with*
 
if variant_enabled xen ; then
-   extra_image xen/vmlinuz
-   extra_image xen/initrd.gz
+   extra_image xen/vmlinuz ../vmlinuz   ../gtk/vmlinuz
+   extra_image xen/initrd.gz   ../initrd.gz ../gtk/initrd.gz
extra_image xen/xm-debian.cfg
fi
 




-- 
-- 
Ian Campbell

A mushroom cloud has no silver lining.


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-27 Thread Ian Campbell
On Sat, 2010-06-26 at 21:49 +0200, Ferenc Wagner wrote:
 Ian Campbell i...@hellion.org.uk writes:
 
  On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote:
 
  Ian Campbell i...@hellion.org.uk writes:
  
  Another option might be to combine gtk/initrd.gz and xen/initrd.gz so
  that the overhead is only the kernel udebs and not duplicating all the
  other stuff.
  
  I probably mentioned this already, but you aren't constrained to a
  single initrd.gz: you can use several ones separated by commas.
 
  Where can I use several? In a Xen domain config file or in some
  bootloader config or something? Is it actually supported of does it just
  happen to work by some coincidence?
 
 Unfortunately not in a Xen domain config, AFAIK.  But isolinux supports
 it, as per syslinux.txt:
 
 It supports multiple filenames separated by commas.
 This is mostly useful for initramfs, which can be composed of
 multiple separate cpio or cpio.gz archives.

OK, Thanks.

 It's actually an overlay, so it may be possible to work around the Xen
 limitation by making the Xen initrd the base one and overwriting its
 arch dependent parts as needed.

Although it probably could be made to work I'm not that keen on making
the regular case more complicated/strange (even if supported by the
bootloader) in order to support Xen and I suspect nobody else is either.
I'd prefer to drop GTK from the Xen images.

Ian.

-- 
-- 
Ian Campbell

BOFH excuse #169:

broadcast packets on wrong frequency


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-26 Thread Ian Campbell
On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote:
 Ian Campbell i...@hellion.org.uk writes:
 
  Another option might be to combine gtk/initrd.gz and xen/initrd.gz so
  that the overhead is only the kernel udebs and not duplicating all the
  other stuff.
 
 I probably mentioned this already, but you aren't constrained to a
 single initrd.gz: you can use several ones separated by commas.

Where can I use several? In a Xen domain config file or in some
bootloader config or something? Is it actually supported of does it just
happen to work by some coincidence?

Ian.

 On the
 other hand I've got no idea how much of the initrd contents is arch
 independent.  And I surely wouldn't miss the graphical part of the Xen
 installer.

-- 
-- 
Ian Campbell

All other things being equal, a bald man cannot be elected President of
the United States.
-- Vic Gold


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-25 Thread Ian Campbell
?

Ian.

-- 
Ian Campbell
Current Noise: Anthrax - Who Cares Wins

So live that you wouldn't be ashamed to sell the family parrot to the
town gossip.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1277475420.25867.112.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-06-25 Thread Ian Campbell
On Wed, 2010-06-23 at 15:45 +0200, Goswin von Brederlow wrote:
 Just a crcy idea: Could the plain i386 kernel be droped instead? That
 would loose support for i486 and i586 cpus on the m-a CD. But is that
 needed there?

I guess it is a possibility, I suppose new installs on i486 and i586
class machines are likely to be a dying breed and there are other images
which contain that kernel for those occasions. (although I guess the
same rationale could be applied to having i386 at all when amd64 is on
the image too ;-) )

Does anyone else have an opinion?

Ian.
-- 
Ian Campbell
Current Noise: Reverend Bizarre - The March Of The War Elephants

New Year's Eve is the time of year when a man most feels his age,
and his wife most often reminds him to act it.
-- Webster's Unafraid Dictionary


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1277475563.25867.118.ca...@zakaz.uk.xensource.com



Re: Multi-arch netinst getting too big

2010-06-25 Thread Ian Campbell
On Fri, 2010-06-25 at 15:17 +0100, Ian Campbell wrote:
 The Lenny multi arch netinst amd64+i3486+powerpc was 472M which left
 around 178M spare so I wonder where that space has gone.
 [...]
 I'll take a look at the non-package content of the DVD next since
 there seems to ~50M accounted there. 

So the sid daily build of multi arch netinst amd64+i3486+powerpc is 614M
(remember that linux-image-686-bigmem has been bumped)

Looking at the space used at the top level:
  * /pool has gone 385M-494M (+109M, seems in line with analysis in
previous mail).
  * /dists has gone 1.4M-1.5M
  * /docs has gone 1.5M-1.4M
  * /install has gone 35M-39M (+4M)
  * /install.386 has gone 18M-38M (+20M)
  * /install.amd has gone 19M-40M (+21M)
  * A few K here and there for /README.*, /syslink, /firmware etc

So it looks like other than /pool the big change is to /install*.

powerpc64 vmlinux,initrd.gz:8.4M+4.3M=12.7M - 11M+4.1M=15.1M   (+2.4M)
powerpc64 vmlinuz-chrp.initrd:  6.5M- 6.9M (+0.4M)

powerpc   vmlinux,initrd.gz:5.2M+4.3M=9.5M  - 6.7M+4.0M=10.7M  (+1.2M)
powerpc   vmlinuz-chrp.initrd:  6.1M- 6.3M (+0.2M)

386   vmlinuz,initrd.gz:1.5M+4.3M=5.8M  - 2.1M+3.9M=6M (+0.2M)
386 gtk   initrd.gz:12M - 15M  (+3M)
386 xen   vmlinuz,initrd.gz:0M  - 2.3M+15M=17.3M   (+17.3)

amd   vmlinuz,initrd.gz:1.7M+4.4M=6.1M  - 2.3M+4.0M=6.3M   (+0.2M)
amd gtk   initrd.gz:13M - 16M  (+3M)
amd xen   vmlinuz,initrd.gz:0   - 2.3M+16M=18.3M   (+18.3M)

So the minor culprits seems to be a smallish increase in the powerpc
vmlinux's and (as Frans predicted) an increase in the gtk initrd.gz's

However the major culprit certainly seems to be the xen initrd.gz's. One
thing to note is that the amd64 xen images should by symlinks to the
regular vmlinuz+gtk/initrd.gz images (since no special kernel is needed
on 64 bit, the intention was to symlink just for consistency in the path
to the kernel for convenience) so there is an immediate 18.3M saving to
be made which I will look into.

The other obvious thing to consider here would be to switch to a non-GTK
initrd for i386/xen which I estimate would save ~10M. It's not clear how
useful graphical install is under Xen anyway due to its more server-ish
focus. Another option might be to combine gtk/initrd.gz and
xen/initrd.gz so that the overhead is only the kernel udebs and not
duplicating all the other stuff.

This seems likely to be enough to squish everything back onto one CD but
doesn't seem like it will buy much headroom after that. It's not that
clear to me where there are other savings to be made though.

Are both powerpc and powerpc64 used these days? (I honestly have no
idea)

Ian.
-- 

Ian Campbell

You know, of course, that the Tasmanians, who never committed adultery, are
now extinct.
-- M. Somerset Maugham


signature.asc
Description: This is a digitally signed message part


Re: Multi-arch netinst getting too big

2010-06-15 Thread Ian Campbell
On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote:
 For the last few builds, the i386/amd64/powerpc sid netinst image has
 become too big to fit on one CD any more. The following packages are
 falling off onto a second disk now:
 
 i386:main:linux-image-2.6.32-5-686-bigmem:27213342
 i386:main:linux-image-2.6-686-bigmem:3036
 i386:main:linux-headers-2.6.32-5-686-bigmem:516338
 i386:main:linux-headers-2.6-686-bigmem:2930

The linux-image ones were added to support installation into a Xen PV
domain and were added to this image precisely because it was one of the
few images which was considered to have room -- it would be a shame to
have to drop them.

 http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/20100615-5/multi-arch/list-cd/debian-testing-amd64-i386-powerpc-netinst.list.gz
 
 in case anybody wants to take a look and suggest things...

I'm afraid I don't have any good ideas. Is this particular image
supposed to contain a complete base system or just enough to fetch the
remainder of the base system from the net?

Ian.

-- 
Ian Campbell
Current Noise: Disfear - The Horns

* SynrG notes that the number of configuration questions to answer in sendmail
  is NON-TRIVIAL
-- Seen on #Debian


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1276610774.19091.9821.ca...@zakaz.uk.xensource.com



Re: [ANNOUNCE] Alpha1 images, last tests and announce on friday

2010-02-18 Thread Ian Campbell
On Thu, 2010-02-18 at 13:59 -0200, Otavio Salvador wrote:

 
 The squeeze_d-i daily CD builds are based on the version of
 D-I you
 uploaded, not on the failing daily D-I builds!
 
 The daily D-I builds only affect the sid_d-i daily CD builds.
 
 Indeed; you're right. I was confusing both. Thanks :-)

Please can somebody confirm which multi-arch netinst images I should be
testing to ensure I am testing this alpha1 release?

Ian.

-- 
Ian Campbell
Current Noise: Iron Monkey - OMI Bozu (Wisdom Of Choking)

Personally, I like to defiantly split my infinitives.  :-)
-- Larry Wall in 199708271551.iaa10...@wall.org


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1266509839.10261.1914.ca...@zakaz.uk.xensource.com



Re: No daily builds since the 26th?

2009-11-02 Thread Ian Campbell
On Sun, 2009-11-01 at 03:41 +, Steve McIntyre wrote: 
 On Sat, Oct 31, 2009 at 08:50:45AM +, Ian Campbell wrote:
 There doesn't seem to have been a daily build since Monday.
 http://people.debian.org/~joeyh/d-i/build-logs.html suggests they aren't
 being attempted and failing but rather just aren't happening.
 
 Pass, you'll have to ask the d-i folks instead. I'm away on vacation
 until next weekend so I can't really investigate more myself right
 now.

Thanks Steve.

The builds are now being attempted again, the failures yesterday and
today were due to locale-chooser not being available for a day or so
while it transitioned from arch:all to arch:any. I think today's build
failed because it happened too soon to pick up today's d-i build which
did succeed so it was still trying to use yesterday's failed d-i build.
I think they should all be fine tomorrow.

Ian.

-- 
Ian Campbell

Stay away from flying saucers today.


signature.asc
Description: This is a digitally signed message part


No daily builds since the 26th?

2009-10-31 Thread Ian Campbell
There doesn't seem to have been a daily build since Monday.
http://people.debian.org/~joeyh/d-i/build-logs.html suggests they aren't
being attempted and failing but rather just aren't happening.

Ian.

-- 
Ian Campbell

Bus error -- driver executed.


signature.asc
Description: This is a digitally signed message part


Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]

2009-10-25 Thread Ian Campbell
On Sun, 2009-10-25 at 06:32 +0100, Frans Pop wrote: 
  Looks to me that the general state of builds is rather pathetic ATM:
 
 Sorry. I should have just written Looks like there are quite a few 
 problems with builds ATM. Does not change the facts or the likelyhood of 
 a successful upload/release any time soon though.

I noticed the i386 failures yesterday. I've no idea when they started,
seems like quite a while ago. Would it be worth having a notification of
build failures sent to the list? (or even just an occasional summary)

i386 is failing with: 
3366 symbols, 654 unresolved
Traceback (most recent call last):
  File /usr/bin/mklibs, line 538, in module
raise No library provides non-weak %s % name
No library provides non-weak 
_nss_files_parse_sg...@glibc_private@libc.so.6
make[2]: *** [stamps/tree-cdrom_gtk-stamp] Error 1
make[1]: *** [_build] Error 2
make: *** [build_cdrom_gtk] Error 2

I only checked the first failure for each arch but this same failure
seems to have effected mips (build_r4k-ip22_cdrom), s390 (build_generic)
and armel (uild_iop32x_netboot_glantank).  The symbol in the mips case
is __gnu_local_gp while the others are
_nss_files_parse_sg...@glibc_private@libc.

I was unable to reproduce in an uptodate i386 sid chroot. I'm not sure
which environment these builds occur, maybe it's a testing thing? I'm
installing a squeeze VM now to check.

powerpc is failing differently with 
E: Couldn't find package firewire-core-modules-2.6.30-1-powerpc-di
or
E: Couldn't find package floppy-modules-2.6.30-1-powerpc64-di
depending on the flavour.

Ian.

-- 
Ian Campbell

Q:  Why did the astrophysicist order three hamburgers?
A:  Because he was hungry.


signature.asc
Description: This is a digitally signed message part


Re: Fix error message from tools/sort_deps

2009-08-23 Thread Ian Campbell
The new apt seems to print lots of 
W: Unable to read 
/storage/mirror/tmp/apt/squeeze-powerpc/apt/preferences.d/ - FileExists (2: No 
such file or directory)
when called by sort_deps. I guess the directory needs to be mkdir'd
somewhere. There does not really seem to be a good place to do this but
the patch below seems like as good a place as any.

Ian. 

diff --git a/Makefile b/Makefile
index e8f92a7..8bb72b2 100755
--- a/Makefile
+++ b/Makefile
@@ -191,6 +191,8 @@ $(ADIR)/status:
@echo Generating a fake status file for apt-get and apt-cache...
$(Q)for ARCH in $(ARCHES); do \
mkdir -p $(ADIR)/$(CODENAME)-$$ARCH; \
+   mkdir -p $(ADIR)/$(CODENAME)-$$ARCH/apt; \
+   mkdir -p $(ADIR)/$(CODENAME)-$$ARCH/apt/preferences.d; \
if [ $$ARCH = source -o $(INSTALLER_CD) = 1 -o 
$(INSTALLER_CD) = 2 ];then \
: $(ADIR)/$(CODENAME)-$$ARCH/status ; \
else \
diff --git a/debian/changelog b/debian/changelog
index 33f05ff..13047ec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -24,6 +24,7 @@ debian-cd (3.1.3) UNRELEASED; urgency=low
 packages or D-I components relative to a regular image.
   * Add variant to create i386/amd64 images that support installing Xen guests.
   * Recognise and ignore Enhances: lines.
+  * Create apt/preferences.d in APTTMP, keeps newer apt from printing a 
warning. 
 
   [ Raphaël Hertzog ]
   * Fallback looking for syslinux/silo/yaboot in $CODENAME when $DI_CODENAME



signature.asc
Description: This is a digitally signed message part


Build error in current svn

2009-08-23 Thread Ian Campbell
I'm seeing with current svn trunk 
cc1: warning: command line option -nostdinc++ is valid for C++/ObjC++ 
but not for C
stdin:25:3: error: invalid preprocessing directive #Used
stdin:31:3: error: invalid preprocessing directive #Used
cc1: warning: command line option -nostdinc++ is valid for C++/ObjC++ 
but not for C
make: *** [/storage/mirror/tmp/squeeze/rawlist] Error 1

Looks like the cause is r1947. Although this is a shell script the here
end up in the output which gets fed to cpp and are not valid comments as
far as cpp is concerned. Use C style comments instead. 

diff --git a/tools/generate_di+k_list b/tools/generate_di+k_list
index 755b174..6042e19 100755
--- a/tools/generate_di+k_list
+++ b/tools/generate_di+k_list
@@ -44,13 +44,13 @@ mdadm
 aptitude
 hotplug
 usbutils
-# Used for Lenny and earlier
+/* Used for Lenny and earlier */
 console-data
 console-common
 console-tools
 console-cyrillic
 console-terminus
-# Used for Squeeze and onwards
+/* Used for Squeeze and onwards */
 console-setup
 pcmcia-cs
 pcmciautils

-- 
Ian Campbell

The trouble with being punctual is that nobody's there to appreciate it.
-- Franklin P. Jones


signature.asc
Description: This is a digitally signed message part


Re: Install from ISO for Xen guest

2009-08-09 Thread Ian Campbell
On Sun, 2009-08-09 at 11:32 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  diff --git a/installer/build/boot/x86/xen/xm-debian.cfg
  b/installer/build/boot/x86/xen/xm-debian.cfg index d1d78e7..7c3ff51
  100644
  --- a/installer/build/boot/x86/xen/xm-debian.cfg
  +++ b/installer/build/boot/x86/xen/xm-debian.cfg
 
 The patch for this file introduces trailing whitespace in several places.
 
  diff --git a/installer/build/config/amd64/cdrom-xen.cfg
  b/installer/build/config/amd64/cdrom-xen.cfg new file mode 100644
  index 000..3f03e74
  --- /dev/null
  +++ b/installer/build/config/amd64/cdrom-xen.cfg
  @@ -0,0 +1,13 @@
  +TYPE=cdrom/gtk
  +
  +EXTRANAME=cdrom/xen/
  +
  +MANIFEST-KERNEL = kernel image for installing under Xen
  +MANIFEST-INITRD = initrd for installing under Xen
  +MANIFEST-XENCFG = example Xen configuration
  +
  +TARGET = $(KERNEL) $(INITRD) xen_config
  +SYMLINK_KERNEL = ../vmlinuz
  +SYMLINK_INITRD = ../gtk/initrd.gz
  +
  +EXTRATARGETS = build_cdrom-gtk
 
 This should be 'EXTRATARGETS = build_cdrom_gtk' (underscore, not hyphen).

Oh yes, strange that I didn't see an error. I guess I got lucky by using
all_build so cdrom_gtk had always already been built or something.

The amd64 netboot-xen which is already committed has the same problem --
I'll fix that right away.

 I've been wondering if the cdrom-xen target should be built automatically 
 with the cdrom_isolinux target, but I guess that has both advantages and 
 disadvantages. In the end I'm OK with having it as a separate top-level 
 variant.

I have no particular preference myself.

Ian.

-- 
Ian Campbell

All's well that ends.


signature.asc
Description: This is a digitally signed message part


Re: Install from ISO for Xen guest

2009-08-09 Thread Ian Campbell
On Sun, 2009-08-09 at 11:16 +0100, Ian Campbell wrote:
 The amd64 netboot-xen which is already committed has the same problem --
 I'll fix that right away.

My mistake, it really is cdrom_gtk and netboot-gtk...

Ian.

-- 
Ian Campbell

BOFH excuse #420:

Feature was not beta tested


signature.asc
Description: This is a digitally signed message part


Re: Install from ISO for Xen guest

2009-08-09 Thread Ian Campbell
On Sun, 2009-08-09 at 16:42 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  I will follow up shortly with a short series of patches which
  introduces image variants to debian-cd and adds the Xen variant as an
  option for i386 and amd64 and a patch to the nightly cron jobs which
  enables this variant for the i386+amd64+powerpc multiarch netinst
  image.
 
 I've committed the debian-cd changes with a few very minor (style) 
 corrections. The implementation is IMO quite nice and clean.

Awesome. Thank you very much for the original guidance and all your
input along the way.

 Ian: feel free to commit the changes for D-I (after the corrections) and 
 when that's done I'll enable the Xen variant for the CD builds.

Done.

Cheers,
Ian.

-- 
Ian Campbell

If it doesn't smell yet, it's pretty fresh.
-- Dave Johnson, on dead seagulls


signature.asc
Description: This is a digitally signed message part


Re: Install from ISO for Xen guest

2009-08-08 Thread Ian Campbell
On Sat, 2009-08-08 at 20:21 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  Below is a patch for debian-installer to build cdrom-xen variants for
  i386 and amd64. If nobody objects I would like to commit this to the
  d-i repository.
 
 I'd like to test it first. The fan of my notebook needs replacing, so that 
 may take a few days.

No problem, thanks.

A few other things are also needed to get a final result which is
actually usable. I wasn't bothering about these explicitly since they
will happen in the routine course of things.

Firstly the i386 and amd64 kernel udebs need to be rebuilt against a
kernel package = 2.6.30-4 in order to pick up a bug fix which prevents
the kernel from booting under Xen.

Secondly an updated udev package is needed in order for d-i to detect
the CD correctly. Marco is working on a new upstream which includes this
and says it'll be done in a few weeks. I've been using a rebuild of the
current version in sid with the necessary patches applied, debdiff is
below.

Ian.

diff -u udev-0.141/rules/debian/50-udev.rules 
udev-0.141/rules/debian/50-udev.rules
--- udev-0.141/rules/debian/50-udev.rules
+++ udev-0.141/rules/debian/50-udev.rules
@@ -6,6 +6,8 @@
IMPORT{program}=cdrom_id --export $tempnode
 KERNEL==sr[0-9]*, ACTION==add|change, \
IMPORT{program}=cdrom_id --export $tempnode
+KERNEL==xvd*, ACTION==add|change, \
+   IMPORT{program}=cdrom_id --export $tempnode
 
 # workarounds for devices which do not report media changes
 SUBSYSTEMS==ide,  KERNEL==hd[a-z], ATTR{removable}==1, \
diff -u udev-0.141/rules/debian/60-persistent-storage.rules 
udev-0.141/rules/debian/60-persistent-storage.rules
--- udev-0.141/rules/debian/60-persistent-storage.rules
+++ udev-0.141/rules/debian/60-persistent-storage.rules
@@ -22,9 +22,6 @@
 # ignore partitions that span the entire disk
 TEST==whole_disk,GOTO=persistent_storage_end
 
-# skip xen virtual hard disks
-DRIVERS==vbd,GOTO=no_hardware_id
-
 # workaround for kernels  2.6.25-rc1
 ENV{DEVTYPE}!=?*, ATTR{range}==?*, ENV{DEVTYPE}=disk
 ENV{DEVTYPE}!=?*, ATTR{start}==?*, ENV{DEVTYPE}=partition
diff -u udev-0.141/debian/changelog udev-0.141/debian/changelog
--- udev-0.141/debian/changelog
+++ udev-0.141/debian/changelog
@@ -1,3 +1,9 @@
+udev (0.141-1.0.hellion0) UNRELEASED; urgency=low
+
+  * Allow Xen vbd's to be probed.
+
+ -- Ian Campbell i...@hellion.org.uk  Wed, 13 May 2009 08:31:33 +0100
+
 udev (0.141-1) unstable; urgency=high
 
   * New upstream release. Fixes:
diff -u udev-0.141/debian/patches/series udev-0.141/debian/patches/series
--- udev-0.141/debian/patches/series
+++ udev-0.141/debian/patches/series
@@ -8,2 +8,4 @@
 dont-build-some-helpers
+path_id-xen-vbd
+cdrom_id-xen-vbd
 
only in patch2:
unchanged:
--- udev-0.141.orig/debian/patches/path_id-xen-vbd
+++ udev-0.141/debian/patches/path_id-xen-vbd
@@ -0,0 +1,51 @@
+commit 09b2999210c6843a2a3de529dd316b741261e31c
+Author: Ian Campbell i...@hellion.org.uk
+Date:   Thu Apr 16 22:46:18 2009 +0200
+
+path_id: support identification of Xen virtual block devices
+
+diff --git a/extras/path_id/path_id b/extras/path_id/path_id
+index d21dea7..7b4973f 100755
+--- a/extras/path_id/path_id
 b/extras/path_id/path_id
+@@ -129,6 +129,30 @@ handle_platform () {
+   RESULT=0
+ }
+ 
++handle_xen () {
++  local DEV=$1
++  cd -P $1
++  vbd_id=${DEV##*/}
++  host_dev_path=$DEV
++  while [ ! -z $host_dev_path ] ; do
++  case $host_dev_path in
++  */vbd*)
++  host_dev_path=${host_dev_path%/*}
++  ;;
++  *)
++  break
++  ;;
++  esac
++  done
++  if [ $d ]; then
++  d=xen-$vbd_id-$d
++  else
++  d=xen-$vbd_id
++  fi
++  D=$host_dev_path
++  RESULT=0
++}
++
+ handle_serio () {
+   local DEV=$1
+   cd -P $1
+@@ -532,6 +556,9 @@ handle_device () {
+   */platform/*)
+   handle_platform $D
+   ;;
++  */vbd-[0-9]*)
++  handle_xen $D
++  ;;
+   */devices)
+   D=
+   ;;
only in patch2:
unchanged:
--- udev-0.141.orig/debian/patches/cdrom_id-xen-vbd
+++ udev-0.141/debian/patches/cdrom_id-xen-vbd
@@ -0,0 +1,35 @@
+commit 55d8f5e208396589476583dad8f2a7f2db3e2ef5
+Author: Kay Sievers kay.siev...@vrfy.org
+Date:   Fri Apr 17 00:29:56 2009 +0200
+
+cdrom_id: add Xen cdrom support
+
+diff --git a/extras/cdrom_id/60-cdrom_id.rules 
b/extras/cdrom_id/60-cdrom_id.rules
+index 12fbf63..a3e8e3c 100644
+--- a/extras/cdrom_id/60-cdrom_id.rules
 b/extras/cdrom_id/60-cdrom_id.rules
+@@ -1,3 +1,5 @@
+-# import optical drive properties
++# do

[PATCH 1/4] boot-x86: move creation of install.bat out of extra_image

2009-08-07 Thread Ian Campbell
There is currently only a single caller but soon I will be adding
another which does not want install.bat created.
---
 tools/boot/squeeze/boot-x86 |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index 29f5566..0892ed7 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -145,9 +145,6 @@ extra_image () {
else
wget $DI_WWW_HOME/cdrom/$image -O 
$CDDIR/$INSTALLDIR/$image
fi
-   kernel_param=
-   [ $dir = gtk ]  kernel_param=video=vesa:ywrap,mtrr vga=788
-   echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz 
initrd=initrd.gz $kernel_param | todos  $CDDIR/$INSTALLDIR/$dir/install.bat
fi
 }
 
@@ -236,6 +233,8 @@ if [ $THISTYPE = isolinux ]; then
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
mv boot$N/isolinux/isolinux.cfg.withgtk 
boot$N/isolinux/isolinux.cfg
fi
+   echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz 
initrd=initrd.gz video=vesa:ywrap,mtrr vga=788 | todos  
$CDDIR/$INSTALLDIR/gtk/install.bat
+
fi
rm -f boot$N/isolinux/isolinux.cfg.with*
 
-- 
1.6.3.3


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



[PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.

2009-08-07 Thread Ian Campbell
---
 easy-build.sh |   28 
 1 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/easy-build.sh b/easy-build.sh
index c586c1e..d85d810 100755
--- a/easy-build.sh
+++ b/easy-build.sh
@@ -25,19 +25,23 @@ if [ $# -eq 0 ]; then
 fi
 
 desktop=
-if [ $1 = -d ]; then
-   case $2 in
-   # Note: gnome is the special gnome task, not the generic task
-   gnome|kde|lxde|xfce|light|all)
-   desktop=$2
-   shift 2
-   ;;
-   *)
-   show_usage
-   exit 1
-   ;;
+while getopts d:h OPT ; do
+   case $OPT in
+   d)
+   case $OPTARG in
+   # Note: gnome is the special gnome task, not the generic task
+   gnome|kde|lxde|xfce|light|all)
+   desktop=$2
+   ;;
+   *)
+   show_usage
+   exit 1
+   ;;
+   esac ;;
+   h) show_usage; exit 1;;
esac
-fi
+done
+shift $(expr $OPTIND - 1)
 
 export DISKTYPE=$1
 shift
-- 
1.6.3.3


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



[PATCH 3/4] Add support for producing disks with (optional) extra variants.

2009-08-07 Thread Ian Campbell
This patch just adds the generic support code:
   * CONF.sh:   Add $(VARIANTS) configuration variable.
   * eash-build.sh: Add command line parameter to enable variants.
   * Makefile:  Define VARIANT_xxx when preprocessing package list.
   * boot/?/common.sh:  Add a function for checking if a variant is enabled.
   * generate_di_list:  Allow variant overrides in udeb exclusion list.

The generate_di_list change introduces an extended syntax to the udeb
exclusion lists. A line in the exclusion list may now include zero or
more conditionals in the form of a positive variant or negative
!variant. In the positive case the relevant udeb will only be
excluded if the given variant is enabled. In the negative case the
relevant udeb will only be excluded if the given variant is
disabled. (This seems like a double negative but I think in the
context of reading the exclude list it is the least confusing was
around). If multiple conditions are given then if any condition is
satisfied the udeb will be excluded.

The intention is to use this support to add support for installing a
Xen guest from an ISO image.

Thanks to Frans Pop for suggesting the approach.
---
 CONF.sh  |3 +++
 Makefile |5 -
 easy-build.sh|7 +--
 tools/boot/squeeze/common.sh |7 +++
 tools/generate_di_list   |   18 +++---
 5 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/CONF.sh b/CONF.sh
index 2cf848a..d92f534 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -189,6 +189,9 @@ export DISKTYPE=CD
 # included. See tasks/README.tasksel for further info.
 export TASK_LANGLIST=tasksel_d-i.languages
 
+# Extra variants to enable:
+export VARIANTS=
+
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude
 # ...but they are okay for other CDs (UNEXCLUDEx == may be included
diff --git a/Makefile b/Makefile
index 1a9b377..ce8f3ec 100755
--- a/Makefile
+++ b/Makefile
@@ -311,9 +311,12 @@ $(BDIR)/rawlist:
ARCHDEFS=$$ARCHDEFS -D ARCH_$(subst -,_,$$ARCH); \
ARCHUNDEFS=$$ARCHUNDEFS -U $$ARCH; \
done; \
+   for VARIANT in $(VARIANTS); do \
+   VARIANTDEFS=$$VARIANTDEFS -D VARIANT_$$VARIANT); \
+   done; \
if [ $(SOURCEONLY)x != yesx ] ; then \
cat $(TASKDIR)/$(TASK) | \
-   cpp -nostdinc -nostdinc++ -P -undef $$ARCHDEFS \
+   cpp -nostdinc -nostdinc++ -P -undef $$ARCHDEFS $$VARIANTDEFS\
$$ARCHUNDEFS -U i386 -U linux -U unix \
-DFORCENONUSONCD1=0 \
-I $(TASKDIR) - -  $(BDIR)/rawlist; \
diff --git a/easy-build.sh b/easy-build.sh
index d85d810..8076620 100755
--- a/easy-build.sh
+++ b/easy-build.sh
@@ -6,7 +6,7 @@ set -e
 ## See also CONF.sh for the meaning of variables used here.
 
 show_usage() {
-   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] 
BC|NETINST|CD|DVD [ARCH ...]
+   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] [-v 
VARIANTS] BC|NETINST|CD|DVD [ARCH ...]
 }
 
 
@@ -25,7 +25,8 @@ if [ $# -eq 0 ]; then
 fi
 
 desktop=
-while getopts d:h OPT ; do
+VARIANTS=
+while getopts d:hV: OPT ; do
case $OPT in
d)
case $OPTARG in
@@ -38,11 +39,13 @@ while getopts d:h OPT ; do
exit 1
;;
esac ;;
+   V) VARIANTS=$VARIANTS $OPTARG ;;
h) show_usage; exit 1;;
esac
 done
 shift $(expr $OPTIND - 1)
 
+export VARIANTS
 export DISKTYPE=$1
 shift
 
diff --git a/tools/boot/squeeze/common.sh b/tools/boot/squeeze/common.sh
index 7735837..d3ccc00 100644
--- a/tools/boot/squeeze/common.sh
+++ b/tools/boot/squeeze/common.sh
@@ -48,3 +48,10 @@ add_mkisofs_opt() {
echo -n $NEW_OPT   $OPTS_FILE
fi
 }
+
+variant_enabled() {
+VARIANT=$1
+
+echo ${VARIANTS} | grep -qw ${VARIANT}
+return $?
+}
diff --git a/tools/generate_di_list b/tools/generate_di_list
index f148d62..8ee7349 100755
--- a/tools/generate_di_list
+++ b/tools/generate_di_list
@@ -18,6 +18,8 @@ if ( $ENV{ARCHES} ) {
 }
 @ARCHES = qw{i386 amd64} unless @ARCHES;
 
+...@variants = split( , $ENV{VARIANTS});
+
 my $DATE=`date`;
 chomp $DATE;
 open(OUT, debian-installer) || die write: $!;
@@ -78,9 +80,19 @@ sub read_exclude {
chomp;
s/^#.*//;
next unless length;
-   $_=quotemeta($_);
-   $_=~s/\\\*/.*/g;
-   push @ret, $_;
+   my ($pkg,@cond) = split( , $_);
+   my $skip = 0;
+   foreach my $cond ( @cond ) {
+   if ($cond =~ /^!(.*)/) {
+   $skip = 1 if grep { $_ eq $1 } @VARIANTS;
+   } else {
+   $skip = 1 unless grep { $_ eq $cond } @VARIANTS;
+   }
+   }
+   next if $skip;
+   

[PATCH 4/4] Add a Xen variant on i386 and amd64.

2009-08-07 Thread Ian Campbell
i386 Xen guests require a PAE (686-bigmem) kernel in order to
run. Therefore this variant includes the relevant installer kernel and
ramdisk in install.386/xen as well as suitable kernel udebs and proper
debs for the installed system.

amd64 Xen has no similar requirement but we include the kernels under
install.amd/xen in order to have a consistent path under both
architectures.
---
 CONF.sh |1 +
 data/squeeze/exclude-udebs-i386 |2 +-
 tools/boot/squeeze/boot-x86 |6 ++
 tools/generate_di+k_list|8 
 4 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/CONF.sh b/CONF.sh
index d92f534..19f32d1 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -190,6 +190,7 @@ export DISKTYPE=CD
 export TASK_LANGLIST=tasksel_d-i.languages
 
 # Extra variants to enable:
+# xen  [i386,amd64]
 export VARIANTS=
 
 # We don't want certain packages to take up space on CD1...
diff --git a/data/squeeze/exclude-udebs-i386 b/data/squeeze/exclude-udebs-i386
index eeed470..b3af1c9 100644
--- a/data/squeeze/exclude-udebs-i386
+++ b/data/squeeze/exclude-udebs-i386
@@ -29,7 +29,7 @@ usb-serial-modules-*
 usb-storage-modules-*
 zlib-modules-*
 # 686-bigmem kernel udebs are only used for the Xen netboot image
-*-686-bigmem-di
+*-686-bigmem-di !xen
 # Not used on i386
 console-keymaps-acorn
 console-keymaps-amiga
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index 0892ed7..58d1276 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -238,6 +238,12 @@ if [ $THISTYPE = isolinux ]; then
fi
rm -f boot$N/isolinux/isolinux.cfg.with*
 
+   if variant_enabled xen ; then
+   extra_image xen/vmlinuz
+   extra_image xen/initrd.gz
+   extra_image xen/xm-debian.cfg
+   fi
+
# Modify win32-loader.ini for the current arch
if [ -e boot$N/win32-loader.ini ]; then
sed -i s|install/|$INSTALLDIR/| boot$N/win32-loader.ini
diff --git a/tools/generate_di+k_list b/tools/generate_di+k_list
index 29e4246..9c2edb0 100755
--- a/tools/generate_di+k_list
+++ b/tools/generate_di+k_list
@@ -124,6 +124,14 @@ atl2-modules-2.6-486
 atl2-modules-2.6-686
 speakup-modules-2.6-486
 speakup-modules-2.6-686
+#ifdef VARIANT_xen
+linux-image-2.6-686-bigmem
+linux-headers-2.6-686-bigmem
+loop-aes-modules-2.6-686-bigmem
+atl2-modules-2.6-686-bigmem
+speakup-modules-2.6-686-bigmem
+#endif
+
 #endif
 
 #ifdef ARCH_amd64
-- 
1.6.3.3


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Install from ISO for Xen guest

2009-08-07 Thread Ian Campbell
This was discussed a little while back on both lists (the
interesting/useful bit starts at
http://lists.debian.org/debian-boot/2009/06/msg00094.html). It's taken
me a while but I've finally got something which works for me.

Below is a patch for debian-installer to build cdrom-xen variants for
i386 and amd64. If nobody objects I would like to commit this to the d-i
repository.

I will follow up shortly with a short series of patches which introduces
image variants to debian-cd and adds the Xen variant as an option for
i386 and amd64 and a patch to the nightly cron jobs which enables this
variant for the i386+amd64+powerpc multiarch netinst image.

One thing which is outstanding is a udev update which is needed for
CDROM devices to actually be detected. Support went into upstream in
release 142 (sid currently has 141).

Ian.

commit a1c1d48b63f664ea988b4ffe2d999b0d40d86827
Author: Ian Campbell i...@hellion.org.uk
Date:   Thu Aug 6 20:24:00 2009 +0100

Add cdrom-xen images to i386 and amd64.

- Update xm-debian.cfg to include the ability to boot from an ISO
- Add an i386 cdrom-xen target using the correct kernel+modules for
  use with Xen (686-bigmem)
- Add an amd64 cdrom-xen target symlinking to the regular amd64
  graphical kernel+initrd, since although a different kernel isn't
  needed for amd64 this keeps things similar for both x86 platforms.

diff --git a/installer/build/boot/x86/xen/xm-debian.cfg 
b/installer/build/boot/x86/xen/xm-debian.cfg
index d1d78e7..7c3ff51 100644
--- a/installer/build/boot/x86/xen/xm-debian.cfg
+++ b/installer/build/boot/x86/xen/xm-debian.cfg
@@ -11,16 +11,26 @@
 # to start the Debian Installer.
 #
 # In the installation case the following additional variables exist:
+#
+# COMMON OPTIONS
+# install-method: cdrom or network
 # install-arch: which architecture to install. e.g. i386 or amd64
-# install-suite: which Debian version to install. e.g. squeeze or sid
-# install-mirror: which Debian mirror to use
-#   e.g. http://ftp.uk.debian.org/debian
-# install-installer: URL to obtain the Debian Installer bits, by
-#   default these are located under install-mirror. To use a nightly
-#   snapshot: http://people.debian.org/~joeyh/d-i/images/daily/
-# install-kernel, install-ramdisk: URLs pointing to the installer kernel and
+# install-installer: URL or path to the Debian Installer bits. By
+#   default for a network install these are located under
+#   install-mirror. For a CDROM install the default is a fixed path on
+#   the CD.
+# install-kernel, install-ramdisk: URL/path to the installer kernel and
 #   ramdisk to use, by default these are located via install-installer.
 # install-extra: extra command line arguments
+#
+# CDROM SPECIFIC OPTIONS
+# install-media: Path to the Debian install media (i.e. an ISO)
+# install-cdrom-device: Name of the CD-ROM device within the guest.
+#
+# NETWORK SPECIFIC OPTIONS
+# install-suite: which Debian version to install. e.g. lenny, squeeze or sid
+# install-mirror: which Debian mirror to use
+#   e.g. http://ftp.uk.debian.org/debian
 #
 
 
@@ -125,18 +135,35 @@ def var_check_with_default(default, var, val):
 return default
 
 xm_vars.var('install', use='Install Debian, default: false', check=check_bool)
+xm_vars.var(install-method,
+use='Installation method to use cdrom or network',
+check=lambda var, val: var_check_with_default('network', var, val))
 
-xm_vars.var(install-arch,
-use='Debian mirror to install from (default: i386)',
-check=lambda var, val: var_check_with_default('i386', var, val))
+# install-method == network
 xm_vars.var(install-mirror,
 use='Debian mirror to install from (default: 
http://ftp.debian.org/debian)',
 check=lambda var, val: 
var_check_with_default('http://ftp.debian.org/debian', var, val))
 xm_vars.var(install-suite,
-use='Debian suite to install (default: squeeze)',
-check=lambda var, val: var_check_with_default(squeeze, var, val))
+use='Debian suite to install (default: lenny)',
+check=lambda var, val: var_check_with_default(lenny, var, val))
+
+# install-method == cdrom
+xm_vars.var(install-media,
+use='Installation media to use (default: None)',
+check=lambda var, val: var_check_with_default(None, var, val))
+xm_vars.var(install-cdrom-device,
+use='Installation media to use (default: xvdd)',
+check=lambda var, val: var_check_with_default('xvdd', var, val))
+
+# Common options
+xm_vars.var(install-arch,
+use='Debian mirror to install from (default: i386)',
+check=lambda var, val: var_check_with_default('i386', var, val))
+xm_vars.var(install-extra,
+use='Extra command line options (default: None)',
+check=lambda var, val: var_check_with_default(None, var, val))
 xm_vars.var(install

Re: Install from ISO for Xen guest

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 07:39 +0100, Ian Campbell wrote:
 I will follow up shortly with[...]a patch to the nightly cron jobs
 which enables this variant for the i386+amd64+powerpc multiarch
 netinst image.

Here it is.

Is this sufficient to ensure this variant is enabled in the actual
official images come release time? Or should I be patching somewhere
else as well?

--- 
enable xen variant for i386+amd64+powerpc multiarch netinst image.

diff --git a/cronjob.daily b/cronjob.daily
index 3908be0..8bb9048 100755
--- a/cronjob.daily
+++ b/cronjob.daily
@@ -60,6 +60,7 @@ if lockfile -r0 .debian-cd.lock ; then
 if [ $arch = multi-arch ] ; then
 echo   i386/amd64/ppc sid netinst
 OMIT_RELEASE_NOTES=1 OMIT_MANUAL=1 NORECOMMENDS=1 \
+VARIANTS=xen \
 NOSUGGESTS=1 COMPLETE=0 INSTALLER_CD=2 \
 TASK=debian-installer+kernel LOGAPPEND=-1 \
 MAXISOS=ALL MAXJIGDOS=ALL DI=sid DI_DIST=$DI_DIST \
@@ -76,6 +77,7 @@ if lockfile -r0 .debian-cd.lock ; then
 
 echo   i386/amd64/ppc squeeze netinst
 OMIT_RELEASE_NOTES=1 OMIT_MANUAL=1 NORECOMMENDS=1 \
+VARIANTS=xen \
 NOSUGGESTS=1 COMPLETE=0 INSTALLER_CD=2 \
 TASK=debian-installer+kernel LOGAPPEND=-1 \
 MAXISOS=ALL MAXJIGDOS=ALL DI=squeeze DI_DIST=$DI_DIST 
./testingcds amd64 i386 powerpc


-- 
Ian Campbell

Your nature demands love and your happiness depends on it.


signature.asc
Description: This is a digitally signed message part


boot powerpc and x86 fixes

2009-08-07 Thread Ian Campbell
While building images recently I noticed a couple of things which were
breaking for me in debian-cd. 

First the powerpc prep variant seems to have been disabled in d-i for
ages (since r50159 in Nov 2007) and isn't part of
http://d-i.debian.org/daily-images/powerpc/daily/ so don't try and fetch
it.

Secondly a recent change by Frans to boot-x86 left us with:
if [ blah ] ; then
# nothing but
# comments
fi
which caused a syntax error. I usually just drop a : in there but
perhaps just removing the whole if block makes sense if we never expect
either of those comment out thing to return.

Ian.

diff --git a/tools/boot/squeeze/boot-powerpc b/tools/boot/squeeze/boot-powerpc
index 213028a..25c74b6 100755
--- a/tools/boot/squeeze/boot-powerpc
+++ b/tools/boot/squeeze/boot-powerpc
@@ -83,7 +83,7 @@ if [ -n $KERNEL_PARAMS ]; then
 fi
 cp $BASEDIR/data/$DI_CODENAME/yaboot/ofboot.b ofboot.b
 
-for subarch in powerpc powerpc64 prep
+for subarch in powerpc powerpc64 #prep
 do
   case $subarch in
 powerpc|prep)
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index 58d1276..bbc29b3 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -71,6 +71,7 @@ fi
 BOOT_IMAGES=cdrom/initrd.gz cdrom/vmlinuz cdrom/debian-cd_info.tar.gz
 # Only include disk images on full CDs, not on smaller images.
 if [ $ARCH = i386 ]  [ $INSTALLER_CD != 1 ]  [ $INSTALLER_CD != 2 ]; 
then
+   :
#DISK_IMAGES=floppy/cd-drivers.img floppy/boot.img floppy/root.img
#EXTRA_DISK_IMAGES=cdrom/boot.img
 fi

-- 
Ian Campbell

Brandy-and-water spoils two good things.
-- Charles Lamb


signature.asc
Description: This is a digitally signed message part


Re: [PATCH 1/4] boot-x86: move creation of install.bat out of extra_image

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 13:33 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  There is currently only a single caller but soon I will be adding
  another which does not want install.bat created.
  ---
   tools/boot/squeeze/boot-x86 |5 ++---
   1 files changed, 2 insertions(+), 3 deletions(-)
 
  diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
  index 29f5566..0892ed7 100644
  --- a/tools/boot/squeeze/boot-x86
  +++ b/tools/boot/squeeze/boot-x86
  @@ -145,9 +145,6 @@ extra_image () {
  else
  wget $DI_WWW_HOME/cdrom/$image -O 
  $CDDIR/$INSTALLDIR/$image
  fi
  -   kernel_param=
  -   [ $dir = gtk ]  kernel_param=video=vesa:ywrap,mtrr vga=788
  -   echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz 
  initrd=initrd.gz
  $kernel_param | todos  $CDDIR/$INSTALLDIR/$dir/install.bat fi
   }
 
  @@ -236,6 +233,8 @@ if [ $THISTYPE = isolinux ]; then
  if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
  mv boot$N/isolinux/isolinux.cfg.withgtk
  boot$N/isolinux/isolinux.cfg fi
  +   echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz 
  initrd=initrd.gz
  video=vesa:ywrap,mtrr vga=788 | todos 
  $CDDIR/$INSTALLDIR/gtk/install.bat +
  fi
  rm -f boot$N/isolinux/isolinux.cfg.with*
 
 Why was $kernel_param (which was conditional on regular versus gtk) 
 replaced with a hardcoded video=vesa:ywrap,mtrr vga=788?

The location of the loadlin bit with the hardcoded video= is within the
same logical scope as the call to extra_image where the condition on gtk
evaluates to true so the output is the same now as it was before. In
fact previously extra_image was only ever called once and GTK was always
true. The non-GTK loadlin bit is hardcoded a bit further up the file.

Ian.

-- 
Ian Campbell
Current Noise: Witchcraft - Schyssta Lögner

Doubt isn't the opposite of faith; it is an element of faith.
-- Paul Tillich, German theologian.


--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 14:05 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  +while getopts d:h OPT ; do
 
 Is getopts also supported in dash?

I believe so. 

I just tried it and it looks like the script is already not dash-ready:
$ dash -x ./easy-build.sh -h
+ set -e
+ export CF=CONF.sh
+ . CONF.sh
.: 1: CONF.sh: not found

(Just to show dash knows about getops since the above didn't get that   
 far:
$ dash -c 'getopts'
getopts: 1: Usage: getopts optstring var [arg]
)

  +   case $OPT in
  +   d)
  +   case $OPTARG in
  +   # Note: gnome is the special gnome task, not the generic 
  task
  +   gnome|kde|lxde|xfce|light|all) 
  +   desktop=$2
  +   ;;
  +   *)
  +   show_usage
  +   exit 1
  +   ;;
  +   esac ;;
  +   h) show_usage; exit 1;;
 
 Please put the commands for the h option on separate lines (as is done
 for the others).

Done.

 AFAIK a plain 'show_usage', if not displayed as the result of an error,
 should have an 'exit 0'.

Done.

 The -h option should be listed in the usage output.

Done.

 Maybe it would be good to also support --help if -h is added.

Since getopts doesn't support long options I agree with Max that it
isn't worth the complexity.

Updated patch below.

Ian.

easy-build.sh: use getopts instead of rolling our own option parsing.

---
 easy-build.sh |   29 ++---
 1 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/easy-build.sh b/easy-build.sh
index c586c1e..5e7a31a 100755
--- a/easy-build.sh
+++ b/easy-build.sh
@@ -6,7 +6,7 @@ set -e
 ## See also CONF.sh for the meaning of variables used here.
 
 show_usage() {
-   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] 
BC|NETINST|CD|DVD [ARCH ...]
+   echo Usage: $(basename $0) [-h] [-d gnome|kde|lxde|xfce|light|all] 
BC|NETINST|CD|DVD [ARCH ...]
 }
 
 
@@ -25,19 +25,26 @@ if [ $# -eq 0 ]; then
 fi
 
 desktop=
-if [ $1 = -d ]; then
-   case $2 in
-   # Note: gnome is the special gnome task, not the generic task
-   gnome|kde|lxde|xfce|light|all)
-   desktop=$2
-   shift 2
-   ;;
-   *)
+while getopts d:h OPT ; do
+   case $OPT in
+   d)
+   case $OPTARG in
+   # Note: gnome is the special gnome task, not the generic task
+   gnome|kde|lxde|xfce|light|all)
+   desktop=$2
+   ;;
+   *)
+   show_usage
+   exit 1
+   ;;
+   esac ;;
+   h) 
show_usage
-   exit 1
+   exit 0
;;
esac
-fi
+done
+shift $(expr $OPTIND - 1)
 
 export DISKTYPE=$1
 shift
-- 
1.6.3.3




-- 
Ian Campbell
Current Noise: Witchcraft - It's So Easy

Logic is the chastity belt of the mind!


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 13:33 +0100, Ian Campbell wrote:
 
 I just tried it and it looks like the script is already not
 dash-ready:
 $ dash -x ./easy-build.sh -h
 + set -e
 + export CF=CONF.sh
 + . CONF.sh
 .: 1: CONF.sh: not found

I'm no expert but it looks like dash obeys $PATH when executing the ..
The manpage doesn't mention this behaviour and bash doesn't seem to
follow it but . is pretty hard to google for so I have looked up the
docs...

$ PATH=.:$PATH ./easy-build.sh -h
Usage: easy-build.sh [-h] [-d gnome|kde|lxde|xfce|light|all] 
BC|NETINST|CD|DVD [ARCH ...]

works for me. So does the following I've no idea if this is correct
analysis though...

--- a/easy-build.sh
+++ b/easy-build.sh
@@ -11,7 +11,7 @@ show_usage() {
 
 
 # Set configuration file to be used for the build and source it
-export CF=CONF.sh
+export CF=./CONF.sh
 . $CF
 export DEBIAN_CD_CONF_SOURCED=true
 unset UPDATE_LOCAL

-- 
Ian Campbell
Current Noise: Black Label Society - Bleed For Me

First law of debate:
Never argue with a fool.  People might not know the difference.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 13:45 +0100, Ian Campbell wrote:
 On Fri, 2009-08-07 at 13:33 +0100, Ian Campbell wrote:
  
  I just tried it and it looks like the script is already not
  dash-ready:
  $ dash -x ./easy-build.sh -h
  + set -e
  + export CF=CONF.sh
  + . CONF.sh
  .: 1: CONF.sh: not found
 
 I'm no expert but it looks like dash obeys $PATH when executing the ..
 The manpage doesn't mention this behaviour and bash doesn't seem to
 follow it but . is pretty hard to google for so I have looked up the
  haven't

 docs...
 
 $ PATH=.:$PATH ./easy-build.sh -h
 Usage: easy-build.sh [-h] [-d gnome|kde|lxde|xfce|light|all] 
 BC|NETINST|CD|DVD [ARCH ...]
 
 works for me. So does the following I've no idea if this is correct
 analysis though...
 
 --- a/easy-build.sh
 +++ b/easy-build.sh
 @@ -11,7 +11,7 @@ show_usage() {
  
 
  # Set configuration file to be used for the build and source it
 -export CF=CONF.sh
 +export CF=./CONF.sh
  . $CF
  export DEBIAN_CD_CONF_SOURCED=true
  unset UPDATE_LOCAL
 
 -- 
 Ian Campbell
 Current Noise: Black Label Society - Bleed For Me
 
 First law of debate:
   Never argue with a fool.  People might not know the difference.
 
 
-- 
Ian Campbell
Current Noise: Black Label Society - Lords Of Destruction

In Brooklyn, we had such great pennant races, it made the World Series
just something that came later.
-- Walter O'Malley, Dodgers owner


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [PATCH 3/4] Add support for producing disks with (optional) extra variants.

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 16:08 +0200, Frans Pop wrote:
 (No need to CC me on replies.)

Sorry about that.

 On Friday 07 August 2009, Ian Campbell wrote:
   show_usage() {
  -   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] 
  BC|NETINST|CD|DVD [ARCH ...]
  +   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] [-v 
  VARIANTS] BC|NETINST|CD|DVD [ARCH ...] }
 
 This line is getting too long now. Suggest changing it to:
 echo Usage: $(basename $0) [OPTIONS] BC|NETINST|CD|DVD [ARCH ...]
 echo   Options:
 echo  -d gnome|kde|lxde|xfce|light|all : desktop variant (task) to use
 echo  -v variant : ...
 echo  -h help

ACK.
 
  @@ -25,7 +25,8 @@ if [ $# -eq 0 ]; then
   fi
   
   desktop=
  -while getopts d:h OPT ; do
  +VARIANTS=
  +while getopts d:hV: OPT ; do
 
 Why capital V instead of lower case v as shown in usage?

I started with one and changed my mind to use the other. I think I
intended to switch completely to -V in order to leave -v free for the
more common use of verbose if that ever became useful or necessary
(maybe unlikely).

Since fixing up the usage spans multiple patches I'll repost the entire
series with all the feedback so far.

Ian.
-- 
Ian Campbell

Marriage is the waste-paper basket of the emotions.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [PATCH 3/4] Add support for producing disks with (optional) extra variants.

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 16:13 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  This patch just adds the generic support code:
 * CONF.sh:   Add $(VARIANTS) configuration variable.
 * eash-build.sh: Add command line parameter to enable variants.
 * Makefile:  Define VARIANT_xxx when preprocessing package list.
 * boot/?/common.sh:  Add a function for checking if a variant is enabled.
 * generate_di_list:  Allow variant overrides in udeb exclusion list.
 
 It would be nice to have the variants functionality documented a bit,
 especially as it adds syntax extentions in various existing files.

Sure.

 Given the already fragmented state of the documentation, a separate
 document in the docs directory probably makes most sense.

Do I need to html it up and wire it into the existing documents? Looks
like that stuff is very incomplete, a bunch of the links are dead and a
variants chapter doesn't really seem to fit in anywhere in the existing
narrative (such as it is), would a simple standalone text document to
acceptable?

Ian.

-- 
Ian Campbell
Current Noise: Black Label Society - Genocide Junkies

That wouldn't be good enough.
-- Larry Wall in 199710131621.jaa14...@wall.org


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



[PATCH v2 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.

2009-08-07 Thread Ian Campbell
---
 easy-build.sh |   32 +++-
 1 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/easy-build.sh b/easy-build.sh
index a0de9d0..b6ce3be 100755
--- a/easy-build.sh
+++ b/easy-build.sh
@@ -6,7 +6,10 @@ set -e
 ## See also CONF.sh for the meaning of variables used here.
 
 show_usage() {
-   echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] 
BC|NETINST|CD|DVD [ARCH ...]
+   echo Usage: $(basename $0) [OPTIONS] BC|NETINST|CD|DVD [ARCH ...]
+   echo   Options:
+   echo  -d gnome|kde|lxde|xfce|light|all : desktop variant (task) to 
use
+   echo  -h help
 }
 
 
@@ -25,19 +28,30 @@ if [ $# -eq 0 ]; then
 fi
 
 desktop=
-if [ $1 = -d ]; then
-   case $2 in
-   # Note: gnome is the special gnome task, not the generic task
-   gnome|kde|lxde|xfce|light|all)
-   desktop=$2
-   shift 2
+while getopts d:h OPT ; do
+   case $OPT in
+   d)
+   case $OPTARG in
+   # Note: gnome is the special gnome task, not the generic task
+   gnome|kde|lxde|xfce|light|all)
+   desktop=$2
+   ;;
+   *)
+   show_usage
+   exit 1
+   ;;
+   esac ;;
+   h) 
+   show_usage
+   exit 0
;;
-   *)
+   \?)
show_usage
exit 1
;;
esac
-fi
+done
+shift $(($OPTIND - 1))
 
 export DISKTYPE=$1
 shift
-- 
1.6.3.3


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Fix error message from tools/sort_deps

2009-08-07 Thread Ian Campbell
So it's not quite as simple as I thought, this patch just leads to other
error messages later on.

On Fri, 2009-08-07 at 18:09 +0100, Ian Campbell wrote:
 It seems that apt-cache depends recently (as of 0.7.22) started
 including Enhances lines in its output. Leading to:
  Generating dependency tree with apt-cache depends...
 UNEXPECTED: Line `  Enhances: kvm
 ' while parsing end of deptree from 'kvm-source'
 [etc]
 
 Accept these lines gracefully.
 
 --- a/tools/sort_deps
 +++ b/tools/sort_deps
 @@ -308,7 +308,7 @@ sub read_depends {
   my $i = shift; # Ref
   my $lines = shift; # Ref
   my $pkg = shift;   # string
 - my $types = 
 (?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks;
 + my $types = 
 (?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks|Enhances;
   my (@dep, @rec, @sug);
   my ($type, $or, $elt);
  
 
 
-- 
Ian Campbell

Your society will be sought by people of taste and refinement.


signature.asc
Description: This is a digitally signed message part


Fix error message from tools/sort_deps

2009-08-07 Thread Ian Campbell
It seems that apt-cache depends recently (as of 0.7.22) started
including Enhances lines in its output. Leading to:
 Generating dependency tree with apt-cache depends...
UNEXPECTED: Line `  Enhances: kvm
' while parsing end of deptree from 'kvm-source'
[etc]

Accept these lines gracefully.

--- a/tools/sort_deps
+++ b/tools/sort_deps
@@ -308,7 +308,7 @@ sub read_depends {
my $i = shift; # Ref
my $lines = shift; # Ref
my $pkg = shift;   # string
-   my $types = 
(?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks;
+   my $types = 
(?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks|Enhances;
my (@dep, @rec, @sug);
my ($type, $or, $elt);
 


-- 
Ian Campbell

There is no delight the equal of dread.  As long as it is somebody else's.
-- Clive Barker


signature.asc
Description: This is a digitally signed message part


[PATCH v2 4/4] Add a Xen variant on i386 and amd64.

2009-08-07 Thread Ian Campbell
i386 Xen guests require a PAE (686-bigmem) kernel in order to
run. Therefore this variant includes the relevant installer kernel and
ramdisk in install.386/xen as well as suitable kernel udebs and proper
debs for the installed system.

amd64 Xen has no similar requirement but we include the kernels under
install.amd/xen in order to have a consistent path under both
architectures.
---
 data/squeeze/exclude-udebs-i386 |2 +-
 docs/README.variants|7 +++
 tools/boot/squeeze/boot-x86 |6 ++
 tools/generate_di+k_list|8 
 4 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/data/squeeze/exclude-udebs-i386 b/data/squeeze/exclude-udebs-i386
index eeed470..b3af1c9 100644
--- a/data/squeeze/exclude-udebs-i386
+++ b/data/squeeze/exclude-udebs-i386
@@ -29,7 +29,7 @@ usb-serial-modules-*
 usb-storage-modules-*
 zlib-modules-*
 # 686-bigmem kernel udebs are only used for the Xen netboot image
-*-686-bigmem-di
+*-686-bigmem-di !xen
 # Not used on i386
 console-keymaps-acorn
 console-keymaps-amiga
diff --git a/docs/README.variants b/docs/README.variants
index 75499b8..aefeb72 100644
--- a/docs/README.variants
+++ b/docs/README.variants
@@ -12,6 +12,13 @@ option (multiple times if desired) to the easy-build.sh 
script.
 Available Variants
 --
 
+* `xen' [i386, amd64 only]
+
+  This variant includes a kernel and installer initrd which is
+  compatible with the Xen hypervisor in `install.arch/xen' and
+  includes matching kernel module .udebs as well as a suitable kernel
+  .deb for installation into the final system.
+
 Implementation
 --
 
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index 1ab405a..c538967 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -238,6 +238,12 @@ if [ $THISTYPE = isolinux ]; then
fi
rm -f boot$N/isolinux/isolinux.cfg.with*
 
+   if variant_enabled xen ; then
+   extra_image xen/vmlinuz
+   extra_image xen/initrd.gz
+   extra_image xen/xm-debian.cfg
+   fi
+
# Modify win32-loader.ini for the current arch
if [ -e boot$N/win32-loader.ini ]; then
sed -i s|install/|$INSTALLDIR/| boot$N/win32-loader.ini
diff --git a/tools/generate_di+k_list b/tools/generate_di+k_list
index 29e4246..9c2edb0 100755
--- a/tools/generate_di+k_list
+++ b/tools/generate_di+k_list
@@ -124,6 +124,14 @@ atl2-modules-2.6-486
 atl2-modules-2.6-686
 speakup-modules-2.6-486
 speakup-modules-2.6-686
+#ifdef VARIANT_xen
+linux-image-2.6-686-bigmem
+linux-headers-2.6-686-bigmem
+loop-aes-modules-2.6-686-bigmem
+atl2-modules-2.6-686-bigmem
+speakup-modules-2.6-686-bigmem
+#endif
+
 #endif
 
 #ifdef ARCH_amd64
-- 
1.6.3.3


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



[PATCH v2 3/4] Add support for producing disks with (optional) extra variants.

2009-08-07 Thread Ian Campbell
This patch just adds the generic support code:
   * CONF.sh:   Add $(VARIANTS) configuration variable.
   * eash-build.sh: Add command line parameter to enable variants.
   * Makefile:  Define VARIANT_xxx when preprocessing package list.
   * boot/?/common.sh:  Add a function for checking if a variant is enabled.
   * generate_di_list:  Allow variant overrides in udeb exclusion list.

Variant support is documented in docs/README.variants

The intention is to use this support to add support for installing a
Xen guest from an ISO image.

Thanks to Frans Pop for suggesting the approach.
---
 CONF.sh  |3 ++
 Makefile |5 +++-
 docs/README.variants |   60 ++
 easy-build.sh|6 +++-
 tools/boot/squeeze/common.sh |7 +
 tools/generate_di_list   |   18 ++--
 6 files changed, 94 insertions(+), 5 deletions(-)
 create mode 100644 docs/README.variants

diff --git a/CONF.sh b/CONF.sh
index 2cf848a..ae33fed 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -189,6 +189,9 @@ export DISKTYPE=CD
 # included. See tasks/README.tasksel for further info.
 export TASK_LANGLIST=tasksel_d-i.languages
 
+# Extra variants to enable. See docs/README.variants for more information.
+export VARIANTS=
+
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude
 # ...but they are okay for other CDs (UNEXCLUDEx == may be included
diff --git a/Makefile b/Makefile
index 1a9b377..e8f92a7 100755
--- a/Makefile
+++ b/Makefile
@@ -311,9 +311,12 @@ $(BDIR)/rawlist:
ARCHDEFS=$$ARCHDEFS -D ARCH_$(subst -,_,$$ARCH); \
ARCHUNDEFS=$$ARCHUNDEFS -U $$ARCH; \
done; \
+   for VARIANT in $(VARIANTS); do \
+   VARIANTDEFS=$$VARIANTDEFS -D VARIANT_$$VARIANT; \
+   done; \
if [ $(SOURCEONLY)x != yesx ] ; then \
cat $(TASKDIR)/$(TASK) | \
-   cpp -nostdinc -nostdinc++ -P -undef $$ARCHDEFS \
+   cpp -nostdinc -nostdinc++ -P -undef $$ARCHDEFS $$VARIANTDEFS\
$$ARCHUNDEFS -U i386 -U linux -U unix \
-DFORCENONUSONCD1=0 \
-I $(TASKDIR) - -  $(BDIR)/rawlist; \
diff --git a/docs/README.variants b/docs/README.variants
new file mode 100644
index 000..75499b8
--- /dev/null
+++ b/docs/README.variants
@@ -0,0 +1,60 @@
+Introduction
+
+
+Variants enable debian-cd to include extra functionality in a built
+image which is somewhat orthogonal to the usual DISKTYPE and ARCH
+configurations.
+
+Variants are enabled by setting the VARIANTS environment variable to a
+space separated list of the variants to enable or by passing the -V
+option (multiple times if desired) to the easy-build.sh script.
+
+Available Variants
+--
+
+Implementation
+--
+
+Variants impact several aspects of the debian-cd infrastructure:
+
+  environment variable
+  
+
+  The $VARIANTS environment variable is available to any scripts etc
+  which are run as part of the build process and is a space separated
+  list of the variants which are enabled.
+
+  In particular this maybe used by the per-archtecture
+  tools/boot/distro/boot-* scripts which make an image bootable on a
+  particular architecure. To facilitate this
+  tools/boot/distro/common.sh defines a function `variant_enabled'
+  which takes a variant name as an argument and returns true if that
+  variant is enabled.
+
+  deb package lists
+  -
+
+  A variant may wish to include extra .deb packages in the image. The
+  package lists are preprocessed using `cpp' as part of the build
+  process and a C-preprocessor variable `VARIANT_x' will be defined
+  to 1 for each variant which is enabled.
+
+  udeb package lists
+  --
+
+  Similarly a variant may which to include extra .udeb packages in the
+  image. The list of udebs to include in an image is generated using
+  tools/generate_di_list which reads one or more udeb exclude files
+  from data/distribution/*. The syntax of these exclude files allows
+  a udeb to be excluded or included based on which variants are
+  enabled.
+
+  Each line in an exclude file specifies a glob pattern, a udeb whose
+  name matches the glob will _not_ be included in the image. After the
+  udeb glob each line can optionally contain on or more space
+  separated conditions. At least one of these conditions must be met
+  in order to exclude the udeb. A condition may either be:
+ - a positive `variant' condition, in which case the udeb is
+   excluded when that variant is enabled
+ - a negative `!variant' condition, in which case the udeb is
+   excluded when that variant is not enabled.
diff --git a/easy-build.sh b/easy-build.sh
index b6ce3be..ce9a078 100755
--- a/easy-build.sh
+++ b/easy-build.sh
@@ -9,6 +9,7 @@ show_usage() {
echo Usage: $(basename $0) [OPTIONS] 

Re: Fix error message from tools/sort_deps

2009-08-07 Thread Ian Campbell
I see now, I think it should be:

--- 
It seems that apt-cache depends recently (as of 0.7.22) started
including Enhances lines in its output. Leading to:

 Generating dependency tree with apt-cache depends...
UNEXPECTED: Line `  Enhances: kvm
' while parsing end of deptree from 'kvm-source'
[etc]

Ignore these lines.
---
 tools/sort_deps |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/sort_deps b/tools/sort_deps
index e40073c..1946c43 100755
--- a/tools/sort_deps
+++ b/tools/sort_deps
@@ -308,7 +309,7 @@ sub read_depends {
my $i = shift; # Ref
my $lines = shift; # Ref
my $pkg = shift;   # string
-   my $types = 
(?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks;
+   my $types = 
(?:Pre)?Depends|Suggests|Recommends|Replaces|Conflicts|Breaks|Enhances;
my (@dep, @rec, @sug);
my ($type, $or, $elt);
 
@@ -317,7 +318,8 @@ sub read_depends {
# Get rid of replaces and conflicts ...
if (($type eq Replaces) or
($type eq Conflicts) or
-   ($type eq Breaks)) {
+   ($type eq Breaks) or
+   ($type eq Enhances)) {
$$i++;
while ($lines-[$$i] =~ m/^\s{4}/) {
$$i++;
-- 
1.6.3.3


-- 
Ian Campbell

It's hard to be humble when you're perfect.


signature.asc
Description: This is a digitally signed message part


Re: Fix error message from tools/sort_deps

2009-08-07 Thread Ian Campbell
On Fri, 2009-08-07 at 19:41 +0200, Frans Pop wrote:
 On Friday 07 August 2009, Ian Campbell wrote:
  So it's not quite as simple as I thought, this patch just leads to
  other error messages later on.
 
 Suggest you compare commit r1911 which did the same for Breaks.

Thanks, that's basically what I ended up with in my follow up patch.

Ian.

-- 
Ian Campbell

QOTD:
Don't let your mind wander -- it's too little to be let out alone.


signature.asc
Description: This is a digitally signed message part


  1   2   >