failed storage configuration at install of ubuntu-22.04-server

Bug #1969822 reported by fernanAguero
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
subiquity
New
Undecided
Unassigned
ubiquity (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

when booting a new VM using the ubuntu-22.04-live-server-amd64.iso file (VMWare), and following the installer options, I went for a "Custom storage layout", because I had 3 disks and wanted to use disk1 (/dev/sda) as main disk (mounted in /), disk2 (/dev/sdb) mounted under /var/lib, and disk3 (/dev/sdc) mounted under /srv.

After formatting all devices and specifying mount points, the system does not allow me to move on, saying "To continue you need to: Select a boot disk

However there is nothing I can do to select one! (the option to "Use As Boot Device" is greyed out).

If I start again fresh and choose the first disk (/dev/sda) and instead of "Format" I go for "Use As Boot Device", the system (again) does not allow me to move on, saying "To continue you need to: Mount a filesystem at /" (now the option "Stop Using As Boot Device" is greyed out).

Hence, in summary, this is very confusing. It is not clear what the installer expects (e.g. how to do things right), and there are no hints provided.

Revision history for this message
fernanAguero (fernan-iib) wrote :
Dan Bungert (dbungert)
Changed in ubiquity (Ubuntu):
status: New → Invalid
Revision history for this message
fernanAguero (fernan-iib) wrote :

Moreover, if I go to a shell and format the disks, when I go back to the installer, and hit "Reset" the system recognizes the changes, and shows the disks as "already formatted as ext4", with "partition 1 existing", "not mounted", and with a message saying:

"To continue you need to: Mount a filesystem at /
Select a boot disk"

But there is now way to mount at / (option greyed out).

I've been able to work around this by selecting Mount -> Other and ignoring the warning about this being dangerous. Both mounting at / and /var/lib produced these warnings. Mounting at /srv did not.

Revision history for this message
Dan Bungert (dbungert) wrote :

Thanks for the report.

> However there is nothing I can do to select one! (the option to "Use As Boot Device" is greyed out).

Up through that part sounds correct - there needs to be a little space to setup for a boot disk and there isn't, so you made the right choice to go backwards a bit and format the disks.

Would you attach the contents of the /var/log/installer directory?
If you're concerned about sharing information, the files I'm most interested in are /var/log/installer/subiquity-server-debug.log and /var/log/installer/block/probe-data.json.

Revision history for this message
fernanAguero (fernan-iib) wrote :

Of course! Please let me know if you need more files or further debugging.

Revision history for this message
Dan Bungert (dbungert) wrote (last edit ):

Thanks for attaching the installer files. Unfortunately the subiquity-server-debug.log is actually a symlink to the real log file, so all we got was an empty symlink.

That said, I can reproduce part of what's going on with the probe-data.
Where I'm confused is the initial state - I think maybe the way things started is that the disks themselves were formatted, without a partition table? Is that correct?

While I'm not yet certain what happened in your case, I've taken a screen recording to show what I would have done at the formatting screen.
https://asciinema.org/a/489119

> I've been able to work around this by selecting Mount -> Other and ignoring the warning about this being dangerous. Both mounting at / and /var/lib produced these warnings. Mounting at /srv did not.

So the concern there is that Subiquity knows we need to write files as part of the install to those partitions, but doesn't know if that is OK to do so. Maybe you're mounting an existing ext4 formatted disk at / and it has stuff - is that going to be ok? In your case it should be fine because you just formatted them, but it doesn't really know that.

The workaround in your case when at the "Editing partition n of /dev/sdX" is to, instead of using "Leave formatted as ext4", to choose the plain "ext4" option which will cause it to be formatted, which should then allow you to mount at "/" without having to choose Other and get a scary-sounding warning.

If you remember, I'm very interested in the initial state of those disks, as I think that's the key to what happened here.

Revision history for this message
fernanAguero (fernan-iib) wrote :

Hi Dan, thanks for the fast response. No, the disks where clean. I just started fresh (from zero!) using the VMWAre Vsphere Client.

New VM
  -> Add HDD (Create New Virtual Disk, Thick Provision Lazy Zeroed, Store with the VM, 50 GB
     SCSI (0:0) Hard Disk 1)
  -> Add HDD (Create New Virtual Disk, Thick Provision Lazy Zeroed, Store with the VM, 300 GB
     SCSI (0:1) Hard Disk 2)
  -> Add HDD (Create New Virtual Disk, Thick Provision Lazy Zeroed, Store with the VM, 300 GB
     SCSI (0:2) Hard Disk 3)
  -> Add CD/DVD Drive (Connect at power on; Device Type: Datastore ISO File: ubuntu-22.04-live-server-amd64.iso)

Then Boot the VM and at the console select Try/Install Ubuntu.
Then, went for the "Custom Storage Layout", this was what I did first, and were unable to proceed past the "Storage Configuration" screen.

In my second attempt (same session, did not reboot the VM), I went up to the "Help" box in the upper right corner and hit the "Exit to Shell" option, where I did the following fdisk commands manually. This is what may be confusing you, as this made the disks appear as formatted.

fdisk /dev/sda (n: create new partition, accept all defaults; a: toogle bootable; w write to disk and exit)
fdisk /dev/sdb (n: create new partition, accept all defaults; w write to disk and exit)
fdisk /dev/sdc (n: create new partition, accept all defaults; w write to disk and exit)
mkfs.ext4 /dev/sda1
mkfs.ext4 /dev/sdb1
mkfs.ext4 /dev/sdc1
exit shell and return to installer
resume configuring storage layout (here is where I succeeded even if I had to select mount -> Other -> / (as the mount / option was greyed out).

My bug report is about two confusing things: 1) starting with fresh disks there is no way of selecting a bootable disk and at the same time selecting / as a mount point (options greyed out); 2) even after formatting the disks in the shell, it is confusing that the "mount under /" option is greyed out and one has to go to "Other", then /.

