[05:54] what is the correct way to configure the ip address of a snappy ubuntu-core? [05:55] in the same vein is there any special procedure for replacing the ubuntu account with a different admin user? or is it the same process as normal ubuntu? [05:56] not really sure how configs live on with the imaging system [10:16] asac`, ogra_, hey, so the kernel plugin now seems to work; I am just getting "Cannot load shared library libudev.so.1" on boot; I know you were looking into that and I'm working from a cached version, so is it working now? [10:16] sergiusens, yeah, i'm working on that [10:16] getting end to end working would be awesome :-) [10:16] ogra_, kudos to you for being great :-) [10:16] there are bugs in fakechroot that i'm currently trying to hack around [10:16] the pieces are comming together [10:17] ogra_, this affects all arches, right? I'm trying on amd64 due to convenience [10:17] yeah, it does [10:17] I guess I won't be able to try out the procedure on a dragonboard until I get to linaro connect [10:18] on arm64 the linker wasnt copied in at all, sorry, i did care for that first yesterday, should have done it the other way round :) [10:18] heh, no worries you never know what will break next until it breaks [10:19] and getting things out of the way is a good thing ;-) [10:20] ogra_, do you know out of hand if to get a nice kernel build from git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git I can go with kdefconfig on its own? [10:20] I'm afraid debian/rules does a lot of massaging in between, but maybe just to get a deb [10:21] i dont thijk you can ... the config usually lives in the debian ir debian.$arch dir in ubuntu [10:21] s/ir/or/ [10:21] * sergiusens tries [10:22] assembled by scripts (ande checked for required parameters) during build [10:25] ogra_, heh, the assembled by scripts means it is not there initially in a clone/checkout though :-) [10:25] it is there, but in parts [10:26] sergiusens, i though asac had asked the kernel team for their check scripts and included them in the kernel plugin [10:27] after all we need to make sure that the required options are all set (systemd reqs., cgroups, squashfs etc etc) [10:29] ogra_, you mean this http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/config-check ? [10:29] sergiusens, yeah, there is another one though [10:30] ogra_, well we don't have that yet, but nothing says we can't force enable some features (to make it transparent) [10:30] ah, mightr just be an input file [10:30] http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/misc/kernelconfig [10:30] debian.$arch/config/annotations has the required options [10:31] not sure which script exactly consumes it though [10:31] ogra_, that's a generated file though, not here http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian [10:31] (these scriptrs are a maze of perl code ) [10:31] yup [10:41] sergiusens, ok, 0.7.32 should ship with libudev now [10:42] oh, but i havent disabled the resize script yet, that might cause havoc on second boot [10:42] (on the dragonboard only) [11:24] ogra_, heh; so I just need to create an os image now; I hope my bandwidth is good enough [11:25] ogra_, can you remind me mvo's branch for creating those? [11:44] sergiusens, http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files [11:45] sergiusens, but that means you need a fresh tarball too [11:46] (which will take some time, the package is still in -proposed [11:46] ) [11:51] i'll trigger a tarball build once it migrated [11:51] heh, and having said that, it just did [11:52] ogra_, oh, ok; I'll wait for the rootfs build [11:52] triggered [11:52] * sergiusens is still cloning from kernel.ubuntu.com [11:53] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ [11:53] (if you want to watch it) [12:06] ogra_, what else can I do :-P [12:25] ogra_, Receiving objects: 100% (4489986/4489986), 999.75 MiB | 119.00 KiB/s, done. [12:25] all done [12:25] ubuntu kernel [12:25] wow [12:25] a shallow clone [12:25] heh [12:26] ogra_, builders during the weekend are a joy! [12:26] yeah :) [12:29] so now i need to fix the resize script ... and i think we should have a script included in the initrd package that makes injecting modules and firmware an easy task [12:29] (doing all the nasty depmod stuff for you etc) [12:30] ogra_: _that_ would be awesome :) [12:30] ogra_, by mounting /lib/modules? [12:31] ogra_, oh, now I see [12:31] sergiusens, just something like "inject-modules.sh /path/to/initrd.img /path/to/modules/dir" [12:31] it would unpack, push the needed modules in, run depmod and re-pack [12:31] since thats quite fiddly [12:32] ogra_, to replace https://github.com/sergiusens/snapcraft/blob/feature/1552168/kernel-plugin/snapcraft/plugins/kernel.py#L154 [12:32] * ogra_ looks [12:32] ogra_, yeah, basically what is done there, maybe cleaner [12:32] sergiusens, i see it uses modules.dep ... where would that come from ? [12:32] ogra_, so infinity talked about writing a "copy_module" thingie which would take care of copying the correct firmware [12:32] (our kernel packages only run depmod from the postinst) [12:33] ogra_, the kernel build [12:33] ah, i see. it is a source build [12:33] yeah, this is all source [12:33] using the upstream ubuntu kernel deb comes later [12:34] well, that is the bit i need on the builders [12:34] where we use packaged kernels [12:35] hmm, do i see that right that you actually include *all* modules ? [12:35] that will give you quite a bloated initrd in the end ... [12:35] ogra_, no just the modules listed [12:36] after all you only want squashfs and vfat/nls as mandatory modules [12:36] ogra_, it only does a --show-depends for self.options.kernel_initrd_mods [12:36] which is in snapcraft.yaml [12:36] ah, k [12:37] and I guess we can add mandatory modules here as an improvement; unless `show-depends` returns `builtin` [12:37] yeah [12:37] (i still think we shold just enforce squashfs to be builtin on all non distro kernels though) [12:38] that way you wouldnt even need to re-pack the initrd at all :) [12:38] ogra_, heh, I'd say the same for fat [12:38] why create a module for something will always load [12:38] *that will [12:39] sometimes it might not even be possible to build a kernel - but in my configs i include all the modules required for snappy directly in vmlinux - so should be good [12:39] vfat is builtin in your distro kernel [12:39] but the nls modules arent [12:39] ah [12:39] s/your/our/ [12:40] i am currently working on the Pine64 kernel config, i got nls,vfat and squashfs [12:40] yeah, thats good [12:40] don't forget apparmor [12:40] right, and the right cgroups options [12:40] yeah - i did not backport that yet .. its crappy Kernel 3.10 again :) [12:41] fun [12:41] if you are interested - https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/arch/arm64/configs/sun50iw1p1smp_linux_defconfig [12:41] no snappy yet, but i got a fully functional xenial image [12:41] would be interesting to see if it works with the new snapcraft plugin;) [12:42] will try it soon - an probably for odroid c2 as well if not somebody else will have done it when i find the time [12:43] (c2 has Kernel 3.14 which is not much better ..) [12:45] ogra_, longsleep I am still missing dtb integration [12:46] going to work on that during my 12 flight that's just around the corner [12:46] where are you atm ? [12:46] I hope I have everything ready to work offline though :-) [12:46] ogra_, Chile [12:46] oh, not changed the continent yet [12:46] ogra_, bad connections, 12 hour layover here as well [12:46] woah [12:46] ogra_, the flght leaving last night was fully booked [12:46] sergiusens: dtb just needs to be copied to /boot or /media/boot for pine64,c1 and c2 [12:47] so total travel time is 43 hours [12:47] oh my [12:47] woah [12:47] return is only 246 :-) [12:47] woops [12:47] 26 [12:47] ogra_, it's fine, they have beds here; I [12:47] heh [12:47] i hope you can bring a battery to the cabin - last time they took mine away before boarding "too high capacity" .. [12:48] I'm only worried that I will arrive Monday 00:30 so no time to adapt to a new timezone and only 6 hours or less of sleep to get ready for a packed Monday [12:48] longsleep, I got upgraded to business ;-) [12:48] most planes here have plugs for long haul flights in economy though [12:49] right if they work :) [12:49] heh, you have to checkout the awesome planes we have here :-) [12:50] in any case it is 12 hours to Sidney then 8 more to Bangkok [12:50] well in business that should be ok :) [12:50] did you get upgraded for both flights? [12:50] the first 12 are business [12:51] the remaining 8 are something else [12:51] so when you land snapcraft has learned to build a perfectly fine device snap (or whatever it is called)? [12:52] kernel snap [12:52] longsleep, it already seems to be building correctly for amd64 except for that initrd thing ogra just uploaded [12:53] sergiusens: thats good, i will finish up to build a classix xenial image for Pine64 this weekend amd then go snappy next week - i guess that will help a lot [12:53] nothing glamorous about this, but what the heck http://paste.ubuntu.com/15291572/ [12:54] what about building stuff for u-boots which do not support initrd.img or vmlinuz? [12:55] not supported anymore [12:55] i did not look into arm64 booting on snappy yet, but at least the kernel cannot be named vmlinuz can it? [12:55] people need to use the u-boot patches for raw files and need to use the patches for the .env file [12:56] we use the same patches on the dragonboard ... kernel is vmlinuz, initrd is initrd.img [12:56] ok i see - i have some research to do then [12:56] how do you build vmlinuz for arm64? Or is it just Image gzip compressed there? [12:56] its like five lines in the build config to change usually [12:56] mak zImage [12:56] ? [12:57] *make [12:57] i was under the impression that is not supported on arm64 - probably got that wrong [12:57] works fine on the dragonboard ... [12:57] but i guess it is a matter of the u-boot implementation [12:58] (and on what u-boot release you base initially) [12:58] that too, but i thought that there is no self extractor code in the kernel on arm64 [12:59] http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch [12:59] but i can already tell that it will be some work to get devices boot vmlinuz and initrd instead of uImage and uInitrd [13:00] what is the u-boot command you boot with on dragonboard? [13:00] bootz? [13:00] booti i think [13:01] ok thats good, but what i do not get is how booti works with vmlinuz but thats probably something i missed [13:01] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/uboot.env.in [13:01] thats our current dragonboard env [13:02] booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_addr} [13:02] thanks, looks good and pretty compatible to mainline u-boot [13:03] though, i am far away from mainline on the pine64 at the moment :/ [13:03] yeah, thanks to the 96boards guys ... [13:03] i think their stuff is already flowing upstream even [13:04] right now, i need to use boota on pine64 and thus also do not have a vmlinuz nor a initrd.im, its all inside a android wrapped kernel.img [13:04] oh ? [13:04] i want to backport booti to the old u-boot eventually, might even be a requirement to get snappy running [13:04] why dont you make u-boot that kernel.img then ? [13:05] and just use the u-boot features [13:05] thats what i do on the dragonboard [13:05] sure, but regarding snapcraft support that will not work right [13:05] http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files [13:05] thats my basic boot setup (independent from snappy) [13:05] (see the README for details) [13:06] yes, i got a similar thing https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess [13:06] the dragonboard also only supports android style booting by default [13:06] lk -> kernel.img usually [13:07] i just trun it into lk -> u-boot.img [13:07] ok, but their u-boot supports booti already [13:07] by pretending the u-boot.img is a kernel one [13:07] yeah, indeed [13:07] and you have neither booti nor bootz ? [13:08] well bootz will not work with the Kernel i have as it does not have an extractor for gz, i have only the uncompressed image and put that into the android format [13:09] it has bootz, but the bootz code does not have the hack to switch to 64-bit mode [13:09] isnt that just a kconfig thing ? [13:09] yes and no, there is just no aarch64 code for it in the kernel [13:09] bah [13:10] ogra_: thats the u-boot config i currently use btw https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/include/configs/sun50iw1p1.h [13:11] everything should work out somehow, i was planning to backport booti from mainline u-boot including the world hack anyways to get rid of the android boot stuff [13:12] sounds good [13:12] longsleep@mose2:/media/longsleep/Storage/Pine64/build-pine64-image/linux-pine64$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION=-longsleep -j4 zImage [13:12] make: *** No rule to make target 'zImage'. Stop. [13:12] :) [13:12] oh my [13:13] i did not even know that mainline Kernels now have a self extractor for aarch64 [13:13] because i did not look that is :) [13:16] so for now, i would prefer if snappy/snapcraft would not be fixated to require vmlinuz or initrd.img or be fixed to those file names [13:16] could make it much easier for platform adopters [13:17] well, as long as you support uboot.env you should still be free to do what you want after all [13:17] yeah, thats good then [13:17] uboot.env is definitely essential though since snappy modifies it [13:17] i alread added all the stuff for the env file including the redundant thing we figured out ages ago. I hope it did not change :) [13:17] from userspace [13:18] see the dragonboard patch ;) [13:18] didnt change [13:18] (and the option still has the typo upstream ;) ) [13:18] hehe ok great - then i think all is well [13:31] ogra_: btw, do you know the reason why in Xenial the serial getty service starts after rc-local service? Seems wrong and is annoying. [13:32] /lib/systemd/system/serial-getty@.service has After=rc-local.service [13:38] nope, no idea [13:39] but thats a getty ... you actually want all boot scripts to have run before you allow logins [13:39] it's a bit weird to tie it to that specific service though [13:41] * ogra_ goes afk a bit [14:50] ubottu, am I here? [14:50] sergiusens: I am only a bot, please don't think I'm intelligent :) [15:16] ogra_, asac` http://paste.ubuntu.com/15293021/ [15:16] it is alive! [15:16] * sergiusens prepares for boarding [15:18] sergiusens: congrats [15:18] sergiusens: have a safe trip [15:19] zyga, thanks, I just need it working on a dragon board now === Abhishek_ is now known as Abhishek_|afk === devil is now known as Guest66916 === Guest66916 is now known as devil_