=== chihchun_afk is now known as chihchun [07:03] good morning [08:11] hey fgimenez, one review please :) [08:11] https://github.com/elopio/subunit/pull/5 [08:12] hi elopio! sure, on it [08:18] mo'in [08:19] elopio: what're you doing up?!? [08:19] Chipaca: hackin' [08:19] going to bed now. [08:19] _o/ [08:19] elopio: that last one sounds like an eminently sane idea [08:42] ogra_: hi, so - silly question. if I mount /writable in the inird read-only and then put it into the generated /etc/fstab as "LABEL=writable /writable ext4 remount,rw 0 0", should this work? [08:42] work for what exactly ? [08:43] (why do you want it in fstab ?) [08:43] ogra_: work in the sense that it will remount it [08:43] sure [08:43] ogra_: how to debug if it does not work :) ? [08:43] sudo touch /writable/foo ... after boot ? [08:44] ogra_: readonly fs, I see it in mount as mounted ro, but fstab conains the remount,rw line and systemd tells me the writable.mount was run [08:44] (i guess your boot log and console would be full of errors already by stuff that tries to write to it via a bind mount) [08:44] ogra_: yeah, there are some errors, fortunately it keeps booting [08:45] i'm not sure if you can force an order of mounts [08:45] you definitely want it rw beofre anything tries to access one of the bind mounts [08:45] pitti: is the fstab generated mounts ordered or will systemd try to mount it all at once? (context is my question above) [08:45] ogra_: aha, that might be a issue indeed [08:46] well, you can influence how we generate the fstab (thats done in initrd) [08:46] ogra_: hrm, hrm, I was hoping I could get back to read-only only in initramfs :/ [08:46] so you could put /writable first in there [08:46] ogra_: right, I did that [08:46] the question is if systemd will process it in the order it is in fstab or not [08:46] i still dont understand why you want this [08:47] mvo: partially ordered, subdirs auto-depend on mounts of their parent dirs [08:47] (you could as well just remount it froma local-bottom script instead) [08:48] pitti: thanks [08:48] mvo:$ systemctl show -p RequiresMountsFor proc-sys-fs-binfmt_misc.mount [08:48] RequiresMountsFor=/proc/sys/fs [08:48] mvo: ^ for example [08:48] pitti, heh, and for cross device bind mounts ? [08:48] ogra_: right, I could just leave it as it is (rw), I had hoped to move all the rw logic out of initrd so that systemd can do the fsck, provide a better emergency etc [08:48] mvo: and RequiresMountsFor= translates into something like Requrires/After=proc-sys-fs.mount for any parent mount [08:49] pitti: aha, nice. let me see [08:49] ogra_: shouldn't matter - a mount is a mount? [08:49] pitti, well, /writable/system-data/foobar might come from /readonly/foobar [08:50] pitti: could it be that systemd paritial ordering does not work for bind mounts, i.e. it only looks at the second column of the bind mounts? [08:50] mvo: could be; haven't read scrollback here yet (still talking to doko/fighting with puppet); can you pastebin systemctl show of that .mount? [08:50] right, the question is if it looks for /writable or for /readonly in the above case [08:51] if the latter then it wont consider it depending on having /writable mounted first [08:52] mvo: ah, the case is "remount"? [08:52] mvo: could very well be that it stumbles over that -- /writable is already mounted, after all [08:52] (just not with the changed options) [08:52] yeah [08:53] i'D really keep that bit in initrd [08:53] pitti: its hard for me to pastebin, this is a very hacked snappy VM, the dependencies look ok of my writable.mount [08:53] the whole basic assembly of the underlying setup at least (/writable plus system-a/b) [08:53] pitti: is there a way to figure out if it actually ran anything [08:55] ogra_: hm, so the initrd will mount /writable and /boot sure, but I wonder if it would make sense to mount it RO and do the RW later [08:55] mvo, yeah, from a local-bottom script [08:55] ogra_: I'm not a initrd guy, so I may be totally off, but what I keep hearing is that this whole fsck in the initrd is bad [08:55] thats runs right before run-init [08:58] well, do we still need the fsck for vfat after the changes we made ? [08:58] i think we shoudl be fine without it nowadays [08:59] mvo: there should be someting like "Mounting /writable..." ... "Mounted /writable" in the journal? [08:59] (snappy update should perhaps run it when/after writing instead, normally nothing writes to the vfat in a way that fs content changes otherwise) [09:00] ogra_: we mount /writable RW in the initrd, part of that is that its is fscked before and I would like to avoid that (same for /boot fwiw). mount both RO and let the normal system startup do the RW and possible fsck dance [09:00] ogra_: but keep in mind I may be totally wrong about that this is a worthwhile goal to persue :) [09:00] mvo: I tested with a bind mount of /media -> /home/media, and I get RequiresMountsFor=/home /media [09:00] yippie ! my new alix board just arrived ... will be my first snappy server ! [09:01] mvo: i. e. at first sight it seems to take the "first column" into account as well for bind mounts -- I suppose it's rather because /writalbe is already mounted, so that the RequiresMountsFor= is satisfied? [09:01] ogra_: new toys! [09:01] mvo, well, we might need to write to it from initrd [09:01] pitti: yeah, the dependencies look ok [09:01] mvo: so check the journal, I suppose it gets remounted too late? [09:02] ogra_: maybe, but I don't see any writes currently (at least in the version that uses squashfs) [09:02] http://www.amazon.de/gp/product/B00JR6X0ZK [09:02] pitti: I don't see anything about /writable in the journal from systemd [09:02] mvo: there are ways around it, like adding a drop-in for systemd-remount-fs.service to also make /writable r/w instead of remounting it in the fstab; just a bit strange [09:02] mvo, yea, thats why i said "might" :) [09:03] we currently dont but that couold change [09:03] ogra_: heh :) ok [09:03] ogra_: well, we could simply reenable all of it once it changes? [09:03] imagine we'd move away from livecd-rootfs and put the /etc/timezone or /etc/hostname stuff in place during boot [09:04] pitti: journalctl -u writable.mount says no entries [09:04] pitti: systemctl status writable.mount tells me its active (mounted) [09:04] i guess we could have our own systemd unit that does the remount without using fstab [09:05] would be the same as a local-bottom script though [09:05] ogra_: yeah [09:05] ogra_: right, then we can just leave it as it is I guess [09:05] I'm mostly curious at this point if I do something wrong or if there is a bug [09:06] ogra_: then I'd just append it to systemd-remount-fs.service and get the ordering for free? [09:06] as long as we are ext4 fsck wont be a biggie anyway for /writable [09:06] it is rather cosmetic [09:12] Good morning all; happy Friday, and happy No News is Good News Day! 😃 [09:31] pitti: ok, so I think systemd simply not supports remount in fstab, it has systemd-remount-fs.service and it looks like this only looks for /, /usr [09:32] mvo: right, what I suspected; so this could be come a systemd-remount-fs.service.d/writable.conf with an extra "ExecStartPost=/bin/mount -o remount" if you want that, then it'll inherit the same dependencies (i. e. it will be done before any other fstab entry) [09:32] pitti: hrm, I think I will just leave it in the initramfs then [09:33] well, we should keep that possibility in mind in case we ever actually *need* to move it out [09:34] given that writable might be encrypted we'll likely need to keep it in initrd though [09:34] (hwo do we handle fsck with encrypted root on server/desktop today btw ? that should have a similar issue) [09:39] ogra_: it hasn't really changed in ages -- the initramfs sets that up [09:39] let's hear it for tests! wooo! [09:39] * Chipaca just found a nasty bug before committing code :) [09:39] pitti, yes, but who does the fsck ? [09:39] is it mountall/systemd or the initrd [09:39] ogra_: back in the days, the OS; with recent initramfs-tools it now fscks / (and /usr) by itself [09:40] ogra_: "OS" -> mountall or systemd-fsck [09:40] ah [09:40] I think the initramfs-tools maintainer's argument was that it's generally a bad idea to fsck the root partition with tools from the root partitions [09:40] so the decryption happens in readonly ? [09:40] ogra_: yes AFAIUI [09:40] ah [09:41] while that argument makes sense, it makes nice plymouth integration much harder, though [09:41] i. e. we lost plymouthy fsck feedback for the root partition [09:41] so, I'm not sure I actually like that change :) [09:41] heh, yeah [09:42] pretty vs. robust, tough :) [09:46] wheee ! [09:46] and my new snappy server is assembled, installed and running :D [09:46] that was exactly 20min of work :D [09:47] (including HW assembly) [09:51] hmmm [09:51] but the resizing didnt work [09:51] (partition is resized, the fs isnt :/ ) [09:54] weird, worked on the second boot [10:00] ogra_: already have your mail stuff snapped? [10:01] asac, nope, thats weekend work ... [10:01] ogra_: if you make a nice bundle that i can easily configure i could also replace my mailserver [10:01] i also want the user setup to be a bit different [10:01] remember to include TLS for the MTA [10:01] then i am in [10:01] one snap delivering a great integrated solution [10:01] MTA, mail filtering, imap [10:01] (and i'm still waiting for the actual SSD, that will only come on monday) [10:01] in one bundle [10:01] mvo: have you seen thomi's talk on connascence? [10:01] easy to configure :) ... done. [10:02] a 32G SDD as bundled doesnt really cut it ;) [10:02] ogra_: you can start with SD to hack on it :) [10:02] Chipaca: not sure, what was the link again? [10:02] ogra_: 32G would be enough for my mail needs [10:02] send it my way :P [10:02] yeah, i have a kingston 32G SSD ... and an USB mSATA adapter here [10:02] you can have it when the new one is here :) [10:02] cool [10:03] it is enought for experimenting on the weekend though [10:03] with snappy home-mail product preinstalled... i am your first customer :P [10:03] mvo: https://www.youtube.com/watch?v=iwADIlIgDNA [10:03] just plug and boot [10:03] haha [10:03] well, you dont want an ogra user preinstalled with my ssh key i guess ;) [10:03] snappy-mail-geek-ready [10:04] a year from now I'm going to own a snappy-powered AI that will have the keys to my snappy-powered attack drone^W^Wspider bot [10:04] I feel like i'm in the future already [10:05] Chipaca, lame ... you just install the AI snap on the drone directly :P [10:05] ogra_: batteries will still be a problem a year from now [10:05] ogra_: we won't solve that one for a bit yet :) [10:05] there are always solar panels you can stick onto it [10:06] ogra_: and give whatever it chooses to attack an easy way to disable it? [10:07] ah, well ... you got a point there [10:32] Chipaca, did we change anything wrt snappy config ... nothing in bug 1472788 seems to work anymore for me [10:32] bug 1472788 in Snappy "snappy config does not work from stdin" [Critical,Triaged] https://launchpad.net/bugs/1472788 [10:32] all variants just generate a go backtrace [10:32] (i'm on 15.04 edge here though) [10:32] ogra_: can you show me the session? [10:33] http://paste.ubuntu.com/12334856/ [10:33] that line used to work for me in the past [10:35] ogra_: and if you add -- before the - ? [10:35] hangs [10:40] mmm [10:40] why the heck to we even need to pass yaml into the command instead of having set/get for variable/value pairs [10:40] * ogra_ still doesnt get whats the benefit of it [10:41] ogra_: what's "15.04 edge" ? [10:41] ogra_: because that code doesn't seem to be what i have here [10:41] Chipaca, the daily 15.04 build [10:41] http://system-image.ubuntu.com/ubuntu-core/15.04/ [10:42] ubuntu-snappy 1.0.1-1+472~ubuntu15.04.1 [10:42] ubuntu-snappy-cli 1.0.1-1+472~ubuntu15.04.1 [10:42] is what the manifest for that image says [10:47] Chipaca, care to quickly look at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (the last commit only if you want) [10:47] * sergiusens fought with raw strings in python sometimes not being raw strings [10:47] oh, and to keep the human touch going, good morning to all (applied retroactively as well) [10:48] moin moin [10:48] good morning sergiusens :) [10:49] hmm, if i use --enable-ssh will there still be an ubuntu user ? and will password auth be on ? [10:49] umm [10:49] ogra_: your yaml is bad and you should feel bad [10:49] * ogra_ feels bad [10:49] ogra_: add an extra space before timezone [10:49] same thing [10:50] ogra_: python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))' [10:50] ogra_: and feed it your yaml [10:52] with the same redirect ? [10:52] ogra_, add two spaces instead of one after config:\n [10:52] and shift the inner ones accordingly [10:52] sergiusens, already tried [10:52] ogra_: yes, with the same redirect [10:52] Chipaca, hangs [10:53] (amd64)ubuntu@localhost:~$ python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))' <(echo 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n') [10:53] ogra_, SIGABRT to see where :-) [10:53] dude [10:53] duude [10:53] (even with corrected space it hangs) [10:53] ogra_: < <(...) [10:54] so many things wrong [10:54] geez [10:54] for example, echo -e [10:54] how else would you force the backslash interpretation in non bash echo ? [10:55] ah, if it's non-bash, then i think you don't need -e [10:55] that is [10:55] dash builtin echo does not need -e [10:55] but /bin/echo does [10:55] but [10:56] on the other hand [10:56] dash does not have <(), or does it? [10:56] -e is a no-op for all the others [10:56] POSIX knows <() i think [10:56] nope [10:57] anyway ... not working ... (no error either though) [10:57] am I seeing this right? ogra_ writing bashisms? [10:57] :P [10:57] * Chipaca refers ogra_ to http://mywiki.wooledge.org/Bashism [10:57] i just want to set my timezone [10:57] ogra_: show me again what you're doing please [10:57] this is really hard :( [10:58] snappy config ubuntu-core < <(echo 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n') [10:58] the nicely prints the config ... using Etc/timezone [10:58] ogra_: that should do nothing [10:58] ogra_: right, that's "get" [10:58] ogra_: "set" is with an argument [10:58] ogra_: go with -- - [10:58] tried, same go traceback [10:59] ogra_: yes, because -e [10:59] ogra_: you can't use <() and not -e a the same time [10:59] doesnt matter if i add or remove -e [10:59] same error [11:00] you're going to make me *try* this stuff [11:00] same behavior in all cases [11:00] * Chipaca boots something that may or may not be 15.04 edge [11:00] oooh [11:00] new error ! [11:01] no, this is 15.04 stable. still, should be the same [11:01] (amd64)ubuntu@localhost:~$ sudo snappy config ubuntu-core -- <(echo -e 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n') [11:01] open /dev/fd/63: no such file or directory [11:01] ogra_: -- - [11:01] and < [11:01] hanngs hard [11:01] dammit [11:01] ha [11:01] < did it [11:01] seriously ... who came up with that insanity [11:02] can we please have proper set/get syntax alongside ? [11:02] ogra_: http://pastebin.ubuntu.com/12335797/ [11:03] Chipaca, right, thats what worked here too now [11:03] ah [11:03] missed that [11:04] still, how is an admin supposed to ever decypher that line ? [11:04] ogra_: http://i.imgur.com/YsbKHg1.gifv [11:04] LOL [11:04] right [11:05] also setting the hostname should tell you that you need to reboot to make it take effect [11:05] (or at least to re-login) [11:06] (not sure, perhaps the timezone setting needs that too) [11:15] ogra_: config can't communicate that kind of thing out :-/ [11:15] maybe it should be able to, but right now it can't [11:16] well, perhaps a generic message like "you might have changed config options that require a reboot" [11:17] ogra_: i'd rather let config hooks tell you things [11:17] yeah, or that [11:17] like "you can't tell me to only use three of the four propellers when i'm a fridge" [11:18] or "this config is dangerous, ask for it again for it to take effect" [11:18] or something, dunno [11:18] just info/error messages [11:19] yeah [11:20] if you want to go crazy, debug messages (logged, not shown), info messages (logged, shown), error messages (logged, shown, config fails) [11:21] yup [11:24] hmm [11:24] why does /var/lib/extrausers/subuid not exist on that image [11:24] i added that in livecd-rootfs [11:26] weird, not there [11:30] * ogra_ uploads a fix [11:37] ogra_, Chipaca the config spec is not completely implemented, configs are supposed to return success or failure with reason [11:38] sergiusens: also probably not panic on bad input [11:38] :) [11:38] well, i think making the interface actually usable is more important than messages and feedback in the end [11:38] its a nice to have thing :) [11:38] Chipaca, that is up to each hook [11:39] sergiusens: yes, the ubuntu-core hook panics and brings snappy down with it, which shouldn't happen [12:07] ok, lunch break for me [12:25] mvo: anyhing I can do to get your branch merged? I'd rather not have LXD use a private, temporary bzr branch if I can help it :) [12:37] stgraber: absolutely agreed, I poked the gettext-go upstream again, no reaction though. to get it merge into trunk someone needs to review it, I need either sergiusens or Chipaca to look at https://code.launchpad.net/~mvo/snappy/snappy-gettext-fixes/+merge/270620. alternatively you (or someone from your team) can of course review it as well :) [12:38] whoa, \" -> \\" ftw [12:41] mvo: looks like it's been reviewed now, thanks :) [12:48] daemon/task.go:29:2: struct field Id should be ID [12:48] whoever wrote golint did not know id was a word, not an acronym [12:53] https://github.com/golang/lint/issues/89 [12:54] thanks Chipaca [12:55] Chipaca: meh, the comment in this upstream bug is unhelpful, there should be at least a --ignore=E101 or something [12:56] i'm coming to expect that kind of response from go upstream [12:56] mvo: in other news, https://code.launchpad.net/~chipaca/snappy/tasks/+merge/270813 \o/ [12:58] hm, that diff is borked, 1 sec [12:58] Chipaca: yay, I go and review now [12:58] fixed now :) [13:36] ppisati, hmm, do you plan non snappy RPi images ? [13:36] * ogra_ just saw bug 1494719 [13:36] bug 1494719 in flash-kernel (Ubuntu) "Support for the RaspberryPi2 platform" [Undecided,New] https://launchpad.net/bugs/1494719 [13:36] ogra_: i already vanilla ubuntu rpi2 images [13:36] *have [13:44] ppisati, well, i was just wondering if you plan actual isos/imgs [13:45] mvo: Did you have a chance to look at the python-apt stuff? Seems like it's having trouble kicking the local system habit. [13:45] tedg: ups, once sec [13:45] np [13:46] https://code.launchpad.net/~chipaca/snappy/daemon-daemon-please-add-a-task---no-by-the-chin-of-my-chinny-chin-chin/+merge/270821 [13:46] and school run for me [13:46] Chipaca: Make sure to listen to the teachers and do your homework! [13:47] tedg, btw, how is that pip plugin looking? [13:47] sergiusens: Okay, I wanted to confirm with zyga that it works for checkbox before doing the MR. [13:47] Chipaca, buffer overflow, branch name too long [13:47] sergiusens: I think they may need an array of requirements text files. [13:48] tedg, ah, so it is on the same branch as before and updated? [13:48] * sergiusens checks [13:48] sergiusens: Yup [13:48] * tedg checks a push to make sure it's all up [13:52] tedg: is "ros-jade-ros-core" a good example pkg? I will poke at the code [13:54] mvo: Yeah, that's supposed to be a meta package for all the base stuff. [13:55] mvo: It pulls in a lot though, lots and lots of boost. [13:56] ta [14:06] tedg: aha, fun, I blame sergiusens :P for the issue, python-apt is fine [14:06] mvo, what did I do? :-) [14:07] tedg, sergiusens: so the issue is that python-argparse is a virtual package but the depedency resolver in the ubuntu plugin will not deal with that [14:07] tedg, sergiusens: give me some more minutes to poke at it and maybe there is a easy way out [14:07] mvo, the ubuntu plugin replacement you mn? [14:07] sergiusens: what replacement is that? [14:07] in any case, that is all original code :-) [14:08] sergiusens: Yes, I was adding arbitrary sources lists [14:08] mvo, there is no more ubuntu plugin [14:08] sergiusens: oh, then I blame the original code ;) [14:08] the "class Ubuntu" [14:08] mvo, yeah, that is mine, mine it is not a plugin ;-) [14:08] ok, sorry, in any case, I blame $someone_else_that_is_not_me :P [14:08] * mvo still looks into a fix [14:08] mvo, but the dependency logic is all from the original plugin, I just used fetch_binares instead of dget [14:09] * mvo nods [14:29] tedg: you have a MP [14:30] asac, rickspencer3 ricmm tedg mvo any all or some mind looking at https://code.launchpad.net/~sergiusens/snapcraft/docs/+merge/270830 ? [14:30] Woot! /me looks [14:30] I think I want rickspencer3 to go through it first as he's the outsider :-) [14:31] sergiusens, tedg: the MP uses the python-apt resolver now and it will also skip priority (essential, important). that is a bit arbitrary, but it will prevent libc, passwd from getting pulled in. adjust as needed using whitelist/blacklist for pkgs or whatever if priority is not the best fit for this [14:32] mvo, where is that MP? [14:32] * sergiusens checks his queue [14:32] sergiusens: https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831 <- this one probably not in your queue [14:33] mvo, right, seems so from the target [14:33] :-) [14:40] mvo, commented with open questions :-) [14:41] sergiusens: thanks, excellent point. why single quoes? [14:41] fgimenez: try + {TestID: "test-with-timestamp", Status: "success", Timestamp: time.Now().UTC().Round(time.Microsecond)}, [14:41] (adding the UTC call) [14:42] sergiusens: it seems the python world has not really made up their mind when to use which [14:43] mvo, because elopio said so; that we should use one and single dominated the code bases these days [14:43] :-) [14:45] sergiusens: fair enough, branch updated, thanks [14:49] mvo, looks good, still missing an either or action on manifest.txt (remove or elif to skip too) [14:51] sergiusens: aha, shows my ignorance with the code, yeah, let me look at this [14:52] sergiusens: i would love to look at it after merge [14:52] quick glance looks good, but want to go tipp to tail to feel how complete etc [14:53] sergiusens: i suggest to use example.tld [14:53] not com :) [14:54] j.k. [14:54] .onion is in fashin currently i heard [14:54] *fashion [14:54] hehe [14:55] :-) [14:56] do i have to poke someone to get MPs reviewed for snapcraft, or will someone review it in a timely manner anyway? https://code.launchpad.net/~bjornt/snapcraft/setuptools/+merge/270733 [14:57] BjornT, I did not comment on that one since it had merge issues; I saw you based it out of mine or rebased yours out of that as well; might want to wait a bit for tedg's pip integration [14:57] BjornT, but, to answer your question, tedg or myself ;-) [14:58] sergiusens: I'm actually not quite sure what to do, I would love to just kill manifest.txt and see if that works, it only lists essential/important packages but then I don't know the rational for the list (debootstrap output maybe?) [14:59] sergiusens: ok :) fwiw, the merge issues should be fixed already. [15:00] BjornT, ah, launchpad never notifies about those :-/ [15:01] BjornT, I'll look, but I'll lock on tedg as he is doing some pip work on that same plugin [15:02] sergiusens: thanks! [15:04] fgimenez: so all green on subunit? should I merge? [15:05] elopio, yup, go ahead! [15:05] thanks. [15:21] mvo, did you just add needs fixing to your own branch? [15:22] he's just honest :) [15:22] sergiusens: yes, but tedg has merged it already (without merging it, not sure what he did) [15:23] Ah, yeah. I merged it to my branch. I can do another merge with updates before things get into the main branch. [15:23] I wouldn't want to have double quoted strings or something crazy like that. [15:24] tedg, there is one minor fix wrt to explicitly installing package_names even if they are in essential or important [15:24] which is what the original implementation already had [15:47] ogra_: using xz seems to work on beagle, canonistack and kvm tests. [15:47] do we care about somethinig else? [15:48] yes, Rpi [15:48] but then i guess i need to make sure it is xz there too [15:49] let me flash it and try. [15:50] are you doing the repacking on the snappy system ? [15:50] I would prefer to always use xz, because we would need a tool to unpack and a tool to repack. That becomes scary bash for me. [15:51] but well, you can help me :) [15:51] ogra_: yes, everything happens on local-premount on snappy. [15:51] well, the question is if we will ever provide the test tool to others [15:51] oh wait, not everything. [15:51] the unpack repack is when it's booted, of course. [15:52] if we give the suite to third parties they could use whatever compression they like for their initrd [15:52] for that it would be nice if the tool could cope with it [15:52] if it is only for use we can just make sure it is always xz everywhere [15:52] s/use/us/ [15:53] it would be nice indeed. [15:54] but maybe we don't care here about how it is compressed. Linux takes care of that and we can assume it works well. [15:55] we just want the option to add spy scripts. We could generate with mkinitramfs, and compress with whatever we like. [15:58] no, we couldnt ... [15:58] not withut making bits of the ro fs writable [15:58] (and i also plan to rip all initrd rebuild tools out of the rootfs since we dont support it on snappy anyway) [15:59] I tried that way a couple of days ago, making it writable. But something went wrong, I now don't remember what. [15:59] your unxz and cpio is the best you can do ... [15:59] just keep that [15:59] ogra_: ok, that makes sense. [15:59] (stripping the init tools, I mean) [16:00]