"Use free space for LVM" in installer breaks boot configuration.

Bug #21242 reported by Sivan Greenberg
8
Affects Status Importance Assigned to Milestone
partman-auto-lvm (Ubuntu)
Invalid
Medium
Fabio Massimo Di Nitto

Bug Description

Tested with daily build 20050908.6, i386:

Regular "default" installation goes just fine, with choosing automatic partitioning
of reminaing free space on the hard drive, however when retesting with "Use free
space for LVM" option, the disk layout offered devides the free space to Swap and /
fs, (with home inside it) and when moving forward with this option selected, d-i
offered me to install ONLY lilo (no apparent way out of it and choose grub) and also
destroyed my grub boot configuration, although I explicitly chose "install lilo
on /dev/hda5" and not on the MBR to avoid this exact problem.

If we can't fix this in time for breezy (which is reasonable withon feature freeze
limits) we should at least note that on the Release Notes so unsuspecting users won't
accidently fall into this and get stuck with a non booting system.

Revision history for this message
Colin Watson (cjwatson) wrote :

Fabio, I thought we created a separate /boot outside LVM to avoid problems like
this?

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

hmm interesting problem.. with several bugs in several places..

partman-auto-lvm meaning of "Use freespace for LVM" is special.
In order to boot with / on LVM there must be an accessible /boot
outside LVM. While parcing the receipe to create the LVM,
iirc there is no way to know if /boot has been previously created
and where (that's because there might be uncommitted changes to the disk layout).

Neither lilo or grub -installer should have attempted a MBR writing, because none
of them can read /boot on LVM.

Colin, what do you suggest to do here?

imho we can just kill the "Use freespace for LVM" option for breezy and rework the
code for breezy+1 with better integration.

Fabio

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

(In reply to comment #1)
> Fabio, I thought we created a separate /boot outside LVM to avoid problems like
> this?

We can only create /boot when we scratch the disk. On some arches including i386
/boot can't be
too far from the beginning of the disk or the bootloader will not work.

Using the freespace cannot ensure that:

a) /boot is in a suitable position/disk.
b) that the installed grub/lilo MBR can access that partition at boot.

Fabio

Revision history for this message
Colin Watson (cjwatson) wrote :

LILO certainly claims to be able to support booting from LVM as of version 22.2.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

(In reply to comment #4)
> LILO certainly claims to be able to support booting from LVM as of version 22.2.

It looks like that LILO can only boot from LVM1 partitions that are not spreaded
over more than PV.
There are also other checks in the code that can easily.

So if we want to assume that lilo is supposed to handle this situation properly,
than it's a lilo bug.

Otherwise we can ask lilo-installer to fail in this sitaution.

There is still the problem that partman-auto-lvm cannot ensure that we will
arrive at the end of the
installation with a usable /boot.

Fabio

Revision history for this message
Sivan Greenberg (sivan) wrote :

(In reply to comment #5)

In any case, 1) we should probably mention this on the release notes for the
unsuspecting users , and
2) maybe this deserves prioritization as a breezy+1 goal ? (e.g., seemless LVM
autoconfiguration)

Revision history for this message
Matt Zimmerman (mdz) wrote :

Should do something about this for 5.10, perhaps disabling this option (leaving
"erase entire disk and use LVM")

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

Ok feature removed.. we will look at it later.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

After discussing with Debian upstream and evaluated the problems implementing
this solution,
upstream itself did remove this feature and marked as TODO.
The major stopper right now is that d-i doesn't have a way to ensure a proper /boot.

Closing thig bug. Feature is gone 100%

Fabio

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.