Mailing List Archive

[PATCH 0/3] x86 disk image and modules initramfs generation
From: "H. Peter Anvin" (Intel) <hpa@zytor.com>

When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.

This adds a build target to generate a hdimage which can be booted
either from BIOS or EFI, and modernizes the genimage.sh script
including adding the ability to add an arbitrary number of initramfs
files (limited only by the length of the command line.)

Possibly more controversial, at least from a Kbuild design perspective
(as usual I'm the guy who wants to do something with Kbuild which it
seems it was never really designed to do), is add the ability to
create an initramfs image which includes all the built modules. Some
distributions cannot be easily booted without modules in initramfs,
and this creates an image which can be added to initramfs to provide
the kernel modules, as finalized by "make modules_install".

The final patch put these two together, and allows the modules
initramfs to be included in the x86 boot image.

Makefile | 17 ++-
arch/x86/Makefile | 8 +-
arch/x86/boot/.gitignore | 1 +
arch/x86/boot/Makefile | 55 +++++----
arch/x86/boot/genimage.sh | 284 +++++++++++++++++++++++++++++++------------
arch/x86/boot/mtools.conf.in | 3 +
usr/.gitignore | 3 +
usr/Kconfig | 31 ++---
usr/Makefile | 39 +++++-
9 files changed, 318 insertions(+), 123 deletions(-)
[PATCH 0/3] x86 disk image and modules initramfs generation [ In reply to ]
From: "H. Peter Anvin" (Intel) <hpa@zytor.com>

When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.

This adds a build target to generate a hdimage which can be booted
either from BIOS or EFI, and modernizes the genimage.sh script
including adding the ability to add an arbitrary number of initramfs
files (limited only by the length of the command line.)

Possibly more controversial, at least from a Kbuild design perspective
(as usual I'm the guy who wants to do something with Kbuild which it
seems it was never really designed to do), is add the ability to
create an initramfs image which includes all the built modules. Some
distributions cannot be easily booted without modules in initramfs,
and this creates an image which can be added to initramfs to provide
the kernel modules, as finalized by "make modules_install".

The final patch put these two together, and allows the modules
initramfs to be included in the x86 boot image.

---

Fixes in v2:

1/3: correct command line generation for multiple initrds
2/3: no change
3/3: append, don't overwrite FDINITRD when adding modules.img

Makefile | 17 ++-
arch/x86/Makefile | 8 +-
arch/x86/boot/.gitignore | 1 +
arch/x86/boot/Makefile | 62 +++++----
arch/x86/boot/genimage.sh | 294 +++++++++++++++++++++++++++++++------------
arch/x86/boot/mtools.conf.in | 3 +
usr/.gitignore | 3 +
usr/Kconfig | 31 ++---
usr/Makefile | 39 +++++-
9 files changed, 331 insertions(+), 127 deletions(-)
RE: [PATCH 0/3] x86 disk image and modules initramfs generation [ In reply to ]
From: H. Peter Anvin
> Sent: 20 April 2021 00:03
>
> When compiling on a different machine than the runtime target,
> including but not limited to simulators, it is rather handy to be able
> to produce a bootable image. The scripts for that in x86 are
> relatively old, and assume a BIOS system.

I've given up and copied the kernel tree onto all my test systems.

I needed something like 'make modules_install' and 'make install'
that would generated a directory tree that could be copied (scp -r)
onto the target system.

But the script to run 'update-grub' is all intwined in the commands.

You also don't get a copy of the headers.
Even for the local system (as root) you just get a symlink into
the source tree.
This causes a problem trying to build 'out of tree' modules
after updating the kernel source tree (but not rebulding).

I can (and do) write 'horrid' makefiles (gmake and nmake)
but this seemed to need more refactoring that I wanted to do.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
RE: [PATCH 0/3] x86 disk image and modules initramfs generation [ In reply to ]
Ok... not really sure how this relates to my patch. You are mentioned three separate things: modules, headers, and enough of the kernel machinery to build out of tree modules. The latter it normally done with a tree that corresponds to the state after build + "make clean"; which I *believe* is the same as after "make prepare". The former two are "make modules_install" and "make headers_install", respectively. Note you can direct them to directory hierarchies other than the local system ones for archiving.

It is simply not possible to provide a *general* solution that fits all distributions × all boot scenarios.

On April 20, 2021 1:30:07 AM PDT, David Laight <David.Laight@ACULAB.COM> wrote:
>From: H. Peter Anvin
>> Sent: 20 April 2021 00:03
>>
>> When compiling on a different machine than the runtime target,
>> including but not limited to simulators, it is rather handy to be
>able
>> to produce a bootable image. The scripts for that in x86 are
>> relatively old, and assume a BIOS system.
>
>I've given up and copied the kernel tree onto all my test systems.
>
>I needed something like 'make modules_install' and 'make install'
>that would generated a directory tree that could be copied (scp -r)
>onto the target system.
>
>But the script to run 'update-grub' is all intwined in the commands.
>
>You also don't get a copy of the headers.
>Even for the local system (as root) you just get a symlink into
>the source tree.
>This causes a problem trying to build 'out of tree' modules
>after updating the kernel source tree (but not rebulding).
>
>I can (and do) write 'horrid' makefiles (gmake and nmake)
>but this seemed to need more refactoring that I wanted to do.
>
> David
>
>-
>Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
>MK1 1PT, UK
>Registration No: 1397386 (Wales)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.