Debian Bug report logs - #823612
rescue-mode should mount /boot/efi if it's available

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: rescue-mode should mount /boot/efi if it's available

Date: Fri, 06 May 2016 15:32:01 +0100

Package: rescue-mode
Version: 1.51
Severity: important

If somebody is trying to debug EFI boot problems, it's quite confusing
for people that /boot/efi is not mounted automatically.

What makes this even worse is that /etc/mtab will be outdated and
/boot/efi will therefore *appear* to be mounted using df, mount,
etc. That's a separate bug, though...

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Message #10 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Steve McIntyre <steve@einval.com>, 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Tue, 21 Jun 2016 21:44:08 +0200

[Message part 1 (text/plain, inline)]

Hi,

Steve McIntyre <steve@einval.com> (2016-05-06):
> Package: rescue-mode
> Version: 1.51
> Severity: important
> 
> If somebody is trying to debug EFI boot problems, it's quite confusing
> for people that /boot/efi is not mounted automatically.

*oops*

Is anyone working on that?

Quick pointers into src:rescue-mode:

    debian/rescue-mode.postinst:has_separate_boot () {
    debian/rescue-mode.templates:Template: rescue/separate-boot


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Cyril Brulebois <kibi@debian.org>

Cc: 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Wed, 22 Jun 2016 15:13:13 +0100

On Tue, Jun 21, 2016 at 09:44:08PM +0200, Cyril Brulebois wrote:
>Hi,
>
>Steve McIntyre <steve@einval.com> (2016-05-06):
>> Package: rescue-mode
>> Version: 1.51
>> Severity: important
>> 
>> If somebody is trying to debug EFI boot problems, it's quite confusing
>> for people that /boot/efi is not mounted automatically.
>
>*oops*
>
>Is anyone working on that?
>
>Quick pointers into src:rescue-mode:
>
>    debian/rescue-mode.postinst:has_separate_boot () {
>    debian/rescue-mode.templates:Template: rescue/separate-boot

I filed the bug as a reminder for me to fix it; if not before, I'll
play with this at DC16.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Message #20 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Cyril Brulebois <kibi@debian.org>

Cc: 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Tue, 28 Jun 2016 12:57:23 +0100

On Wed, Jun 22, 2016 at 03:13:13PM +0100, Steve McIntyre wrote:
>On Tue, Jun 21, 2016 at 09:44:08PM +0200, Cyril Brulebois wrote:
>>Hi,
>>
>>Steve McIntyre <steve@einval.com> (2016-05-06):
>>> Package: rescue-mode
>>> Version: 1.51
>>> Severity: important
>>> 
>>> If somebody is trying to debug EFI boot problems, it's quite confusing
>>> for people that /boot/efi is not mounted automatically.
>>
>>*oops*
>>
>>Is anyone working on that?
>>
>>Quick pointers into src:rescue-mode:
>>
>>    debian/rescue-mode.postinst:has_separate_boot () {
>>    debian/rescue-mode.templates:Template: rescue/separate-boot
>
>I filed the bug as a reminder for me to fix it; if not before, I'll
>play with this at DC16.

So, I've been pondering about this a little. At the moment, rescue
just tends to mount the root filesystem and nothing else. Then the
user is left to work out how to mount the rest of their system (if
needed) on their own. I'm thinking we could/should improve this - once
we've mounted the rootfs, we could offer to mount (likely-looking?)
other filesystems from /etc/fstab. Maybe with a selection interface,
and we automatically tag the likely ones?

What do you think?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Message #25 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Steve McIntyre <steve@einval.com>

Cc: 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Tue, 28 Jun 2016 14:15:32 +0200

[Message part 1 (text/plain, inline)]

Steve McIntyre <steve@einval.com> (2016-06-28):
> So, I've been pondering about this a little. At the moment, rescue
> just tends to mount the root filesystem and nothing else. Then the
> user is left to work out how to mount the rest of their system (if
> needed) on their own. I'm thinking we could/should improve this - once
> we've mounted the rootfs, we could offer to mount (likely-looking?)
> other filesystems from /etc/fstab. Maybe with a selection interface,
> and we automatically tag the likely ones?
> 
> What do you think?

Your summary isn't entirely accurate: we already prompt when separate
boot is detected; we could elaborate on that for /boot/efi, which was
my initial point.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Cyril Brulebois <kibi@debian.org>

Cc: 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Tue, 28 Jun 2016 14:38:59 +0100

On Tue, Jun 28, 2016 at 02:15:32PM +0200, Cyril Brulebois wrote:
>Steve McIntyre <steve@einval.com> (2016-06-28):
>> So, I've been pondering about this a little. At the moment, rescue
>> just tends to mount the root filesystem and nothing else. Then the
>> user is left to work out how to mount the rest of their system (if
>> needed) on their own. I'm thinking we could/should improve this - once
>> we've mounted the rootfs, we could offer to mount (likely-looking?)
>> other filesystems from /etc/fstab. Maybe with a selection interface,
>> and we automatically tag the likely ones?
>> 
>> What do you think?
>
>Your summary isn't entirely accurate: we already prompt when separate
>boot is detected; we could elaborate on that for /boot/efi, which was
>my initial point.

Ah, OK. Thanks for correcting me. I should actually look at the
code... :-)

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
            handing rope-creating factories for users to hang multiple
            instances of themselves.

Message #35 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Cyril Brulebois <kibi@debian.org>, 823612@bugs.debian.org, Steve McIntyre <steve@einval.com>

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Tue, 28 Jun 2016 21:13:25 +0200

[Message part 1 (text/plain, inline)]

On Tue, 2016-06-28 at 14:15 +0200, Cyril Brulebois wrote:
> Steve McIntyre <steve@einval.com> (2016-06-28):
> > So, I've been pondering about this a little. At the moment, rescue
> > just tends to mount the root filesystem and nothing else. Then the
> > user is left to work out how to mount the rest of their system (if
> > needed) on their own. I'm thinking we could/should improve this -
> > once
> > we've mounted the rootfs, we could offer to mount (likely-looking?)
> > other filesystems from /etc/fstab. Maybe with a selection
> > interface,
> > and we automatically tag the likely ones?
> > 
> > What do you think?
> 
> Your summary isn't entirely accurate: we already prompt when separate
> boot is detected; we could elaborate on that for /boot/efi, which was
> my initial point.

I wonder why we offer to mount /boot but not /usr (more and more
programs live there), /var (some of them might need state there) or
/tmp (don't want to create files there that will never be cleaned up).

Also, does the question about mounting /boot really merit critical
priority?  Is 'yes' not a good default?

Ben.

-- 

Ben Hutchings
If at first you don't succeed, you're doing about average.

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: Cyril Brulebois <kibi@debian.org>, 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Fri, 1 Jul 2016 21:56:38 +0100

On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
>
>I wonder why we offer to mount /boot but not /usr (more and more
>programs live there), /var (some of them might need state there) or
>/tmp (don't want to create files there that will never be cleaned up).

Maybe, yes. For now I've made the code here much more generic to make
it easier to ask about other filesystems, and added a check for
/boot/efi too.

>Also, does the question about mounting /boot really merit critical
>priority?  Is 'yes' not a good default?

*If* the /boot fs is broken, attempting to auto-mount is probably not
a good plan. This is about the only sensible way to allow people to
control that, I guess.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/

Message #45 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Steve McIntyre <steve@einval.com>

Cc: Cyril Brulebois <kibi@debian.org>, 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Fri, 01 Jul 2016 23:41:58 +0200

[Message part 1 (text/plain, inline)]

On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
> On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
> > 
> > I wonder why we offer to mount /boot but not /usr (more and more
> > programs live there), /var (some of them might need state there) or
> > /tmp (don't want to create files there that will never be cleaned
> > up).
> 
> Maybe, yes. For now I've made the code here much more generic to make
> it easier to ask about other filesystems, and added a check for
> /boot/efi too.
> 
> > Also, does the question about mounting /boot really merit critical
> > priority?  Is 'yes' not a good default?
> 
> *If* the /boot fs is broken, attempting to auto-mount is probably not
> a good plan.

That's true.  Perhaps the sensible thing is perhaps to mount /usr and
the virtual filesystems unconditionally, and then ask whether to mount
all the other local filesystem ('mount -a -O no_network').

Ben.

>  This is about the only sensible way to allow people to
> control that, I guess.
> 
-- 

Ben Hutchings
All extremists should be taken out and shot.

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: Cyril Brulebois <kibi@debian.org>, 823612@bugs.debian.org

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Fri, 1 Jul 2016 23:05:57 +0100

On Fri, Jul 01, 2016 at 11:41:58PM +0200, Ben Hutchings wrote:
>On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
>> On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
>> > 
>> > I wonder why we offer to mount /boot but not /usr (more and more
>> > programs live there), /var (some of them might need state there) or
>> > /tmp (don't want to create files there that will never be cleaned
>> > up).
>> 
>> Maybe, yes. For now I've made the code here much more generic to make
>> it easier to ask about other filesystems, and added a check for
>> /boot/efi too.
>> 
>> > Also, does the question about mounting /boot really merit critical
>> > priority?  Is 'yes' not a good default?
>> 
>> *If* the /boot fs is broken, attempting to auto-mount is probably not
>> a good plan.
>
>That's true.  Perhaps the sensible thing is perhaps to mount /usr and
>the virtual filesystems unconditionally, and then ask whether to mount
>all the other local filesystem ('mount -a -O no_network').

How are /usr and any other disk-based filesystems likely to be any
different to /boot here?

I'd agree about the virtual fsen...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Message #55 received at 823612@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Steve McIntyre <steve@einval.com>, 823612@bugs.debian.org

Cc: Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#823612: rescue-mode should mount /boot/efi if it's available

Date: Sat, 02 Jul 2016 01:16:38 +0200

[Message part 1 (text/plain, inline)]

On Fri, 2016-07-01 at 23:05 +0100, Steve McIntyre wrote:
> On Fri, Jul 01, 2016 at 11:41:58PM +0200, Ben Hutchings wrote:
> > On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
> > > On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
> > > > 
> > > > I wonder why we offer to mount /boot but not /usr (more and more
> > > > programs live there), /var (some of them might need state there) or
> > > > /tmp (don't want to create files there that will never be cleaned
> > > > up).
> > > 
> > > Maybe, yes. For now I've made the code here much more generic to make
> > > it easier to ask about other filesystems, and added a check for
> > > /boot/efi too.
> > > 
> > > > Also, does the question about mounting /boot really merit critical
> > > > priority?  Is 'yes' not a good default?
> > > 
> > > *If* the /boot fs is broken, attempting to auto-mount is probably not
> > > a good plan.
> > 
> > That's true.  Perhaps the sensible thing is perhaps to mount /usr and
> > the virtual filesystems unconditionally, and then ask whether to mount
> > all the other local filesystem ('mount -a -O no_network').
> 
> How are /usr and any other disk-based filesystems likely to be any
> different to /boot here?

/usr should be mounted unconditionally because binaries on the root
filesystem may in practice depend on it or there may not even be any
binaries on the root filesystem (https://wiki.debian.org/UsrMerge).

For the other local filesystems, I'm proposing that we ask a single
question whether to mount them rather than asking separately about
/boot, /boot/efi, etc.

> I'd agree about the virtual fsen...

And the essential virtual filesystems do already get mounted
unconditionally.

Ben.

-- 

Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 823612-close@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: 823612-close@bugs.debian.org

Subject: Bug#823612: fixed in rescue 1.57

Date: Mon, 04 Jul 2016 16:29:40 +0000

Source: rescue
Source-Version: 1.57

We believe that the bug you reported is fixed in the latest version of
rescue, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 823612@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier <bubulle@debian.org> (supplier of updated rescue package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 04 Jul 2016 16:00:20 +0200
Source: rescue
Binary: rescue-check rescue-mode
Architecture: source all
Version: 1.57
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Christian Perrier <bubulle@debian.org>
Description:
 rescue-check - enter d-i rescue mode if requested (udeb)
 rescue-mode - mount requested partition and start a rescue shell (udeb)
Closes: 823612
Changes:
 rescue (1.57) unstable; urgency=medium
 .
   [ Steve McIntyre ]
   * Extend the support for checking for and mounting /boot to be more
     generic. Add mounting of /boot/efi for now. Closes: #823612
Checksums-Sha1:
 fb8f7358f908ede9931a87d01eeacd1efac1dfe6 1663 rescue_1.57.dsc
 90d5b3497f5b6f06c36bbbbd55ea4577839bc8b2 134032 rescue_1.57.tar.xz
 beb96d4496d4ca8e876ccd2441b3ec94e96da86c 2616 rescue-check_1.57_all.udeb
 41064cc6747329d05672043b0a525d7820d223e1 142178 rescue-mode_1.57_all.udeb
Checksums-Sha256:
 33d38c7fc964cefe4c099c621b01a5e3b4986f2b4f3c4169d7ebc9c36ae79ce6 1663 rescue_1.57.dsc
 e0b315756f17a8f80070ee1d4bce8ce34094c3b6034bf5706d244a383cc53e46 134032 rescue_1.57.tar.xz
 b53c4b79e63289dd5d8bd06c40f23bd603c55ed24e518a9ae95b1e585b9d1861 2616 rescue-check_1.57_all.udeb
 7dcbab19250abbc144bcb8d8b8175eb51f20d8ae98667ddee04607a9ff831548 142178 rescue-mode_1.57_all.udeb
Files:
 827630e95462a963fb92841a670b8b77 1663 debian-installer optional rescue_1.57.dsc
 c66e5cd336b62de00b2ce2c43f5c1ca8 134032 debian-installer optional rescue_1.57.tar.xz
 67bbc8da0c46cf537ef3dab77178834c 2616 debian-installer standard rescue-check_1.57_all.udeb
 fde77ec1d44ce081d4156f5acb34a9fa 142178 debian-installer optional rescue-mode_1.57_all.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXem9LAAoJEIcvcCxNbiWo87wQAJY3BtHoa9IXGBMrgIEMXZLy
nJ7MqaTKrJYjUY32taK8JSe7E1vi+FpfcsvANZ9kxx+3OGsehWbNfBUitZoCGG+x
pSV8waMy2HbzG6hRJ8S+PLafNQP3BrZpSlvbUrLaVesDkotfiEYXJJIAxjriAjyO
/L1IeGTYYkiQXntGYREx/z4s2hGMJkHcALXVeoC9svNiENuQDJoB48gsqV/TVEnL
gar3TJioPVt0uZJy20juOk2x9/orOTArTls4x6O0SB9SKDK3dQ7ikyN1l8KdY66K
S0Ybp0L4RXSA8JPZ5ybDMPlCPupilpFA7Z9OqHPbShkzFevjAna+Yp3dRW6V+1p8
ocPsdiWOHLuN6qXfaPpmJ2u6gE2T04yV4BDtn+SOJMgcKNWnXYxDeC8Ult4rgdxf
ELZ4KbayFhLAJmtHUsWInQ3HIW1ZFLgLUglAmdATIB2ASXpRLh1ZqPd2k+rTbW3u
76zf5FkMe89t0hOg0ZfZT4B+S79Hth/sR+FrHwPOHFJ2IxxYImP/y2Lx3gGg7AOf
xS7r6DAOYSsaZBHqnqySdhVkONhngReOai1jAYVJk2kEXiCzV3AvIJdhnPs3u0Yc
9I7rZR5pYVQluZGMzFs8hMnQjYi8BDl4Ur3gkMhy6oJ6+CJXJDBnau8wyfOn7coZ
Mb08b8HiCcVs12kxXVBb
=+YvC
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.