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
