My first topic on the Discourse. I’m trying to perform Ubuntu Desktop installation utilizing two disks. My ultimate goal is to have maximum performance on my root volume.
In Debian this is fairly easy - I just use Expert Installation, partition my drives:
nvme0n1p1 - esp
nvme0n1p2 - boot
nvme0n1p3 + nvme1n1p1 - LVM striped volume
Then mount this partition scheme to /target and Bob’s your uncle.
Unfortunately I cannot seem to do the same with Ubuntu. The Desktop installer straight up doesn’t have any “Expert Installation”, nor does it see or respect already existing LVM volumes. The process is the same - the installer mounts configured filesystem to /target, but it does that only after you click “Install”, so there’s no way to remount this for my liking.
I also tried using automated install using curtin, prepared a YAML file, but in the docs there’s no mention about striped LVM, and pointing to two partitions in lvm_partition stage just creates a linear LVM volume.
So I ask - is there a way to utilize striped LVM in Ubuntu? Or is this simply not possible at all?
(as a clarification - while there’s no significant transfer speed difference between linear and striped, since the former saves data linearly, filling drives one by one, you run into slowdowns and performance hits when you approach the last blocks of the first drive, so in my case everything that is in the space between 900 and 1000 GB of my array is significantly slower to access).
Hi, I have several installation problems, all similar to yours.
I am using Linux distros since 1992 on a multitude of machines, and now I want to migrate from buggy OpenSuse to Ubuntu, on machines having huge amounts of RAID-6 data on dozens of spindles, without losing any data.
I encountered the following list of problems, enhanced with suggestions:
existing LVMs are recognized by the installers from 24.04.3 until the most recent daily CD build (via irritating selection of a so-called “disk“ respresenting the LVM pool), but changing anything (like creation of a new LV) does not actually work. For example, creating /dev/ssd/root2 for a parallel root LV shows me a graphics where the OLD root1 LV is going to be DESTROYED by moving it to a different position in the graphics. Therefore I don’t take the risk of trying this (maybe the graphics is just wrong, but I cannot afford this risk).
1b) I can workaround by a manual “lvcreate…” in the LiveCD mode. However, the later install process works ONLY when an empty filesystem is also created beforehand, although it should be possible to select a new filesystem in an uninitialized LV, but actually fails whatever I try to select.
1b2) another non-working workaround trial revealed another POTENTIALLY DANGEROUS problem: after just creating a NEW LV without formatting it, I was able to see the new LV via “lvs” in another tty. But after the mentioned fs-creation failure, the LV was shown as “gone” again. I have not checked for a reason for this behavior, but this doesn’t increase my confidence on the correctness of the installer. Maybe it is trivial and has to do with something at /etc/lvm/… but this might distract other people from using Ubuntu.
1c) Again the workaround of manually creating both a new LV and a new filesystem seems to work for a new installation at /dev/ssd/root2 . But this installation fails finally at the last step of creating a grub2 loader resp installing a boot section on my existing MBR setup. I don’t see any selection possibility where I could tell the installer to use /dev/nvm* or any other existing MBR or GPT or LVM entry. So no chance for me to migrate to Ubuntu….
1d) just a question: will the old grub2 config options be retained, by just adding the new Ubuntu boot option? It does not matter to me if the old /boot/grub2/ residing on /dev/sdd/root1 becomes unused in future, or whether a new grub2 bootloader stage is installed to wherever, as long as the old multi-boot behavior remains possible without manual interventions.
impossible to check: in the installer, I cannot select a dual-boot option to keep my existing OpenSuse on /dev/ssd/root1 in parallel to the new Ubuntu /dev/ssd/root2 in order to later install TONS of used software under Ubuntu, and to manually transfer lots of configurations from an RPM-based system to a Debian-alike system.
optional feature request: the OpenSuse installer offers the possibility of creating software RAIDs, and later placing LVM on top of it. A similar Ubuntu installer feature would be really GREAT not only for me (ATM I don’t need it, but an Ubuntu migration should last for decades).
even better feature request, ATM not for me until I need to buy a new notebook: old OpenSuse installers were able to shrink existing Windows partitions and to install Linux aside of dual-boot, and it actually worked. I believe that such an Ubuntu feature would be HIGHLY appreciated by the whole world …. Hint: the German c’t magazine has/had instructions / some Powershell scripts for inplace shrinking.
I suggest you setup the disk as you need in gparted etc, then use the “something else” option and you can specify the file systems to use for the install.
If you know the commands to use to setup the disk etc rather than gparted then by all means use those. Set up the disks as you desire then run the installer.
Thanks, your idea is great and will work on blank disks / ssds. I have done suchalike on a few notebooks where I just discarded the pre-installed Windows. But I cannot afford the risk of replacing my more than 10-years old MBR setup, excect when making a dd_rescue backup beforehand at another machine so I can revert to my old MBR setup. Thanks for your idea, I will try and report my experiences in a few days.
Sadly, this doesn’t fix the issue for me, as the desktop installer simply does not recognize any existing LVs, nor does it allow for creation of those. From “something else” I can only use XFS, ext4 or btrfs on a single disk, and nothing else, my configured striped LV doesn’t show up at all.
I understand this is a niche use case, so I would like to suggest a ready and easy solution for advanced users - a simple fix in curtin code. Adding “stripes” to possible properties of LVM_PARTITION:
As well as a simple if statement in lvm_partition_handler function definition:
#curtin/commands/block_meta.py
stripes = info['stripes']
if stripes is not None and stripes >= 2 and stripes % 2 == 0:
cmd.extend(["--stripes", stripes, "--stripesize", "64k"])
I have this already created in the curtin code locally, however I lack the technical know-how about Canonical Launchpad to contribute properly
EDIT: I have successfully forked and branched curtin, as well as created a merge proposal:
Mounting the whole structure to /target doesn’t work, the installer still shows two separate disks and only the efi and boot partitions, while the partitions that are a part of the LV are shown as empty:
The newer ubuntu desktop installer does not support custom LVM schemes during the install. My guess is due to the infinite scenarios here that would need to be maintained in the installer compared to the low number of average desktop users that would implement such a thing. My guess only.
I think Server comes with more options here, and I know some install server & build out from there with a WM or DE.
On Desktop, for the root install you can give LVM the entire disk space and then do some customizations after. You can carefully reduce the unmounted filesystrm size & LV size for root. Then you can create additional LVs alongside your root LV, perhaps to move your home to or for data storage. From there, you should be able to extend your volume group into another disk. I’d test it out in a VM and take notes to get your process down.
You are right, that’s why I don’t think having this explicitly in the general installer is a good idea.
However, having an “expert” install, like Debian or LMDE does, which allows you to just mount anything you want to /target and have the system installed there would be just perfect. Basic users don’t need this and won’t ever see this, advanced users will have the freedom to configure their system as they like.
This is why I proposed a merge request to add this functionality in Ubuntu Automated Install. Basic user will never use this, and advanced user can just write a short YAML, that will configure this feature as expected. Especially since this is basically just adding a simple “-i [number]” to the partitioning command
Your idea of shrinking, moving and growing the filesystem might also work, but it’s significantly more work and risk than just having it installed the way you want.
yes, lack of LVM awareness has been a complaint since this installer was introduced back with Ubuntu 23.04?, and at first, using the new installer was optional. It is not optional with 24.04 and later. There are several long threads about this on the old Ubuntu forum in those times that you can read., with bug reports. So, if you already had any other operating system already installed, and wanted to add ubuntu with LVM, you cannot. Some reports:
I have URLs to a couple of old-forum threads on this topic, but they are now unreachable. In fact, ubuntuforums.org appears to redirect to this forum (history erased?).
The idea of using a server CD version for upgrade of existing LVM-based installations is good, but there remain some hindering limits:
All tested installers appear to require an extra space of ~8MB for GRUB2 boot stages, which must NOT be assigned to any PVS and NOT be assigned to an EFI partition / FAT32 partition and NOT pre-assigned to anything via GPT. Essentially a blank space, not consumed at GPT level.
Some consequence: I was unable to migrate from my OpenSuse installations to any Ubuntu, because in the Suse universe everything works without such a restriction, and is automatically installed without such an unassigned space.
I have not checked on other systems where GPT and/or MBR has consumed all sectors for any pre-installed system.
I workarounded by plugging a new M2 SSD into an empty M2 slot at my workstation, und using the BIOS boot options for dual boot.
But this won’t work at a notebook where no M2 slot is present at all.
Dear Ubuntu developers: please consider removing this GRUB install restriction from all of the Ubuntu installers.
