The development of the VubuntuBox Linux Distribution has required making a custom installation of Lubuntu, and I thought the easiest way to do this would be through the standard / recommended methods for making an Automatic Installation, which was either to use preseeding or to use kickstart.
In the end, it turned out that I needed to use both to automate the installation to a level needed, and that several “tricks” were needed to solve inherent limitations of kickstart (and preseeding). And now that I’ve figured some of these out, I am writing several blog articles to share what I’ve learned, so others hopefully won’t have to bang their head against the wall as much as I have. Also, I should note, that I’m not a Linux expert, so there may be more elegant solutions than the ones I’ll be sharing in these articles.
One of the first challenges that was faced, was how to ask questions of the user in the beginning of an installation, but act on these at the end of the installation. This has been important in VubuntuBox because the goal is to have the installation as automatic as possible, and so it is better to have all user interaction happen in the beginning and then to be able to just leave the machine to do the rest.
I never figured out how to do this with preseeding, although it has an early_command and late_command option, these just never seemed to work right for me. Kickstart has the %pre and %post scripts, and with an ingenious trick from Michael Ludvig, you can make these interactive with the user. But I could not at first figure out how to get environmental variables created in the %pre section to work in the %post section, and because the default behavior is to have the %post be a chroot of the final installation, I couldn’t just save the variables in the initial file system (rootfs).
The solution to this problem was to create a ram disk where I could save my variables by using the following code in my %pre script:
mkfs -q /dev/ram1 8192
mkdir -p /variables
mount /dev/ram1 /variables
I then would read in variables and copy them to the /variables folder, as the following example code demonstrates:
read -p "Enter the full URL of the Virtual Image: " VirtualImageURL
echo $VirtualImageURL > /variables/VirtualImageURL
Also, while I’m not sure if it is necessary, I went ahead and unmounted the ram disk at the end of the %pre section, and then mounted it again in the post section, with similar code, but not using the mkfs again, as the file system is still in /dev/ram1.
To get a variable out, I would use the export command with inline command substitution, as the following example in the %post section shows:
export VirtualImageURL=`cat /variables/VirtualImageURL`
There are probably some more elegant solutions for some of this (like some type of loop to get all the variables from the ram disk), but I can vouch that my method works.
Also, I should mention, that to do this, you need to have mkfs installed in the %pre environment. And for right now, I’m “cheating” by just copying in the binary and libraries. But in the future, I hope to be able to load the appropriate packages, as I talked about in a previous post.
- November 30, 2014 @ 05:50:29 [Current Revision] by Jacob Walker
- November 30, 2014 @ 05:50:29 by Jacob Walker