according to FHS 2.3 [0]:
The contents of the root filesystem must be adequate to boot,
restore, recover, and/or repair the system.
if LVM is needed in the boot, /var is a separate partition, and LVM
cannot operate without its cache, archives, and backups, it would seem
that LVM must store the data in /etc.
However, if any of those predicates are untrue (i don't know lvm well
enough to know if this is the case), the unneeded data should probably
be stored in /var so that lvm can be used with a ro root filesystem,
as you suggest. If this is the case, then the data is basically just
"variable state information". This would mean that the severity of
this bug should be elevated to serious, because it's probably a policy
violation to store data of this type in /etc instead of /var/lib.
I'd like to point out one other situation where storing this data in
/var would be much better than the current configuration:
The root filesystem is often configured errors=remount-ro. In the
event of root filesystem errors, this effectively disables lvm
operations which change the state of the lvm information stored in
/etc. However, this circumstance is one in which a sysadmin would
*really* want to be able to make use of lvm (e.g. setting up a
recovery volume, snapshotting existing volumes, etc).
Someone who understands lvm in more detail, in particular which of
these files are truly necessary for boot, should probably comment on
this bug. i note that i can boot with the root filesystem on an lvm
device (using a modern initramfs setup), so i don't think that the
data stored in /etc/lvm/ is necessarily crucial to the boot process.
If it's decided that the decision should be left to the sysadmin, is
there a way that this could be made clearer? the sysadmin could
always choose to symlink /etc/lvm to /var/lib/lvm (or something
similar), but it would be nice to help them make that decision.
--dkg
[0] http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