Hope it is clearer now. I am now attaching the complete logs, though I understand they may contain information from the whole session and may be confusing. I can try and reproduce with a new VM from scratch.

PS: how can you run asciinema within the installer?

Cheers -- fernan

Revision history for this message
Dan Bungert (dbungert) wrote :

Thanks again for the logs Fernan, I now believe I understand what happened.

About your item #1 ("starting with fresh disks")
It's our expectation that most people will, when faced with a blank disk or one they are reformatting, will use the "Add Partition" on the "Free Space" area under a disk to add one or more partitions. It's also a good idea to proactively "Use as Boot device" from the menu on a disk to have more control over where that boot device ends up - the first time you add a partition to a disk, Subiquity will notice that nothing is setup for boot yet and try to help with that, which may or may not match your intentions.

The problem you ran into was using the "Format" option from the disk, not the "Free Space" area. "Format" on an empty disk results in an obscure option to setup the disk for formatting and mounting directly, without an partition table. And given that when you dropped to a shell you created partition tables, I'm guessing the direct format and mount of the disks isn't what you had in mind.

About item #2 ("even after formatting the disks in the shell"), that one is more challenging. Subiquity is trying to prevent people from losing data - maybe you're mounting a partition at "/" and it already has data there - the install process is going to wipe out some of that! When Subiquity is in charge of creating the partitions starting from free space, you can do this more simply (Free Space -> Add Partition -> choose Format and Mount options). To go back to a state of a blank disk one can use the Disk -> Reformat option, which will reverse your steps manually done on the command line but will also let the installer clearly know that there isn't data on that disk that needs to be preserved.

I completely agree that this is a User Experience issue and will keep this bug around to investigate if we can do this better. In particular I think the Disk -> Format option is confusing. In the meantime I hope the above helps you to get your VM going.

Revision history for this message
Dan Bungert (dbungert) wrote :

> PS: how can you run asciinema within the installer?

I cheated and used developer tools :)
(`make dryrun` in the source tree if you're interested)

To simulate that with the real installer the easiest thing would be to SSH into the install and capture the SSHed terminal.

Revision history for this message
Pushpendra Kumar (pushpi-gangwar) wrote :

Yes, I can reproduce this issue with Ubuntu 22.04.2 server. I'm trying to create VG over two disks. And same problem is happening that after creating VG I cannot create not LVM partition as a standard partition is required for '/boot'.

And if I go back before creation VG step, then I can select a disk as boot device, then installer automatically creates this partition with mount point '/boot'. But then problem is that I cannot select this disk to form VG with another disk. As only one disk shows in VG creation view.

So, I'm left with only option is that:
1) Choose 1 disk as boot disk, and then I can create GPT partitions only on this disk.
2) On second disk I can create VG, and then I can create LV's. But there is no point as I need remaining portion of first disk too in this VG.

So, I can give you logs or other stuff, what you need to fix this issue.

So far, I have ready few comments, I will read rest and reply/response later accordingly.

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.