[00:37] So on bug 2064909 they manually set up a single ext4 partition mounted to / with a boot flag and with the encryption box checked and the end result: wrong passphrase. Any clues? [00:37] -Ubottu[m]:#lubuntu-devel- Launchpad Bug #2064909 (https://bugs.launchpad.net/bugs/2064909) in calamares "Lubuntu and Kubuntu 24.04 fail to decrypt on boot when installed on encrypted partition" [Undecided, New] [00:40] oof, he's circumventing the "always leave /boot unencrypted" changes we made [00:41] right so really he should have a separate partition for boot then, eh? [00:41] that's specifically not supported by Canonical. [00:41] according to mkukri [00:42] so yes, he should be making a separate /boot partition. Why this broke is anyone's guess, but this isn't something that probably should be fixed I don't think. [00:44] i don't think we can limit what people can do with manual partitioning, right? [00:44] Correct. [00:45] So there's no way to prevent this other than mentioning it in the manual [00:46] right [00:46] ^ there's a fun one for you lynorian [00:46] I'm going to give him a workaround that might let him do this anyway, and also warn him that this is a bad idea. [00:48] oh i was going to reply and mark it won't fix [00:49] ope, I just replied... [00:49] I think what broke his stuff was that I changed us from using LUKS1 to using LUKS2 when we changed to unencrypted /boot. [00:50] Pretty sure GRUB doesn't support LUKS2 (yet). [02:26] I think it’s best to just stick with unencrypted /boot anyways if not for any other reason but because we can’t ever have an encrypted EFI partition from what I understand [02:27] true [02:28] *if* you have Secure Boot set up and *if* it works right for your system and *if* there isn't some catastrophic vulnerability that lets you bypass it and *if* the user doesn't scream at the sight of the words "Secure" and "Boot" next to each other and turn it off, you can theoretically/hopefully keep tampering of /boot/efi from being a problem. [02:28] As for LUKS, it’s apparent to me that 2 is more secure [02:29] If any of those fail (like on my system where Secure Boot is off and I like it that way), then there's really not much point in encrypted /boot from a theoretical standpoint - getting the key from the user and exfiltrating it becomes harder but not impossible at all. [02:29] ⚠️ if-count level high [02:30] really, if someone malicious gets physical access to your computer for more than a few seconds, you should just reinstall from scratch and restore from backups. Some people can do a lot of damage even in just a few seconds. [02:30] So IMO the security benefits of LUKS2 are worth the problems with unencrypted /boot (not to mention the fact that encrypted /boot is a security *hazard* according to Canonical, so probably there's some way to bypass Secure Boot with a specially crafted passphrase or some other insanity there) [02:31] But we really should put something in the manual about this. Namely:... (full message at ) [02:32] That seems like a good idea to me. [02:32] Yeah the security issues with encrypted /boot are not intuitive. Again, it may be worthwhile to explain [02:32] Also, welcome to my chat system straddling again [02:33] It might also be a good addition to the manual to warn people against using manual partitioning, namely that there are no mechanisms in place to keep the user from doing something that just doesn’t work [02:34] Shoot we might even want to provide some examples. Maybe we could do this in the doc section of discourse and link to it [02:36] Speaking of discourse, I really wish we could move to the main one. The support issue is a sticky wicket, though. I see why they want to promote askubuntu but it’s really got poor categorization. I almost feel like there should be an askbuntu for every flavor [02:36] askbuntu - for those who can't be bothered to hit u three times [02:36] s//\*/, s//\*/ [02:37] but yeah I see what you're saying [02:37] Discourse is just so much more powerful. That’s why we keep wanting to jam everything in there [02:51] "So there's no way to prevent..." <- We could always create a page on Lubuntu discourse in the documentation section... I've been wondering about that since I read Aaron's reply (Thanks arraybolt3 for reply on bug report by the way) [02:52] (I don't think many users will encounter it, thus I see discourse.doco as suitable.. but that's just me) [03:08] * ChrisGuiver[m] catches up on reading and finally noticed Walter already suggested ^ [03:12] Thanks too to wxl [06:41] "catches up on reading and..." <- > * <@guiverc:ubuntu.com> catches up on reading and finally noticed Walter already suggested ^ [06:41] Great minds think alike 🤣 [12:55] "according to mkukri" <- and the Ubuntu Security Team if that helps your case in the future :P [12:56] "Pretty sure GRUB doesn't support..." <- It does, it just isn't secure [17:17] -Ubottu[m]:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Jammy 22.04.4] has been updated (20240508) [18:11] Simon Quigley: I guess you got tired of the methodical bootstrapping and decided "meh, throw it all at the archive" :P [18:11] AaronRainbolt: precisely 😛 [18:12] Maybe you can assign me something I should actually be working on when I have free time. It feels a bit bad to think that syncing things bit by bit was my job and then every morning to wake up and it's already been done or the plan changed :P [18:16] AaronRainbolt: did the Matrix update eat my PM [18:16] looks like it [18:16] Well, this was the easy part [18:16] Next step is no-change rebuilds, and getting it to migrate [18:17] I planned on letting you do that part completely - this will be the easiest Qt 6 transition we'll ever do [18:17] get you some practice for when we get to a million rdeps [18:21] apologies for pulling the rug out from under you more than once during this thing... heh [18:23] np [21:11] Aaron Rainbolt: welp, we're waiting on binNEW [21:12] You're welcome to strategically NCR only those reverse dependencies that do not need something from binNEW [21:15] sounds good [21:40] Attempting my first ncr using doko's rebuild-for script [21:41] fcitx-qt5 [21:42] which I always assumed was called fctix rather than fcitx, so :P [21:43] "Flexible Context-aware Input Tool with eXtension support" [21:43] aka stupid name [21:45] that's a long name [21:46] acronyms over three words long tend to be kind of problematic [21:47] and even five word long ones (SCUBA) are ok, as long as there aren't words in it that aren't part of the acronym [21:53] Aaron Rainbolt: looks like binNMU has been cleared, the baton is yours 🙂 [21:53] neato! [21:53] ooooh, qcoro just went belly-up on symbols [21:54] oh lots and lots of symbols! [21:54] cracks knuckles and prepares for a painful update session [21:54] nice thing is I already uploaded to the archive so I don't need to upload to a PPA to get all the symbols. Just throw a new upload at the archive with the symbols fixes. [21:54] or maybe even sync from Debian if they have it fixed already [21:55] I doubt it heh [21:55] We're actually doing this transition before Debian, so all the FTBFS you are seeing is probably unique [21:56] probably fix symbols in Debian first and then sync for least effort? [21:56] I'll need help with that [21:58] Either solution works, if you're asking for my opinion let's do Ubuntu first then sync whatever necessary changes up to Debian, iff it can be reproduced with an unstable chroot + 6.6.2 from experimental [21:58] sometimes we do carry a delta just for symbols changes... although that's fairly rate [21:58] s/rate/rare/ [21:59] Either way, if the package in question is either in Debian Qt/KDE or in Debian KDE Extras, just ping me, I'll do a team upload to experimental [21:59] kk [21:59] I'll do Ubuntu then since I lack many needed powers in Debian [21:59] and you have things like porterboxes for working on that [22:00] "bah, just iterate in experimental" 😛 [22:01] haha, yeah that too [22:02] just upgraded my build system VM to Oracular [22:47] arraybolt3 / Aaron: how goes the universe? Anything interesting that isn't on Simon's plate as a "don't touch it"? [22:48] teward: Things seem OK on my end, waiting for a couple more qcoro builds to hurry up and crash so I can get the symbols logs for them. [22:48] nice [22:48] I could start NCR'ing some more things in the mean time [22:49] yeah if you need NCRs queued I'd queue those up earlier than later if you need nochange rebuilds because that's coming [22:49] btw is it generally a good idea to NCR in a PPA and *then* throw it at the archive, or is simply hurling things at the builders at Mach speeds and fixing the fallout thereafter acceptable? [22:49] i mean [22:49] it depends? [22:49] reducing initial fallout is best [22:49] but since we're in the Debian Sync states and stuff we're probably going to be having a lot of things in the builders [22:50] it's going to result in an FTBFS with loooooong riscv64 builds either way [22:50] so i always NCR in local sbuild just to make sure there isn't any major nasty hardcrashes I don't expect but [22:50] yeah riscv64 is evilpain [22:50] makes sense [22:53] and the last of the qcoro builds finally went up in flames so I can start fire extinguishing now. [22:54] now I get to enjoy the mental gymnastics of remembering the right syntax for pkgkde-symbolshelper [22:56] * AaronRainbolt sent a code block: http://localhost:8008/_matrix/media/v3/download/chat.staging.ubuntu.com/QQhkSmsBisMYjcNdXwnhHJUk [22:58] I think time_t64 may be rearing its head again [22:58] or the archive is messed up [23:07] looks like a combination of a messed up archive plus bad pinning settings.