I've used Slackware as my Main daily Driver for 20+ years and I still love it best but even Current DAW is a bit behind on Pipewire and I need the low latency and despise the issues with Pussaudio. So I tried Ubuntu Studio Trial/Installer USB and it looked surprisingly great!

That said and TBH while systemd is a bit of a learning curve for little value, it's not a big deal... BUT GRUB IS!

I have been an inveterate multibooter since sometime around 1990 and still am. I very much like rEFInd since it is Human Readable Config'd and with syntax much like LILO or eLILO and handles multibooting very nicely.

One recent OpSys I checked out for over a year from time to time was OpenSuse which is prolly why I'm pretty comfortable with systemd and marginally OK with Grub2, but once installed rEFInd boots it just fine and I rarely ever have to see a grub screen or mess with grub commands for Suse. It just doesn't provide a heavily developed Studio version like Canonical does.

However I've tried installing Ubuntu Studio maybe 2 dozen times in different partition arrangements on different drives but always with -

over 100GB / - as either Ext4 or BTRFS
roughly 10 GB /boot - usually as Ext2
and
500MB vfat /boot/efi flagged as boot,esp

It repeatedly fails. After just looking up options and trying stuff I finally got it to boot and I liked it a lot. Pipewire and wireplumber are very new and work a treat. It did take me awhile to get DaVinci Resolve installed and working but I don't mind a little "legwork".

I don't know what was the cause but at some point /var/log/cups log started running in a loop, at one point before I stopped it hitting 200GB so I decided to reinstall and keep my own log of changes to avoid cups log runaway. I'm betting on a fuX0red initrd from dealing with grub syntax errors.

Unfortunately I forgot which of the many things I tried to get Grub to work after chroot-ing in so once again I am fighting with grub install, which fails and hands me generic error logs dropping to apparently useless "grub.cfg.new".

FWIW I now have several failed installs over 3 disks and finally today risked partition editing-resizing to provide install room on nvme0n1 with the above mentioned partition scheme. In every case the installer finally gives me a lit "Next" prompt after manual partition assignment but despite it's "glad hand" it fails at the same grubby spot every time.

So - TLDR - what am I doing wrong or what can I do to fix an install that gets me either to a grub prompt or maybe better sometimes (thanks to rEFInd) a loaded kernel emergency terminal that says it "can't find root" even if I check /etc/fstab entries for validity or do "prefix=" and "root=" from Grub CLI?

Thank you in advance for any assistance. I want to like it but this installer is an obstacle, at least for me.

You give no information that will help fix the problem. Reinstall with the partition layout you originally desired. Use only one EFI partition(the original efi partition even if it is on a different drive), if using btrfs use a boot partition. After reinstalling if ubuntu still doesn't boot, post the actual error messages, the output of 'lsblk -f', the contents of the ubuntu fstab, the output of 'efibootmgr -v',the contents of EFI/ubuntu/grub.cfg on the efi partition, and information about the other systems if this is a multiboot system and the system you want to control the boot menu.

Thanks colorpurple21859 for your suggestions and I will try them. In the meantime I did manage to get the latest failed on grub install attempt to boot, much like the previous "fix" but a few items don't work quite right, notably polkit. It will not a accept password. I understand that polkit has it's own rules but so far don't know how to fix them - Catch 22.

I'm a bit reticent to wipe all but one esp partition, as I still play with some legacy OpSys that still don't do EFI but can be hacked to work with CSM enabled and using similar old school chainloading syntax that I prefer to keep separated. Additionally I have a LOT (a dozen plus?) of bootable systems and run into problems with limitations of Fat and ESP partition size restrictions. It seems such restrictions can be all over the map where some operating systems/bootloaders will work with well over 1GB while others won't unless esp is under 500MB.

