Bug#626031: marked as done (debian-kernel-handbook: please support U-Boot format images.)
Your message dated Sun, 8 May 2011 13:45:00 +0100
with message-id <BANLkTi=NZYFnYs7DPxs8u44vOg80tschPA@mail.gmail.com>
and subject line Re: Bug#626031: debian-kernel-handbook: please support U-Boot format images.
has caused the Debian Bug report #626031,
regarding debian-kernel-handbook: please support U-Boot format images.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact firstname.lastname@example.org
Debian Bug Tracking System
Contact email@example.com with problems
--- Begin Message ---
While looking to DebianBug#550584, I wonder why do we need to carry
with the burden of maintaining hardcoded stuff for some architectures,
while part of it is maintained by Linux kernel upstream developers.
Adding support for U-Boot image format ('uImage' kernel target) in
official kernel packages seem to me the right thing to do, it would
not only simplify `flash-kernel` (see #108 comments for a `flash-kernel`
summary of issues) but also `debian-installer` which currently have to
add extra code to support U-Boot image format per device. Part of that
extra code could be reduced by allowing U-Boot format images in official
Regarding initramfs generation, it could be generated as usual by initramfs
tools but if platform uses U-Boot format after creating, updating or deleting
initrd.img it should call the uinitrd.img handler (nowadays flash-kernel) with
a couple parameters:
The following patch against SVN trunk (r89) ammends kernel handbook policy
for allowing U-Boot image format support (and also fixes some indentation
to be coherent with writting style).
--- chapter-initramfs.sgml (revision 89)
+++ chapter-initramfs.sgml (working copy)
@@ -63,7 +63,7 @@
<heading>Choosing the tool</heading>
- At the end of the kernel package installation a script is
+ At the end of the kernel package installation a script is
automatically invoked to determine the availability of the
initramfs-generating tools and run one of them. This script
contains the list of all such tools available in Debian.
@@ -96,20 +96,33 @@
be regenerated. This is achieved by the command
# dpkg-reconfigure linux-image-2.6.18-3-686
- where <tt>linux-image-2.6.18-3-686</tt> is the name of the
+ where <tt>linux-image-2.6.18-3-686</tt> is the name of the
kernel package for which the initramfs regeneration is requested.
<heading>Examining the initramfs contents</heading>
Occasionally it is useful to examine the contents of initramfs
to diagnose a problem or for educational purposes. They are
compressed <tt>cpio</tt> archives, which may be extracted
using the command
$ zcat /boot/initrd.img-2.6.18-3-686 | cpio -i
It will unpack the contents of the initramfs into the current directory.
+ <sect id="initramfs-uimage">
+ <heading>Generating U-Boot format initramfs images (uinitrd.img)</heading>
+ If U-Boot format (<tt>uImage</tt>) Linux kernel image exists
+ initramfs generation tool must run to create, update or delete initramfs
+ after each one of those tasks it must pass control to the uinitrd.img
+ generation tool, nowadays the only known tool <tt>flash-kernel</tt> passing
+ two arguments: action performed (create, update, delete) and
--- chapter-update-hooks.sgml (revision 89)
+++ chapter-update-hooks.sgml (working copy)
@@ -28,7 +28,8 @@
optionally, the absolute path to the kernel image. If the
second argument is missing then the path is
either <tt>/boot/vmlinuz-<em>version</em></tt> or
- <tt>/boot/vmlinux-<em>version</em></tt>, according to
+ <tt>/boot/vmlinux-<em>version</em></tt> or
+ <tt>/boot/uImage-<em>version</em></tt>, according to
architecture convention. The environment variable
<tt>DEB_MAINT_PARAMS</tt> will contain the arguments given to
the kernel maintainer script, possibly single-quoted. In a
--- chapter-packaging.sgml (revision 89)
+++ chapter-packaging.sgml (working copy)
@@ -281,19 +281,35 @@
pre-built binary modules for a particular
arch/featureset/flavour combination. Names of the files
installed by this package are
- architecture-dependent. Typical locations of essential
- files for the <tt>i386</tt> architecture are:
+ architecture-dependent. Traditionally Debian Linux kernel uses
+ <tt>vmlinuz</tt>, a gzip compressed ELF, COFF or a.out image.
+ U-Boot format Linux kernel images, <tt>uImage</tt>, are supported as well
+ for architectures that use such format.
+ Typical locations of essential files are:
The binary (compressed) kernel image.
+ The binary (compressed) kernel image (U-Boot format).
Initial RAM filesystem (initramfs) image. Note, that this file is automatically generated
in the installation process and is <strong>not</strong> shipped as a part of the package.
+ This file is generated if <tt>vmlinuz</tt> image exists.
See <ref id="initramfs"> for more details.
+ Initial RAM filesystem (initramfs) image (U-Boot format). Note, that this
+ file is automatically generated
+ in the installation process and is <strong>not</strong> shipped as a part of the package.
+ This file is generated if <tt>uImage</tt> image exists.
+ See <ref id="initramfs"> for more details.
The kernel configuration file used to build this particular kernel. May be used
-- Héctor Orón
-- System Information:
Debian Release: wheezy/sid
APT prefers stable
APT policy: (700, 'stable'), (600, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.37-1-686 (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
2011/5/8 Hector Oron <firstname.lastname@example.org>:
> OK, I understand that, I did not had such a deep thought on machine ID stuff.
> Maybe because I was not thinking it is the general case, do we always
> change machine ID?
> IIUC, few devices need to change ID, if I am wrong then it is probably
> not worth to implement
> such behaviour.
Checking `flash-kernel` again, this proposal is probably useless due
to Machine ID stuff.
Closing the bug.
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
--- End Message ---