[00:00] @kc2bez OK, that would make sense. I'm also wondering if it's doing non-BTRFS-compatible things like swapfiles that are causing the mess, or maybe it's making a wonky fstab. [00:02] Maybe. Makes me wonder why it worked before though. It actually didn't start failing until late in the cycle. [00:08] I'm pretty sure I found it. [00:08] When you do a calamares BTRFS install, the fstab file has a bunch of options after the word "defaults" that are set. [00:09] Deleting all of those options makes it boot. And this is with using Calamares to install directly to BTRFS. [00:09] My working fstab looks like this: [00:09] UUID= / btrfs subvol=/@,defaults 0 1 [00:09] UUID= /home btrfs subvol=/@home,defaults 0 2 [00:10] Upgrading works [00:10] By modding the fstab file to look like that, it boots properly. [00:10] arraybolt3: Why would that be the case if the fstabs are identical between versions? [00:10] Also, it would be worth looking into which argument [00:10] OK, will do. [00:10] Not sure why it works, but it does. [00:14] I nuked all the "extra" options in the fstab, so now I'm having to do another exploded install, so it'll take me a bit. [00:14] Thanks [00:14] tsimonq2: Upgrading works? That's very good to know. Congrats! [00:15] Thanks :) [00:18] Oh, I also got rid of the swap entry, I just remembered. Dunno if that has anything to do with it, we'll find out. [00:20] OK, removing just the swap entry didn't make things better. In fact, I got more errors this time. [00:22] Removing autodefrag from both / and /home also didn't help. [00:23] Removing space_cache from both / and /home allows it to boot. [00:26] Pinpointed issue to space_cache. Now I'm going to find out which entry needs space_cache removed to allow bootup. [00:30] @tsimonq2 @teward If the space_cache option is set on the root fs in fstab, a BTRFS install will fail to boot. [00:31] If I use the default generated fstab but remove the space_cache option from only just the root fs, everything works. I can leave space_cache on the home fs and on swap. [00:32] [telegram] Okay, so the next question is what exactly that option does [00:32] Uh... I have no idea. :D [00:32] [telegram] And what made it grumpy all of the sudden. [00:34] https://superuser.com/questions/855506 [00:35] Also https://redd.it/kxar77 [00:37] OK, here's the actual official source: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html [00:38] It does something that speeds up disk access. I'm wondering if maybe the kernel is expecting space_cache v2 when only space_cache v1 is in use. Let's see... [00:40] @tsimonq2 @teward Something more interesting: the thing boots when using "space_cache=v2" on the root fs. [00:43] arraybolt3: Before I forget, what's a name I can credit you by when we get this fixed? :) [00:43] I use the name Aaron Rainbolt. (You don't have to credit me, though, this is a team effort, and we've all fried our brains trying to make this work.) [00:44] It seems we're close. I have to go AFK nowish but when I come back I'll confirm and tweak the Cala settings [00:44] OK. One last thing, using "clear_cache,space_cache=v1" also let it boot. [00:44] Fair enough but thanks :) if we do end up respinning before the first point release with this, I'll add you to the list [00:45] I'm guessing something is mounting the filesystem with space_cache=v2, and the BTRFS docs state that once space_cache=v2 is used, it will always be used unless you use clear_cache,sp [00:45] clear_cache,space_cache=v1. [00:46] Got it [00:48] Or clear_cache,nospace_cache. (Don't take my word as gospel, if I refer to the docs, use the docs, I shorten stuff sometimes) [01:39] arraybolt3: You nailed it. I edited the fstab.conf calamares module with space_cache=v2 for btrfs and the install worked. [01:40] NICE! Wow, we make a great team. [02:30] tsimonq2: kc2bez[m]: not sure this warrants a respin just for BTRFS. Just saying. [02:31] I don't think so either; we can just document what needs to be done to install/correct an install too; my 2c We can correct at 22.04.1 [02:39] i agree with guiverc though it's why i asked ;) [02:39] * guiverc thought I was agreeing with you teward [02:40] i'm tired :P [02:40] * guiverc smiles [04:12] Not a special respin but if we want it for 22.04.1 it needs to be a SRU. We'll need it for 22.10 anyway. [04:18] I've almost finished writing the workaround guide. [04:19] kc2bez: Your solution with modding /etc/calamares/fstab.conf was awesome, and I'm using it in the guide. Thank you! [04:21] Agh, wrong file path, I meant /etc/calamares/modules/fstab.conf [04:22] we could always push the work-around (on discourse) to blog as well of special-respin.. blog will allow more readers, ubuntu-news (maybe) etc & thus it's being treated as special.case & we're working for users benefit maybe? [04:23] * guiverc note as always, I'm writing with lubuntu hat on ^ [04:25] As it turns out, there's three solutions to the BTRFS problem. You can use kc2bez's installation config tweak, you can mod fstab after installation, or you can mount the BTRFS partition with "mount /dev/vda1 /mnt -o clear_cache,space_cache=v1" after installation. Should I document all three? Currently, I've only documented the first two. [04:30] Unless others (ie. devs) have an opinion it's your choice.. You could always document two 'properly' then state a third as part of a final paragraph & mention briefly. I'll convert to a wiki once on discourse so it can be edited as required (by you too arraybolt3 I hope soon) [04:34] guiverc: OK. I like your solution. I like only documenting one solution per problem, since the Arch community has demonstrated that, if you're given two solutions to the same problem, there's a good chance that you'll use *both* solutions rather than one or the other. I don't think that would blow everything up here, but it's still unnecessary. Your solution lets me document everything [04:34] without as much risk of that happening. [04:35] If you're happy with just documented one (the best) you can do that too.. Most GNU/Linux is a do-ocracy; those that do the work decide [04:36] * guiverc is using a term I heard Richard Brown (ex-OpenSuSE head) use many times.. [04:36] LOL yeah but the best solution is the best solution, no matter who thought of it. [05:19] arraybolt3, FYI: I changed **bold** to #title (it's larger & new/existing installation stands out better), I'll also add around ctrl+alt+T [05:25] Oh, thank you! I didn't know Discourse had that feature. Nice. [05:25] another edit; there were more keys I missed... [05:27] I like what that thing does. I'll start using it. [05:27] yeah it make it easier to read I believe [05:29] Thank you so much! [05:30] Nah, it's mostly Thank you very much arraybolt3; you've achieved the wanted solution ! [05:32] OK, my brain is beginning to resemble a lump of charcoal, so I think I'll go offline for a bit before my head explodes. :) I am so thankful and honored to be a part of this team, and thank you all for everything you've done and for letting me help! [12:07] So, got some news from upstream. They're saying kernel bug. Apparently space_cache was changed in 5.15, who woulda thought? [12:07] "Since space_cache=v2 is set by default in kernel 5.15 and later, you can probably just remove that from your fstab.conf." [12:08] Bingo [12:09] "I am not sure how Ubuntu boots exactly but what was happening in Arch-based distros is that it was mounting the filesystem in the initrd with space_cache=v2 and then trying to mount the other subvols with space_cache=v1 which fails." [12:09] So Aaron was probably half-right [12:10] Nice! [12:13] https://github.com/calamares/calamares/commit/0bef2a91a1b529425bb53bedd0eba087270e1eb5 [12:13] Commit 0bef2a9 in calamares/calamares "[fstab] Remove space_cache from btrfs mount options" [12:22] https://github.com/calamares/calamares/pull/1824 [12:22] Pull 1824 in calamares/calamares "Remove space_cache from btrfs mount options" [Merged] [12:26] guiverc @Leokolb feel free to test the above fix if you have a second before I do ^ [12:26] I still need to find my flash drive with my GPG key :) [12:26] Probably by EOD USA time I'll be able to test myself [12:27] [telegram] Good news! [12:29] For sure! [13:02] kc2bez[m]: oh definitely this needs SRU'd in for .1 [13:02] [telegram] Tested and works! Thanks @tsimonq2 - (re @lubuntu_bot: (irc) guiverc @Leokolb feel free to test the above fix if you have a second before I do ^) [13:02] but i can push that hard if needed [13:03] *pushes tsimonq2 into /dev/urandom for reasons* [13:12] [telegram] I think @teward001 has It :P (re @lubuntu_bot: (irc) I still need to find my flash drive with my GPG key :)) [14:31] [telegram] Updated orig BTRFS bug report https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1966774 - comment #15 :) [14:31] Launchpad bug 1966774 in calamares (Ubuntu) "btrfs partioning with calamares results in unbootable system" [Undecided, Confirmed] [15:09] [telegram] nah simon left it in /dev/null. so its gone (re @N0um3n0: I think @teward001 has It :P) [15:19] GO SIMON GO! [15:20] * Eickmeyer cheers [15:22] [telegram] 👍 (re @lubuntu_bot: (irc) cheers) [15:43] [telegram] @kc2bez FYI - i'm going to be using drone.io in a self-hosted instance/environment for our CI now. it's docker driven primarily [15:43] [telegram] we'll just use my drone instance for now that's on a VPS [15:44] * tsimonq2 excludes the change from Ubuntu Studio and makes Eickmeyer fix it himself [15:44] jk XD [15:44] anyway [15:44] Now for the flash drive hunt... I'll be afk for that [15:44] When I come back, I'll have a few uploads to kinetic [15:45] Once those hit proposed (Chris and Leo may want to watch for that) I'll link it here, you should just be able to upgrade the Calamares settings package to test and be good [15:48] [telegram] :) (re @lubuntu_bot: (irc) Once those hit proposed (Chris and Leo may want to watch for that) I'll link it here, you should just be able to upgrade the Calamares settings package to test and be good) [15:57] Many thanks Simon Quigley ! [16:03] @teward001 That makes sense, I think it should work for us. [16:45] -queuebot:#lubuntu-devel- Unapproved: calamares-settings-ubuntu (kinetic-proposed/universe) [1:22.04.4 => 1:22.10.1] (lubuntu, ubuntustudio) [17:12] ^^^ [17:12] LocutusOfBorg sponsored for me since I can't find my flash drive yet. Thanks :) [17:14] :) [17:46] [telegram] tsimonq2: was it for Ubuntu or for Debian [17:46] [telegram] 'cause i can't sponsor anything in Debian [17:46] [telegram] also FT job is FT job [17:47] Ubuntu, you can't see it in Telegram [17:47] Unapproved: calamares-settings-ubuntu (kinetic-proposed/universe) [1:22.04.4 => 1:22.10.1] (lubuntu, ubuntustudio) [17:49] [telegram] kc2bez: i was responding to Simon stabbing me privately to sponsor :P [17:49] [telegram] thanks [17:56] 👍️ [20:34] Okay so, vorlon indicated that it's not an SRU blocker for that to land in Kinetic. [20:34] If anyone wants to get a head-start on the paperwork, go for it. Otherwise that's looking like a weekend thing or perhaps Monday thing [20:35] [telegram] https://matterbridge.lubuntu.me/040a1615/file_4371.jpg [21:05] -queuebot:#lubuntu-devel- Unapproved: accepted lubuntu-meta [source] (kinetic-proposed) [22.10.1] [21:45] Hey, this might be silly, but does anyone have an idea of when the first kinetic ISOs will be out for beta testing? I've not done beta testing before, but would like to. [21:46] Or I guess alpha testing, but whatever. [21:48] [telegram] I'd not expect to see dailies of kinetic for a week or two (alpha) [21:48] OK. [21:50] What do lubuntu developers usually do when a new release first gets going? I've heard of "packaging" but I don't know what that is or how to do it. [21:51] Not sure what is up with matrix. It doesn't look like my messages are making it. [21:51] @kc2bez :( [21:51] arraybolt3: this is a good page to read for testing. https://phab.lubuntu.me/w/testing/ [21:51] https://phab.lubuntu.me/w/packaging/packaging-guide/ [21:52] Thank you kindly! @kc2bez @guiverc [21:52] but as for packaging, standard Ubuntu & Debian guides are good resources too [21:53] https://packaging.ubuntu.com/html/ https://packaging.ubuntu.com/ubuntu-packaging-guide.pdf etc [21:54] Cool. I'll take a look at those. [21:55] We follow the Debian policy as referred by the Lubuntu wiki page. [21:55] I'd read the Lubuntu docs first; most appropriate.. the Ubuntu/Debian stuff is useful for general background [22:01] To over simplify a bit packaging is the "formula" which packages are created. Debian and therefore Ubuntu have specific guidelines on how they are created. [22:02] Is packaging how we get new versions of software into (L)Ubuntu? [22:04] Essentially, yes. Developers adjust the packaging based on changes made upstream and then can build the packages. [22:05] Developers sign and upload to the appropriate place. [22:05] Nice. The Lubuntu guide was a bit over my head, so I'm reading the Ubuntu guide and then I'll hopefully be able to understand the other one. [22:05] It comes with time. [22:06] Hang around and we can get you there. [22:22] Yeah, kinetic just barely opened, I wouldn't think we need a SRU for that only jammy [22:23] Oh that is amazingly out of context now. [22:24] I think there are some others floating around the ether too. [22:25] Getting it tested in kinetic should help with the SRU process though. [23:00] In the meantime this is a good page to read. https://phab.lubuntu.me/w/testing/ [23:00] Thanks! [23:01] I sent that an hour ago on Matrx ;) [23:02] I see that, but I sorta missed it... [23:02] I submitted a request to join Lubuntu-QA [23:04] already approved it looks like arraybolt3 [23:05] :) [23:05] but thanks arraybolt3 for letting us know (so it can be approved etc) [23:06] Thank you! [23:10] Of course. Thanks for sticking around and helping out!