[04:26] Bug #1901262 changed: Unable to mount NTFS drives with write support

[04:26] Bug #1904319 changed: pi 400 mate 20.10 gitkraken snap fails to launch <20.10> [07:09] morning [07:09] good morning [07:09] mborzecki mvo found an interesting bug last night [07:10] zyga: hey [07:10] what bug? [07:10] mborzecki we may need to make some mount profiles exempt from robust mount namespace updates [07:10] is there a lp ticket? [07:10] mborzecki tl;dr /var/lib/snapd/hostfs/tmp/.X11-unix /tmp/.X11-unix none bind,ro 0 0 should not be unmounted during mount namespace update [07:11] I think so but we discussed bug details "by hand" not through the system [07:11] mborzecki I was thinking that snapd could mark some mount entries with x-snapd.fragile [07:11] and those would not be unmounted during the re-construction process [07:11] (well, not always I mean) [07:11] and those would use the old algorithm that was used before the robust mount namespace updates we added [07:12] I'm sure mvo will be around and explain everything [07:13] what in particular breaks when that gets unmounted? [07:13] jamesh that's very interessting [07:13] chrome crashes with int3 [07:13] how was that found? [07:13] ah [07:13] as in debugger break? [07:13] mborzecki dunno, ask mvo [07:13] is it AppArmor permissions based on file path of the socket? [07:13] jamesh yes, I strongly suspect that [07:13] re-validation revoking access [07:53] Hi! Is there a documentation or guidelines on how to modify a gadget from uc18 to uc20? Mine is working fine in uc18, but uc20 gives me troubles [07:53] First the error messages were explicit, like you have to remove uboot.env for some reason, fair enough [07:54] But now my ubuntu-image command just fails without much of an error message: https://gist.github.com/gibsson/8fa0b7acd772d714f2d295853419bae8 [07:58] gbisson uc20 and uc18 are quite different, not sure where the docs are now but it may require some changes to fit the new structure [08:00] zyga: thanks, I get that it is different, yet I'd expect some doc to migrate from one to the other, is anybody able to give on insights on the differences? [08:01] gbisson there may be a doc like that, I just don't know [08:01] mborzecki perhaps you have a pointer? [08:03] gbisson: is your model published anywhere? [08:04] morning [08:04] pstolowski: hey [08:05] morphis: hi, yes it is on the store: nitrogen-gadget, source code is here: https://github.com/boundarydevices/ubuntu-core/tree/20-armhf/gadget [08:05] I haven't pushed my latest changes yet, give me a sec [08:06] ok [08:06] it's done, I basically only removed uboot.env.in and touched uboot.conf like rpi does [08:06] pstolowski hey [08:16] I guess I understand the issue, the gadget.yawl needs to have a system-seed [08:20] gbisson: tried building with you model and got the same error [08:20] gbisson: also yes, you need system-seed and system-save [08:21] mborzecki: sure about system-save? the pi-gadget says: "ubuntu-save is optional for unencrypted devices" [08:21] gbisson: it is, if you're 100% you're not going to do encryption then it should be ok [08:22] mborzecki: ok, thanks! [08:23] gbisson: but afaik it can also be used if you do some factory-like modes, which is still wip [08:24] mborzecki: is the 16M size still valid? also, can we use gpt instead of mbr in the gadget.yaml? [08:26] gbisson: 16M will likely be ok, keep in mind there's some overhead from ext4, we try to use 1k block size so that should give you at least 8MB of free space there, but if you deploy that on emmc with 4k logical block sizes you'd likely end up with very little free space [08:26] gbisson: and you can use gpt if your system can boot from that [08:38] good morning mvo [08:40] mborzecki: ok thanks for the details [08:41] good morning zyga === juergh_ is now known as juergh [09:05] is there any chance someone could do https://forum.snapcraft.io/t/create-1-16-track-for-go/22643 quickly? [09:07] morning [09:07] mborzecki: what is system-boot for now? seems like system-seed replaced it? (as it contains all boot-assets) [09:10] gbisson: system-boot is created when system gets installed and should contain the run system bootloader, the usual way we expect it to work is to have bootloaders chainload from seed (aka recovery) -> boot (actual), that's theory which mostly matches how we can make it work with grub, practice may be little different with uboot/lk [09:11] mborzecki: ok so it's needed. Do you have a gpt example by any chance? I only could find mbr and not sure what "type" to use for gpt [09:11] gbisson: iirc with uboot, there' a boot.sel file which lives on system-boot, gets modified by snapd when a new core/kernel arrives and is read by uboot which lives on system-seed (couldn't chainload so there's just one bootloader) [09:13] mborzecki: I see boot.sel in seed part for now, not sure what to do with it [09:13] gbisson: let me see, there's amd64 gadget https://github.com/snapcore/pc-amd64-gadget/blob/20/gadget.yaml and there's a dragonboard one https://github.com/snapcore/dragonboard-gadget/tree/18 but i don't see a 20 branch there yet [09:15] mborzecki: thanks, indeed dragonboard clearly won't work on uc20 right now [09:32] mborzecki: so uboot must load boot.sel from seed (recovery) part the first time and then use the one from boot part instead? [09:53] gbisson: you can take a look at the pi kernel for reference: https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/bootscript/all/bootscr.rpi?h=ubuntu/focal-updates [09:59] mborzecki: perfect thanks! [10:05] pedronis: hi, is there a reason FindSequence(..) is not defined for RODatabase interface? [10:06] pstolowski: no, I suppose it just wasn't needed so far [10:16] ack. i'm not sure it's needed yet [10:34] i'm heading to the dentist. bbl [10:45] PR snapd#9916 opened: daemon: move postSnap and inst.dispatch tests to api_snaps_test.go [11:25] PR snapd#9917 opened: interfaces: opengl: add Xilinx zocl bits === msalvatore_ is now known as msalvatore [11:54] a review for #9859 would be great [11:54] PR #9859: overlord: add manager gadget refresh test [12:34] re [12:39] welcome back pstolowski [13:05] PR snapd#9918 opened: boot: use a common helper for mocking boot assets in cache [13:19] Does snapd restart services when I have already started them in a post-refresh hook via snapctl? Use case: I need to start a service in order to perform migrations, and another one to be up before the last post-refresh line. Would be suboptimal if snapd restarts them again after the post-refresh hook 😊 [13:27] dot-tobias: snapd shouldn't specifically _restart_ services after the post-refresh hook, if the service is inactive but enabled, snapd will start it, but if the service is active and enabled, then snapd will still "start" it but the start will do nothing if I recall correctly [14:46] gbisson: hey if you're still around, I'm curious what bootloader you are using in your nitrogen-gadget? it seems to be an arm based board with u-boot that is _not_ the raspi, is that correct? [15:12] ijohnson, nitrogen is IMX IIRC [15:12] likely u-boot [15:13] mmm right, they will need to use boot.scr instead of uboot.env then [15:13] (for now at least) [15:15] do we have any documentation about how the differences are between UC18 u-boot and UC20 u-boot ? while i have a kernel ready for my https://wiki.radxa.com/RockpiN10 port, figuring out these required gadget changes is really hard [15:15] s/how/all/ [15:16] no we don't unfortunately we talked about writing something up to help folks migrate [15:16] but that hasn't been written just yet [15:16] that would be great [15:16] yeah, understood ... [15:17] but i guess uboot.env would stay simply untouched and upstream-style, just making sure to consume boot.scr from it then ? [15:18] (and snapd only modifies boot,scr) [15:23] ijohnson: Thanks! Was hoping for that, thanks for the clarification! [15:24] dot-tobias: np happy to help, if that's not how things work feel free to reach out again and we can take a look [15:24] ogra: well the issue is more that u-boot itself when it sees both uboot.env and boot.scr does weird things like ignoring one and only using the other iirc [15:25] yeah, i didnt literally mean uboot.env but simply the built in environment [15:25] i.e. make sure the default env loads boot.scr (created during gadget creation)... snapd handles the rest [15:27] ijohnson nitrogen is an coretex m board [15:35] https://boundarydevices.com/product/nitrogen6x/ [15:35] and https://boundarydevices.com/nitrogen-sbcs-and-soms/ [15:36] iMX 6-8 [15:37] not actually coretex-m 🙂 [15:37] (some come with additional -m attached though) [15:54] Bug #1912615 changed: Snapd refresh doesn't recover from connection interruption [15:56] PR snapcraft#3435 opened: extensions: Fix Documents, Pictures etc symlinks [15:57] it me! [16:06] Bug #1912615 opened: Snapd refresh doesn't recover from connection interruption [16:12] Bug #1912615 changed: Snapd refresh doesn't recover from connection interruption [16:29] pedronis: i think https://bugs.launchpad.net/snapd/+bug/1899992 is an interesting general issue where we let valid core config in, but over time it stops being valid (because of various factors other than us declaring something obsolete), and this breaks all core config processing on first validation error [16:29] Bug #1899992: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:30] Bug #1899992 changed: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:31] pstolowski: yes, it's a config option whose validity can change over time [16:32] pstolowski: we need to think a bit what to do [16:32] ijohnson: yes I'm using i.MX platforms with uboot [16:33] Bug #1899992 opened: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:36] pedronis: yes.. i think options that were once valid and we let them in, should only result in warnings later and not prevent other settings. not sure how annoying that will be [16:36] anyway, something for later [16:37] pstolowski: in theory we should only validate the delta [16:37] (that's not how the code is organized right now, I know) [16:37] pedronis: that's a good point, although it would make sense to let the user know that some setting is no longer effective [16:39] I know, but anyway even under that principle (validate only delta), this is a case where the code applying things would have to deal with invalid things (because validity is not only a property of the value) [16:39] ogra: interesting, different nitrogen [16:39] yeah 🙂 [16:40] pstolowski: so we could do something special there [16:42] Bug #1899992 changed: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:44] pedronis: ok, we can discuss and i can take a look a this after validation sets or when i'm blocked [16:48] Bug #1899992 opened: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:51] Bug #1899992 changed: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [16:53] mup: please stop [16:53] pstolowski: I apologize, but I'm pretty strict about only responding to known commands. [17:11] pstolowski: I approved #9893 with some comments [17:11] PR #9893: store: support validation sets with fetch-assertions action

[17:13] pedronis: thanks! === Ringtailed-Fox is now known as RingtailedFox