F21 partitioning circus

Chris Murphy lists at colorremedies.com
Mon Feb 23 21:15:03 UTC 2015


On Mon, Feb 23, 2015 at 8:11 AM, Wade Hampton <wadehamptoniv at gmail.com> wrote:
> [snip]
>
> This was a good thread and is tied in with my experience
> this weekend.  I had a very old laptop with F13 that had not
> been booted in years.  I tried to load F21 on it using the
> same partitions (and keeping the old Windows partitions).
> Anaconda more or less let me try but gave me a warning
> about /boot being below the RECOMMENDED size (not
> that it would not work).

There's a thread on test@ "Does anyone reuse /boot or /var
partitions?" that explores some of this. But I think if you can
reproduce this, you need to file a bug, I don't see how else such
things get fixed because this is not a Fedora QA test case to reuse or
share /boot because it's not best practices.

If the installer is going to permit a non-empty /boot to be used for
installation, then it should check free space not volume size; and
fail with a clear warning. Such checks are a nice little pile of code
and further require translations due to the warning. And that's why
I'm more in favor of non-empty /boot being unsupported. That's not the
same thing as requiring it to be reformatted, but if the installer
team were to go that route I think that's better than the shared case
which is simply dysfunctional and inconsistent with the FHS as well.
The long standing history is that /boot is owned/paired with a
particular root fs. End of discussion. There's just no good that comes
from trying to support arbitrary content and avoid stepping on things,
not least of which is that a pile of bootloader code and configuration
(all of which is distro specific and are mutually incompatible since
distros maintain their own substantially different GRUB forks, in
effect) that's distro specific contained in /boot.

So this is a Do Not Pass Go as far as I'm concerned.



> F21 installed without any indicated errors.  However I got
> an OOPS on first boot.
>
> I was able to boot into the recovery partition and inspect
> the /boot.  The initrd for normal boot was incomplete and
> the /boot was full.  I did NOT receive an error on install.
> IMHO, this was a silent failure (bug reported).

Yes I'd say that's at least one bug. The installer should be aware if
dracut or new-kernel-pkg exited with something other than 0 and would
report that to the user. So there's some missing error checking (which
may or may not actually be the installer's fault); and another bug if
that error checking doesn't have a practical way of being implemented,
the installer needs to simply disallow non-empty /boot as well as ones
that have insufficient space.

>
> Yes, there are those of us who have done "interesting things"
> with our partitioning over the years.  We would like to continue
> to be able to manually partition, manually setup RAID,
> and do similar things.    Its definitely not good for the average
> user, but some of us need it.  However, we should see
> errors when things fail....

Or flat out indicate that the layout isn't supported, so that you
don't end up going down a rabbit hole thinking it is supported, only
to encounter an error later in process, or worse, once "Begin
Installation" has been clicked and on-disk changes have already been
made.

Better to pre-fail than fail later. And it's not like I've seen anyone
 (except me) post bugs demonstrating their installer failure cases.



-- 
Chris Murphy


More information about the users mailing list