Also, while I recognize the simplification value of having just one ESP partition, and I could indeed be wrong, but I don't see a problem when proper UUID designation directs bootloading to just one. There should be no wiggle room there to binary code. The only possible problem, which admittedly I don't understand, is that my mobo firmware designates disk order the same way every time unless I alter it, which I don't on my Main PC. Slackware also never varies and I don't even need to resort to UUID, just "dev/foo" which I VASTLY prefer. Maybe it's a systemd thing but sometimes, some systems, seem to do random disk order assignment.

FWIW I ALWAYS check with some version of parted, or if trying to do Grub Rescue - "ls (HDfoo,GPTfoo2)/" to confirm I'm in the right drive before any operation.

As for boot control, I am firmly committed to rEFInd since it's .conf is human readable with legacy syntax AND does not require running a binary executable to update - Edit and Go! I like that. It can launch additional instances of rEFInd on other drives/esp, Grub directly, or kernels, fallback loaders... you name it. rEFInd r0x!

However I may soon relinquish my play around systems as I've begun to focus more on modern apps rather than base code and re-purposing. I've gotten pretty heavy into AV editing.

I'm not going to attempt to "go back" to original partition layout as I'm convinced the far simpler arrangement on nvme0n1 has the best odds of easy success. I don't normally accede to "easy" but I am aware of my limitations with systemd and automated package managers as well as Grub.

I have worked some with BTRFS on my NAS and like it a lot so Ubuntu gets btrfs.

Being very much against UUID (I label everything and can immediately understand where I am unlike UUID) I nevertheless have knowledge and experience at verifying UUID entries Ubuntu and others that depend on Grub, seem to prefer. So I have checked etc/fstab, grub.cfg, etc to confirm correct partition identification and assignment.

Efibootmgr is a weird case. It's odd to me that an EFI firmware entries are made when Grub fails to even install properly. So I have spent a lot of time in "efibootmgr -b #xxxx -B" as well as in CMOS disabling ubuntu entries that don't boot.

Sorry for the ramble, been a tough week. For now, I'm going to try to fix polkit and continue with what does boot (even if every other time it dumps me in "maintenance"... possibly some cdrom/noble repo nonsense or fsck issue) but succeeds with a simple reboot. If my clean-up measures fail I will likely start paring down as per your well thought out suggestions.

Minor Update - Polkit working now. It just takes me awhile to adjust to not simply editing a text file but having to run an app.

Having one EFI partition or at least one per physical hard drive simplifies things greatly but your comment above has nothing to do with that. A Legacy/CSM installed and bootable OS does not use the EFI partition. You should be able to boot in either mode if the physical hardware allows it you have Legacy/CSM as well as UEFI enabled in the BIOS. On some newer computers, there is no option for Legacy/CSM and I expect most manufacturers will be following suit.

If you are having a problem, then post the information suggested in post 2 above which will be useful in finding a solution. As pointed out in post 2, there is really no information in your post(s) that would be useful in resolving a problem.

One thing I am curious about, why install the same OS multiple times to different drives/partitions when they have failed? Why not overwrite the first install with the second?

Maybe, but for the foreseeable future I won't be buying any of those motherboards and I don't do OEM, I build my own.

