Curious case of /lib/libkmod.so.2
Hi d-i developers, I'm working on an bootloader/installer system for some industrial equipment. Until now, my main interaction with d-i has been grabbing the pre-cooked kernel/initrds from Debian or Ubuntu, and tacking on a few extra files to the tail of the initrd, like preseed, scripts, and an extra udeb or two. However, I've come to a place where I'd like to have more control over some things (incl exact kernel version) and so I want to generate my own initrd with just the particular udebs I require. I'm basing most of my work on the Makefile here, which details downloading a dependency tree of packages, and creating a bare bones dpkg setup into which they are installed: https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build/Makefile#n308 My system actually mostly works, but one key file I'm missing is /lib/libkmod.so.2. This file isn't contained within any of the udebs (libkmod2-udeb is just a multi-call binary with no libs), and in fact a little tracing reveals that it springs into existence as a result of the mklibs-copy call which happens here: https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build/Makefile#n526 Without this lib, systemd-udevd fails to link at runtime (called by the init script), and the kernel panics shortly after boot. So my main question is, what is going on with the mklibs-copy call? Where are the contents of libkmod.so.2 coming from? They're byte-for-byte identical with the copy in the libkmod2 package, but in a different location, and I don't even have that package installed. I'm sure there's some silly explanation here that I'm just not seeing, but a I think I need a poke in the right direction to get there. Thanks, Mike
Re: LVM partitioning preseed.cfg / kickstart question
Below is a known-good partitioning recipe similar to your use case.
It puts all of /, not just /boot, in a real partition.
I think the main difference is the start of the second stanza
614401000 1 lvm
while you have
100 1000 -1 xfs
There may be a bug in handling -1 as the upper limit;
hopefully you will be able to flush it out if so.
To simplify things, I'd stick with d-i alone for the moment
and then introduce kickstart if it is helpful.
Kind regards
Vince
d-i partman-md/device_remove_mdboolean true
d-i partman-md/confirm_nooverwrite boolean true
d-i partman-md/confirm boolean true
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-lvm/confirm_nooverwriteboolean true
d-i partman-lvm/confirmboolean true
d-i partman-lvm/vgdelete_confirm boolean true
d-i partman-auto-lvm/no_boot boolean true
d-i partman-auto-lvm/new_vg_name string linux
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirmboolean true
d-i partman-basicfilesystems/no_swap boolean false
d-i partman/mount_style select uuid
d-i partman/confirm_nooverwrite boolean true
d-i partman-auto/method string lvm
d-i partman-auto/expert_recipe string workstation : \
10245 1024 ext4 \
$primary{ } \
$bootable{ }\
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ / } \
. \
614401000 1 lvm \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
. \
2048300% 65536 linux-swap \
$defaultignore{ } \
$lvmok{ } \
method{ swap } \
format{ } \
. \
20480 5 20480 ext4 \
$defaultignore{ } \
$lvmok{ } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ /usr } \
. \
40965 4096 ext4 \
$defaultignore{ } \
$lvmok{ } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ /var } \
. \
20485 2048 ext4 \
$defaultignore{ } \
$lvmok{ } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ /var/log } \
. \
204852048 ext4 \
$defaultignore{ } \
$lvmok{ } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ /tmp } \
. \
409654096 ext4 \
$defaultignore{ } \
$lvmok{ } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
