Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224503 > unrolled thread

Re: Suggestion for systemd and /usr on seperate partition

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Suggestion for systemd and /usr on seperate partition Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2020-07-07 17:00 +0200
    Re: Suggestion for systemd and /usr on seperate partition David Wright <deblis@lionunicorn.co.uk> - 2020-07-07 18:10 +0200
      Re: Suggestion for systemd and /usr on seperate partition Michael Stone <mstone@debian.org> - 2020-07-07 18:30 +0200
        Re: Suggestion for systemd and /usr on seperate partition Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2020-07-07 19:00 +0200
          Re: Suggestion for systemd and /usr on seperate partition David Wright <deblis@lionunicorn.co.uk> - 2020-07-08 02:00 +0200
          Re: Suggestion for systemd and /usr on seperate partition Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-08 08:00 +0200
            Re: Suggestion for systemd and /usr on seperate partition Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2020-07-08 10:30 +0200
              Re: Suggestion for systemd and /usr on seperate partition Michael Stone <mstone@debian.org> - 2020-07-08 15:30 +0200
              Re: Suggestion for systemd and /usr on seperate partition David Wright <deblis@lionunicorn.co.uk> - 2020-07-08 16:40 +0200
            Re: Suggestion for systemd and /usr on seperate partition <tomas@tuxteam.de> - 2020-07-08 10:40 +0200
              Re: Suggestion for systemd and /usr on seperate partition Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-09 10:20 +0200
                Re: Suggestion for systemd and /usr on seperate partition <tomas@tuxteam.de> - 2020-07-09 11:20 +0200
                  Re: Suggestion for systemd and /usr on seperate partition David Wright <deblis@lionunicorn.co.uk> - 2020-07-09 16:40 +0200
                  Re: Suggestion for systemd and /usr on seperate partition Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-09 18:20 +0200

#224503 — Re: Suggestion for systemd and /usr on seperate partition

[Multipart message — attachments visible in raw view] — view raw

On 2/11/14 8:58 am, Elimar Riesebieter wrote:
> * David Baron <d_baron@012.net.il> [2014-11-01 19:13 +0200]:
> 
>> On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote:
> 
> [...]
> 
>>> It's your decision. MODULES=most should be okay. BUSYBOX=y is
>>> essential.
>>
>> This is what the install gave me.  I have not touched it.
>> Where do I tell it to mount /usr?
> 
> No need to. initramfs-tools does it by default. Check dmesg or
> journal.

Still today, it fails to mount /usr if /usr is a logical volume using lvm2


I worked around that problem with an extra "activate" line in the following file:

   /usr/share/initramfs-tools/scripts/local-top/lvm2

       activate "/dev/mapper/vg0-usr"


I placed that after the line to activate ROOT....

