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

Groups > linux.debian.maint.boot > #63603 > unrolled thread

Bug#963156: /cdrom should be remounted rw before partman executes, when mapped to an ESP

Back to article view | Back to linux.debian.maint.boot

Contents

  Bug#963156: /cdrom should be remounted rw before partman executes, when mapped to an ESP Pete Batard <pete@akeo.ie> - 2020-06-19 20:00 +0200
    Bug#963156: Would appreciate an update Pete Batard <pete@akeo.ie> - 2020-08-03 13:50 +0200
    Bug#963156: Patch submitted Pete Batard <pete@akeo.ie> - 2020-08-05 02:00 +0200
    Bug#963156: Patch submitted Pete Batard <pete@akeo.ie> - 2020-08-05 13:00 +0200
    Bug#963156: marked as done (/cdrom should be remounted rw before  partman executes, when mapped to an ESP) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-09-01 00:30 +0200

#63603 — Bug#963156: /cdrom should be remounted rw before partman executes, when mapped to an ESP

Package: partman-auto
Severity: important
Tags: d-i

(NB: Resubmitting this bug, which was already submitted as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963150, against 
partman-auto since "partman" does not appear to exist as a valid Debian 
package)


THE GOAL
========

When installing Debian from the official netinst ISO in UEFI mode it may 
be very convenient to do so by:
- Creating a large enough ESP (GPT or MBR) on the target installation 
disk (e.g. 350 MB)
- Extracting the ISO content to said ESP and let the UEFI system proceed 
from there.

Doing so alleviates the need to use two media to complete a Debian 
installation, where one can do, and, with disk capacity being plentiful 
nowadays, wasting a couple hundred MB can be seen as a good tradeof if 
it leads to a much easier GNU/Linux installation, especially on SoC 
systems where devices and ports may be limited.

For instance using a USB single media, with an ESP onto which the Debian 
11 netinst ISO has been extracted, is the method we are going to 
recommend to proceed with a Debian installation on the Raspberry Pi 4, 
since there now exists a UEFI firmware for that platform and Linux 
kernel 5.x has added the networking support required for netinst (which 
has already been backported to the Debian 11 5.x kernel).


THE PROBLEM
===========

One major roadblock with doing the above however is that, whereas 
partman correctly detects the ESP and attempts to use for its intended 
purpose (meaning that, after the Debian Installer has completed, EFI 
GRUB will be updated to replace the netinst bootloader, therefore 
handling boot for the final system), it ultimately fails to mount the 
ESP to /boot/efi because:

1. When booting from USB/HDD, the Debian installer has already mounted 
the ESP to /cdrom as *read-only*.

2. The Linux kernel prevents a block device from being mounted more than 
once *when the read/write permissions are going to be different*

This means that, if you have an ESP with the netinst ISO content in 
/dev/sda1, you will see it mounted as follows before partman launches:

] /dev/sda1 on /cdrom type vfat (ro,...)

But after you partition the system (whilst telling it to keep the 
existing ESP) partman will report the following error:

] The attempt to mount a file system with type vfat in SCSI1 (0,0,0),
] partition #1 (sda) at /boot/efi failed.

This effectively breaks the installation process and prevents users from 
reusing the ESP.

On the other hand, if you issue the command:

] mount -o remount,rw /dev/sda1 /cdrom

prior to executing partman, then everything works as expected.

Again, this is because /cdrom is then mounted read/write, which allows 
/boot/efi (which points to the same underlying block device) to also be 
mounted read/write, as required by partman for mounting ESPs as well as 
for the rest of the installation process.

In other words, the main issue is that, if an ESP is also used as the 
/cdrom device, then we *must* ensure that it is mounted rw by the time 
partman is invoked.

At this stage, I must stress how critical this issue is when it comes to 
ensuring that the installation of vanilla Debian on Raspberry Pi 4 can 
happen with the *exact same ease* as it does on a PC.

If we can fix this problem, then new Debian, wanting to use on a a Pi 4, 
  can simply create a USB drive with a small ESP, using the official 
netinst ISO (as well as the the Raspberry Pi UEFI firmware) and by 
simply plugging that drive on the device, they will proceed through an 
installation of Debian that's about as painless as the installation of 
Raspbian, even as the latter is specifically dedicated for that 
hardware. As such, it is highly desirable that this issue gets fixed for 
the 11.0 release.


THE POSSIBLE SOLUTIONS
======================

I am currently seeing 3 possibilities to address the issue above.

* OPTION #0: Ask users to switch to a shell when partman starts and 
issue a 'mount -o remount,rw' command. Dismissed as option 0, since the 
whole point behind opening this bug report is that asking users to 
toggle to a shell during install and enter a command that they might not 
be familiar with is a less than ideal solution, and one we should really 
strive to avoid.