My apologies since it is likely my unfamiliarity, at the very least with Ubuntu, but to some degree with systemd and grub, that prevents me from giving more than the basics of what partition scheme I used/tried, what error message ("We're sorry, some error has occurred..." is not the level of info I'm used to) and the basic results upon boot attempts or even chroot from the install media.

Probably lack of definitive knowledge on my part. As I'd mentioned, my experience has been that, for example, some systems accept only under 500MB for esp while others work just fine with 500MB or above. There is no "one size fits all" solution, so I try stuff.

I also tried a few variations. TBH I am rather pleased to see that the Ubuntu installer has improved a lot. It used to be so dense and aggressive it was safest to remove all but one drive. Nevertheless, it is still only "interactive" at best, like an A,B,C,D multiple choice test, so I tried multiple choices before I asked for help.

Frankly I consider this a bit of a bug. At the very least a decent error message as to what exactly failed would be great, but none exists.

Simply put, if I partition according to EFI standards (nebulous as some are) and let the installer choose say "/dev/sda" instead of "/dev/sda1" (which I vastly prefer in a multiboot environment) if I follow all of the conventions and it fails I want to know how and why.


FWIW I have installed well more than dozens of systemd/grub systems (several versions of Arch, anARCHy, Manjaro, Debian, Centos, PopOS, Suse Leap and Tumbleweed, Rocky, and more) while I have seen some errors some few times, the messages were instructive and most just worked because I am experienced with systems and UEFI requirements.

You were given several simple commands in post 2 which you could run from the 'live' system to post the output to get help.

I've not used Ubuntu Studio so I don't know which installer it uses but the major Ubuntu's use a new installer which will actually install EFI files to EFI partition selected by the user. Earlier versions would install to the first EFI partition if one existed regardless of what the user selected.

If there are no specific errors shown you could indicate at what point during the install the errors occur.

Either option should install to the EFI partition since no boot code is written to the MBR, at least from my experience and from what I have read.

Thanks again yancek. I'll post the results of all in post #2 tomorrow as I will have to reboot and I'm a tad harried just trying to get Ubuntu Studio to accept disabling cpu scaling_governor=powersave and get performance instead and frankly this is just one reason Slackware is my Main and has been for 20+ years. It boots but sometimes drops to maintenance CLI but Ctrl-D marches right on to Desktop with no problems. I just would like to not see errors every time I update-grub. Maybe the above data will give you what we want to get this proper.

I hate it that these so-called modern hand-holding systems that require binaries for damned near everything instead of editable text, change fundamental processes with almost every release. Almost everything basic I did in Slackware 7 still functions in Slackware 15.0. It's actually possible to accumulate a capital of a body of knowledge not possible when the base rules always change.

Anyway my apologies for ranting. I know much of my problems stem from changing from what I've grown accustomed to.

This is what we have been waiting for, from your post in another thread:
Did you edit a file related to grub?

LOL several times! That's part of what I did to get a failed Grub install to finally boot.

Anyway this is pretty big (lots of partitions and systems) so here's a link on Dropbox for all you asked for. FWIW it boots fine from rEFInd although I have yet to be able to make a manual entry that works (maybe due to "switcheroo") but one or more entries by rEFInd's version of OS Prober boots with no issues.


https://pastebin.com/QcpUKzgk

Let me know if there's any issues with the link.

What happens if you run

Posting the output of the command in post 11 could be helpful even if it fails when run from Ubuntu Studio. I see you are booted from entry Boot0004 but you have another rEFInd entry (Boot0008)? You also have 7 Ubuntu EFI entries. Have you tried booting from each? You might do that and delete the ones that fail.

Thank you for your response, yancek, and yes, I do need to clean up efi boot entries at some point but it is rather low priority since I now can boot every system I have from Boot0004 rEFInd.

Also the only time I ever access BIOS/UEFI Boot Order (F8 in my case) is most often to boot removable drives like Live USB. I care little about firmware entries as long as my one Boot0004 rEFInd works. The additional rEFInd was from attempting a fix to Ubuntu Studio by installing refind in it.

Again, it's very long and I'll likely clean up all these unneeded bits at some point but everything works from one Boot0004 so not high priority atm.

https://pastebin.com/xVT4Qe96

If you can boot your systems with rEFInd, what is the problem? Do you just want to install and use Grub from Ubuntu Studio? I'd start by testing the various ubuntu entries in your BIOS and eliminating/deleting the entries that don't boot. If one entry does boot, all you need to do is to set it to first boot priority in the BIOS. If none boot, reinstall Grub from Ubuntu Studio. Part of the problem may be as mentioned in an earlier post, the fact that you have btrfs filesystems. I'm not familiar with it so can't speak to that. Your lsblk output shows several boot partitions. Is one of those for Ubuntu Studio?