So, still broken after all this time :(



# dpkg-query -l |grep initramfs
ii  initramfs-tools                        0.133+deb10u1                      all          generic modular initramfs generator (automation)
ii  initramfs-tools-core                   0.133+deb10u1                      all          generic modular initramfs generator (core tools)
ii  libklibc:amd64                         2.0.6-1                            amd64        minimal libc subset for use with initramfs



# aptitude show initramfs-tools initramfs-tools-core
Wed  8 Jul 00:40:15 AEST 2020 -- show initramfs-tools initramfs-tools-core
Package: initramfs-tools
Version: 0.133+deb10u1
State: installed
Automatically installed: no
Multi-Arch: foreign
Priority: optional
Section: utils
Maintainer: Debian kernel team <debian-kernel@lists.debian.org>
Architecture: all
Uncompressed Size: 114 k
Depends: initramfs-tools-core (= 0.133+deb10u1), linux-base
Suggests: bash-completion
Conflicts: linux-initramfs-tool, usplash (< 0.5.50)
Breaks: e2fsprogs (< 1.42.13), initscripts (< 2.88dsf-59.3~), upstart
Provides: linux-initramfs-tool
Description: generic modular initramfs generator (automation)

Tags: admin::boot, admin::filesystem, admin::install, admin::kernel, devel::lang:c, devel::library, implemented-in::c, implemented-in::shell, interface::commandline,
role::devel-lib, role::program, scope::application, scope::utility, works-with::archive

Package: initramfs-tools-core
Version: 0.133+deb10u1
New: yes
State: installed
Automatically installed: yes
Multi-Arch: foreign
Priority: optional
Section: utils
Maintainer: Debian kernel team <debian-kernel@lists.debian.org>
Architecture: all
Uncompressed Size: 213 k
Depends: klibc-utils (>= 2.0.4-8~), cpio (>= 2.12), kmod, udev, coreutils (>= 8.24), e2fsprogs
Recommends: busybox (>= 1:1.22.0-17~) | busybox-static (>= 1:1.22.0-17~), pigz
Suggests: bash-completion
Breaks: busybox (< 1:1.22.0-17~), busybox-static (< 1:1.22.0-17~), initramfs-tools (< 0.121~)
Replaces: initramfs-tools (< 0.121~)
Description: generic modular initramfs generator (core tools)



This is a system now running Devuan Beowulf btw, but it gets most of it's packages directly from Debian repos.


A.

[toc] | [next] | [standalone]

#224510

On Wed 08 Jul 2020 at 00:41:12 (+1000), Andrew McGlashan wrote:
> On 2/11/14 8:58 am, Elimar Riesebieter wrote:
> > * David Baron <d_baron@012.net.il> [2014-11-01 19:13 +0200]:
> >> On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote:
> > 
> > [...]
> > 
> >>> It's your decision. MODULES=most should be okay. BUSYBOX=y is
> >>> essential.
> >>
> >> This is what the install gave me.  I have not touched it.
> >> Where do I tell it to mount /usr?
> > 
> > No need to. initramfs-tools does it by default. Check dmesg or
> > journal.
> 
> Still today, it fails to mount /usr if /usr is a logical volume using lvm2
> 
> I worked around that problem with an extra "activate" line in the following file:
> 
>    /usr/share/initramfs-tools/scripts/local-top/lvm2
> 
>        activate "/dev/mapper/vg0-usr"
> 
> I placed that after the line to activate ROOT....
> 
> So, still broken after all this time :(

Is this link worth a read?

https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

BTW the first line of the thread is "completely without starting any flamewars:"

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224512

On Tue, Jul 07, 2020 at 10:45:17AM -0500, David Wright wrote:
>On Wed 08 Jul 2020 at 00:41:12 (+1000), Andrew McGlashan wrote:
>> On 2/11/14 8:58 am, Elimar Riesebieter wrote:
>> > * David Baron <d_baron@012.net.il> [2014-11-01 19:13 +0200]:
>> >> On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote:
>> >
>> > [...]
>> >
>> >>> It's your decision. MODULES=most should be okay. BUSYBOX=y is
>> >>> essential.
>> >>
>> >> This is what the install gave me.  I have not touched it.
>> >> Where do I tell it to mount /usr?
>> >
>> > No need to. initramfs-tools does it by default. Check dmesg or
>> > journal.
>>
>> Still today, it fails to mount /usr if /usr is a logical volume using lvm2
>>
>> I worked around that problem with an extra "activate" line in the following file:
>>
>>    /usr/share/initramfs-tools/scripts/local-top/lvm2
>>
>>        activate "/dev/mapper/vg0-usr"
>>
>> I placed that after the line to activate ROOT....
>>
>> So, still broken after all this time :(
>
>Is this link worth a read?
>
>https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
>
>BTW the first line of the thread is "completely without starting any flamewars:"

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.

[toc] | [prev] | [next] | [standalone]

#224516

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 8/7/20 2:11 am, Michael Stone wrote:
> On Tue, Jul 07, 2020 at 10:45:17AM -0500, David Wright wrote:
>> On Wed 08 Jul 2020 at 00:41:12 (+1000), Andrew McGlashan wrote:
>>> On 2/11/14 8:58 am, Elimar Riesebieter wrote:
>>> > * David Baron <d_baron@012.net.il> [2014-11-01 19:13 +0200]:
>>> >> On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote:
>>> >
>>> > [...]
>>> >
>>> >>> It's your decision. MODULES=most should be okay. BUSYBOX=y is
>>> >>> essential.
>>> >>
>>> >> This is what the install gave me.  I have not touched it.
>>> >> Where do I tell it to mount /usr?
>>> >
>>> > No need to. initramfs-tools does it by default. Check dmesg or
>>> > journal.
>>>
>>> Still today, it fails to mount /usr if /usr is a logical volume using lvm2
>>>
>>> I worked around that problem with an extra "activate" line in the following file:
>>>
>>>    /usr/share/initramfs-tools/scripts/local-top/lvm2
>>>
>>>        activate "/dev/mapper/vg0-usr"
>>>
>>> I placed that after the line to activate ROOT....
>>>
>>> So, still broken after all this time :(
>>
>> Is this link worth a read?
>>
>> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
>>
>> BTW the first line of the thread is "completely without starting any flamewars:"
> 
> 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.

The mentioned intramfs config file has a strange note about it being "dangerous" to enable activate all logical volumes, why?!?!?!

Debian/Devuan are Linux distros that allow for continuous upgrading without re-installing; the fact that MANY systems have previously separated root and /usr and, effectively
"times have changed" really isn't an acceptable answer.

Even systemd doesn't seem to think it should be a problem for those that choose to use systemd.

A.

[toc] | [prev] | [next] | [standalone]

#224547

On Wed 08 Jul 2020 at 02:35:09 (+1000), Andrew McGlashan wrote:
> On 8/7/20 2:11 am, Michael Stone wrote:
> > On Tue, Jul 07, 2020 at 10:45:17AM -0500, David Wright wrote:
> >> On Wed 08 Jul 2020 at 00:41:12 (+1000), Andrew McGlashan wrote:
> >>> On 2/11/14 8:58 am, Elimar Riesebieter wrote:
> >>> > * David Baron <d_baron@012.net.il> [2014-11-01 19:13 +0200]:
> >>> >> On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote:
> >>> >
> >>> > [...]
> >>> >
> >>> >>> It's your decision. MODULES=most should be okay. BUSYBOX=y is
> >>> >>> essential.
> >>> >>
> >>> >> This is what the install gave me.  I have not touched it.
> >>> >> Where do I tell it to mount /usr?
> >>> >
> >>> > No need to. initramfs-tools does it by default. Check dmesg or
> >>> > journal.
> >>>
> >>> Still today, it fails to mount /usr if /usr is a logical volume using lvm2
> >>>
> >>> I worked around that problem with an extra "activate" line in the following file:
> >>>
> >>>    /usr/share/initramfs-tools/scripts/local-top/lvm2
> >>>
> >>>        activate "/dev/mapper/vg0-usr"
> >>>
> >>> I placed that after the line to activate ROOT....
> >>>
> >>> So, still broken after all this time :(
> >>
> >> Is this link worth a read?
> >>
> >> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> >>
> >> BTW the first line of the thread is "completely without starting any flamewars:"
> > 
> > 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.

Agreed, but I think both the OP and the reviver are discussing
legacy-partitioned systems. AFAIK these have remained upgradable
on stable from wheezy¹ through to buster—or are you saying that
that's not true? (IDK: all my primary (buster) systems are
/usr-merged too, being installed afresh.)

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

The reason I included that line was that the page includes:
   "It isn't systemd's fault. systemd mostly works fine with /usr on a
    separate file system that is not pre-mounted at boot."
That had been true for years before this 2014 thread started.
It would be easy to think that the subject line was suggesting this is
not the case, and for the thread to pick up flames. That's all.

> Just doing dist-upgrade with a perfectly acceptable file system previously is no reason why it should break.

Quite right. You read the Release Notes and follow their advice at each upgrade.

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

> Debian/Devuan are Linux distros that allow for continuous upgrading without re-installing; the fact that MANY systems have previously separated root and /usr and, effectively
> "times have changed" really isn't an acceptable answer.

True; I would expect at least a migration path for each distribution.

> Even systemd doesn't seem to think it should be a problem for those that choose to use systemd.

I'm not clear what the significance of "Even …" is. You are presumably
not running systemd, in view of this:

> >>> This is a system now running Devuan Beowulf btw, but it gets most of it's packages directly from Debian repos.

So what steps did you take since, say, wheezy¹ to compensate for the
changes that have been come about?

¹ IIRC booting wheezy did not require anything from /usr until the
scripts in /etc/init.d/ had mounted /usr as per /etc/fstab.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224576

[Multipart message — attachments visible in raw view] — view raw

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 was under the impression that LVM is used in particular for its 
flexibility in adjusting your partitions. What prevents you from merging 
'/' and '/usr'?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224581

[Multipart message — attachments visible in raw view] — view raw

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



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).


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.



Kind Regards
AndrewM

[toc] | [prev] | [next] | [standalone]

#224592

On Wed, Jul 08, 2020 at 06:07:05PM +1000, Andrew McGlashan wrote:
>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).

Why not just reference it by path?

[toc] | [prev] | [next] | [standalone]

#224598

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.

[toc] | [prev] | [next] | [standalone]

#224582

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 08, 2020 at 08:35:35AM +0300, Andrei POPESCU wrote:

[...]

> I was under the impression that LVM is used in particular for its 
> flexibility in adjusting your partitions.

But it won't make disappear a separate /usr partition "by magic".

> What prevents you from merging '/' and '/usr'?

This thread is talking about upgrades. Do you suggest an upgrade
copying the contents of the /usr partition over to the / partition
and dropping the separate /usr (perhaps recovering the space somehow)?

Sounds pretty risky.

FWIW, I still have a separate /usr on Buster (inherited from older
installations). I'd have no problems with a merged /usr, but hey,
I have no problems with leaving things as they are either.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#224631

[Multipart message — attachments visible in raw view] — view raw

On Mi, 08 iul 20, 10:20:45, tomas@tuxteam.de wrote:
> On Wed, Jul 08, 2020 at 08:35:35AM +0300, Andrei POPESCU wrote:
> 
> [...]
> 
> > I was under the impression that LVM is used in particular for its 
> > flexibility in adjusting your partitions.
> 
> But it won't make disappear a separate /usr partition "by magic".
> 
> > What prevents you from merging '/' and '/usr'?
> 
> This thread is talking about upgrades. Do you suggest an upgrade
> copying the contents of the /usr partition over to the / partition
> and dropping the separate /usr (perhaps recovering the space somehow)?
 
Or the other way around ('/usr' could be bigger than '/'). 

> Sounds pretty risky.

Sure. On the other hand, what is the point of using LVM if one is not 
going to use it to adjust partitions when required?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224634

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 09, 2020 at 10:56:26AM +0300, Andrei POPESCU wrote:

[...]

> > Sounds pretty risky.
> 
> Sure. On the other hand, what is the point of using LVM if one is not 
> going to use it to adjust partitions when required?

You first have to copy stuff, then delete stuff, then shrink, then move
around. So at some point, you need double the space /usr is taking.

LVM won't change that.

Not a process I'd be comfortable rolling out for a distro to run
automatically on wildly different user's machines out there. No way.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#224650

On Thu 09 Jul 2020 at 11:02:49 (+0200), tomas@tuxteam.de wrote:
> On Thu, Jul 09, 2020 at 10:56:26AM +0300, Andrei POPESCU wrote:
> 
> [...]
> 
> > > Sounds pretty risky.
> > 
> > Sure. On the other hand, what is the point of using LVM if one is not 
> > going to use it to adjust partitions when required?
> 
> You first have to copy stuff, then delete stuff, then shrink, then move
> around. So at some point, you need double the space /usr is taking.
> 
> LVM won't change that.
> 
> Not a process I'd be comfortable rolling out for a distro to run
> automatically on wildly different user's machines out there. No way.

Agreed. And implementing such a change as an upgrade, running on the
system that's being "adjusted", seems misguided.

A separate / and /usr only becomes an encumbrance when you boot the
system: there's no problem while the system is up and running.
So there's no reason to change it on a live system: wait until it's
down for some reason.

And read the Release Notes before a dist-upgrade!

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224654

[Multipart message — attachments visible in raw view] — view raw

On Jo, 09 iul 20, 11:02:49, tomas@tuxteam.de wrote:
> On Thu, Jul 09, 2020 at 10:56:26AM +0300, Andrei POPESCU wrote:
> 
> [...]
> 
> > > Sounds pretty risky.
> > 
> > Sure. On the other hand, what is the point of using LVM if one is not 
> > going to use it to adjust partitions when required?
> 
> You first have to copy stuff, then delete stuff, then shrink, then move
> around. So at some point, you need double the space /usr is taking.
> 
> LVM won't change that.
> 
> Not a process I'd be comfortable rolling out for a distro to run
> automatically on wildly different user's machines out there. No way.

Did I imply it should be done automatically? That was definitely *not* 
my intention.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web