On Wed, Dec 08, 2021 at 11:36:47PM +0100, Philip Hands wrote:
>Pascal Hambourg <pas...@plouf.fr.eu.org> writes:
>
>> Le 08/12/2021 à 10:49, Philip Hands a écrit :
>>>
>>> Is it a problem if /home or /usr/share are left unmounted during rescue?
>>
>> /usr/share contains architecture-independent files for many programs
>> such as bash, grub, os-prober, debconf, dpkg, initramfs-tools...
>>
>> How common is it to have a separate /usr/share and what is the rationale
>> for it ?
>
>Not common at all, I'd guess.
>
>Back in the days when /usr was not needed to boot, I have occasionally
>moved part or all of /usr/share (most often just /usr/share/doc) onto
>another partition and then put a symlink in, in order to make space when
>it turned out that /usr was filling up and it was too painful to resize.
>
>If doing that makes things break during a rescue attempt these days, it
>seems fairly likely to break during normal boot, so doing that seems
>likely to be the reason for running the rescue system, in which case
>you're going to have to mount wherever /usr/share is now yourself, and
>you really ought to remember how you just broke the system, so that
>seems like no great hardship.
Nod. A separate /usr filesystem is a configuration that was supported
well by d-i and Debian for a number of years, hence I agreed that it
was worth improving rescue-mode to explicitly support it. I *could*
also be convinced that we should do similar for a separate /var. Other
more exotic configurations are not as important IMHO:
1. People configuring with *many* filesystems that they may want
can run mount manually inside /target once things have started
2. The main point of rescue mode (IMHO) is to get a system up and
running *normally*, particularly if it doesn't boot
currently. Hence the focus on /boot, boot/efi and now /usr. I
believe we should not try to extend that list willy-nilly.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
