18.04.1 can't put /boot on SW RAID or LVM

Bug #1785332 reported by Sean Fulton
88
This bug affects 19 people
Affects Status Importance Assigned to Milestone
subiquity
Fix Released
High
Unassigned

Bug Description

I am attempting to install 18.04.1 on RAID1. I partition the drives and format them, but the installer refuses to continue saying "You must mount a partition of a local disk at /boot to continue. I can not mount a raid partition on /boot.

This should be supported as it worked (in a fairly convoluted way) on 16.04. Also, the instructions for Manual/Advanced Install on the ubuntu web site does not seem to cover this version.

Install media is: ubuntu-18.04.1-live-server-amd64.iso

Paul White (paulw2u)
affects: ubuntu → subiquity (Ubuntu)
affects: subiquity (Ubuntu) → subiquity
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Yes, this should be supported but as you note it's a bit complicated.

Changed in subiquity:
status: New → Triaged
importance: Undecided → High
summary: - 18.04.1 Can't Install on SW RAID
+ 18.04.1 can't put /boot on SW RAID
Revision history for this message
Ed McDonagh (ed-mcdonagh) wrote : Re: 18.04.1 can't put /boot on SW RAID

Subiquity also refuses to allow /boot on LVM. With the alternate installer, 18.04 was happy to install /boot/efi on an automatically allocated partition, and have / and swap as logical volumes in an LVM volume group.

With 18.04.1 using the standard server download, I get the same message "You must mount a partition of a local disk at /boot to continue".

If I create the same setup but with standard partitions and no LVM, it is happy. Within LVM, /boot is not available as a mount point.

I'd conclude from this that the release notes suggesting Subiquity is now ready to do LVM installs for Ubuntu is not correct.

Is this a separate bug, or the same bug?

Revision history for this message
Snowman (snowmanko) wrote :

Same problem here, this new installer is really bad. :(

Revision history for this message
Alexandr Metlov (superios) wrote :

This problem actual so far.
Ubuntu, version 18.04.1 / 11 october 2018

information type: Public → Public Security
information type: Public Security → Public
summary: - 18.04.1 can't put /boot on SW RAID
+ 18.04.1 can't put /boot on SW RAID or LVM
Revision history for this message
Sebastian Nohn (sebastian-nohn) wrote :

Can confirm this.

Revision history for this message
ustas33 (ustas33) wrote :

+1
Same problem here.
I can use USB drive for /boot, but it's shit and sticks solution.

Revision history for this message
Andrew Shark (ashark) wrote :

As a workaround you can use a ubuntu-18.04.1-server-amd64.iso (that iso without "live" in its name). Its installer allows you to not create a separate partition for /boot, so you can just leave this directory to be stored on a root partition, which can be on software raid.

Revision history for this message
agent 8131 (agent-8131) wrote :

If you want to use RAID (and probably LVM) use the non-live server image (even for desktops) and save yourself a lot of hassle:

http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-amd64.iso

I could not get RAID1 to work for a desktop install any other way. I didn't have similar problems with my last desktop, built initially with Ubuntu 11.04 and ubiquity 2.6.10.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I am informed that grub now automatically delays boot if it cannot write to /boot (which avoids the issue where you put /boot on raid and then install a bad kernel, and then can't fix your machine because grub can't record the failed boot and interrupting the bootloader is hard over ipmi or in UEFI boot or whatever) so, subject to testing that this is correct, we can just lift the restriction. We should still leave some of the code paths present though because support for encrypted LVM will land soon and we don't want to let the user have /boot on that...

tags: added: id-5b6772b430ec8080355d80d6
Revision history for this message
Daniel Smedegaard Buus (danielbuus) wrote :

How is this "new" installer still the default, let alone even being used? It's absolute garbage, and once again I now have to do the Googles and re-download, re-image, and restart a server installation because of this piece of sh*t installer that Crapnonical for some reason is pushing on us. Some unknown reason. Perhaps I'd see the reason, if my view wasn't block by the mountain of missing features and crap bugs and shortcomings.

WHY?!?!? "Alternate" (read: normal, tested, and working) installer WORKS, the "regular" (read: new, untested, broken) DOES NOT. THROW IT AWAY.

Revision history for this message
Paul Crawford (psc-sat) wrote :

This bug is still present on the 18.04.2 live server ISO.

Revision history for this message
Mikko Rantalainen (mira) wrote :

I confirm that this bug is still present in 18.04.2 server ISO (non-live version). 16.04 allowed to create md raid and put everything on it (grub supports it!) but this requires creating a separate partition for /boot alone.

Is there any alternative-alternative installer for 18.04.2 with a working (=old) installer?

Revision history for this message
Michael Kofler (michael-kofler) wrote :

Also was unable to do a fairly simple RAID-1 setup. I agree with #10: https://ubuntu.com/download/server should link directly to the old installer, presenting the new one only as an experimental option.

Revision history for this message
MrSparkle (alex-marshall) wrote :

Same as #13, very simple non-LVM RAID 1 setup to replace an existing RAID 1 setup carried forward from the last LTS release. What an unpleasant surprise especially considering the doc's at https://help.ubuntu.com/lts/serverguide/advanced-installation.html make no mention of the new restriction. When will this be corrected? Do I need to re-install 16 then roll forward to keep /boot inside the array?

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

This is fixed in the stable channel of subiquity. I can't remember if it was fixed in the 18.04.3 media -- I think so, but if not, update the snap during the install.

Changed in subiquity:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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