Hello, On 07/12/2013 02:24 AM, Thomas Neumann (FAI) wrote: > Probably the only one who knows that is Michael Tautschnig, but he hasn't > been seen on this list since April 2011. I have run into these problems and > tried to dig into setup-storage's code but to be frank it's not exactly the > prettiest in terms of style and readability. Wasn't to happy with my patch > since I'm pretty sure preserving partitions is not possible with it: > > http://www.mail-archive.com/linux-fai-devel%40uni-koeln.de/msg00712.html
For anybody else trying to figure it out in the future, here's the bit of it I've been able to put together. The descriptions are from the post perspective (that is.. a command with this post-dependency provides the following). exist_<DEV> - device exists (this gets double used for devices and partitions.. could be a problem) wipefs_<PART DEV> - device has had wipefs run self_cleared_VG_<VG> - Volume group has been "cleared" self_cleared_<LVM VOLNAME>, Logical Volume has been "cleared" cleared1_<DISK DEV> - all partitions have been "cleared" on DEV cleared2_<DISK DEV> - disk label has been made on DEV prep2_<PART DEV> - partition has been made (usually then translated into exist_) has_fs_<PART DEV> - partition has been formatted with filesystem vgchange_a_n_VG_<VG> - mostly useless?. The VG has been disabled. vg_enabled_for_destroy_<VG> - vgchange -a y has been run to enable existing partitions wipefs_vg/<LVM VOLNAME> - logical volume has been wipefs'd lv_rm_<VG>/<LVM VOLNAME> - logical volume removed from volgroup vg_removed_<VG> - volume group removed from usage pvremove_<VG> - physical volume removed pv_sigs_removed_wipe_<DEV>_<VG> - wipefs was run on physical volume that was part of VG pv_sigs_removed_<VG> - wipefs has been run for all PVs in VG (all devs) flag_lvm_<DEV> - dev has been flagged in the partition table as an lvm volume pv_done_<DEV> - pvcreate has been run on DEV vg_created_<VG> - VG has been created vg_enabled_<VG> - VG has been enabled (vgchange -a y VG) I'm still trying to understand what "cleared" means in its various contexts. > So I started on a different project to create a test harness for testing > different partition setups in short time. Main usage was intended to check > if setup-storage is doing the same things after tweaking the code and > applying bugfixes. (Would be pretty embarassing to get LVM to work but break > MD- oder crypto-devices.) > > https://lists.uni-koeln.de/pipermail/linux-fai/2013-March/010003.html > > It works pretty nicely except that you can't verify disk configs using > /dev/disk/by-path/, by-id/ etc. since the volumes are emulated with loopback > devices and one would have to do some udev magic to make it work. Good deal there. Congrats on it... do you actually have any test cases with lvm and preserve? If not, what are others doing? > > > Since all my work-related itches are scratched I can only allot my copious > free time to it. There isn't too much of that at the moment - so I'm > currently not actively working on finding a solution. [Apart from the free > time I must confess that I'm actually scared of the perl code inside setup- > storage - on the outside it looks like it's split nicely into different > libraries but on the inside it's more like it's one big fscking pile with > usage of package-scoped variables all over the place.] I was kinda hoping > that Michael would come back sooner or later and would fix this mess himself > but that does seem less and less probable with each month passing. Nod, my work-related itches are asking for lvm with preserve. (not so interested in re-size or encrypted or other file-systems). I'm probably just going to roll back to a pre-4.0 version of fai to make it happen. (I'd love to use my spare time, but it involves 2 kids less than 4 years old, ugh). I've taken a look through the code to see what I could do in a few days. I originally thought there was never a case where vgchange -a n VG was required. I was able to remove vgchange -a n VG (Volume Group) from the code and the related dependencies, and add some ways to tell one "true" command from another. That said, I was a bit surprised to find out that even when a partition is preserved, the entire partition table is blown away anyway and then rebuilt with the preserved partition using the same boundaries. Scarily enough this means if the install crashes at a certain point, the preserved partition will effectively have disappeared. (Obviously erasing and re-writing the partition table requires having all vg's disabled, making my original assertion wrong) You're right about the code being a "pile", and I'm sorry to hear that the original contributor isn't showing up any more. This leads me to a few questions: 1. Am I an odd case, do other people have lvm and preserve working for them? 2. Is there a bit of functionality that 4.0 provides that 3.8 doesn't? 3. If this code is really as bad as it seems with no maintainer, why not roll back to the pre-4.0 version of setup-storage. (I get group collaboration/development, but that either requires somebody that will reverse engineer, or somebody that has the overall design in their head. I don't think that exists here.) Anyway, I'd be glad to hear if I'm wrong/out of line, with these suggestions/questions. I'm interested in helping fix things, as we use FAI, here, at work, but I'm also facing a fall semester deadline and a number of other things to do in order to have our labs be ready. At least, I hope the partial documentation of the dependencies are helpful (some of it even <em>seems</em> straight forward). -Ken P.S. I can pass along my changes to the code if requested, but since it appears to be a dead end compared to the original design, I don't think it is worth much.