* OPTION #1: Alter the cdrom mount script 
(var/lib/dpkg/info/cdrom-detect.postinst which comes from 
https://packages.debian.org/bullseye/cdrom-detect) so that it tries to 
mount /cdrom rw by default. This basically means editing the "linux)" 
case from the script to change:
      OPTIONS=ro,exec
to
      OPTIONS=rw,exec

I have tested this to produce the expected result. However, this will 
lead to an attempt to mount all optical media rw, which makes little 
sense. So a slightly better option could be to alter the try_mount() 
function of the script to take a third parameter that specifies the type 
of read/write options that should be used, or break the OPTIONS into 
OPTIONS_CDROM OPTIONS_FAT, and only have rw for the latter. It needs to 
be pointed out that formally requesting rw on a read-only media does not 
seem to be an major issue, as linux will fall back to mounting the media 
read-only if it can't mount it read+write.

By far, modifying cdrom-detect.postinst is the simplest solution, but it 
may also be the most difficult to justify if these changes are to be 
upstreamed (since the script caters for more than Linux) even more so 
as, without context, a lot of people may wonder why a /cdrom device 
should be attempted to be mounted rw and/or may see it as a dangerous 
practice that should be avoided.

* OPTION 3: Alter the partman initialisation scripts to remount /cdrom 
rw when it detects that /cdrom maps to an ESP.

This of course is the preferred option, especially as there already seem 
to exist scripts in lib/partman/init.d/ (such as 50efi) that have the 
capability to detect ESP, and the problem we are trying to fix is 
related to partman usage. However I am not familiar enough with partman 
at this stage to propose a patch, so this would need to come from a 
Debian maintainer that is more familiar with this process.

Basically, such a script would need to:
1. Retrieve the underlying device that is associated with the mounted 
/cdrom (e.g. /dev/sda1)
2. Determine if it belongs to a parent block device
3. Query the parent block device for partitions to see if the one that 
is associated with /cdrom is an MBR ESP (type 0xef) or GPT ESP (uses the 
UEFI GPT type)
4. If that is the case, issue a mount -o remount,rw of that partition as 
/cdrom

Hopefully, this is is not something that may too difficult to craft for 
a person that is privy to the existing partman script.


To conclude, I will reiterate that this issue is the last major hurdle 
we have to making netinst installation on the Raspberry Pi 4 as easy as 
a breeze (since the SoC from that platform can boot directly from USB 
and we do have a relatively stable and SBBR compliant UEFI firmware), so 
I really hope it can get the traction it deserves. Especially, the 
Raspberry Pi 4 has already sold more than a million unit therefore a lot 
of people are likely to be interested into installing and running Debian 
ARM64 onto it. Making it as painless as possible with the release of 
Debian 11 should therefore be a goal that I hope we can all aspire to.

Thank you,

/Pete

[toc] | [next] | [standalone]

#63846 — Bug#963156: Would appreciate an update

Since we haven't seen any progress or update on this from Debian, we're 
sending a reminder that, as per https://github.com/pftf/RPi4/issues/76, 
this issue is still very much active for us and an actual showstopper 
for the installation of Debian 11 on the Pi 4, using the regular Debian 
setup utility (but again, this is not a Raspberry Pi only issue, but one 
that also applies to x86 users who extract mini.iso or netinst.iso 
content to a GPT, so as to achieve a single-drive setup and installation).

Considering that the last showstopper we have (with the UEFI console 
defaulting to serial instead of Graphical) is in the process of being 
resolved, this really is the last major item we need to make the Debian 
installation experience on the Raspberry Pi 4 achieve parity with the 
Debian installation experience on PC.

As such, we would really appreciate if someone could look into this to 
ensure this issue gets solved for the Debian 11 release.

Thanks,

/Pete

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

#63903 — Bug#963156: Patch submitted

A patch for this issue has now been submitted in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918

A new report was created since we ultimately propose to fix this in 
partman-efi instead of partman-auto.

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

#63911 — Bug#963156: Patch submitted

Hi Adrian,

On 2020.08.05 07:48, John Paul Adrian Glaubitz wrote:
> On 8/5/20 1:47 AM, Pete Batard wrote:
>> A patch for this issue has now been submitted in:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918
>>
>> A new report was created since we ultimately propose to fix
>> this in partman-efi instead of partman-auto.
> 
> It is possible to re-assign bug reports to another package, see [1].

That's good to know. Thanks!

> Also, we use Debian Salsa for submitting patches nowadays. You can create
> a guest account and open a pull request [2].

I have now done just that in 
https://salsa.debian.org/installer-team/partman-efi/-/merge_requests/1

Is there any chance https://www.debian.org/Bugs/Reporting could be 
updated to indicate that the process of submitting a patch for a bug 
report is better handled by salsa?

At the moment, if you look at this page, it indicates that you should 
attach your patch to a bug report if you have one.

If salsa is now the established model for submitting patches, I think it 
would be better to have a very explicit: "If you want to submit a patch, 
please locate the relevant package at https://salsa.debian.org/ and 
create a merge request instead." on the bugs reporting page.

Thanks,

/Pete

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

#64189 — Bug#963156: marked as done (/cdrom should be remounted rw before partman executes, when mapped to an ESP)

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

Your message dated Tue, 1 Sep 2020 00:17:00 +0200
with message-id <20200831221659.bzmcxuy4py355fcs@percival.namespace.at>
and subject line Re: Bug#963156: Bug can be closed
has caused the Debian Bug report #963156,
regarding /cdrom should be remounted rw before partman executes, when mapped to an ESP
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
963156: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963156
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.boot

csiph-web