[05:29] -queuebot:#lubuntu-devel- Unapproved: lubuntu-installer-prompt (noble-proposed/universe) [24.04.5 => 24.04.5.1] (lubuntu)
[12:22] <mkukri> hello, i am investigating LP: #2060624 , and i do wonder, in the calamares based installer, what is/should be responsible for configuring grub-pc/efi's debconf entries during/after installation
[12:22] -ubottu:#lubuntu-devel- Launchpad bug 2060624 in grub2 (Ubuntu) "lubuntu/xubuntu reinstall (& install) on dual boot system, grub does appear & offer OS choice" [Undecided, New] https://launchpad.net/bugs/2060624
[12:23] <mkukri> subiquity has logic to this itself, and there is also a cloud-init module that suppossed to do this (although it's less complete and more buggy)
[12:24] <mkukri> s/subiquity/curtin in this case just be clear, it applies to both desktop isntaller and server one
[12:34]  * guiverc can't help there sorry.. you need a developer.    I did get same response on ubuntu-desktop-installer (xubuntu) BEFORE the format was forced.
[12:59] <mkukri> than this issue might strictly be unrelated but it seems like calamares based ubuntu installs do not fill the grub-pc/efi debconf fields correctly
[13:12] <mkukri> interestingly grub2/enable_os_prober is still false in debconf, even in installations were the alternative OS shows up in the menu
[13:14] <mkukri> hmm in fact regenerating grub debconf with update-grub after the os booted reproduces the bad behavior
[13:41] <mkukri> guiverc, i seem to have reproduced this on the desktop installer too, and i have a hunch what's going on but i am gonna do a few more tests before proclaiming it for sure
[14:03] <guiverc> :|  at creating it with ubuntu-desktop-installer (I like confirmation of what i experiened, but :( at it still being possible as the forced-format b/c of another issue I thought prevented it appearing with ubuntu-desktop-installer...
[14:04] <tsimonq2> mkukri: There's debconf prompts for that?
[14:05] <mkukri> grub-{efi,pc}/install-devices needs to be filled in, otherwise grub is not reinstalled on package update
[14:06] <mkukri> this is what curtin does https://github.com/canonical/curtin/blob/204562c277b096229ca20ba546149deef1d85e38/curtin/commands/curthooks.py#L632
[14:06] <mkukri> tsimonq2 ^
[14:06] <mkukri> the os-prober one i think im wrong about
[14:07] <mkukri> it exists, but there is an ubuntu patch that should force it enabled if the existing grub.cfg was generated with os-prober enabled
[14:08] <mkukri> and btw definitely not release critical, there were similar bugs (grub not reinstalling) in cloud images for years. but it should eventually be fixed
[14:11] <tsimonq2> mkukri: Ah okay, I see, thanks :)
[14:12] <tsimonq2> If I had to guess off the top of my head, this is where the modification should be made: https://git.lubuntu.me/Lubuntu/calamares-settings-ubuntu/src/branch/ubuntu/noble/common/modules/before_bootloader_context.conf
[14:13] <tsimonq2> Either that, or a dedicated contextualprocess to set the debconf prompts
[14:13]  * tsimonq2 would be interested in seeing what entries this results in *exactly* for the main Desktop Installer
[14:58] <mkukri> tsimonq2 i can give you an example from a simple install, the more annyoing case is raid where you have to put multiple things into the multiselect
[15:02] <mkukri> so for example, a simple *BIOS* qemu VM results in *grub-pc/install_devices: /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001
[15:05] <mkukri> also i am not sure if lubuntu uses cloud-init at all, but the following recent bug might be relevant too https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2060695
[15:05] -ubottu:#lubuntu-devel- Launchpad bug 2060695 in cloud-init (Ubuntu) "24.04 grub-pc cannot upgrade on mirrored software RAID root disk" [Medium, Triaged]
[15:06] <mkukri> tl;dr cloud-init's cc_grub_dpkg module can mess things up on first boot if enabled
[15:51] <tsimonq2> mkukri: ack looking thanks :)
[15:52] <tsimonq2> mkukri: I don't believe Lubuntu uses cloud-init, no
[15:55] <mkukri> seems to be my observation as well because, ive done some lubuntu installs to (try to) track down the above bug and grub-pc/install-devices was always empty
[15:55] <mkukri> so yeah i assume it should be set by your installer
[16:05] <tsimonq2> mkukri: Calamares doesn't support RAID yet, interesting
[16:06] <arraybolt3> I just recently did a side-by-side install of Kubuntu (which also uses Calamares) and Windows 10 and os-prober did the right thing...
[16:07] <arraybolt3> does having the debconf fields not filled in result in an intermittent issue in this area?
[16:07] <tsimonq2> arraybolt3: To my understanding, when the grub package is updated it looks for those debconf config values to install GRUB to the right place
[16:07] <tsimonq2> postinst or similar
[16:07] <arraybolt3> right
[16:08] <mkukri> arraybolt3, yeah the os-prober issue is seperate from this
[16:08] <arraybolt3> I've seen very strange GRUB prompts during bootloader updates (or possibly even just kernel updates) that looked like something was awry with debconf
[16:08] <arraybolt3> and that is NOT a good UX
[16:08] <mkukri> i just noticed that this _whle_ looking at tthat
[16:08] <arraybolt3> so I'd say this is worth calling a release blocker in the event we can get a fix for it
[16:08] <mkukri> those should go away if debconf is set
[16:08] <mkukri> or there is grub-pc/cloud_style_installation but i recommend not setting that outside cloud images, that uses grub-probe instead
[16:08] <arraybolt3> right
[16:09] <tsimonq2> arraybolt3: What kind of errors did you see? just for the sake of justifying the fix
[16:09] <mkukri> i dont think this should give you errors, just debconf questions
[16:09] <tsimonq2> ah okay that follows
[16:10] <mkukri> and in non-ineractive mode it should just silently leave the old grub installed on disk
[16:10] <arraybolt3> yep, debconf questions
[16:10] <arraybolt3> so you'd upgrade and then see "Where eddo you want to install GRUB?"
[16:10] <arraybolt3> (or something like that)
[16:10] <arraybolt3> s/eddo/do/
[16:10] <arraybolt3> (lag is horrible right now because I'm zsync'ing an ISO)
[16:10] <mkukri> the reason this didnt come up in 23.10 btw is because grub-pc was *never* updated due to a multi year workaround....
[16:10] <mkukri> that  i finally removed in 24.04
[16:11] <arraybolt3> aha
[16:11] <arraybolt3> that makes a lot of sense
[16:12] <mkukri> and that's why cloud_style_installation was added, and why the cloud-init issue with subiquity was discovered too...
[16:12] <mkukri> things seem okay in noble, but i still have many discussions to have with various folks over the issues that were papered over for years
[16:12] <tsimonq2> mkukri: Can I ask why you think this may not be a 24.04 release blocker?
[16:13] <tsimonq2> (If I'm reading your earlier messages correctly, that is.)
[16:13] <mkukri> i guess i didnt have the debconf questions popping up in mind earlier
[16:13] <mkukri> i was only thinking of noninteractive upgrades
[16:14] <tsimonq2> arraybolt3: oh... wait... does Kubuntu's update notifier even support debconf prompts?
[16:14] <arraybolt3> Kubuntu's does not, Lubuntu's does.
[16:14] <arraybolt3> (because I made very sure that it did :P)
[16:14] <tsimonq2> I'd definitely call it a release blocker for Kubuntu then, what do you think?
[16:14] <arraybolt3> Even on Kubuntu though this issue should trigger if the user upgrades via apt, which I did for a while and still do sometimes.
[16:15] <mkukri> is kubuntu and lubuntu the only flavours not using the new desktop installer?
[16:15] <arraybolt3> Ubuntu Unity also.
[16:15] <tsimonq2> mkukri: and Ubuntu Unity
[16:15] <tsimonq2> arraybolt3: jinx :)_
[16:15] <arraybolt3> The main difficulty I'm seeing is, how do we get Calamares to tell us what device the bootloader was installed to?
[16:15]  * arraybolt3 digs in scripts
[16:15] <tsimonq2> arraybolt3: already there
[16:15] <tsimonq2> globalstorage
[16:16] <arraybolt3> right but I mean in a contextual process
[16:16] <arraybolt3> Calamares doesn't expose everything to the shell script thingies
[16:16] <arraybolt3> we could write a module in Python...
[16:16] <tsimonq2> Calamares exposes all globalStorage values to contextualprocesses :)
[16:16] <arraybolt3> but let's exhaust the other options first for sanity's sake
[16:16] <arraybolt3> oh it does? Perfect.
[16:17] <mkukri> should i file a bug about this. and what package is appopriate?
[16:18] <tsimonq2> mkukri: calamares-settings-ubuntu and yes please
[16:20] <arraybolt3> tsimonq2: I see a contextualprocess can decide what code to run based on the value of a global storage key, but does it let you use the value of a global storage key as a variable?
[16:20] <tsimonq2> ...oh?
[16:21] <arraybolt3> The thing is we need to be able to say "take the global storage key, find the corresponding by-id device, stuff it in this debconf entry".
[16:22] <mkukri> https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/2063354
[16:22] -ubottu:#lubuntu-devel- Launchpad bug 2063354 in calamares-settings-ubuntu (Ubuntu) "Calamares based flavours do not set grub-{efi,pc}/install_devices debconf" [Undecided, New]
[16:22] <tsimonq2> arraybolt3: hey guess what, the bootloader module itself is written in Python :P
[16:22] <tsimonq2> mkukri: Thank you!
[16:22] <arraybolt3> tsimonq2: heh, well there you go
[16:23] <tsimonq2> arraybolt3: do we want to move to Matrix?
[16:23] <arraybolt3> tsimonq2: mkukri is here so I think this is OK here for now
[16:24] <tsimonq2> arraybolt3: ok cool :)
[16:24] <mkukri> im end of day currently, but if you need help please tag my nick, ill check on IRC periodically
[16:25] <arraybolt3> will do, thank you for your help!
[16:26] <arraybolt3> tsimonq2: want me to tackle the patch or are you already doing it?
[16:26] <tsimonq2> arraybolt3: I'm on it, will check in
[16:26] <tsimonq2> arraybolt3: In the meantime any chance you could update RT and the bug report on what's happening?
[16:27] <tsimonq2> (probs release blocker for all three flavors, eh?)
[16:27] <arraybolt3> sure thing
[16:27] <tsimonq2> thank you :)
[16:27] <arraybolt3> and yes, probably a release blocker
[16:27] <mkukri> i assume the desktop installer based ones are fine?
[16:27] <mkukri> and maybe talk to the release team please
[16:29] <arraybolt3> I do not know if the desktop installer based ones are fine or not. If they don't set the debconf prompt, they're probably not fine.
[16:29] <arraybolt3> er, the debconf variable - you know what I mean
[16:29] <mkukri> curtin sets it
[16:30] <arraybolt3> Either the user will get unsightly debconf prompts, OR GRUB won't end up updating most likely, which would leave a gaping security hole and opportunity for Secure Boot bypasses and potential failure to boot if the SBAT key is rotated out.
[16:30] <mkukri> ubuntu desktop itself is definitely fine
[16:30] <mkukri> (ubuntu server too) i do test test thoseregularly
[16:30] <arraybolt3> kk
[16:31] <mkukri> and i think i tested xubuntu too yesteday, but dont hold me to that
[16:31]  * mkukri is going afk for a bit but will be back later
[16:48] <tsimonq2> arraybolt3: At this point, just wondering if setting it to /dev/disk/by-id/SOMETHING is the right thing compared to just /dev/sda1?
[16:48] <tsimonq2> thoughts?
[16:48] <arraybolt3> tsimonq2: /dev/sdXY are unstable and *will* change if the user changes drives (by, e.g., booting with a USB drive inserted).
[16:48] <arraybolt3> Learned this the hard way some time ago, and it's pretty common advice on the Interwebs.
[16:49] <arraybolt3> Figuring out the link between /dev/whatever and /dev/disk/by-id/SOMETHING should be easy enough in theory since the /dev/disk/by-id thingamajigs are just symlinks.
[16:49] <tsimonq2> That follows, now just wondering how it works with the main desktop installer, if there are multiple /dev/disk/by-id entries that match to one disk
[16:49] <tsimonq2> (can happen, from what I'm reading)
[16:49] <arraybolt3> https://www.tutorialspoint.com/python/os_readlink.htm
[16:50] <arraybolt3> oh really? That's not good...
[16:50] <arraybolt3> mmm, I see that I have that situation on *this* system I'm typing on.
[16:50] <tsimonq2> Bright side, the debconf config value is of type "multiselect"
[16:50] <arraybolt3> for me nvme-eui.00253857214071d7 and nvme-Samsung_SSD_970_EVO_Plus_1TB_S6S1NJ0T713093F point to the same partition
[16:50] <arraybolt3> er, the same NVME namespace I mean
[16:50] <arraybolt3> gosh I wish that there weren't NVME namespaces *and* partitions :P
[16:51] <arraybolt3> tsimonq2: maybe by-uuid would work too/instead? Just a thought.
[16:52] <tsimonq2> arraybolt3: the other thing is that in this virtual machine I can only see one by-id mapping to /dev/sda1
[16:53] <tsimonq2> Do you have test hardware? Would be great to see what those entries are actually set to in such a case with the Ubuntu Desktop installer
[16:53] <arraybolt3> tsimonq2: https://termbin.com/8n2f
[16:53] <arraybolt3> hrm... I can make the hardware I have test hardware.
[16:54] <tsimonq2> If you're okay with that, go for it
[16:55] <arraybolt3> I lost my two best testing laptops, one to video card failure, and one to whatever power mess it suffers from, so I'm stuck using one desktop for everything test-wise :P
[16:55] <arraybolt3> but anyway, I was going to test Xubuntu Minimal anyway so I'll give it a shot there
[16:55] <tsimonq2> awesome, thanks
[16:55] <arraybolt3> and maybe also try it in BIOS mode so we get a good picture
[16:57] <tsimonq2> BIOS and UEFI would be great for full testing coverage, probably looking for `sudo debconf-show grub2` on first boot
[16:57] <arraybolt3> nifty
[17:07] <tsimonq2> Testing some code now which just sets an example value for that debconf setting - to test syntax before we have actual values to work with :)
[17:11] <tsimonq2> arraybolt3: `sudo debconf-show grub-pc` not `sudo debconf-show grub2` my bad :)
[17:17] <tsimonq2> I just did a `sudo dpkg-reconfigure grub-pc` on an installed system which gave me some ideas, would still like to see the output of that for both GRUB and EFI to double check though
[17:21] <arraybolt3> tsimonq2: Might take me a bit, I'm just now starting to install Xubuntu for testing.
[17:21] <arraybolt3> Also I'm multitasking between work duties and also Matrix Council activity
[17:23] <arraybolt3> Got the installation going now.
[17:26] <tsimonq2> arraybolt3: sweet thanks
[17:28] <arraybolt3> tsimonq2: alright, so, from an EFI installation:
[17:28] <arraybolt3> uh, `sudo debconf-show grub2` on Xubuntu Minimal outputs nothing.
[17:28] <arraybolt3> Not even a newline.
[17:28] <tsimonq2> arraybolt3: 17:11 < tsimonq2> arraybolt3: `sudo debconf-show grub-pc` not `sudo debconf-show grub2` my bad :)
[17:29] <tsimonq2> :)
[17:29] <arraybolt3> oh lol, alrighty
[17:29] <arraybolt3> ok, grub-pc shows this:
[17:29] <arraybolt3> uh, lemme pastebin
[17:30] <arraybolt3> https://termbin.com/bn4o
[17:30] <tsimonq2> can I get the whole thing?
[17:30] <arraybolt3> I have the ls -l from /dev/disk/by-id coming
[17:30] <arraybolt3> and that is the whole thing
[17:30] <tsimonq2> wait, the whole output?
[17:30] <arraybolt3> That's literally the result of `sudo debconf-show grub-pc | nc termbin.com 9999`
[17:30] <arraybolt3> so yes, that's the whole output
[17:31] <tsimonq2> oh wow this is interesting, ok, yes please what is the /dev/disk/by-id output?
[17:31] <arraybolt3> frustratingly it looks like this particular physical machine with a SATA drive does NOT have multiple /dev/disk/by-id entries that point to the same device!
[17:31] <arraybolt3> https://termbin.com/y01a
[17:31] <arraybolt3> I didn't expect that
[17:31] <arraybolt3> And I cannot safely do this test on my primary laptop.
[17:33] <tsimonq2> arraybolt3: On your primary laptop, any chance you could just run `sudo dpkg-reconfigure grub-pc`, make sure all the entries are correct, then get the debconf-show output from that?
[17:33] <tsimonq2> also looking on my end
[17:35] <arraybolt3> grr, well... https://termbin.com/xiuu now you don't get any device at all... because this is a 22.04 installation on my main laptop.
[17:35] <tsimonq2> aaaaaaaHA
[17:35] <tsimonq2> ok it's only one device
[17:35] <tsimonq2> but it picks the first from the list
[17:36] <arraybolt3> ok good whatever works :P
[17:36] <tsimonq2> arraybolt3: I appreciate ya :)
[17:36] <arraybolt3> sorry I wasn't much help
[17:36] <arraybolt3> I tried *really hard* though
[17:36] <tsimonq2> you helped more than you think - only one debconf setting for that package is a good one
[17:40] <arraybolt3> ah ok
[17:50] <mkukri> make sure to test cryptsetup, LVM and those types of things if you support it too. ive seen weird bugs elsewhere with that before
[17:54] <arraybolt3> mkukri: we have a pretty immense checklist for the Cala-based flavors that covers almost all those weird edge cases (except for LVM which Doesn't Work(TM) with Calamres yet).
[17:54] <arraybolt3> tsimonq2: you still need the BIOS install output? I'm about to reinstall in BIOS mode for that.
[17:55] <arraybolt3> oh fun, Dell's BIOS has arbitrarily decided to gray out my legacy boot option for who-knows-why
[17:55] <arraybolt3> oh there we go, had to enable legacy option ROMs first
[17:58] <tsimonq2> arraybolt3: That would help :)
[17:58] <arraybolt3> kk, in progress...
[17:59] <arraybolt3> (man this installer takes like time and eternity to load)
[17:59] <tsimonq2> Prototype fix:
[17:59] <tsimonq2> +def get_disk_id(device_name):
[17:59] <tsimonq2> +    by_id_path = "/dev/disk/by-id"
[17:59] <tsimonq2> +    device_path = os.path.realpath(device_name)
[17:59] <tsimonq2> +
[17:59] <tsimonq2> +    for entry in os.listdir(by_id_path):
[17:59] <tsimonq2> +        full_entry_path = os.path.join(by_id_path, entry)
[17:59] <tsimonq2> +        if os.path.realpath(full_entry_path) == device_path:
[17:59] <tsimonq2> +            return full_entry_path
[17:59] <tsimonq2> [...]
[17:59] <tsimonq2> +        dev_id_path = get_disk_id(boot_loader["installPath"])
[17:59] <tsimonq2> +        check_target_env_call(["echo 'grub-pc grub-pc/install_devices multiselect " + dev_id_path + "' | debconf-set-selections"])
[18:00] <arraybolt3> Install in progress
[18:01] <arraybolt3> I don't get the details of what that function does but it looks vaguely right to me :)
[18:02] <tsimonq2> the one thing that's verylikely to cause issues is check_target_env_call
[18:02] <tsimonq2> and yep just ran into it not DTRT - coooooooooool
[18:03] <arraybolt3> needs sudo rights perhaps?
[18:03] <arraybolt3> or are you not chroot'd in?
[18:04] <arraybolt3> mmm, you probably need to run that command from within a chroot environment
[18:05] <arraybolt3> tsimonq2: alright a BIOS system has some significantly more interesting keys: https://termbin.com/qixa
[18:06] <arraybolt3> not sure which ones you care about (probably things like grub2/kfreebsd_cmdline_default are ignorable :P), but there you go
[18:06] <arraybolt3> and also ls -l from /dev/disk/by-id: https://termbin.com/15h8
[18:07] <tsimonq2> check_target_env_call means "call this in the target environment and check the result" :)
[18:07] <tsimonq2> arraybolt3: looking thanks!
[18:07] <arraybolt3> ah shoot then you *are* chroot'd in it sounds like
[18:08] <arraybolt3> well, I'm sure you'll figure it out, good luck and I'll be around to try and help
[18:08] <tsimonq2> thanks - also that BIOS output helps thank you :)
[18:44] <tsimonq2> arraybolt3: I have working code for BIOS, testing for EFI
[18:52] <arraybolt3> awesome
[18:59] <tsimonq2> arraybolt3: can I rubber ducky off you real quick?
[19:00] <tsimonq2> BIOS is good, EFI is the last hurdle here
[19:00] <tsimonq2> It seems like in the bootloader module it's being passed as /boot/efi, not the actual partition name
[19:00] <arraybolt3> oooh, ok
[19:01] <tsimonq2> So when grabbing the device ID for EFI, it should grab the ID corresponding to the partition mounted at /boot/efi yes?
[19:01] <arraybolt3> In that instance figure out what partition is mounted at /boot/efi and then use that?
[19:01] <arraybolt3> jinx
[19:01] <arraybolt3> so yeah, that sounds right
[19:01] <tsimonq2> sounds good :) finding some coffee
[19:01]  * genii twitches
[19:36] <mkukri> into install_device you need to put the actual disks
[19:36] <mkukri> tsimonq2, arraybolt3. grub-multi-install internally finds all the ESPs from that and mounts them
[19:37] <mkukri> /boot/efi is just a fallback and that mountpoint is ignored when you set install devices
[19:37] <mkukri> and grub-pc also expects the bare disks, but that part i think is obvious
[19:39] <tsimonq2> mkukri: Oh, just the actual disks?
[19:40] <tsimonq2> mkukri: Nothing under like /dev/disk/by-id or /dev/disk/by-uuid, just e.g. /dev/sda1 ?
[19:40] <mkukri> seems like i am wrong sorry, i checked a desktop installer install and it seems to have the ESP device node https://imgur.com/a/nVSnPGj
[19:40] <mkukri> the by-id and by-uuid part is still there yeah. i was just trying to say that it wasnt expecting the partition but it looks like it is
[19:41] <tsimonq2> No problem! Quick question though...
[19:41] <tsimonq2> Does by-uuid work just as well as by-id in this case?
[19:41] <mkukri> well, i do want to switch to by-uuid *eventually* but it's not tested yet
[19:42] <mkukri> and just to be clear this is the debconf options i get https://imgur.com/a/MvCEVlQ and the above image is the result in debconf db
[19:42] <tsimonq2> mkukri: The current roadblock I have is, for some reason I can only query by-uuid on EFI and by-id on BIOS
[19:43] <tsimonq2> Otherwise I have working code now
[19:44] <mkukri> by-id should work on EFI
[19:44] <mkukri> how are you trying to query it?
[19:44] <tsimonq2> $ ls -l /dev/disk/by-id/
[19:44] <tsimonq2> total 0
[19:44] <tsimonq2> lrwxrwxrwx 1 root root 9 Apr 24 13:45 ata-QEMU_DVD-ROM_QM00001 -> ../../sr0
[19:45] <mkukri> also if you are using a if=virtio disk in qemu you have to give it a serial number on the command line or it wont show up
[19:45] <tsimonq2> mkukri: Simple ls of /dev/disk/by-id
[19:45] <tsimonq2> oooh
[19:45] <tsimonq2> mkukri: I am using QEMU, how does that part work?
[19:45] <mkukri> what command line flag are you using to specify your hard disk?
[19:45] <mkukri> or is it virt manager? or LXD?
[19:45] <tsimonq2> virt-managere
[19:45] <tsimonq2> s/managere/manager/
[19:46] <mkukri> ah i am not sure what that does, but i am guessing it doesnt give the disk a serial number
[19:46] <mkukri> this is a problem with regular ubuntu as well in that case the debconf wont be filled either
[19:46] <mkukri> but the fallback install via /boot/efi still works
[19:46] <mkukri> if you want to test it similar to real hardware, try to specify a disk serial number for your VM in the options somewhere
[19:46] <mkukri> g
[19:47] <mkukri> apparently you can put <serial>some-arbitrary-serial</serial> in the vm's xml inside the <disk> tag
[19:47] <tsimonq2> ok looking then thanks
[19:48] <tsimonq2> mkukri: So to be clear, as for right now you'd recommend against going with by-uuid?
[19:49] <mkukri> if you want to have the same bugs as us then yes :)
[19:49] <mkukri> by uuid is the future plan but maybe it's better if we all switch at once in the 24.10 or 25.04 cycle
[19:50] <tsimonq2> cool, when we do get to that point it'll be a one-liner :)
[19:50] <mkukri> there are problems like UUID's not actually always being unique :/
[19:51]  * mkukri looks at our cloud images in disappointment.....
[19:51] <tsimonq2> oh wowww, okay, didn't know that
[19:52] <mkukri> the issue is, the images are obviously pre generated, so you'd need to replace the uuid with a random one on first boot, but no one has bothered yet
[19:53] <tsimonq2> ahh okay
[19:53] <tsimonq2> mkukri: yes that <serial>ABCDGEF</serial> fix worked \o/
[19:54] <tsimonq2> ok doing a final round of testing before uploading, should be in the clear in the next hour here
[19:54] <mkukri> im glad to hear, that took me many many hours of headbanging to figure out once
[19:54] <mkukri> so you said you dont have LVM or RAID. but do you have cryptsetup?
[19:54] <mkukri> and maybe ZFS?
[19:55] <mkukri> did you test those?
[19:57] <tsimonq2> I can do a round of testing with those, yeah. For now I have just been concerned with making sure regular non-encrypted BIOS and EFI work
[19:57] <tsimonq2> We don't do ZFS, RAID, or LVM at this current point in time, but encrypted installs definitely
[19:58] <mkukri> okay cool im just trying to be exhaustive
[19:58] <tsimonq2> no you're okay :) thanks for that
[19:58] <mkukri> and amd64 bios and uefi are your only GRUB based platforms?
[19:58] <tsimonq2> yes
[19:59] <mkukri> okay i think, i guess that's all the cases than
[19:59] <tsimonq2> cool cool :)
[20:30] -queuebot:#lubuntu-devel- Unapproved: calamares (noble-proposed/universe) [3.3.5-0ubuntu3 => 3.3.5-0ubuntu4] (lubuntu, ubuntustudio)
[20:42] -queuebot:#lubuntu-devel- Unapproved: rejected lubuntu-installer-prompt [source] (noble-proposed) [24.04.5.1]
[20:45] -queuebot:#lubuntu-devel- Unapproved: lubuntu-installer-prompt (noble-proposed/universe) [24.04.5 => 24.04.6] (lubuntu)
[20:50] -queuebot:#lubuntu-devel- Unapproved: accepted lubuntu-installer-prompt [source] (noble-proposed) [24.04.6]