Re: Bug#978729: ERROR build/debian-cd: E: The value 'unstable' is invalid for APT::Default-Release as such a release is not available in the sources when building buster image
Control: reassign 978729 debian-cd On 2020-12-31, Daniel Leidert wrote: > I'm trying to build a custom Buster image. The host system is a Debian > Sid/unstable. When I run the build right after "make image-tree" is invoked in > /usr/share/simple-cdd/tools/build/debian-cd > > ERROR build/debian-cd: E: The value 'unstable' is invalid for > APT::Default-Release as such a release is not available in the sources when > building buster image > > because my local apt.conf has the default value set to 'unstable'. But my > local > APT configuration IMHO shouldn't be of any concern to simple-cdd or debian-cd. > So I have to edit this file to make it work. Maybe it should create a > temporary > apt.conf setting APT::Default-Release to the value used for the --dist switch? Reassigning to debian-cd, as simple-cdd is just calling debian-cd's "make image-tree". It might be possible for simple-cdd to workaround this or provide hooks to workaround it, but seems better to have debian-cd not depend on local apt configuration... live well, vagrant signature.asc Description: PGP signature
Bug#896638: debian-cd: Unable to build CD image with unsigned repository
Package: debian-cd
Severity: normal
Tags: patch
Control: block 879642 by -1
With recent changes to apt requiring signed repositories, simple-cdd is
unable to build an image, as it dynamically generates an unsigned apt
repository.
A patch below adds an option to apt to allow insecure repositories when
ARCHIVE_UNSIGNED=1. An alternate approach would be to add [trusted=yes]
on each of the sources.list entries.
I'm fairly sure this won't impact other parts of the build process, but
not 100% sure.
live well,
vagrant
commit 9bbd627c7ff5abe006a3596d5d8a2cd8e24758ba
Author: Vagrant Cascadian <vagr...@debian.org>
Date: Sun Apr 22 13:28:14 2018 -0700
Add boolean variable ARCHIVE_UNSIGNED, which configures apt to allow
insecure repositories.
In general, use of this option should be avoided, but is useful when
using a custom dynamically generated local repository, where a signed
repository wouldn't necessarily add much in the way of security.
diff --git a/tools/apt-selection b/tools/apt-selection
index 209e0c5..274e546 100755
--- a/tools/apt-selection
+++ b/tools/apt-selection
@@ -44,6 +44,10 @@ options=" -q -o
Dir::State::status=$APTTMP/$THIS_PKGSET/status \
-o APT::Architectures::=$ARCH \
-o Acquire::Languages=none"
+if [ "$ARCHIVE_UNSIGNED"x = "1"x ]; then
+options="$options -o Acquire::AllowInsecureRepositories=true"
+fi
+
sections=main
if [ "${NONFREE:-0}" != "0" ] || [ "${EXTRANONFREE:-0}" != "0" ] || [
"${FORCE_FIRMWARE:-0}" != "0" ]; then
sections="$sections non-free"
signature.asc
Description: PGP signature
Bug#884552: debian-cd: Support KERNEL_PARAMS in arm64
Package: debian-cd Version: 3.1.20 Severity: normal Tags: patch Currently, debian-cd does not modify the grub.cfg to include KERNEL_PARAMS on arm64. On x86, it works because it derives the grub entries from isolinux configuration files, which do support KERNEL_PARAMS. The following patch adds support for this for stretch and buster on arm64. diff --git a/tools/boot/buster/boot-arm64 b/tools/boot/buster/boot-arm64 index f7cbe42..d00b5f2 100755 --- a/tools/boot/buster/boot-arm64 +++ b/tools/boot/buster/boot-arm64 @@ -155,6 +155,9 @@ if [ -d boot$N/grub ] ; then # in case they're still there sed -i "s,\%install\%,$INSTALLDIR,g" $CDDIR/boot/grub/grub.cfg +# Substitute custom KERNEL_PARAMS into grub.cfg +sed -i "s,/vmlinuz ,/vmlinuz $KERNEL_PARAMS ,g" $CDDIR/boot/grub/grub.cfg + else echo " No EFI boot code for $ARCH on CD$N" fi diff --git a/tools/boot/stretch/boot-arm64 b/tools/boot/stretch/boot-arm64 index f7cbe42..d00b5f2 100755 --- a/tools/boot/stretch/boot-arm64 +++ b/tools/boot/stretch/boot-arm64 @@ -155,6 +155,9 @@ if [ -d boot$N/grub ] ; then # in case they're still there sed -i "s,\%install\%,$INSTALLDIR,g" $CDDIR/boot/grub/grub.cfg +# Substitute custom KERNEL_PARAMS into grub.cfg +sed -i "s,/vmlinuz ,/vmlinuz $KERNEL_PARAMS ,g" $CDDIR/boot/grub/grub.cfg + else echo " No EFI boot code for $ARCH on CD$N" fi live well, vagrant signature.asc Description: PGP signature
Bug#861436: debian-cd: Should recommend wget, used when using DI_WWW_HOME.
Package: debian-cd
Version: 3.1.19
Severity: normal
Tags: patch
When DI_WWW_HOME is set, debian-cd uses wget to download the installer
images. Since not everyoone will use DI_WWW_HOME, adding wget to
recommends seems appropriate.
diff --git a/debian/control b/debian/control
index a05cc66..81c82e6 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Browser:
http://anonscm.debian.org/git/debian-cd/debian-cd.git;a=summary
Package: debian-cd
Architecture: all
Depends: ${misc:Depends}, curl, perl, dpkg-dev, cpp, libdigest-md5-perl,
libdigest-sha-perl, tofrodos, apt (>= 0.3.11.1), make, xorriso | genisoimage,
lynx-cur | lynx, grep-dctrl, bc, libcompress-zlib-perl, bzip2, libdpkg-perl
-Recommends: hfsutils, netpbm, isolinux, syslinux-common, syslinux-utils,
mtools, dosfstools, syslinux-utils
+Recommends: hfsutils, netpbm, isolinux, syslinux-common, syslinux-utils,
mtools, dosfstools, syslinux-utils, wget
Description: Tools for building (Official) Debian CD set
Debian-cd is the official tool for building Debian CD set since the potato
release. It was formerly called YACS (for Yet Another CD Script).
live well,
vagrant
signature.asc
Description: PGP signature
Re: Bug#839946: Can't use global $_ in "my" at $root_dir/tmp/debian-cd/tools/make_disc_trees.pl
Control: reassign 839946 debian-cd Control: affects 839946 simple-cdd On 2016-10-06, Braiam Peguero wrote: > Building a cd on testing/sid without setting any option > results in: > > 2016-10-06 13:15:49,570 DEBUG build/debian-cd stdout: Get:1 > file:$root_dir/tmp/mirror sid InRelease ... > 2016-10-06 13:15:49,621 DEBUG build/debian-cd stdout: Reading package lists... > 2016-10-06 13:15:49,621 DEBUG build/debian-cd stderr: W: The repository > 'file:$root_dir/tmp/mirror sid Release' is not signed. > 2016-10-06 13:15:49,621 DEBUG build/debian-cd stderr: W: Target Contents-deb- > legacy (Contents-amd64) is configured multiple times in $root_dir/tmp/cd- > build/apt/sid-amd64/apt/sources.list:1 and $root_dir/tmp/cd-build/apt/sid- > amd64/apt/sources.list:2 ... > 2016-10-06 13:15:51,586 DEBUG build/debian-cd stderr: Can't use global $_ in > "my" at $root_dir/tmp/debian-cd/tools/make_disc_trees.pl line 1230, near "my > $_ > " > 2016-10-06 13:15:51,586 DEBUG build/debian-cd stderr: Execution of > $root_dir/tmp/debian-cd/tools/make_disc_trees.pl aborted due to compilation > errors. > 2016-10-06 13:15:51,587 DEBUG build/debian-cd stdout: Makefile:410: recipe for > target 'image-trees' failed > 2016-10-06 13:15:51,587 DEBUG build/debian-cd stderr: make: *** [image-trees] > Error 255 This appears to be fixed in debian-cd git as of a few days ago: https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/commit/?id=ae59c4e92b7f1b8303908cc81497514d40f2de8c Since simple-cdd is just using debian-cd, and debian-cd fixes the issue, I've reassigned the bug to debian-cd. live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On 2015-01-07, Ian Campbell wrote: 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: 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? Yes, the hd-media images still need an .iso file on some other media, such as USB, SATA or an additional SD card. 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. 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... live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On 2015-01-05, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-01-02): 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. Given discussions on this patchset are still going on, I've decided to stop waiting on it, and to upload d-i without it. Not to delay a new d-i version, but I'm wondering if it makes sense to decouple some of the parts of the patchset into a smaller patchset at this point, such as the netboot/tftpboot support with u-boot only sd images? Maybe concatenateable images? Some of these features seem only somewhat related, and it would be nice to get the uncontested bits out of the way. live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
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.
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.
Thats really helpful, thanks!
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 don't think so, as netboot/hd-media are different images entirely. I
guess you could conceptually make one image with both initrds, and you
could use the menu support to select between the initrds... not sure if
that's worth doing at the moment.
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.
Seems reasonable. I'll add it to the increasing list of features I want
to get into u-boot for Jessie+1...
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).
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? :)
live well,
vagrant
signature.asc
Description: PGP signature
Re: [PATCH V3 4/6] Add SD-card image build support for hd-media builds on armhf
On 2015-01-01, Karsten Merker wrote: +++ b/build/boot/README.concatenateable_images ... +To create a complete image from the two parts on Linux systems, you can +use zcat (for .gz images), bzcat (for .bz2 images) or xzcat (for .xz +images) as follows: + + zcat firmware.board_name.img.gz partition.img.gz complete_image.img + +respectively + + bzcat firmware.board_name.img.bz2 partition.img.bz2 complete_image.img + +respectively + + xzcat firmware.board_name.img.xz partition.img.xz complete_image.img I'm wondering if one example would be sufficiently explanatory? I'd suggest changing as follows: to for example: and removing the bzcat/xzcat examples. --- a/build/config/armhf/hd-media.cfg +++ b/build/config/armhf/hd-media.cfg ... +.PHONY: hd-media_images_full +hd-media_images_full: $(KERNEL) $(INITRD) $(TEMP_DTBS) hd-media_bootscript + -rm -rf $(TEMP)/hd-media_images_full + mkdir $(TEMP)/hd-media_images_full ... +.PHONY: hd-media_images_concatenateable +hd-media_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS) hd-media_bootscript + -rm -rf $(TEMP)/hd-media_images_concatenateable + mkdir $(TEMP)/hd-media_images_concatenateable The hd-media_images_full and hd-media_images_concatenateable targets are very similar. Would it make sense to always build the concatenateable images, and then have the hd-media_images_full target generate it's images by simply concatenating the results of the hd-media_images_concatenateable target? That would reduce some code duplication; are there any drawbacks or significant differences in the resulting images? live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On 2014-12-30, Ian Campbell wrote:
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...
Thanks for taking the time.
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).
I overall like the idea, all the parts (kernel, initrd, dtb) are already
shipped in d-i, and those that aren't (u-boot) are easy to depend
on. The bootscripts could still go into d-i, or this image generation
utility itself...
I would also hope that these images get shipped through some official
channel(like the .iso files produced by debian-cd), in a format that's
easy for the end-user to install, though. Not sure what it takes to make
that happen.
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.
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.
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...
I also think more systems support booting boot scripts than u-boot's
PXE emulation at this point.
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:
* u-boot only for each supported platform
* hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
each platform
* hd-media concatenateable with kernel + initrd + dtbs + bootscript
* netboot full with u-boot + kernel + initrd + dtbs + bootscript for
each platform (like mini.iso)
* netboot concatenateable with kernel + initrd + dtbs + bootscript
* netboot boot script for use with TFTP
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 attached to it all happening inside of debian-installer, just
hope that whatever's done makes it easy for the users to install debian
on some of these newish accessible low-power platforms...
live well,
vagrant
signature.asc
Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On 2014-12-26, Karsten Merker wrote:
On Tue, Dec 23, 2014 at 02:17:16PM -0800, Vagrant Cascadian wrote:
On 2014-12-23, Karsten Merker wrote:
I don't think it's possible yet to have the device-independent parts
working with *all* platforms (at least for Jessie), but we can get close
with a few relatively simple workarounds:
Some of the issues with bootscr.mainline_common are inconsistancies
across platforms with the u-boot console settings (particularly the baud
rate not being appended)
...
I do not know what the default environment on those platforms
looks like, but assuming that they define the fdtfile environment
variable, how about adding stanzas like
if test ${fdtfile} = am335x-boneblack.dtb ; then
(set the necessary environment variables)
fi
to bootscr.mainline_common for those special cases?
For the default serial console, yes, this could work (at least for
imx6q-wandboard.dtb and imx6q-cubox-i.dtb). For setting the framebuffer
or other console, it would still probably require manually (or through
uEnv.txt) setting the console variable.
It would get increasingly more complicated the more boards get supported
over time, but at the moment we're looking at only a handful of boards.
Alternately, could also check for specific values of console/baudrate,
which could support broader classes of systems:
# wandboard, cubox-i and possibly other imx systems may need to append
# the baud rate.
if test ${console} = ttymxc0 test -n ${baudrate} ; then
setenv console=${console},${baudrate}
fi
This way, if the user has manually configured the console value somehow
(such as console=tty0 for framebuffer), it doesn't blindly overwrite it
just because it detects a certain ${fdtfile}.
That doesn't address the conditionals that the BeagleBone Black would
need, which could potentially boot off of eMMC or an inserted SD card,
and thus ${devnum} and related variables would need to be set
conditionally...
I had planned on patching u-boot to emulate the config_distro_bootcmd
for BeagleBone Black (like with wandboard/cubox-i), but was unable to
resolve incompatible uses of ${bootpart}.
Regarding uEnv.txt: is that file automatically read by the
default environment of those platforms before executing boot.scr,
or does boot.scr have to explicitly source uEnv.txt?
The BeagleBone Black, Wandboard* and CuBox-i systems should all load
uEnv.txt before the bootscript, at least with the u-boot in Debian. I've
added some patches for uEnv.txt support and changed the order on some of
those to make sure that they worked more-or-less consistantly.
I tried getting uEnv.txt support into mainline u-boot's
config_distro_bootcmd.h, but didn't get much favorable feedback about
that:
http://lists.denx.de/pipermail/u-boot/2014-October/190843.html
Though I do think it's generally useful to be able to make generic
images and tweak them with a few uEnv.txt variables to set things that
are not detectable.
The netboot images here seem more like the mini.iso netboot images on
x86, though I've tested several armhf installs with the boot.scr,
kernel, initrd, dtb all downloaded via TFTP (more like the pxe boot
images on x86).
...
I have added support for building a netboot.tar.gz similar to the
i386/amd64 PXE one in V2 of the patchset.
Excellent!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#767223: Dont append kernel params for isolinux/deskop filesin Jessie
Control: forcemerge 766411 767223 On 2014-10-29, Prema wrote: Current Debian installer removed desktop folder under isolinux and merged it to head. But the debian-cd still searches for the desktop/*cfg files under isolinux folder. The attached patch removes the search of desktop folder under Jessie. Reported this a few days ago, and came up with the same patch. :) live well, vagrant pgpnemzFiz0in.pgp Description: PGP signature
Bug#766411: debian-cd: can't read boot1/isolinux/desktop/*.cfg
Package: debian-cd Version: 3.1.15 Severity: important Tags: patch When building a Jessie image with debian-cd (admittedly by way of simple-cdd), I get: 'boot1/isolinux/win32-loader.ini' - 'boot1/win32-loader.ini' gtk/vmlinuz identical to ../vmlinuz. Linking sed: can't read boot1/isolinux/desktop/*.cfg: No such file or directory FAILED: error 2 Failed to start disc 1, error 512 Makefile:406: recipe for target 'image-trees' failed make: *** [image-trees] Error 2 It appears to be partially fixed in git: b494adcb039ec2f9d2787a3e76cd68366a493400 adapt desktop handling for tasksel/d-i changes But simple-cdd makes use of KERNEL_PARAMS, and triggers the issue in another place: diff --git a/tools/boot/jessie/boot-x86 b/tools/boot/jessie/boot-x86 index e42dee0..bc549ac 100644 --- a/tools/boot/jessie/boot-x86 +++ b/tools/boot/jessie/boot-x86 @@ -364,7 +364,7 @@ sed -i s|built on|built $BUILD_DATE; d-i| boot$N/isolinux/f1.txt if [ -n $KERNEL_PARAMS ]; then # Substitute custom kernel params into the isolinux config file(s) - for file in boot$N/isolinux/*.cfg boot$N/isolinux/desktop/*.cfg; do + for file in boot$N/isolinux/*.cfg ; do case $(basename $file) in instsel.cfg) continue ;; With that applied to git, it works for me... live well, vagrant -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (120, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debian-cd depends on: ii apt1.0.9.3 ii bc 1.06.95-9 ii bzip2 1.0.6-7 ii cpp4:4.9.1-1 ii curl 7.38.0-2 ii dctrl-tools [grep-dctrl] 2.23 ii dpkg-dev 1.17.13 ii genisoimage9:1.1.11-3 pn libcompress-zlib-perl none pn libdigest-md5-perl none ii libdpkg-perl 1.17.13 ii lynx-cur 2.8.9dev1-2 ii make 4.0-8 ii perl [libdigest-sha-perl] 5.20.1-1 ii tofrodos 1.7.13+ds-1 ii xorriso1.3.2-1.1 Versions of packages debian-cd recommends: ii dosfstools 3.0.26-4 ii hfsutils 3.2.6-13 pn isolinux none ii mtools 4.0.18-2 ii netpbm 2:10.0-15.1+b1 ii syslinux-common 3:6.03+dfsg-1 debian-cd suggests no packages. -- no debconf information pgpZuqOdEzB0n.pgp Description: PGP signature
Bug#752180: debian-cd: doesn't work on multiarch enabled system
On Fri, Jun 20, 2014 at 05:58:17PM +0200, Raphaël Hertzog wrote: Package: debian-cd Version: 3.1.15 Severity: important ... The problem is clearly related to multi-arch since the conflicts mention i386 packages while I was trying to build amd64 ISO on a amd64 system. The underlying problem is that apt automaticallys includes foreign architecture when dpkg --print-foreign-architectures returns something. The APT invocations made by debian-cd should include the required parameter to avoid this: apt-cache -o APT::Architectures::=$ARCH Are you sure you tested this with 3.1.15? I had the same issue with older versions, but 3.1.15 included exactly the fix you proposed... live well, vagrant signature.asc Description: Digital signature
Bug#752133: debian-cd: Use cpu autodetection by default on amd64-i386 CDs
Package: debian-cd Version: 3.1.15 Severity: wishlist With a multi-arch CD containing both amd64 and i386, the default boot menu entry appears to install 32 bit, and the user has to explicitly select the 64 bit installation option. Unless you first go to the help menu, and then hit ENTER to boot:... Then it autodetects weather you're running amd64 or i386, and runs the appropriate one. So most of the code is already there... Wouldn't it make more sense to default to autodetection, and allow the user to select 32 or 64 bit explicitly (maye even hidden away in an Advanced sub-menu)? Is there concern that autodetection might fail too often to be worth it? I've seen hundreds of computers per year work just fine of a fairly random distribution in hardware at a computer recycling facility, and I cannot recall ifcpu64 failing me even once... that said it was mostly 3-7 year old hardware. I could dig a little deeper and possibly write a patch, if there wasn't opposition to the general idea... Thanks for maintaining debian-cd! live well, vagrant signature.asc Description: Digital signature
Bug#751814: debian-cd: wrong date in changelog for 3.1.15
Package: debian-cd Version: 3.1.15 Severity: minor I was a bit confused to find the date listed for the 3.1.15 entry in debian/changelog, when I was looking for a rough idea what timeframe an issue was fixed... -- Steve McIntyre 93...@debian.org Tue, 11 Feb 2014 01:57:01 + But it appears to not have been uploaded to the archive until 2014-06-03, and contains commits from the same day. So, while this may seem like a really minor issue, it can get a bit confusing when I know X was broken last week, but the changelog lists it has having been fixed in an upload *months* ago..., which can then lead to time wasted searching for bugs in other packages. I think it would be worth updating the changelog line for 3.1.15 in a future upload to be closer to when it really was uploaded, apparently 2014-06-03. Thanks for developing and maintaining debian-cd! live well, vagrant signature.asc Description: Digital signature
Bug#569632: debian-cd: broken isolinux configuration
Package: debian-cd Version: 3.1.2 Severity: important when generating a squeeze CD, the isolinux configuration still contains templates so that the boot prompt line contains things such as: /%install%/vmlinuz ... desktop=%desktop% ... initrd=/%install%/initrd.gz ... with the debian-cd version in svn, this works fine. please consider uploading a new version of debian-cd to the archive. thanks! live well, vagrant -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: build a CD from varous repositories
On Sat, Nov 07, 2009 at 02:25:10PM +0100, Geronimo Ma. Hernandez wrote: Hello and thank you for your support. Try 'debmirror' (or one of the similar packages). I already used your script (mirror-sync) which wrappes debmirror. The point is, that (from my understanding) debmirror only works with blacklists (--exclude). ... and so far, I don't know, what I should exclude. you could try simple-cdd: http://wiki.debian.org/Simple-CDD it generates a partial mirror based on what packages you're interested in, and uses debian-cd to generate a CD image based with those packages. it has some support for multiple repositories, and there are some tricks for adding custom packages as well. live well, vagrant -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
SPLASHPNG broken? (was Re: simple-cdd 0.3.10 splash)
On Thu, May 21, 2009 at 12:52:22AM +0200, Jordi Soucheiron wrote: I'm using a profile which has a export SPLASHPNG line in it. In previous versions it worked fine, but for some reason it's not working anymore. I've been reading simple-cdd and debian-cd scripts and I think that the problem may be that debian-cd unsets the variable, but I'm not sure. looks like you found a bug in debian-cd. it seems like the new isolinux menus debian-cd generates use splash.png directly, instead of the file that the SPLASHPNG code generates(splash.rle). this patch to debian-cd seemed to sort of fix it for me: --- tools/boot/lenny/boot-x86 (revision 1916) +++ tools/boot/lenny/boot-x86 (working copy) @@ -303,6 +303,7 @@ # Insert our own splash screen. Color index 0 is # background, and index 7 is foreground. Set to black and # white respecively + cp $SPLASHPNG boot$N/isolinux/splash.png pngtopnm $SPLASHPNG | ppmquant 16 | \ ppmtolss16 #ff=7 #00=0 boot$N/isolinux/splash.rle fi other tools/boot/*/boot-* probably also need to be modified similarly. I've tryed to modify the debian-cd inside the tmp directory, but it's useless because simple-cdd rsyncs the image with the one in /usr/share. I could try to modify the debian-cd scripts of /usr/share, but I rather modify the iso (it's faster and safer). Any ideas? for that, simply make a copy of the debian-cd directory: cp -a /usr/share/debian-cd /home/USER/my-debian-cd and add a line to profiles/default.conf: debian_cd_dir=/home/USER/my-debian-cd and modify /home/USER/my-debian-cd as needed. live well, vagrant 2009/5/21 Vagrant Cascadian vagr...@freegeek.org: On Wed, May 13, 2009 at 03:56:50PM +0200, Jordi Soucheiron wrote: It seems that the last versions of simplecdd don't allow me to specify a custom splash image. I've been able to solve it editing the iso with isomaster, but I'd like to use the .conf file like before. Does anybody know how to fix this? there's no special code in simple-cdd to handle this; it just uses debian-cd's SPLASHPNG variable, which needs to be exported, for example: in profiles/SOMEPROFILE.conf: export SPLASHPNG=$simple_cdd_dir/someimage.png where someimage.png is a file in your simple-cdd working dir. also note: it seems like debian-custom redirects to the blends list now... should probably start using simple-...@packages.debian.org until i manage to register a new list specifically for simple-cdd. live well, vagrant -- Jordi Soucheiron Software Engineer DEXMA Parc Tecnològic la Salle Sant Joan de la Salle, 42 08022 Barcelona t/f: [+34] 93 181 01 95 www.dexmatech.com jsouchei...@dexmatech.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: partial fix for ISOLINUX_DEFAULT
On Sat, Jan 03, 2009 at 07:41:10PM +0100, Frans Pop wrote: On Thursday 25 December 2008, Vagrant Cascadian wrote: looking at debian-cd svn, i noticed that there was a FIXME for supporting ISOLINUX_DEFAULT. this very imperfect patch at the very least gets installgui working with the menus, to make Graphical Install the default menu selection, although it relies on text.cfg getting loaded before gtk.cfg: I'm not really happy with this patch. 1) It's actual function seems extremely limited. Effectively it only moves the default selection one line down. 2) It does not really support multi-arch nor multi-desktop CD/DVDs. 3) It only works because I expect isolinux will use the last 'default' statement it encounters, but having two default statements in a config seems rather ugly to me. here's a patch that seems to addresses 2 (at least for i386+amd64) and 3. i might be able to look into adding support for other architectures and using a more generic variable name (GRAPHICAL_DEFAULT? GUI_DEFAULT?), but i don't have the hardware to really test other arches. live well, vagrant Index: tools/boot/lenny/boot-x86 === --- tools/boot/lenny/boot-x86 (revision 1849) +++ tools/boot/lenny/boot-x86 (working copy) @@ -237,8 +239,23 @@ # FIXME - this is broken for the current setup which no longer # has a 'default' statement in isolinux.cfg if [ -n $ISOLINUX_DEFAULT ]; then - sed -i s/^DEFAULT .*$/DEFAULT $ISOLINUX_DEFAULT/ \ - boot$N/isolinux/isolinux.cfg + case $ISOLINUX_DEFAULT in + gtk) + for txtcfg in $(ls boot$N/isolinux/txt.cfg boot$N/isolinux/amdtxt.cfg boot$N/isolinux/*/*txtdt.cfg) ; do + sed -i -e 's,menu default.*,,g' $txtcfg + done + for gtkcfg in $(ls boot$N/isolinux/gtk.cfg boot$N/isolinux/amdgtk.cfg boot$N/isolinux/*/*gtkdt.cfg) ; do + case $(basename $gtkcfg) in + amd*) + echo menu default64 $gtkcfg + ;; + *) + echo menu default $gtkcfg + ;; + esac + done + ;; + esac fi if [ -z $MULTIARCH ]; then -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: partial fix for ISOLINUX_DEFAULT
On Sat, Jan 03, 2009 at 07:41:10PM +0100, Frans Pop wrote: On Thursday 25 December 2008, Vagrant Cascadian wrote: looking at debian-cd svn, i noticed that there was a FIXME for supporting ISOLINUX_DEFAULT. this very imperfect patch at the very least gets installgui working with the menus, to make Graphical Install the default menu selection, although it relies on text.cfg getting loaded before gtk.cfg: I'm not really happy with this patch. not surprising, really. i'm not much happy with it myself. thanks for looking it over. :) 1) It's actual function seems extremely limited. Effectively it only moves the default selection one line down. yes. pretty much. allows a person to hit enter to get a graphical installer, rather than having to think about which option to choose. 2) It does not really support multi-arch nor multi-desktop CD/DVDs. 3) It only works because I expect isolinux will use the last 'default' statement it encounters, but having two default statements in a config seems rather ugly to me. agreed. would it be any better if it removed the default entries from other configs? i haven't looked into it, but i'm guessing debian-installer is what generates the isolinux configuration files? it might be better to re-work those a little to make it easier to configure the default menu, as the current isolinux configuration is a little difficult to customize. the other idea i had was some way to change the order of config files, so that the graphical installer would come up first. would still require a way to remove the menu default entry from other options. or if syslinux could be patched to allow a menu default $FOO outside of a particular section... 4) It is indeed only a very partial fix. What exactly is the use case this is trying to cover? Unless it is very persuasive I'd be inclined to remove this altogether... in etch there was a way to make it default to the graphical installer. it doesn't seem unreasonable to want to make that the default behavior on a custom CD. now that there's a menu by default, it's easier to select the graphical installer, so maybe it's not as big of a deal to remove support for it. i'm also curious if there is there a planned timeline to upload debian-cd to unstable soon? We've just implemented the recent changes for daily/weekly builds and everything seems to work. So I guess we could do a release. good to hear. That would allow you to also update simple-cdd. ah, it seems you read my mind. :) live well, vagrant -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
partial fix for ISOLINUX_DEFAULT
looking at debian-cd svn, i noticed that there was a FIXME for supporting ISOLINUX_DEFAULT. this very imperfect patch at the very least gets installgui working with the menus, to make Graphical Install the default menu selection, although it relies on text.cfg getting loaded before gtk.cfg: Index: tools/boot/lenny/boot-x86 === --- tools/boot/lenny/boot-x86 (revision 1828) +++ tools/boot/lenny/boot-x86 (working copy) @@ -237,8 +237,9 @@ # FIXME - this is broken for the current setup which no longer # has a 'default' statement in isolinux.cfg if [ -n $ISOLINUX_DEFAULT ]; then - sed -i s/^DEFAULT .*$/DEFAULT $ISOLINUX_DEFAULT/ \ - boot$N/isolinux/isolinux.cfg + case $ISOLINUX_DEFAULT in + installgui) echo menu default boot$N/isolinux/gtk.cfg ;; + esac fi if [ -z $MULTIARCH ]; then i'm also curious if there is there a planned timeline to upload debian-cd to unstable soon? live well, vagrant -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
debconf8 bof: building debian from debian
i was asked to find out if folks from various projects would be interested in a proposed bof for debconf8. please let me know if you are interested and would be able to attend. Building Debian from Debian discussion of the miscelany of tools that build debian installations Many tools all essentially install Debian, in some capacity, form or fashion. This would be a discussion of the various tools in Debian used to install Debian chroots, virtual servers, physical hardware, etc. and what common issues and workarounds are currently needed, with an eye towards developing more common code to share between projects. people interested in the following tools or similar tools would be valuable to the discussion: debian-installer debian-cd simple-cdd debian-live xen-tools util-vserver pbuilder cdebootstrap debootstrap LTSP FAI thanks! live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416230: debian-cd: support KERNEL_PARAMS for powerpc, alpha and sparc
Package: debian-cd
Version: 3.0.1
Severity: wishlist
Tags: patch
i make use of the KERNEL_PARAMS variable when creating custom
debian-installer CDs, but after trying to build a powerpc image, noticed
that it is only supported on i386 and amd64... why should other
architectures miss out on the fun?
please consider the attached patch (untested) to add support for
KERNEL_PARAMS to powerpc, alpha and sparc.
not sure how the other arches work to even try...
live well,
vagrant
Index: tools/boot/etch/boot-powerpc
===
--- tools/boot/etch/boot-powerpc (revision 1386)
+++ tools/boot/etch/boot-powerpc (working copy)
@@ -75,6 +75,9 @@
boot.msg
cat $BASEDIR/data/$DI_CODENAME/yaboot/yaboot.conf \
| sed s/CODENAME/${CODENAME}/g yaboot.conf
+if [ -n $KERNEL_PARAMS ]; then
+sed -ie s|append=\|append=\$KERNEL_PARAMS |g yaboot.conf
+fi
cp $BASEDIR/data/$DI_CODENAME/yaboot/ofboot.b ofboot.b
for subarch in powerpc powerpc64 prep
@@ -123,5 +126,8 @@
cp $BASEDIR/data/$DI_CODENAME/chrp/bootinfo.txt ppc
mkdir etc
cp $INSTALLDIR/yaboot.conf etc
+if [ -n $KERNEL_PARAMS ]; then
+sed -ie s|append=\|append=\$KERNEL_PARAMS |g etc/yaboot.conf
+fi
exit 0
Index: tools/boot/etch/boot-alpha
===
--- tools/boot/etch/boot-alpha (revision 1386)
+++ tools/boot/etch/boot-alpha (working copy)
@@ -80,9 +80,9 @@
RSIZE=$(expr $(zcat boot$N/boot/initrd.gz | wc --bytes) / 1024)
OPTS=ramdisk_size=$RSIZE initrd=/boot/initrd.gz root=/dev/ram devfs=mount,dall
-echo 0:boot/vmlinuz $OPTS boot$N/etc/aboot.conf
-echo 1:boot/vmlinuz $OPTS console=ttyS0 boot$N/etc/aboot.conf
-echo 2:boot/vmlinuz $OPTS console=ttyS1 boot$N/etc/aboot.conf
+echo 0:boot/vmlinuz $OPTS $KERNEL_PARAMS boot$N/etc/aboot.conf
+echo 1:boot/vmlinuz $OPTS console=ttyS0 $KERNEL_PARAMS boot$N/etc/aboot.conf
+echo 2:boot/vmlinuz $OPTS console=ttyS1 $KERNEL_PARAMS boot$N/etc/aboot.conf
mkdir -p boot$N/milo
Index: tools/boot/etch/boot-sparc
===
--- tools/boot/etch/boot-sparc (revision 1386)
+++ tools/boot/etch/boot-sparc (working copy)
@@ -46,6 +46,9 @@
# Some custom etc files
cp -f -p $BASEDIR/data/etch/sparc/silo.conf $inst/boot/
+if [ -n $KERNEL_PARAMS ]; then
+sed -ie s|append=\|append=\$KERNEL_PARAMS |g $inst/boot/silo.conf
+fi
cat $BASEDIR/data/etch/sparc/debian.txt \
| sed s/\${MEDIA_TYPE}/CDROM/ \
| sed s/\${DEBIAN_VERSION}/${CODENAME}/g \
