Archive for the ‘Preseed’ Category

Debian/Ubuntu Preseed LVM and expert_recipe

Friday, June 29th, 2012 by Gary Richards - Categories: Debian/Ubuntu, Linux, Preseed

I just spent a whole bunch of time ripping my hair out with some preseed files for a seemingly simple Ubuntu setup.

Either canonical have modified the debian installer in an odd way or Debian have done it and Canonical have released it with Ubuntu Precise not realising the differences.. I don’t know which.

This client has a bunch of Ubuntu Lucid KVM hosts, each created with 10GB of LVM via some really simple preseed options:


d-i partman-auto/method string lvm
d-i partman-auto-lvm/guided_size string 10GB
d-i partman-auto/choose_recipe select atomic

This works perfectly… I get /boot as a 256M physical partition at the begining of my disk, an LVM PV setup with the remainder of the disk, an LVM VG in all this space, an LVM LV that’s 512M for swap (these machines have 48G of RAM, we don’t want tons and tons of swap, if we’re swapping more than 512M then things are going wrong!) and an LVM LV for root that’s about 8.8G in size.

Cue trying the same preseed file with precise…. and then the installer telling me that 10GB guided partitioning size is not big enough for the current recipe (atomic) and that I need 57GB, what the…?

It seems that the default recipe now insists on 100% RAM used for your swap partition, with a significantly higher priority than it must have had before. So 48G + approx 9G (the 9G must be in the new recipe too I guess?).

It’s ok I thought, i’ve created ‘expert_recipe’ entries before, I can do it for some LVM too… well yes it turns out I can and I learnt alot along the way. So to remind myself for when I need to do it next time, I quickly brain dumped everything I can remember here!

Firstly, we’re PXE booting machines, but i’m sure it works with other ways of preseeding, add DEBCONF_DEBUG=5 to your kernel arguments. Then, when in the installer, switch to virtual console 4 (alt-F4). You’ll see lots of unecessary output and things whizzing by at light speed, but it can be helpful in finding all manner of debconf options that you could set for any step that it’s asking you a question for.

For example, I know for a fact that whilst I was testing this that I had to confirm every single time that I wanted to nuke the existing lvm (or the existing partitions when I was not using lvm mode). The output of the debconf debug suggested that in both instances, the question it was asking me was for partman-lvm/confirm_nooverwrite (or partman/confirm_nooverwrite in the non lvm mode). So in my preseed file I simply added


d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman/confirm_nooverwrite boolean true

And now it doesn’t prompt me for that question anymore. It’s worth noting that there were a whole bunch of other things that I added along the way to make it not ask me any questions about partitioning, some of them may be important to some people, you may not want the installer to nuke your disks without confirming with you, etc. So you’re on your own there… Just work out which questions you don’t want to be asked and add the relevant options to your preseed file.

Ok, onto the actual expert_recipe stuff….

I failed around alot with this, some things partly worked (for example, one time I managed to partition the disks correctly sized, but without LVM) other things just errored and the output was incredibly cryptic! So be warned. I found a whole load of documentation on the internet, from varying sources, doing things in various ways, alot of which seemed to not actually work. So again, be warned, no one seems to quite understand how to do this properly (myself included) and the official documentation is as cryptic as anything else.

The first thing to understand before anything else is what the options $defaultignore{ }, $lvmok{ } and $lvmignore do.

As far as I can tell these are used to define which sections of your recipe are used based on the method that you select for partman-auto/method.

  • $default-ignore{ } – If partman-auto/method is ‘regular’ (which I assume is the default?) then ignore this partition when considering this recipe
  • $lvmok{ } – If partman-auto/method is ‘lvm’ then this partition is to be created within the lvm, not as a regular partition
  • $lvmignore{ } – If partman-auto/method is ‘lvm’ then ignore this partition when considering this recipe

These are the things that confused me the most. Because once you understand them, i’m pretty sure that you could write a recipe that contained two partititons (maybe more?) for the same mountpoint, but with differing instances of these options. Which of the partitions were then created would be down to whether you’ve specified regular or lvm for the partman-auto/method.

Now that I understand that, the rest of what I needed to do was quite easy.

