martin f krafft wrote (ten years ago!):
> Package: lvm2
> Version: 2.02.44-3
> Severity: minor
>
> If /etc happens to be read-only, almost every operation yields an
> "error 5". This is misleading, and the error message should be
> better. Also, I should be able to specify an alternate/more
> appropriate location for the backup...
FYI, I have been doing this for nearly ten years:
sed -i /etc/lvm/lvm.conf -e '/backup_dir/ c backup_dir =
"/var/backups/lvm/backup"'
sed -i /etc/lvm/lvm.conf -e '/archive_dir/ c archive_dir =
"/var/backups/lvm/archive"'
My reason was much simpler:
If LVM archives to /etc/, my etckeeper git history fills with distracting crap.
(My LVM state changes every night, when I rsync from temporary LVM snapshots.)
Why doesn't Debian (or upstream) make that the default?
Attached is an (untested) draft patch for debian/patches/ to do just that.
As a test, I used systemd's ProtectSystem=full to block lvm2's write
access to /etc, to see if it still failed with no message.
Here the test unit:
# /etc/systemd/system/delete-me-525579.service
[Service]
Type=oneshot
# Make /etc read-only, as a test.
ProtectSystem=full
ExecStartPre=/usr/sbin/zfs create -V 8G omega/ZVOLs/delete-me-525579
ExecStart=/usr/sbin/pvcreate /dev/zvol/omega/ZVOLs/delete-me-525579
ExecStart=/usr/sbin/vgcreate VG0 /dev/zvol/omega/ZVOLs/delete-me-525579
ExecStart=/usr/sbin/lvcreate --name=foo --size=100M VG0
ExecStart=/usr/sbin/lvextend --size=200M VG0/foo
ExecStart=/usr/sbin/vgchange -an
ExecStopPost=/usr/sbin/zfs destroy omega/ZVOLs/delete-me-525579
Here is it working without ProtectSystem=full:
May 30 12:33:47 not-omega systemd[1]: delete-me-525579.service: Service has
more than one ExecStart= setting, which is only allowed for Type=oneshot
services. Refusing.
May 30 12:34:45 not-omega systemd[1]: Starting delete-me-525579.service...
May 30 12:34:48 not-omega pvcreate[19672]: Physical volume
"/dev/zvol/omega/ZVOLs/delete-me-525579" successfully created.
May 30 12:34:52 not-omega vgcreate[19877]: Volume group "VG0"
successfully created
May 30 12:34:57 not-omega lvcreate[20028]: Logical volume "foo" created.
May 30 12:34:59 not-omega lvextend[20208]: Size of logical volume VG0/foo
changed from 100.00 MiB (25 extents) to 200.00 MiB (50 extents).
May 30 12:34:59 not-omega lvextend[20208]: Logical volume VG0/foo
successfully resized.
May 30 12:35:01 not-omega vgchange[20322]: 0 logical volume(s) in volume
group "VG0" now active
May 30 12:35:04 not-omega systemd[1]: delete-me-525579.service: Succeeded.
May 30 12:35:04 not-omega systemd[1]: Started delete-me-525579.service.
May 30 12:35:04 not-omega systemd[1]: delete-me-525579.service: Consumed
340ms CPU time, no IP traffic.
Here is it failing with ProtectSystem=full:
May 30 12:36:28 not-omega systemd[1]: Starting delete-me-525579.service...
May 30 12:36:31 not-omega pvcreate[22588]: Physical volume
"/dev/zvol/omega/ZVOLs/delete-me-525579" successfully created.
May 30 12:36:34 not-omega vgcreate[22731]: Cannot archive volume group
metadata for VG0 to read-only filesystem.
May 30 12:36:34 not-omega systemd[1]: delete-me-525579.service: Main
process exited, code=exited, status=5/NOTINSTALLED
May 30 12:36:35 not-omega systemd[1]: delete-me-525579.service: Failed with
result 'exit-code'.
May 30 12:36:35 not-omega systemd[1]: Failed to start
delete-me-525579.service.
May 30 12:36:35 not-omega systemd[1]: delete-me-525579.service: Consumed
175ms CPU time, no IP traffic.
So you can see that at least vgcreate is giving a useful error message now.
By doing each step by hand prior to the systemd ProtectSystem=full, I can also
get:
May 30 12:40:44 not-omega lvcreate[24889]: Cannot archive volume group
metadata for VG0 to read-only filesystem.
May 30 12:41:35 not-omega lvextend[25653]: Cannot archive volume group
metadata for VG0 to read-only filesystem.
May 30 12:41:56 not-omega vgchange[26201]: 0 logical volume(s) in volume
group "VG0" now active
That last one wasn't an error; it succeeded.
Description: Backup to /var/backup/lvm/ (not /etc/lvm/) by default.
See also discussion on https://bugs.debian.org/525579
(This patch does NOT fix that bug, though!)
Author: Trent W. Buck <trentb...@gmail.com>
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: <vendor|upstream|other>, <url of original patch>
Bug: <url in upstream bugtracker>
Bug-Debian: https://bugs.debian.org/<bugnumber>
Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber>
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By: <name and email of someone who approved the patch>
Last-Update: 2019-05-30
--- lvm2-2.03.02.orig/conf/example.conf.in
+++ lvm2-2.03.02/conf/example.conf.in
@@ -758,7 +758,7 @@ backup {
# Configuration option backup/backup_dir.
# Location of the metadata backup files.
# Remember to back up this directory regularly!
- backup_dir = "@DEFAULT_SYS_DIR@/@DEFAULT_BACKUP_SUBDIR@"
+ backup_dir = "/var/backup/lvm/@DEFAULT_BACKUP_SUBDIR@"
# Configuration option backup/archive.
# Maintain an archive of old metadata configurations.
@@ -768,7 +768,7 @@ backup {
# Configuration option backup/archive_dir.
# Location of the metdata archive files.
# Remember to back up this directory regularly!
- archive_dir = "@DEFAULT_SYS_DIR@/@DEFAULT_ARCHIVE_SUBDIR@"
+ archive_dir = "/var/backup/lvm/@DEFAULT_ARCHIVE_SUBDIR@"
# Configuration option backup/retain_min.
# Minimum number of archives to keep.
