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 <d...@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.