I started out with a simple regular recipe that involved no lvm at all:

d-i partman-auto/expert_recipe string                         \
      test ::                                                 \
              256 10 256 ext3                                 \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext3 }    \
                      mountpoint{ /boot }                     \
              .                                               \
              9472 10 9472 ext3                               \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext3 }    \
                      mountpoint{ / }                         \
              .                                               \
              512 10 512 linux-swap                           \
                      method{ swap } format{ }                \
              .

This worked fine with partman-auto/method regular.

I then introduced the lvm related options and switched to partman-auto/method lvm:

d-i partman-auto/expert_recipe string                         \
      test ::                                                 \
              256 10 256 ext3                                 \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext3 }    \
                      mountpoint{ /boot }                     \
              .                                               \
              9472 10 9472 ext3                               \
                      $lvmok{} lv_name{ root } $defaultignore{ } \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext3 }    \
                      mountpoint{ / }                         \
              .                                               \
              512 10 512 linux-swap                           \
                      $lvmok{ } lv_name{ swap_1 } $defaultignore{ } \
                      method{ swap } format{ }                \
              .

Which creates me what the original Lucid installer created me.

$lvmok{ } for / and for the swap partition ensure that these partitions are created within some LVM space. $defaultignore{ } means that these same partitions will be ignored if i’m using parted-auto/method regular (meaning that the install will fail miserably if i’m using that method).

What I should probably do is add another / and swap partition that would be setup for my hosts that aren’t using LVM and add $lvmignore{ } to them so that they’re only considered when i’m not using parted-auto/method lvm.

The /boot partition specifies none of the options at all. Meaning that it will be considered whether i’m using regular or lvm as my method.

Other things that are worth noting:

Defining your expert_recipe alone is not enough to make your recipe get used. One thing that was not obvious to me from the example preseed files was that anything other than atomic, home, multi were available. It turns out that you need to give it the name of your expert recipe

d-i partman-auto/choose_recipe select

As the auto partitioning likes to perform magic based on sizes and priorities of the partitions in your expert_recipes, it does some calculations based on minimum sizes for all selected partitions and priorities. My original problem (the 57GB minimum size required) seems to have been caused by this. The default atomic recipe must specify partitions that must be something like 100% of your available ram for swap and the other partitions minimum size must be approx 9GB.

So even though I specified:

d-i partman-auto-lvm/guided_size string 10GB

It was telling me that 10GB was too small for my recipe. Now I understand why. My new expert recipe has a total minimum size of 10GB, so the above setting works fine.

The minimum priority maximum settings for each partition also seem to be a little confusing.

Taking the /boot partition from my example:

256 10 256 ext3 \
$primary{ } $bootable{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 } \
mountpoint{ /boot } \

What i’m hoping this is doing is saying the minimum size this partition can be is 256M, the maximum it can be is 256M, the priority of this partiton is 10.

You may notice that all my partitions I specify the min and max as the same value. The priority for all partitions is 10. (apparently the lower the number for priority, the higher the priority…)

I’m pretty sure this is designed in such a way that if I didn’t want very specific sized partitions, I could specify that my root partition had some ridiculously high maximum size. Then, assuming that I wasn’t specifying partman-auto-lvm/guided_size as 10GB, the root partition would get created much bigger (most likely filling the remainder of the disk).

I’m also pretty sure that the priority in this instance would be mostly ignored as /boot and swap would almost have their maximum size the same as their minimum size, so the only thing that could be larger is the / partition.

If I have another partition that could also be created with some sort of dynamic size, this is likely to be when the priority actually makes a difference. Imagine /home defined similarly to my dynamic / partition i’ve been talking about. If it had the same settings, I would imagine that the remaining space would be split equally between / and /home. If the priority of /home was lower (and therefore higher priority) I would image /home would consume more of the available space than / would (I just don’t know by how much other than it would likely be based on the difference in priority. Unfortunately I don’t have the remaining time right now to test!).

The last thing i’ll say… Preseeding is very confusing to the beginner, the documentation is confusing and everyones examples on it are confusing… But once you start to understand parts of it, it actually seems quite powerful :)