CD creation fails with "disk full", because of rounding errors.
The minimum size of data-allocation is a 'cluster', which is a
power-of-two multiple of sectors.
mkfs.msdos chooses minimum FAT and cluster size for image: FAT12<16G
mkfs.msdos uses block-count where a block is 1024 B, but must be rounded
up to track_size with 32 sectors.
Round up each file to clusters before summing.
A sub-directory entry needs 1 cluster minimum.
Previous changes enabled gzip compressed Linux kernels, but not 100%
sure that it works on all systems. Disable this compression for now.
Switch hppa to use xorriso by default instead of mkisofs. Xorriso
supports kernel command lines to be up to 1023 bytes, better than
mkisofs. mkisofs only supports the older palo version 4 header format
which can hold only 127 characters which might be too small.
Previously, this code was being confused by the re-use/overloading of
existing keywords in the ifcpu64.c module and not producing any menu
entries. Now, explicitly parse the new options and pick out just the
64-bit menus as they're a strict superset of the menus in isolinux.
This may enable some more issues, e.g. people trying to load a 64-bit
kernel on a 32-bit system, but until we get some auto-detection of CPU
in grub there's not much we can do about that. Let's get *something*
working at least.
Currently the ins loader (mostly HMC loading into an LPAR) only
supports kernels up to 8 MiB. The jessie kernel has 11 MiB, which
does not fit and hence gets its tail overwritten by the initrd
(root.bin) loaded at this address. This change bumps the load
address to 16 MiB, which should allow for some more growth of
the kernel.
Signed-off-by: Philipp Kern <pkern@debian.org>
Object code only modules date back to 2.2 and 2.4 kernel times, when
IBM did not release the source to certain kernel modules. Since many
years everything needed to boot and run the machine is actually
open source. It also got broken due to the kernel growing larger and
adding the oco.bin would overwrite parts of the kernel.
It's safe to say that nobody is actually using this.
Even if they won't boot directly from CD/DVD, make it easy for people
using our images by giving them all the bits they'll need to get them
booting somehow.
Replace "alpha" with "a" and "beta" with "b". We've only got 32
characters to use here, so we need to shorten this. This way we can
specify DEBVERSION as a useful long string like "stretch-DI-alpha1" as
a version to appear in file/directory names, but without overflowing
at the VOLID level. May need more tweaks later here, but for now this
seems to do what we need.
FTAOD: this won't change "alpha" in the architecture name, as that is
added later.
Make sure that the package we're told about exists before we look for
its size - a number of the dependencies and recommends may not exist
and this will cause errors for us.
Also list the configured max_pkg_size at the top of the script, to
help with debugging later.
Previously, the code would only check sizes for packages explicitly
listed but packages brought in due to dependency resolution would not
be checked. Now fixed.
When we've got multiple copies of the same initramfs hard-linked
together, gzip gets unhappy when we start modifying things
later. Explicitly break the links to fix that.
This code was using "-efi-boot-part", which works fine for booting but
creates images that d-i can't use: only the full disk or the ESP
partition would contain working filesystems, and d-i doesn't like that.
Instead, switch to appending the ESP as an extra partition on the end
of the image. This will take a small amount of extra space, but will
at least work reliably!
Split the code up and use BOOT_EFI and BOOT_BIOS to control which
goes where. We now support:
* BOOT_BIOS=1 BOOT_EFI=0 for BIOS boot only via an ElTorito boot
record (like debian-cd used to be before EFI support was added)
* BOOT_BIOS=1 BOOT_EFI=2 for standard BIOS boot as
primary ElTorito boot record and EFI as an alternate ElTorito boot
record (common case, just like we've been doing for amd64 in
debian-cd for a while)
* BOOT_BIOS=0 and BOOT_EFI=1 for *only* EFI boot as the primary
ElTorito boot record (new case, might be useful for some
Macs *maybe*)
Set BOOT_METHODS in the debian-cd environment to determine which of
these cases is desired in a given build.
Also removed the support for the "old" syslinux packaging layout, it's
not been around for a while now.
Remove un-needed boot$N in the xorriso command line, we don't have
crappy BIOS lomitations.
Remove support for older xorriso versions.
Use new -efi-boot-part --efi-boot-image options to make an
isohybrid-style images with an explicit EFI partition. Will hopefully
make d-i happier with our images from USB.
Provide hashes for uncompressed Translation-* files, and remove the
uncompressed versions from the output disc. Closes: #767253. Initial
patch from Michael Vogt - thanks!
d-i has removed these files now, so don't look for them for kernel
params. Closes: #767223, #766411. Thanks to Prema and Vagrant for
(identical!) patches. :-)
tasksel now allows selecting the desktop, and d-i has dropped the boot
menu desktop selection, so we no longer need to have desktop boot
menus on CDs.
CD images for specific desktops (xfce/kde/mate/etc) should still
override the default tasksel desktop.
The code was assuming that the first line of output was something like
this (and this is the case of the cd builder machine that uses a custom
built xorriso):
> GNU xorriso 1.2.6 : RockRidge filesystem manipulator, libburnia project.
But the output of the version packaged in Debian does not have the GNU
string:
> xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.
We fix this issue by extracting the version from the line starting with
"xorriso version" which does not have this discrepancy.
debian-installer now has extra steps to create a grub_embed file which
can be passed to xorriso's --embedded-boot option. Add corresponding
code in debian-cd to use it to make images USB bootable.
Patch from Samuel Thibault.
When making a custom server netinstall ISO, it may be desired to not
have MS Windows files. Unfortunately there's currently no check for
loadlin.exe, so install.bat gets created regardless. Fix this.
debian-cd currently expects there to always be isolinux/desktop/*
files and a dtmenu.cfg file, failing if they are missing. Make it so
debian-cd can cope whether those files are present or not.
better safety when extracting boot loader files.
* Update all the relevant boot-* scripts to do the right thing when
extracting packages and sources, depending on
$ARCHIVE_EXTRACTED_SOURCES as above
Steve pointed out that this lookup is only here so that helper scripts
can grab those sources and make them available in a public location
such as http://cdimage.debian.org/cdimage/cd-sources/. The sources are
not embedded in the generated ISO and are thus not strictly needed
for building the ISO image.
This should happen even when we're not building source ISOs but it's
not needed if we don't have any similar policy in place. Thus CONF.sh
is now leaving $ARCHIVE_EXTRACTED_SOURCES unset by default and the
source will only be looked up if that value is set.
+ tools/sort_deps: parse out Built-Using from Packages files too and
pass any such data on to tools/merge_package_lists
+ tools/merge_package_lists: if we have any built-using source
packages listed when doing a combined binary/source set, add them in
the same way as existing listed sources.
* Other bug fixes in tools/merge_package_lists:
+ Fix handling of multi-line Binary: fields
+ Print out the accumulated size of source packages in output also
(fix to printf format string)
versions of a source package:
+ make_disc_trees.pl now tracks arrays of packages when parsing
apt-cache output
+ We'll now pull in all the extra packages included in Sources.gz
because of Built-Using.
had a limited set of hard-coded menu entries - this was buggy and
didn't take into account all the possible boot variations. Now parse
the isolinux menus already provided in the d-i build and generate
equivalent grub menus, complete with themes for a reasonable layout
with graphics and titles.
+ Check all the architectures available in the archive if we're not
specifically told which to use (e.g. on source builds)
+ If we fail to find packages/sources for the specified package, say
so and bail out properly.
Old code used to add the various options in the special case for
"pacakges providing not truly virtual pacakges", which amounted to an
OR dep on the whole set. I missed that in the re-implementation with
version tracking.
Now explicitly switched to adding an OR dep for *all* cases here -
other code will deal with that already. Tweak the logging code to make
things clearer too...
+ Use/parse output from a newer version of apt so that "apt-cache
depends" will include version information on dependencies.
+ All tracking of packages now include versions, so we pass around
hashes of {package name, comparison op, version} everywhere instead
of simply passing package names as strings.
+ Add the APT::Cache::ShowVersion=1 option to apt-cache calls to
turn on version reporting. Needs a locally-patched version of apt
*for now*, but expecting that to be fixed for the Wheezy
release. The new code degrades gracefully if version info is not
available.
+ Add a dependency on libdpkg-perl for version comparison code.
+ Pull in grub-efi for amd64 and i386
+ Lots of extra code in boot-x86:
- pull grub EFI pieces out of the latest debian-cd_info.tar.gz
blobs in d-i, if they're there. If so, use them to make x86 images
bootable via EFI (both via CD and USB)
- generate boot entries for grub on the fly; temporary code for now,
will switch to parsing the isolinux entries shortly instead.
- depending more and more on xorriso rather than genisoimage...
+ Track whether a dependency chain is caused by a hard dependency
(Depends) or soft (Recommends/Suggests). If we fail to add a package
down the chain on a *soft* dependency, don't invalidate the entire
chain.
+ When checking OR dependencies, *first* check to see if any of the
options are already installed *before* trying to install the first
option. Helps a lot with circular deps such as task-lxde-desktop ->
task-desktop -> (task-gnome-desktop | task-lxde-desktop | etc.); in
this case, of course task-lxde-desktop should satisfy the OR dep.
If $DI_CODENAME is ever set to a bad value, one would end up trying to
use a non-existing debian-installer, resulting in non-bootable images
way later. To detect that much earlier, make sure all locations
(computed from $CODENAME and $DI_CODENAME) are directories.
menu (pulled in by desktop tasks),
aptitude (pulled in by debootstap, and may be demoted to optional),
alsa-utils, alsa-base (pulled in by task-desktop),
mdetect, read-edid (no longer used by xorg),
grub (handed by generate_di+k_list),
deborphan, debfoster, localepurge (expert user stuff),
chdrvfont (no such package any more)
* Updated generate_di+k_list to match more closely the current
packages d-i apt-installs.
+ removed architectures: alpha arm hppa
+ removed releases: etch lenny
+ removed unversioned data/sparc and data/yaboot, versioned
equivalents are in place already.
+ Switch to “3.0 (native)” source format to get rid of .svn
directories in the source package (when built from the svn checkout
directly)
+ Support build-arch/build-indep targets in debian/rules.
+ Drop executable rights from tools/boot/wheezy/boot-hurd
(and fix debian/rules to not re-add it).
+ Bump Standards-Version to 3.9.2 (no change required).
Falls back to old location so update_tasks can still be used with old
tasksel.
This does not deal with most of the task information being removed from
debian-tasks.desc. The file still has Key fields, that now list the task-*
packages, and the packages Depend on the crucial packages for the task.
So to that extent it should continue to work.
However, with NORECOMMENDS set, the Recommended other packages for tasks
won't be included on CD. This still needs to be dealt with, probably by
adding all packages listed in Recommends of task-* packages to the
generated task list files.
+ Removed all mention of 686-bigmem as it's now gone
+ Moved 686 to interesting-fromcd23
+ Added 686-pae onto CD#1 in place of 686
+ Leave the 486 kernel on CD#1 still, for people who can't use 686-pae
Rather than use the firmware task which gets out of date, look for
firmware/microcode files directly in the Packages file. Check for
things installing in /lib/firmware, and add those packages.
of packages on the CD too. There's always a small chance we'll have to
remove them *again* (e.g. large source packages that don't fit), so
let's make that possible.
+ Remove the old non-US stuff from it, it's not been needed in years.
+ Cope with .bz2 source files too.
+ Merged and simplified the old functionality from scansources.old
and scanpackages.old into the new script create_control.
+ Makefile: Add support for overriding the MKISOFS and MKISOFS_OPTS
variables on a per-arch basis
+ CONF.sh: add working examples for this
+ tools/boot/squeeze/boot-x86: if configured to use xorriso, add the
extra command line options to add the isohybrid MBR. Also work
around a difference in ISO directory naming between genisoimage and
xorriso.
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.
+ Add "FORCE_FIRMWARE=1" to CONF.sh to turn this on
+ Will pick up on packages in the "firmware" task and install them
+ Will also add sym-links to them in CD1/firmware so that new d-i code
can find them easily.
+ Will add a short sentence into README.html/README.txt
* Add top-level control of which checksums are desired for output images
see the CHECKSUMS setting in CONF.sh
* Fix some bashisms in tools/apt-selection.
The old setup worked fine with an ext2 initrd but fails with an initramfs,
either because autodetection is different for initramfs or because of kernel
changes (I suspect the first).
This means that booting s390 from CD has not worked since sometime during the
Etch release cycle, even though support for booting from CD was only added
early in that cycle - ouch.
For booting with an initramfs initrd we apparently need to specify its
offset and size at specific memory locations.
Change is based on SuSE's CD boot. Many thanks to Adam Thornton, Mark Post
(of Novell) and Bastian Blank for providing the pointers to the missing bits.
This fixes booting from CD using the d390.ins file; tested in Hercules for
both Lenny (31-bit kernel) and Squeeze (64-bit kernel).
Booting from CD using the d390.tdf file may still be broken (if possible at
all) as I have no idea how to test that.
didn't gave any result. This is useful when using partial mirrors built by
simple-cdd while trying to build a Debian CD using a newer d-i (in my case
etch CD with lenny d-i).
* Use dpkg --fsys-tarfile instead of ar for extracting files from deb
packages. The previous invocation could have failed for packages using
something other than gzip compression.
Patch from 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....]
Ignore these lines.
Patch from 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.