All 2 entries tagged Autoyast

No other Warwick Blogs use the tag Autoyast on entries | View entries tagged Autoyast at Technorati | There are no images tagged Autoyast on this blog

June 29, 2011

Update a driver in an initrd file

Recently I found myself wanting to put SUSE Linux Enterprise Desktop 11 SP1 on to machine with a Sandybridge chipset. This was a problem as the e1000e driver in SLED 11 SP1 isn't new enough to support the network card in the machine. Having found an updated driver I still had the problem that I wanted to be able to do installations over the network with AutoYaST and PXE boot. That didn't work because the initrd file being used for PXE boot didn't have the new e1000e driver in. So the install failed almost immediately due to the absence of a network connection.

The solution is to make a new initrd file containing the new e1000e driver. It's far from obvious how to do this but I found the solution at This post is basically just me duplicating the information because you can never have such information in too many places. Also I've expanded it a little bit to include instructions on how to do some bits that I had to work out. You can of course adapt the following for whatever module you might find the need to update.

First of all, make a new directory and unpack the current initrd in to it

$ mkdir -p updated_initrd/initrd_unpack
$ cd updated_initrd/initrd_unpack
$ gunzip -dc /path/to/initrd | cpio -idmuv

Now get the new version of the e1000e module. I found this in an rpm on Novell's website which I needed to download and unpack to get the driver out of it.

$ cd ..
$ wget
$ mkdir rpmcontents
$ cd rpmcontents
$ rpm2cpio ../intel-e1000e-kmp-pae-1.2.20_2.6.32.12_0.7-1.i586.rpm | cpio -idv

Next copy the new driver over in to where you unpacked the initrd

$ cp lib/modules/ ../initrd_unpack/modules/
cp: overwrite `../initrd/modules/e1000e.ko'? y

Now you need to update files called modules.alias and modules.pcimap using information that you get from the depmod command. You can get the information to put in modules.alias with

$ /sbin/depmod -n $(pwd)/lib/modules/ | grep ^alias > /tmp/newaliases

Then I made a copy of the modules.alias file with the information for e1000e removed from it

$ grep  -v ' e1000e$' ../initrd_unpack/lib/modules/ > /tmp/modules.alias

Add the new information to that file

$ cat  /tmp/newaliases >>  /tmp/modules.alias

And then replace the original file

$ cp /tmp/modules.alias  ../initrd_unpack/lib/modules/
cp: overwrite `../initrd_unpack/lib/modules/'? y

The process is the same for the modules.pcimap file

$ /sbin/depmod -n $(pwd)/lib/modules/ | grep '^e1000e ' > /tmp/newpcimap
$ grep -v '^e1000e ' ../initrd_unpack/lib/modules/ > /tmp/modules.pcimap
$ cat /tmp/newpcimap >> /tmp/modules.pcimap
$ cp /tmp/modules.pcimap ../initrd_unpack/lib/modules/
cp: overwrite `../initrd_unpack/lib/modules/'? y

Finally, make the new initrd file

$ cd ../initrd_unpack
$ find . | cpio --quiet -o -H newc > ../initrd
$ cd ..
$ gzip -v9c initrd > initrd.gz
$ mv initrd.gz initrd
mv: overwrite `initrd'? y
$ file initrd
initrd: gzip compressed data, was "initrd", from Unix, last modified: Wed Jun 29 12:31:49 2011, max compression

November 05, 2008

Altering AutoYaST profiles on the fly…

...or: How to have one or more variants of an AutoYaST profile without having to actually maintain them.

Say you maintain a bunch of machines running some SUSE variant, you install them using AutoYaST so they're all identical but you find that sometimes you want to install a machine in a way which is slightly different to normal. For example, you want to be able to re-install a machine whilst preserving the contents of a particular partition. This presents a problem because it means you need more than one AutoYaST profile, the one you usually use and the variant. If you change the main profile you have to make the same changes to the variant. Maintaining a variant is going to be prone to human error, forgetfulness and possibly problems could be caused by trying to use a variant which you don't realise hasn't been maintained.

Faced with such a situation myself a neat solution occurred to me. My AutoYaST profile is accessed from a web sever at time of installation, so a script on the web server can be used to manipulate the XML on the fly and serve the modified version. This way only one AutoYaST profile has to be maintained but you can can have as many variants of it as you like provided you write a script to produce that variant. E.g. This PHP:

# reads the autoinst.xml file, alters the partition config data so that
# partitions are re-used rather than created, and /local is not formatted
# then outputs the new xml.



foreach ($data->partitioning->drive->partitions->partition as $partition) {
if ($partition->mount=="/local") $partition->format="false";

header('Content-Type: text/xml');
print $data->asXML();

saved as a suitably named file on the web server and it's url provided as the source of the AutoYaST profile at install time allows machines to be re-installed whilst preserving the contents of the partition that gets mounted at /local.

Search this blog


RSS2.0 Atom
Not signed in
Sign in

Powered by BlogBuilder