| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:44 |
|---|---|---|
| fgimenez | good morning | 07:06 |
| dholbach | can anyone explain this? http://pastebin.ubuntu.com/12261129/ | 07:17 |
| mvo | kickinz1: I pushed your branch for docker, thanks again | 07:17 |
| mvo | dholbach: uh | 07:19 |
| mvo | dholbach: let me try to reproduce | 07:19 |
| fgimenez | dholbach, mvo it seems to be already reported https://bugs.launchpad.net/snappy/+bug/1474658 | 07:23 |
| ubottu | Launchpad bug 1474658 in Snappy "Can't install hello-dbus-fwk & mir: snappy package not found" [Undecided,Confirmed] | 07:23 |
| dholbach | oh ok, thanks fgimenez! | 07:23 |
| kickinz1 | mvo thanks! | 07:31 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mvo, so after your comments about vfat and size issues yesterday i looked up the sizes again ... max file size is 4GB on fat32 ... and max volume size lies between 2TB and 16TB depending on the sector size, i doubt we'd run into any probs with that | 08:46 |
| ogra_ | https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 ... | 08:47 |
| mvo | ogra_: thanks, I was thinking about it last night and I think we need to jump straight to the images, I had hoped we could have a intermediate step to have less churn in the code | 08:55 |
| ogra_ | yeah | 08:56 |
| mvo | ogra_: your and stephans comments make a lot of sense | 08:57 |
| ogra_ | we had similar discussions when we did the phone design :) | 08:57 |
| ogra_ | there was some training here in advance ;) | 08:57 |
| mvo | heh :) | 08:58 |
| mvo | I think we could do it as a intermediate step, but then why bother and go all the way | 08:58 |
| ogra_ | i actually dont think it matters if you use system-boot or writable since both hold a writable system ... writes to system-boot just happen a lot less which makes it a bit safer ... | 08:59 |
| ogra_ | if you want an immediate step, keep everythingn as is, but just ship img files inside the respective snaps | 08:59 |
| ogra_ | instead of whatever it is now (tarballs ?) | 08:59 |
| * mvo nods | 09:00 | |
| mvo | it seems like the work for this is almost the same as going all the way, so I think all the way it is | 09:01 |
| ogra_ | ok | 09:01 |
| ogra_ | that makes us depend on squashfs though ... which means we need a solution for the module in case we want a generic initrd | 09:02 |
| mvo | indeed | 09:02 |
| ogra_ | a modules.img formatted as ext2 would work, or we compile squashfs into the kernel or we postpone generic initrds | 09:03 |
| ogra_ | (sadly modules.img would benefit most from squashfs :P ) | 09:03 |
| mvo | hm, I guess we need to talk to the kernel guys how horrible squashfs into the kernel is | 09:03 |
| ogra_ | well, if it even works :) | 09:04 |
| mvo | I still don't full understand the benefit from the generic initrd (but thats just my ignorance) so I can't comment how horrible postponing that would be | 09:04 |
| ogra_ | easy porting, less maintenance | 09:05 |
| ogra_ | you dont have a way to just tell the kernel build tools to generate an initrd for you during kernel build ... | 09:05 |
| ogra_ | so you need to create a chroot of the target arch, install all bits in there and run update-initramfs ... or you garb a binar initrd from one of the device tarballs and modify (and potentially break) it | 09:06 |
| ogra_ | sigh, my typing sucks | 09:07 |
| mvo | I wonder if we could improve the tooling that generates the kernel snap from the kernel binary we get | 09:07 |
| mvo | this is what I do right now (add some stuff to the initrd) | 09:07 |
| mvo | we could also generate it there and have some fancy config that contols what goes in/out | 09:07 |
| mvo | but yeah, the tooling we have right now is not great | 09:08 |
| ogra_ | right, we could just provide tooling ... but it is still a debootstrap, chroot etc if you build it from scratch ... | 09:08 |
| ogra_ | quite some effort ... | 09:08 |
| ogra_ | and automated modifying would mean quite some scriptery | 09:09 |
| ogra_ | in case you want to use a "template" initrd | 09:09 |
| ogra_ | we need to somehow make sure all arches and ports are on the same page wrt scripts and binaries in the initrd ... if i use a 15.04/foo image it needs to be the same initrd in use on my bananapi as there is in the azure cloud | 09:12 |
| ogra_ | else debugging will become painful | 09:13 |
| * mvo nods | 09:16 | |
| asac | read in some email that we have snappy service now in trunk? whats the syntax/semantic of that? | 09:16 |
| ogra_ | asac, snappy service start|stop|status | 09:17 |
| asac | ogra_: ok... log would be nice too i guess :) | 09:17 |
| asac | ogra_: no restart? | 09:17 |
| ogra_ | Chipaca, ^^^ ? | 09:17 |
| ogra_ | i guess also restart | 09:18 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ snappy service help | 09:18 |
| ogra_ | Unknown command `help'. Please specify one command of: disable, enable, restart, start, status or stop | 09:18 |
| ogra_ | ;) | 09:18 |
| asac | ogra_: how do i list the services available that i can put as argument? | 09:19 |
| ogra_ | good question | 09:19 |
| asac | :) | 09:19 |
| ogra_ | i think its the name of the snap ... | 09:20 |
| * ogra_ tries | 09:20 | |
| asac | ogra_: you can have multiple services per snap | 09:20 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ snappy service status webdm | 09:20 |
| asac | so cant be just that | 09:20 |
| ogra_ | SnapServiceState | 09:20 |
| ogra_ | webdmsnappydenabled; loaded; active (running) | 09:20 |
| ogra_ | (had to install webdm first) | 09:20 |
| asac | ok maybe that applies for all services in a snap? | 09:21 |
| ogra_ | so whatever snappy list gives you i guess | 09:21 |
| asac | the service is snappyd here :) | 09:21 |
| asac | not webdm | 09:21 |
| asac | at least the column titles suggest such | 09:21 |
| ogra_ | oh,. right | 09:22 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo snappy service disable webdm snappyd | 09:23 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ snappy service status webdm | 09:23 |
| ogra_ | SnapServiceState | 09:23 |
| ogra_ | webdmsnappyddisabled; loaded; active (running) | 09:23 |
| asac | ic so mnaybe also status webdm snappyd | 09:23 |
| ogra_ | yeah, but for webdm that prints just the same | 09:24 |
| ogra_ | no idea if it actually filters or just gets ignored | 09:24 |
| asac | looking at code it seems to get filtered | 09:25 |
| ogra_ | cool | 09:25 |
| asac | so just webdm stop should stop all | 09:25 |
| ogra_ | well, in any case it works | 09:25 |
| asac | whch is also neat | 09:25 |
| asac | just need log imo | 09:25 |
| ogra_ | and is pretty intuitive given i have used it for the first time 5min ago ;) | 09:25 |
| asac | then no need to fiddle with systemd cli anymore | 09:25 |
| asac | hehe | 09:25 |
| mvo | yes, that was the reason for it | 09:26 |
| Chipaca | pindonga: morning sir. I just came accross a log entry that has no _SOURCE_REALTIME_TIMESTAMP. Please advise... | 09:27 |
| Chipaca | um | 09:28 |
| Chipaca | pindonga: not you :) | 09:28 |
| Chipaca | pitti: you ^^ | 09:28 |
| Chipaca | pitti: http://pastebin.ubuntu.com/12261699/ | 09:28 |
| pitti | Chipaca: the manpage describes it as optional | 09:31 |
| pitti | i. e. only if it's different from __REALTIME_TIMESTAMP | 09:31 |
| Chipaca | ah, gotcha | 09:32 |
| Chipaca | ta | 09:32 |
| === chihchun_afk is now known as chihchun | ||
| pitti | Chipaca: (or the source isn't trusted) | 09:36 |
| sja_ | Hey Guys! (Hopefully) quick question: I need pppd to establish a ppp connection from a snap. Should I include the binary from ubuntu repos in my snap? | 09:37 |
| Chipaca | sja_: yes | 09:39 |
| ogra_ | sja_, we dont care ;) ... | 09:39 |
| Chipaca | ah, better answer | 09:39 |
| ogra_ | sja_, you could also build your own binary :) | 09:39 |
| Chipaca | sja_: the one from ubuntu might be hardwired to look for things in /etc/ | 09:39 |
| Chipaca | i don't know | 09:39 |
| ogra_ | (it is often more convenient to use it from the archive indeed ) | 09:39 |
| sja_ | :-) So it's to me to keep it up ti date | 09:40 |
| ogra_ | yeah | 09:40 |
| ogra_ | you got all the freedom to use whatever suits your needs :) | 09:40 |
| sja_ | ok. Well, pppd should not be updated so often. It's not the hot new technology. ;-) | 09:40 |
| ogra_ | effectively the snap only uses binaries ... how you produced them is up to you | 09:40 |
| ogra_ | in case of pppd Chipaca is right, it might expect files in locations you cant control ... | 09:41 |
| ogra_ | so you might need to invoke it with cmdline options that override this | 09:41 |
| ogra_ | (if it supports that) | 09:42 |
| sja_ | yes. Hopfully if all params given, it'll not look for files in /etc, but I#ll see it in the logs. | 09:42 |
| ogra_ | yeah | 09:42 |
| sja_ | thanks. | 09:42 |
| sja_ | @asac greetings from openHAB team, I'll start a new try to make an openHAB-Snap the next weeks. | 09:43 |
| nothal | sja_: No such command! | 09:43 |
| asac | sja_: oh awesome! | 09:48 |
| asac | :) | 09:48 |
| asac | welcome | 09:48 |
| asac | on above, i think ricmm was talking about including pppd in core... not sure if that happened or we decided against it | 09:50 |
| ogra_ | uh | 09:50 |
| asac | ricmm: what did we end up doing? | 09:50 |
| === kickinz1 is now known as kickinz1|lunch | ||
| sja_ | Ok, my setup is, that I have an USB stick with a specific usb id (great for udev) which is then available on /dev/ttyUSBX. To talk to the stick, I connect via pppd to that tty and have a new network interface ppp0. For that I have to set a route like ´ip -6 route add fc00::/10 dev ppp0` | 09:53 |
| sja_ | So, I'm fine with an own pppd binary in my snap, but I worry about the route now. | 09:55 |
| sja_ | And I need IPv6 | 09:55 |
| === guest42315 is now known as pixelr0 | ||
| ricmm | asac: my suggestion was to include pppd in core, as well as wdt | 10:19 |
| ricmm | commonly used low level services like that, however the discussion stalled at some point | 10:20 |
| ogra_ | ricmm, where do you draw the line then ? you'd also want pppoed and whatnot | 10:21 |
| * ogra_ guesses it sums up | 10:22 | |
| sja_ | I see that there is a problem on keeping the core clean and simple. Wouldn't it be better to give the community good guide on how to include those kind of binaries off the default ubuntu repos? Together with cross compiling for armhf. | 10:24 |
| sja_ | Maybe that would be enought for most of the snap authors. | 10:24 |
| ogra_ | sigh | 10:36 |
| ogra_ | seems there were some serious user changes in some package in wily ... all images that do a passwd check during build failed | 10:37 |
| ogra_ | hmm, could be rsyslog | 10:40 |
| mvip | Looks like there are still some `apt` leftovers in Snappy. For instance, /etc/cron.daily/apt | 10:47 |
| ogra_ | mvip, can you file a bug for that ? | 10:49 |
| mvip | ogra_ sure. What's the bugtrack URL? | 10:52 |
| ogra_ | see the channel topic :) | 10:52 |
| mvip | ogra_: my bad :) | 10:53 |
| === pixelr0 is now known as guest42315 | ||
| mvip | ogra_: https://bugs.launchpad.net/snappy/+bug/1491781 | 10:59 |
| ubottu | Launchpad bug 1491781 in Snappy "apt leftovers in Snappy (cron)" [Undecided,New] | 10:59 |
| ogra_ | thanks ! | 10:59 |
| mvip | np | 11:00 |
| ogra_ | oh my ... rsyslog jumped from 7.4.4 to 8.12 with the last upload ... | 11:01 |
| ogra_ | changing *everything* | 11:02 |
| ogra_ | (1.4MB diff :/ ) | 11:02 |
| === joc_ is now known as joc|lunch | ||
| sja_ | One more: What about ntp? I think this should be part of core, think about ssl handshakes and so on. | 11:16 |
| ogra_ | sja_, there are plans for systemd-timesyncd | 11:19 |
| ogra_ | not sure where we stand with that though | 11:19 |
| sja_ | ogra_ ok, thanks | 11:20 |
| === chihchun is now known as chihchun_afk | ||
| rickspencer3 | what should I do if I want to put snappy on my bbb with developer mode, and ssh enabled, and I want to be getting daily updates? | 12:09 |
| rickspencer3 | i.e. is there such an image, do I have to use udf to make one? | 12:09 |
| ogra_ | rickspencer3, snappy update should still work | 12:12 |
| ogra_ | i think we only disable the autopilot | 12:12 |
| ogra_ | (which you can enable via snappy config for the ubuntu-core package | 12:13 |
| ogra_ | ) | 12:13 |
| rickspencer3 | ogra_, so, which image should I download, and will ssh and developer mode be set up automatically? | 12:14 |
| ogra_ | i think our prepared images all have developer mode enabled (i could be wrong though) | 12:15 |
| rickspencer3 | ok, I'll try it out | 12:15 |
| ogra_ | mvo, i see pending changes from you in livecd-rootfs, is it ok to upload that (i need a change to fix the image build failures) | 12:22 |
| mvo | ogra_: yeah, go for it | 12:22 |
| ogra_ | great, thanks | 12:23 |
| ogra_ | systemd dropped a group ... all images fail :/ | 12:23 |
| ogra_ | and the number of images using the check obviously grew ... | 12:23 |
| ogra_ | i guess we need to find a better mechanism if that grows even more ... this will eat my whole afternoon | 12:24 |
| Chipaca | why do we even ship cron & at? | 12:36 |
| mvo | a good question we probably should not | 12:38 |
| beuno | so you can run cron every hour? | 12:42 |
| Chipaca | beuno: man systemd.timer | 12:43 |
| Mikaela | I prefer to use cron, because it's easier and doesn't require writing two systemd units. cron also runs even when loginctl isn't running for normal users. | 12:52 |
| ogra_ | mvo, that rm -f dance at the end of 500-move-kernel-to-device-tar.binary starts getting hilarious ... | 12:54 |
| mvo | ogra_: :-/ | 12:55 |
| ogra_ | i wonder if we couldnt cover half of it with purging the kernel package and linux-firmware | 12:55 |
| ogra_ | so only removing the initrd would be left | 12:55 |
| Chipaca | Mikaela: but you don't get to write either in snappy world | 12:57 |
| Mikaela | I don't understand | 12:58 |
| Chipaca | Mikaela: yes | 12:58 |
| Chipaca | Mikaela: you say you prefer to use cron | 12:58 |
| Chipaca | Mikaela: but you can't | 12:58 |
| Chipaca | Mikaela: that is, a snap can't add a crontab entry | 12:59 |
| Mikaela | what happened to "crontab -e"? | 12:59 |
| ogra_ | not oable by a snap unless the snap ships cron inside (and has that pointing to SNAP_APP_DATA_DIR for the crontab) | 12:59 |
| ogra_ | *doable | 12:59 |
| ogra_ | indeed you could do crontab -e via ssh as user/admin (if we made the crontab cache dir writable) ... buut a snap cant | 13:00 |
| ogra_ | -u | 13:00 |
| Mikaela | exaxmple, I have dynamic DNS update script. On normal devices I use https://github.com/Mikaela/scripts/blob/gh-pages/bash/ydns-simple#L12 on my phone I have to use the ydns-simple.* from https://github.com/Mikaela/shell-things/tree/master/etc/systemd/system/sailfish | 13:00 |
| Mikaela | I wasn't thinking about packages, but user putting their task to crontab | 13:01 |
| Mikaela | at I have never used though | 13:02 |
| Chipaca | Mikaela: but how would the user have ydns? | 13:02 |
| Mikaela | by curling it as from what I understood it's still possible to run scripts and compile outside of snaps | 13:03 |
| Chipaca | Mikaela: you don't have curl, you don't have dig | 13:03 |
| Chipaca | Mikaela: you don't have wget | 13:04 |
| Mikaela | copy-paste to vi? | 13:04 |
| ogra_ | you would do it via the ydns.mikaela snap :) which shipd a script "set-ydns-timer" and sets the timers inside the snap env | 13:04 |
| ogra_ | *ships | 13:04 |
| ogra_ | (and inside your snap you can have curl,wget,dig ... | 13:05 |
| ogra_ | ) | 13:05 |
| Mikaela | and the script would have to be edited to take the user details from external file | 13:05 |
| Chipaca | Mikaela: my point was that your "ydns-simple" script tries to use tools that are not present on a snappy core system | 13:05 |
| Mikaela | I see | 13:05 |
| Chipaca | Mikaela: cron is the least of your troubles | 13:05 |
| ogra_ | right, you can only do it inside a snap | 13:05 |
| Chipaca | Mikaela: a snappy core system is (or tries to be) *very* stripped down | 13:06 |
| ogra_ | might even get rid of bash at some point | 13:06 |
| Chipaca | yep | 13:06 |
| Chipaca | but not openssl, hopefully :) | 13:06 |
| Mikaela | the very doesn't seem to be enough emphatized | 13:07 |
| Chipaca | and ydns-simple doesn't set -e, so it'll be fun | 13:07 |
| ogra_ | snappy core = systemd, the snappy binary, HW enablement and all the glue needed to make these three work | 13:08 |
| ogra_ | everything else is a snap on top of this | 13:08 |
| Chipaca | exactly. Everything not in that list is either exceptional (openssl), POSIXish (grep), or we-haven't-gotten-around-to-nuking-it | 13:09 |
| Chipaca | python3, for example | 13:09 |
| Chipaca | perl, i hope | 13:09 |
| Chipaca | awk, maybe | 13:09 |
| Mikaela | how about openssh-server? | 13:09 |
| Chipaca | what about it? | 13:10 |
| ogra_ | thats indeed part of developer mode ... | 13:10 |
| Mikaela | so it hasn't disappeared anywhere | 13:10 |
| Chipaca | Mikaela: but it's not there (or at least, not running) without --developer-mode | 13:14 |
| Mikaela | I see | 13:14 |
| ogra_ | new wily image building | 13:16 |
| * ogra_ hopes the changes were enough to make it build now | 13:16 | |
| Mikaela | rolling/edge again seems to timeout with "vagrant up" | 13:29 |
| Chipaca | Mikaela: where? | 13:37 |
| Mikaela | % vagrant init http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/core-edge-amd64-vagrant.box && vagrant up | 13:38 |
| Chipaca | Mikaela: do you get any logs? | 13:41 |
| Mikaela | moment | 13:42 |
| Mikaela | http://paste.ubuntu.com/12263034/ | 13:43 |
| Mikaela | the stable works | 13:43 |
| Chipaca | ogra_: is that a you thing ^? | 13:44 |
| elopio | ogra_: or somebody, how can I pass the debug boot option to the kernel with kvm ? | 14:24 |
| mvo | elopio: do you have kvm in front of you are you mean in the lap? | 14:25 |
| mvo | elopio: if its a one off thing you can go into the grub menu and append "systemd.log_level=debug" (or "debug" if you want the kernel debug) | 14:26 |
| elopio | mvo: so, I can unpack the img and edit the grub conf, right? | 14:28 |
| mvo | elopio: yes, that works too | 14:28 |
| mvo | elopio: whats the use-case? I wonder if we should provide something easier, we have no esasy way right now to extend the grub cmdline | 14:29 |
| elopio | mvo: how do I enter grub manually, to give it a try first? | 14:29 |
| mvo | elopio: kvm -m 1500 snappy.img should show you a grub boot menu for 3s, there you can do the usualy "hit e for edit" dance | 14:29 |
| elopio | mvo: just playing with the options of initramfs. With debug, it says it will write a file with all the shell calls it makes. | 14:29 |
| mvo | elopio: aha, I see | 14:30 |
| === joc|lunch is now known as joc_ | ||
| ogra_ | Chipaca, no idea, looks like --enable-ssh or --developer-mode was missing when the image was created ... i never used any cloud stuff | 14:35 |
| ogra_ | sigh, seems livecd-rootfs wasnt in the wily archive when i started the image build | 14:37 |
| * ogra_ tries again, it should have migrated now | 14:37 | |
| Chipaca | rsalveti: who builds the cloud stuff, ie http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/ ? | 14:39 |
| Chipaca | rsalveti: seems something is broken :) | 14:39 |
| rsalveti | utlemming: ^ | 14:40 |
| ogra_ | \o/ | 14:46 |
| ogra_ | finally ! | 14:46 |
| ogra_ | images are building again | 14:46 |
| elopio | ogra_, mvo: I can go set the debug option in image #141. For some reason, in #159 it doesn't work. | 15:29 |
| ogra_ | how do you set it ? | 15:30 |
| ogra_ | just adding "debug" on the cmdline in grub.cfg ? | 15:30 |
| elopio | ogra_: I go to grub and add debug to the linux line. | 15:30 |
| ogra_ | ah, interactively | 15:30 |
| elopio | ogra_: yes. | 15:30 |
| mvo | elopio: you don't get debug and it works otherwise? or it fails in a bigger way? | 15:31 |
| elopio | mvo: I don't get the /dev/.initramfs/initramfs.debug file. | 15:31 |
| elopio | but I think I see the boot printing a lot more info, let me confirm that. | 15:31 |
| ogra_ | hmm | 15:32 |
| ogra_ | elopio, are you sure it is /dev not /run/initramfs/ ? | 15:32 |
| ogra_ | should be the latter | 15:32 |
| elopio | ah, so in 141 it's in /dev and in 159 is in /run | 15:33 |
| ogra_ | init:exec >/run/initramfs/initramfs.debug 2>&1 | 15:36 |
| ogra_ | thats what grep gets me in initramfs-tools | 15:36 |
| elopio | ok, this doesn't work for us anyway because it only prints Running /scripts/init-premount. It doesn't print what the premount does. | 15:36 |
| ogra_ | well, there is only one script in premount (the resize) and that writes its own log in /run/initramfs | 15:37 |
| elopio | ogra_: I only see another file in /run/initramfs, fsck-writable. How do I get that resize log? | 15:38 |
| ogra_ | it gets only written if it resizes | 15:38 |
| ogra_ | else the script is a no-op | 15:38 |
| ogra_ | you need to have the writable partition leave 10% free space, else it wont kick off | 15:39 |
| elopio | good, let me check on the cloud. | 15:39 |
| ogra_ | free= unpatitioned | 15:39 |
| elopio | ogra_: I found something like this to check the free %: sudo parted /dev/mmcblk0 unit % print free | grep 'Free Space' | tail -n1 | awk '{print $3}' | 15:40 |
| ogra_ | i usually just dd 1GB to the end of the kvm image ... | 15:40 |
| elopio | but I'm wondering, how can I know the right /dev name for the disk I want? | 15:40 |
| ogra_ | findfs LABEL=writable | 15:41 |
| elopio | ogra_: but that gives me the partition. I need to strip the partition number, which sometimes is #, sometimes is p#. | 15:42 |
| ogra_ | also if you want to look at the code ... boot the VM ... look at /usr/share/initramfs-tools/scripts/local-premount/resize | 15:42 |
| elopio | I wanted a magic command that tells me the disk where a partition is. | 15:42 |
| ogra_ | there is no magic command sadly ... there is some magic parsing sysfs | 15:42 |
| ogra_ | line 25-27 | 15:43 |
| ogra_ | in the above script | 15:43 |
| elopio | ok, let me play with that. | 15:45 |
| elopio | too much shell for me today :) | 15:45 |
| ogra_ | err, i was looking at the wrong versioon ... might not be 25-27 | 15:46 |
| ogra_ | ah, 26-28 in the actual code :) | 15:46 |
| ogra_ | writable_part="$(findfs LABEL=writable)" | 15:47 |
| ogra_ | syspath="$(dirname $(realpath /sys/class/block/$(basename $writable_part)))" | 15:47 |
| ogra_ | device="$(realpath /dev/block/$(cat $syspath/dev))" | 15:47 |
| ogra_ | partition=$(cat $syspath/$(basename $writable_part)/partition) | 15:47 |
| elopio | ogra_: I'm looking at the source branch, but yes, I found it. | 15:47 |
| ogra_ | yeah, i was looking at a local copy ... | 15:47 |
| elopio | ogra_: what happens if I don't want my partition to be resized? Like I flash my sd card with snappy, and I'm leaving the last part of the card for something else. | 15:50 |
| ogra_ | elopio, you cant prevent it currently | 15:50 |
| Chipaca | mvo: i can haz review of https://code.launchpad.net/~chipaca/snappy/logs/+merge/270048 ? | 15:54 |
| ogra_ | elopio, the code is also still far from ideal ... instead of re-writing the GPT from scratch parted should just fix it and resize ... that will all need more love later | 15:56 |
| mvo | Chipaca: sure thing | 15:56 |
| elopio | ogra_: I'm finding initramfs really cool, and your hack to do the resize is nice too. And well, it seems to work. | 16:00 |
| ogra_ | well, until you lose power in the middle of rewriting the GPT :) | 16:00 |
| ogra_ | then you completely lost | 16:00 |
| ogra_ | for doing it proper we'll need bug 1490608 fixed at some point | 16:01 |
| ubottu | bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608 | 16:01 |
| elopio | um, that sounds ugly. | 16:01 |
| ogra_ | so it takes a nanosecond instead of two seconds ... | 16:01 |
| ogra_ | keeping the potential breakage window smaller and being less intrusive | 16:02 |
| ogra_ | effectively it should be just an option i can give when calling "parted resizepart" so that GPT doesnt need its own finction | 16:03 |
| ogra_ | *function | 16:03 |
| ogra_ | its a compromise :) | 16:03 |
| ogra_ | until we can have the real thing | 16:03 |
| elopio | ogra_: and can you fix the gpt if you find it corrupted on boot? | 16:04 |
| ogra_ | elopio, parted can ... it just cant do it from a script | 16:04 |
| ogra_ | GPT stores a backup of the table at the end of the disk usually | 16:04 |
| ogra_ | if you now write the image to a bigger disk that backup doesnt align | 16:05 |
| ogra_ | its a simple copy to the right place ... | 16:05 |
| elopio | I get it. | 16:05 |
| ogra_ | but since it cant do it scripted currently i had to competely re-write the GPT for now | 16:05 |
| ogra_ | this is not to stay :) | 16:05 |
| ogra_ | (it is a nice hack ... but has potential for breakage in it if it dies during re-writing) | 16:06 |
| ogra_ | (though the timing of the dieing needs to be prefect to actually break it ... the window is very small ... like 1sec or even less) | 16:07 |
| elopio | ogra_: so tell me if this makes sense: | 16:10 |
| elopio | 1. add a test to the current snappy integration suite to check with parted that the free space at the end is less than 10%. | 16:10 |
| elopio | 2. Make an image with less than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that nothing was resized. | 16:10 |
| elopio | 3. Make an image with gpt and more than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that the free space at the end is less than 10%. | 16:10 |
| elopio | 4. Make an image with mbr and more than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that the free space at the end is less than 10%. | 16:10 |
| ogra_ | elopio, for 2: | 16:13 |
| ogra_ | dd oflag=append conv=notrunc if=/dev/zero of=kvm-rolling.img bs=1MB count=1000 | 16:13 |
| ogra_ | thats what i use for testing | 16:13 |
| ogra_ | appends 1GB | 16:13 |
| ogra_ | i'm not sure hwo you want to achieve 4 ... that would need hackery inside ubuntu-device-flash | 16:14 |
| ogra_ | since the partition table type is hardcoded per arch (x86 = GPT ... arm = mbr) | 16:16 |
| elopio | I had no idea how to achieve 2-4. That was the next step after defining the tests :) | 16:16 |
| ogra_ | the list looks fine ... but 4 will likely mean to test on armhf | 16:16 |
| elopio | ogra_: do we need a snappy image for 2-4? Can't we just prepare a disk, throw it to kvm and check the prints during initramfs? | 16:17 |
| elopio | we don't need to check that it actually boots. Just that the premount worked. | 16:17 |
| ogra_ | hmm, you need a partition labeled "writable" beyond that it should just work, yeah | 16:20 |
| elopio | well, it would be a lot nicer if we could run parted to do the check, not just check the prints. | 16:20 |
| elopio | maybe, we can use break=boot, and do the check there. | 16:20 |
| ogra_ | sure, you can just run parted after the resize has run | 16:21 |
| elopio | ogra_: as you can see, I'm just throwing everything I read last night. Please tell me if I'm giving stupid options here. | 16:21 |
| ogra_ | you could do that from a local-bottom script even ... | 16:21 |
| ogra_ | no stupid options here :) | 16:22 |
| elopio | I have no idea what a local-bottom script is. | 16:22 |
| ogra_ | the same thing as a local-premount script just run later :) | 16:22 |
| elopio | ah, right. | 16:22 |
| ogra_ | initramfs starts /init (the script) ... that processes all the subdirs under scripts/ at certain points | 16:23 |
| ogra_ | so if you want to verify something you could just create a local-bottom subdir and dump your check script in | 16:23 |
| elopio | ogra_: ahhh, that's smart. | 16:23 |
| elopio | I like that. | 16:24 |
| ogra_ | initramfs-tools is super flexible :) | 16:24 |
| elopio | ogra_: ok, so what I'm missing here is how to create the disk for the .img to use with kvm. Any pointers for that? | 16:25 |
| ogra_ | well, all you need is a writable partition i think | 16:25 |
| ogra_ | depends if you actually want to boot or if just dumping the info about the resize is enough | 16:26 |
| ogra_ | else you'd also need system-a at least | 16:26 |
| elopio | I think i'd prefer to avoid booting. | 16:27 |
| elopio | on this bottom script, exit with != 0 if the free space is more than 10%. I can do that by just copying things from your resize script. | 16:27 |
| elopio | I'm not sure how to signal sucess. | 16:28 |
| elopio | I'll just start. ogra_: I'll make cards for the four tests pasting our discussion in there. Feel free to add suggestions there. | 16:30 |
| ogra_ | cool, thanks | 16:35 |
| tedg | Okay, this isn't going to work. I think that pip is going to have to be its own plugin. Refactor after lunch. | 17:27 |
| === greyback_ is now known as greyback|eod | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!