announcement - forking setup-storage

[Thomas Neumann]

On Friday, October 04, 2013 12:54:40 AM Thomas Neumann wrote:
> I did not plan anything for this weekend. Hopefully I get the
> configuration parser into a presentable state so there's something to
> play with. Another big item on my list is a bugtracker. (I haven't really
> thought about it, except that I definitely want to use one.)

I'm frustrated. Haven't made much progress. Except I finally understand why

  vg vg_system disk1.3
  disk_config lvm
  vg_system-root      /         4G-12G    xfs  rw

and

  disk_config lvm
  vg vg_system disk1.3
  vg_system-root      /         4G-12G    xfs  rw

are both valid configurations.

The configuration format seems (and is always documented) as if 'disk_config 
<something>' and the following lines are related. (disk_config lvm is 
followed by logical volumes, disk_config raid is followed by md devices, ...)

Well they aren't.

The config file interpretation is line based. Except when it isn't. (At least 
with physical volumes there's a dependency between disk_config <device> and 
the subsequent lines.

I haven't tested this, but 

disk_config disk1
primary         -       200M    -       -
primary         -       4G-     -       -

disk_config disk2 sameas:disk1
disk_config disk3 sameas:disk1

disk_config raid
disk_config cryptsetup
disk_config lvm

raid1  /boot     disk1.1,disk2.1    ext3    defaults
luks   -           md1                    -       -
raid1  -           disk1.2,disk2.2    -       -

vg vg_encrypt md1
vg vg_system disk3.2

vg_encrypt-root    /        1-10G     ext4 defaults
luks            /secure vg_system-secure        xfs     rw,nodev,nosuid
tmp            /tmp tmp ext2      mode=1777
vg_system-home /home 512M-1G xfs  rw,nodev createopts="-L home"

is likely to be a valid configuration. If it isn't then it's not a syntax 
issue, but setup-storage's internal state keeping got confused at some 
point.


I'd really like to keep the current configuration file format, but it's making 
the parser more complicated then it should be. Hmph. By the way: Who knows 
what the second last line in the above configuration does? Hint: It does not 
create a tmpfs volume. It also doesn't create a normal ext2 partition.


A simple tmpfs volume would be

  tmpfs <mountpoint> <tmpfs_size> <mount_options>

Instead it's a 'encrypted partition for /tmp usage, will be recreated with a 
random key at each boot and reformatted as ext2'

  tmp <mountpoint> <size> <filesystem> <mount_options> <fs_options>

That's a very small and non-obvious difference. (I don't know what happens if 
you specify <filesystem> as anything else then ext2.)



I'm still pondering if there's a way to transform the current setup-storage 
code into a better shape. For now I'm continuing to dig around in the code 
and try to understand & reimplement it. Still nothing working to show 
though.

bye
thomas