Re: Suggestion for systemd and /usr on seperate partition
On Wed 08 Jul 2020 at 18:07:05 (+1000), Andrew McGlashan wrote:
> On 8/7/20 3:35 pm, Andrei POPESCU wrote:
> > On Mi, 08 iul 20, 02:35:09, Andrew McGlashan wrote:
> >> On 8/7/20 2:11 am, Michael Stone wrote:
> >>>
> >>> The short answer is that there simply isn't a good reason to do this
> >>> on a modern system, and there is no volunteer to donate the enormous
> >>> amount of effort required to make
> >>> something work for which there isn't a good justification for
> >>> expending that effort. There should be no flamewar, if someone wants
> >>> the situation to change they simply need to be
> >>> the person who puts in all the work.
> >>
> >> Just doing dist-upgrade with a perfectly acceptable file system
> >> previously is no reason why it should break.
> >
> > Debian supports upgrading of most packages between releases.
> >
> > It provides no guarantees about hardware, partitioning schemes,
> > partition sizes, file systems, etc.
I'm not going to suggest that this is proof, but the Release Notes for
buster still carry the warning that one should make sure any /usr
partition has been remounted rw if necessary.
> > I was under the impression that LVM is used in particular for its
> > flexibility in adjusting your partitions. What prevents you from merging
> > '/' and '/usr'?
>
> Yes, that might be the best fix; but I didn't expect it to be necessary.
I haven't seen anything in the Release Notes suggesting that it is necessary.
> On 8/7/20 9:40 am, David Wright wrote:
> >> The mentioned intramfs config file has a strange note about it being "dangerous" to enable activate all logical volumes, why?!?!?!
> > A reference to the specific file would help. I see no mention here.
>
> Line 35 of /usr/share/initramfs-tools/scripts/local-top/lvm2 (see below) that mentions the risk:
>
> Also see the attached email that I sent to the Devuan DNG list for more reference.
>
> Below is the file I changed, added line numbered as 63.
>
> # cat -n /usr/share/initramfs-tools/scripts/local-top/lvm2
> 1 #!/bin/sh
> 2
> 3 PREREQ="mdadm mdrun multipath"
> 4
> 5 prereqs()
> 6 {
> 7 echo "$PREREQ"
> 8 }
> 9
> 10 case $1 in
> 11 # get pre-requisites
> 12 prereqs)
> 13 prereqs
> 14 exit 0
> 15 ;;
> 16 esac
> 17
> 18 if [ ! -e /sbin/lvm ]; then
> 19 exit 0
> 20 fi
> 21
> 22 lvchange_activate() {
> 23 lvm lvchange -aay -y --sysinit --ignoreskippedcluster "$@"
> 24 }
> 25
> 26 activate() {
> 27 local dev="$1"
> 28
> 29 # Make sure that we have a non-empty argument
> 30 if [ -z "$dev" ]; then
> 31 return 1
> 32 fi
> 33
> 34 case "$dev" in
> 35 # Take care of lilo boot arg, risky activating of all vg
> 36 fe[0-9]*)
> 37 lvchange_activate
> 38 exit 0
> 39 ;;
> 40 # FIXME: check major
> 41 /dev/root)
> 42 lvchange_activate
> 43 exit 0
> 44 ;;
> 45
> 46 /dev/mapper/*)
> 47 eval $(dmsetup splitname --nameprefixes --noheadings --rows "${dev#/dev/mapper/}")
> 48 if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
> 49 lvchange_activate "$DM_VG_NAME/$DM_LV_NAME"
> 50 fi
> 51 ;;
> 52
> 53 /dev/*/*)
> 54 # Could be /dev/VG/LV; use lvs to check
> 55 if lvm lvs -- "$dev" >/dev/null 2>&1; then
> 56 lvchange_activate "$dev"
> 57 fi
> 58 ;;
> 59 esac
> 60 }
> 61
> 62 activate "$ROOT"
> 63 activate "/dev/mapper/vg0-usr"
> 64 activate "$resume"
> 65
> 66 exit 0
>
> A line for /usr is in /etc/fstab using it's UUID ... same as root is referenced by UUID (both are in the same lvm2 volume group).
Well, this could be your problem. The jessie Release Notes say:
--✄--------
4.6.2 Changes to root and /usr filesystem mounting and checking
initramfs-tools will now also run fsck on the root filesystem before
mounting it. If the chosen init program is systemd and there is a
separate /usr filesystem, it will also fsck and mount /usr.
• If /usr is a separate filesystem on a RAID device and the
INITRDSTART setting in /etc/default/mdadm is not ’all’, you
will need to change it to include that device.
• If /usr is a separate filesystem on an LVM logical volume, and
the line for /usr in /etc/fstab specifies the device by UUID or
LABEL, you must change this line to specify the device using
the format /dev/mapper/VG-LV or /dev/VG/LV.
• It is no longer possible to bind-mount the /usr filesystem.
--✄--------
> NB: If /usr wasn't being used with lvm2, then this problem might not have surfaced and it probably would not have been a problem if the whole VG was activated instead of just the
> root file system because the UUID would have been "known or attainable" from the logical volumes.
> Date: Tue, 7 Jul 2020 02:00:38 +1000
> From: Andrew McGlashan via Dng <dng@lists.dyne.org>
> Subject: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left
> at initramfs shell -- with fix and query
>
> I had another "simple" server upgrade from Devuan Ascii to Devuan Beowulf, these are the details and my work around for the problem.
>
> There was nothing particularly special about this server, it doesn't use encrypted file systems; it started out life as a Debian Wheezy installation, migrated to Devuan Jessie and
So perhaps you didn't see Debian's Release Notes.
> later to Devuan Ascii and now Beowulf.
>
> The server has /boot on it's own RAID1 partition with another RAID1 volume for the rest of the disk being an LVM2 volume group having a number of logical volumes for root, swap,
> /usr/, /var/, /home/ and more.
>
> After the dist-upgrade, it failed to boot and remained at the ministrants shell environment after having complained about not being able to find the /usr file system via it's UUID.
>
> It had another error as well which was fixed by allocating 25% to RUNSIZE variable (up from 10%) in /etc/initramfs-tools/initramfs.conf
>
> - it was unable to find "rm" when running the boot up scripts before dumping itself to the initramfs shell.
>
> Once at the initramfs prompt after fixing the first problem, I was able to do the following:
>
> (initramfs) lvm
>
> lvm> vgchange -ay
>
> lvm> exit
>
> (initramfs) exit
>
> And then the server would continue to boot properly.
>
> _The second fix, which I consider to be "clunky", was to adjust the /usr/share/initramfs-tools/scripts/local-top/lvm2 file, adding in a line near the bottom as highlighted_
>
> activate "$ROOT"
> *activate "/dev/mapper/vg0-usr"*
> activate "$resume"
>
> Then I rebuilt the initramfs in the usual way.
>
> update-initramfs -u -k all
>
> The original lvm2 script specifically only activated the root file system (/dev/mapper/vg0-root), even though /usr (/dev/mapper/vg0-usr) was in the exact same volume group as a
> separate file system, thus stopping boot from succeeding as expected.
>
> Other volumes come online in due course okay.
>
> All was good with subsequent reboots.
>
> Now, cludge or clunky, this was required because the /usr file system was [and continues to be] separate to the root file system and the initramfs only cared to enable the root
> file system, leaving all other logical volumes as being "NOT AVAILABLE", including /usr which was definitely required!
>
> Have I fixed this appropriately, or should I some how fix it another way?
The Release Notes for stretch are below. I have no idea what Devuan's
equivalent looks like.
--✄--------
5.1.1. Late mounting of /usr is no longer supported
Note
This section only applies to systems using a custom kernel, where
/usr is on a separate mount point from /. If you use the kernel
packages provided by Debian, you are unaffected by this issue.
Mounting of /usr using only tools found in / is no longer
supported. This has only worked for a few specific configurations
in the past, and now they are explicitly unsupported.
This means that for stretch all systems where /usr is a separate
partition need to use an initramfs generator that will mount /
usr. All initramfs generators in stretch do so.
--✄--------
Cheers,
David.
Reply to: