[00:08] um, scratch that. [00:08] downloaded again and now it works. [00:08] unping. [01:04] jdstrand, when you have a sec, I had to upload a new version of emonhub-pi, the review tools did not get an update yet [02:34] Saviq: accepted === chihchun_afk is now known as chihchun === wolfeidau_ is now known as wolfeidau [06:44] good morning [07:01] good morning [07:12] Saviq, heh, yeah, thats a fake key (--developer-mode needs it) ... next image i'll edit my name out :) [07:22] Saviq, for installing packages ubuntu-device-flash has the --install option ;) [07:23] (that's how webdm gets into my image) [07:51] ogra_, yup, learned that, too, but oem/software works after all [07:52] is there (will there be) a way to hw-assign from an OEM snap? or a gadget snap? [07:54] heh and why does unity-settings-daemon die when building an image :D [07:54] you mean to ship a config with an app snap that enables certain hw access by default ? [07:54] ogra_, not sure if an app snap, but maybe an oem/gadget snap? [07:55] ogra_, but well, sure, app would work, too [07:55] i think you wont be able to upload that to the store, but for sideloading there should be an ability [07:55] an oem or gadget snap has full HW access [07:55] and access to hwe from a framework or app snap needs to be defined for that snap [07:56] *hw [07:58] ogra_, didn't find anything re: hw-assign in https://developer.ubuntu.com/en/snappy/guides/oem/ - that's where I'd expect to put it? under /oem/hardware [07:59] what exactly would you do with it ? [07:59] ogra_, I want for an app to have access to /dev/ttyAMA0 straight after flashing [08:00] right, so that app snap needs to define it, not the oem snap [08:00] but it won't be accepted to the store? [08:00] it wouldnt be accepted with a default that silently enables access to the device [08:01] the requirement is that the admin runs the hw-assign command for the snap to switch on the access [08:01] after installing it [08:01] hmm so how do we plan to support these kind of usecases, say, a managed switch app [08:01] if you want to sell a managed switch, you can't leave the hw-assign to the end user [08:02] well, for you as developer there will be a way to sideload [08:02] sure, I'm thinking end-user [08:02] [...] or expect for the factory line to boot and run hw-assign on every unit? [08:02] if you sell a managed switch with a branded and preinstalled image you will likely also have your own store namespace [08:02] in which you will be able to put such a snap [08:03] hmm [08:03] (for details better ask the store people :) ) [08:49] ppisati, hi, do you know of a way to disable serial in u-boot for the raspi2? I tried changing std{in,out,err}, but that didn't help, only thing that worked was to set bootdelay to 0 so that it ignores any input (I've an expansion board that talks on ttyAMA0 and interrupts the boot process) [08:51] I thought changing std... should work, but u-boot still reads from the serial port and interrupts auto-boot because the board sends stuff through [08:51] Saviq: disabling uboot from reading the serial... [08:52] Saviq: no idea [08:52] Saviq: you probably need to build your own uboot [08:54] well, on the Rpi a lot of the initialization is done via the binary blob ... [08:54] so even building your own uboot might not help [08:56] right, i forgot about thir binary blob [08:57] ogra_: deos it emit anything on the console? i don't remember... [08:57] uhm [08:57] i dont think it does [08:57] but i think it initializes it [08:58] there might be a way to manage that via config.txt [08:59] well, bootdelay=0 it is :P [08:59] it's not like the usb keyboard works anyway ;P [08:59] bootdelay=0 in config.txt ? [09:00] as a uboot param it only disables the ability to stop the autoboot [09:00] wouldnt change anything in console usage [09:24] ogra_, no, setenv [09:25] ogra_, and my problem is exactly that - autoboot is stopped because serial is talking [09:27] but udev always talks to serial ... it just doesnt wait for input when autoboot is off [09:27] err [09:27] "autoboot interception" [09:31] Saviq: i don't see any option to disable the serial output [09:31] Saviq: you can try to change the baud/serial clock [09:31] Saviq: and hope that it doesn't interfer [09:31] albeit it's a crappy solution. i know :) [09:33] * ogra_ just notes what he wrote above :P [09:33] s/udev/uboot/ [09:50] ogra_, sure, and that's exactly it - I just need it to boot, and it doesn't if I leave it - because the board I have is talking on serial on boot, so interrupts u-boot [09:51] ppisati, it's not about output, input rather [09:51] Saviq: same logic applies [09:51] Saviq, well, thats a matter of luck then [09:51] Saviq: since you don't have any option to not init the serial, wreak it [09:51] Saviq: or better [09:51] Saviq: write an email to the raspy2/broadcom people [09:52] Saviq: and ask for that feature [09:52] Saviq: btw, how did you make it work with the original broadcom img? [09:52] ogra_, sure, I'm not saying bootdelay is the right solution [09:52] ppisati, it Just Works with https://wiki.ubuntu.com/ARM/RaspberryPi and Raspbian [09:52] ppisati, afaict the bootloader there (not u-boot) isn't talking on serial by default? [09:53] Saviq: then patch our uboot [09:53] Saviq: and rip out the serial input part [09:54] ppisati, yeah, need to dig into u-boot for that, there's no obvious configs for that, the only relevant thing I found was SILENT... but that won't help with input I don't think [09:55] I was really expecting setenv stdin "usbkbd" to work [09:55] because it was serial,usbkbd by default [09:55] but that didn't change anything [09:56] so yeah, still looking for the right solution, am ok with the interim one though [10:18] Hi all [10:18] Is there any GUI for snappy? [10:19] Rlyeh, https://developer.ubuntu.com/en/snappy/guides/webdm/? [10:19] only web currently [10:19] I'm using it now [10:19] Thank you [10:36] bah, I don't understand [10:37] upgrading that snappy install, mounting /boot/efi fails [10:37] "FAT-fs (vda2): IO charset iso8859-1 not found" [10:37] but the same partition mounts fine booting the old / on system-b === greyback__ is now known as greyback [10:40] shouldnt it be mounted all the time ? [10:43] ogra_, I don't think so, it's in fstab [10:43] the mount target fails and sends systemd in debug mode [10:48] sounds like a module mistmatch or so [10:48] can you check lsmod between the two boots ? [10:55] ogra_, yeah, on the failed boot lsmod lists only psmouse and pata_acpi [10:56] do you see modules in /lib/modules/* ? [10:56] hum [10:57] only a /lib/modiles/4.0.0-4-generic [10:57] and nothin underneat ? [10:57] but the kernel in use is 3.19.0-22 [10:57] ah [10:57] yes, they are there [10:57] but modproble looks for a 3.19 [10:57] right [10:57] wth [10:58] /boot has 4.0 [10:58] sounds like an issue with the grub stuff again ? [10:58] where is the booted 3.19 kernel coming from? [10:58] I guess [10:58] Chipaca, ^^^ ? [10:58] mvo_, sergiusens, Chipaca, ^ [10:59] i wonder if we hardcode 3.* soemwhere for the version :P [10:59] could be... [11:01] whasup? [11:01] seb128: is this on personal? [11:02] yes [11:03] Chipaca, I installed personal 28 yesterday [11:03] and upgraded to 30 with "snappy update" [11:03] the new version fails to boot, it load a kernel 3.19 but the /boot version is 4.0 [11:03] which makes it fail to load modules [11:06] seb128: what gadget snap does personal use? [11:06] no idea, how do I tell? [11:06] amd64_generic iirc [11:06] if that's one [11:10] seb128: rolling , yes? [11:10] yes [11:10] Chipaca, http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/ [11:11] Chipaca, looks like $prefix/a and /b both have the 3.19 kernel [11:11] where today's image /boot has 4.0 [11:11] why does /boot have a kernel, and why are you booting that instead if $prefix/a or /b? [11:12] so unsure what is supposed to update the boot kernels but that went wrong [11:12] Chipaca, well, it's booting $prefix/a /b [11:12] which is what creates the issue [11:12] sounds to me like personal is broken [11:12] the system-b partition has /lib/modules/4.0 [11:12] which is the current wily kernel [11:13] $prefix/b should have a 4.0 kernel [11:13] that matches the installed os [11:13] Chipaca, could be, but the issue is that the $prefix/b kernel is the old one and not matching the current image kernel [11:13] new image work fine [11:14] it's just a snappy updated one that has that issue [11:14] seb128: the kernel should not be on /boot [11:14] it should be on /boot/a/etc [11:14] right [11:14] boot/grub/a/ or whatever it is [11:14] it loads (gd0,gp2)/EFI/ubuntu/grub/a [11:14] that is 3.19 [11:14] but then it tries to boot [11:14] which is why i say it sounds like personal is broken [11:15] and disk has /lib/modules/4 [11:15] no 3.19 [11:15] so it fails to load modules [11:15] sorry if what I wrote is confusing [11:15] it does boot the a/b vmlinuz versions [11:16] the issue is that personal 30, which is today image has /lib/modules/4 [11:16] new kernel major [11:16] and for some reason the b partition from the upgrade has an old kernel [11:16] so boot fails because it doesn't find modules matching the kernel [11:16] yes, yes, i understand [11:16] it was not confusing [11:16] Chipaca, how would personal be able to break an underlying mechanism ? [11:16] i mean, your description wasn't [11:17] k [11:17] snappy should work distinct from that [11:17] but it's not personal which includes the boot/grub/b [11:17] that was generated/build at the upgrade time [11:17] new image don't have that issue [11:19] Chipaca, the b partition kernel is somehow copied when updating the image I guess? do you know what code does that? [11:20] seb128: snappy copies it [11:20] from where? [11:21] seb128: the new version might not include a kernel, in which case it gets copied [11:22] is that coming from the device tarball? [11:23] well the "new version" has a kernel, if you meant the image [11:23] i don't know where and if the device tarball comes into it :) [11:23] since a fresh image builds fine [11:23] boots fine [11:23] i expect sergiusens will take one look at the symptoms and know what's going on [11:23] k [11:24] so better wait for him than waste time guessing now [11:24] let's wait for him then [11:24] thanks [11:24] if he comes in and doesn't, then let's sleuth around [11:25] seb128: Chipaca ogra_ the livecdrootfs "kernel" and "initrd" entries are all that matter now [11:26] sergiusens, and seb128 got that one installed ... but the old one was completelly removed (so no modules) [11:26] sergiusens: mo'in :) [11:26] so /boot/grub/[a|b]/vmlinuz [11:26] ogra_: oh nice, how did that happen? [11:26] sergiusens, hey [11:27] sergiusens, install snappy personal 28 from yesterday [11:27] snappy update [11:27] reboot [11:27] get a system-b boot [11:27] kernel loaded is 3.19 [11:27] disk / files are 4.0 [11:27] boots fail to load any module [11:27] sergiusens, that's the summary [11:27] seb128: lib/modules/ only for 4 as well? [11:27] yes [11:27] which is basically what fails the boot [11:28] strange [11:28] do you have another kernel in /boot directly or some such ? [11:28] modprobe something gives a "fails to load /lib/modules/3.19..." [11:28] no [11:28] ogra_: there is, I didn't clean those up either in the 500-.*kernel.* task [11:28] sergiusens, perhaps grub falls back to that ... lbut if seb128 says there isnt one ... [11:28] there should be in /boot (system-[ab]) [11:29] ogra_: our grub.cfg doesn't look for one there [11:30] sergiusens, ogra_, http://picpaste.com/grub-9EyGcmUy.png [11:30] if that helps [11:30] http://picpaste.com/pics/grub-9EyGcmUy.1436355024.png [11:31] the vmlinuz size on those matches the 3.19 from hd0,4 [11:32] seb128: right, that /boot is system-a/boot/ [11:33] sergiusens, well, in any case $prefix/a|b shouldn't be identical [11:33] seb128: what's in (hd0,2)/[a|b] ? [11:33] oh, sorry it's above [11:34] right [11:34] neither matches the system kernel [11:34] they both match the old image 3.19 one [11:37] seb128: I need to see the system-image delta because this would make them look the same: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-desktop-next/hooks/500-move-kernel-to-device-tar.binary [11:37] sergiusens, where is the delta? [11:38] seb128: /pool/device-c06d05a678026547b8d48d99556b24281164724e7bffd61c95c261c6e9e3ab70.delta-device-4c246a16efc5ecf0c5f861394250cd68147710376c24d533939365c748939449.tar.xz [11:39] sergiusens, do you need that from my system or...? [11:40] seb128: oh no, I'm downloading for s-i, you don't have it in it's original form anymore ;-) [11:40] k [11:40] let me know if you need more info from me [11:40] but you can probably reproduce by installed personal 29 [11:40] then doing a snappy update [11:41] installing* [11:41] seb128: I bet core has the same problem [11:41] fgimenez: ^ [11:41] yeah, I'm doing an install now to see [11:41] but I would bet the same [11:48] * ogra_ thinks seb128 should just have used the stable personal image ... there also lightdm and the session would work :P [11:48] :-) [11:49] sergiusens, rsalveti: I am happy to report that with 118, we have a working 15.04 edge for Azure. [11:49] utlemming: \o/ [11:50] elopio: fgimenez: I published another image yesterday with a minor fix for azure, and hopefully that should be the last known bug we have [11:50] utlemming, yay [11:52] rsalveti, ok thx 118 then right? [11:52] utlemming: \o/ [11:52] fgimenez: yeah, and 119 for armhf [11:52] they are out of sync [11:52] rsalveti, ok [11:53] sergiusens, sorry wasn't connected :) which problem on core? [11:53] sergiusens, rsalveti: thank you guys for the help in getting this cleared. You guys were great :) [11:54] np [11:59] seb128: ogra_ mvo_ Chipaca these are the system image delivered files in the delta: http://paste.ubuntu.com/11841020/ [11:59] seb128: ogra_ mvo_ Chipaca assets/vmlinuz and system/boot/vmlinuz-4... [12:00] this is a livecd-rootfs/s-i problem and not a snappy update one I think [12:00] and 'removed' basically removes 3.19 [12:05] sergiusens, eparse ? (for your last line) [12:05] sergiusens: hm, it should be possible to reproduce this on core too - let me try that [12:07] ogra_: the s-i 'removed' file has 3.19 listed as a remove target [12:07] mvo_: yeah, that is the suspicion [12:08] ah [12:08] mvo_: I'm not sure how to make livecd-rootfs and/or s-i do what we want though [12:09] hmm [12:09] how often do we actually copy the azure tarball around ? [12:09] there seems to be a cp in live-build/auto/build and there is a hook as well where the same cp gets called [12:10] ogra_: for rolling we shouldn't be needing it soon-ish [12:11] well, and even then i guess once would be enough :) [12:12] i dont see where livecd-rootfs could be wrong here [12:13] the code seems all fine [12:15] ogra_: yeah, I don't either [12:16] ogra_: but how would a different kernel than the one copied end up there? [12:16] bug in s-i ? [12:17] ogra_: hmmm, maybe .signed is != than the unsigned one [12:17] yeah [12:17] well, we dont ship .signed [12:17] we copy/move it to be plain vmlinuz, no ? [12:18] ogra_: yes we do, vmlinuz-4.0.0-4-generic.efi.signed [12:18] ogra_: yeah, there's an if in the 500 task that prefers the .signed one [12:18] ogra_: mvo_ that's it [12:19] but we should have the signed 4.0 one there at that point [12:19] ogra_: mvo_ I mean, that is the reason for the different sig http://paste.ubuntu.com/11841115/ [12:19] why would we end up with a 3.x signed one during build [12:19] ah [12:20] seb128: can you md5sum the kernels? [12:22] ogra_: they are all 4.0 delivered in the delta [12:22] mvo_: this makes me thing the SyncBootAssets stuff runs after the upgrader logic and it is overwritting [12:22] think* [12:27] sergiusens, what kernels? the a/b vmlinuz? [12:28] seb128: yeah [12:28] that's going to match the 3.19 kernel I guess [12:28] since they are byte identical in size [12:28] Saviq: ogra_: you'll be able to assign hardware to snaps at the gadget snap later on, the spec for that is still in progress [12:29] from the ls earlier [12:29] rsalveti, that still wont enable it in your app snap [12:29] rsalveti, ah, /me just wrote a nice post to the snappy-devel ML ;) [12:29] seb128: right, then no worries [12:29] rsalveti, for that you still need to either call hw-assign or have a sideloaded snap that has it enabled [12:30] hmm? [12:32] Saviq: rsalveti dev nodes are assignable through the oem snap today [12:32] d'oh [12:32] if just hw-assign yeah, you can do that [12:32] but for the gadget snap there is also the idea of abstracting hardware and assigning a special piece of hardware to an app or framework [12:33] Saviq: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ [12:33] ogra_, ppisati, btw, I just grokked what you guys were talking about "the raspi blob and config.txt", I don't think that's a problem as when not using U-Boot (and IIUC booting straight into the kernel) there's no such problems [12:33] sergiusens, right, I was sure I read about that somewhere, but it's not there in the oem guide, or in the packaging reference [12:34] Saviq: no it's not :-/ [12:34] * sergiusens blames mvo ;-) [12:34] guess we can make an mr for that doc :-) [12:34] Saviq, RPi can not boot without the binary blob ... [12:34] sergiusens: hm? === mvo_ is now known as mvo [12:35] Saviq, it is: blob -> u-boot -> kernel [12:35] ogra_, yes [12:35] mvo: not documenting the oem hw-assign work :-) [12:35] *cough* [12:35] lalalala [12:35] ogra_, others go blob -> kernel directly [12:35] yes [12:35] and dont use an initrd [12:35] ogra_, so disabling console=ttyAMA0 there is enough [12:35] in the config.txt you mean ? [12:35] ogra_, yes [12:36] ogra_, but when u-boot comes into play, u-boot itself talks serial, too, so changing uEnv.txt is not enough [12:36] ogra_, so all in all I still just need to disable serial in u-boot, and bootdelay 0 gets it done, while obviously not a good solution [12:37] well, i fear there is no good solution :) [12:37] as long as there is that binary blob ... [12:37] that's why I thought dropping "serial" from u-boot's env std{in,out,err} would work, but it didn't (sounds like a bug) [12:38] well, sounds like an upstream bug then [12:38] ogra_, well, it's u-boot that's problematic in my case, blob isn't great for sure, but isn't a problem atm [12:39] ogra_, totally, will go to them to find out === erkules_ is now known as erkules [13:00] sergiusens, mvo, do you want a bug report/more info from me on that upgrade/kernel issue? [13:01] seb128: I think that would be good, with the exact image versions [13:05] beuno, hey, sorry to bug you, could I ask you to remove emonhub-pi.saviq from the store? I had to rename it (if you could ack emonhub.saviq please - it passes click-review with tools-proposed PPA) and it ended up under phone for some reason, as well as snappy [13:06] Saviq, isnt there an option in the store UI for you to do it yourself ? [13:06] ogra_, can't see it, it's there for drafts, otherwise I can only unpublish [13:07] yeah, unpublish was what i meant [13:07] unpublish and publish again [13:07] ogra_, don't think I can rename this way, can I? and I don't want it under Phone, either, not sure how it ended up there [13:08] you can not rename [13:08] seb128, so I created an Ubuntu Personal image with u-d-f and got it in KVM, but I only get the unity8 greeter with the QXL video model, and then my mouse pointer is strangely offset from my actual mouse so I can't possibly get through the edge demo, haha [13:08] you need a new submission and delete the old one from the store [13:08] ogra_, yeah, which is what I asked for, I can't delete myself it seems [13:08] kyrofa, wow, thats more than i get ! [13:08] kyrofa, use virt-manager rather than kvm maybe? [13:08] Saviq, you can unpublish [13:08] kyrofa, I don't get those issues with it [13:08] ogra_, that I did [13:08] that should delete everything [13:09] ogra_, well, it's still there, just not published ;) [13:09] and then create a new app in the store under the new name [13:09] you can not use the old bits anyway [13:09] seb128, I used virt-manager... thought that was still kvm? [13:09] ogra_, that still leaves me with the original in the list, my OCD can't deal with that ;) [13:09] heh [13:10] ogra_, what's happening for you? [13:10] kyrofa, lightdm with guest account ... if i hit enter it logs into a black screen [13:10] seb128, initially I tried it with regular-old kvm, but them I get the lightdm [13:10] ogra_, try QXL video model [13:11] * ogra_ will ty that later after we released 15.04 :) [13:11] ogra_, that's exactly what I get if I DON'T use QXL [13:11] kyrofa, k, unsure about the mouse ofset, you should be able to focus the password entry by clicking around no? [13:11] (currently my bandwith is used for other images) [13:11] seb128, that's correct, but the edge demo is hopeless haha [13:11] ogra_, when did you try that? those issues are resolved since friday [13:11] kyrofa, oh :-/ [13:11] seb128, and I don't get a mouse offset with a regular ubuntu image [13:11] it's just one dnd from the left [13:12] seb128, thursday ;) [13:12] ogra_, k, try again then! [13:12] yeah [13:12] takes a century to download that image :P [13:12] you carry so much bloat [13:12] lol [13:13] * Chipaca ~> late lunch [13:13] yeah, what's up with those people installing softwares so you can actually do something with your system [13:13] rather than watching a blinking cursor [13:13] my phone doesnt need all that ! [13:13] :P [13:13] no unity8 on your phone, right ;-) [13:14] seb128, talking to kgunn it sounded like when he was testing it earlier lightdm was on vt7 and unity8 was on vt8. I couldn't verify that-- is that still how it's supposed to be working? [13:14] kyrofa, we activated autologin now so no [13:14] what kgunn described was when you were getting the greeter at boot [13:14] seb128, when you run the image, do you see a unity8 login or lightdm? [13:14] seb128, ah, okay [13:14] unity8 [13:15] seb128, but you didn't have to mess with the video model settings at all? [13:15] you have to use qlx/spice [13:15] otherwise unity8 doesn't work [13:15] and you get a session which fails to start and send you back to the lightdm greete [13:15] greeter [13:15] seb128, ah, okay so that makes sense. Definitely what ogra_ is running into then [13:15] unless you install VMM [13:16] then it's magic [13:16] right [13:16] kgunn, haha man, you guys must have a cooler VMM than I do [13:17] kgunn, although I'm running mine on trusty. Too old? [13:17] oh may be [13:17] hopefully not [13:17] kyrofa: curious, what's your desktop gpu [13:17] if it is it should be updated via an SRU [13:18] kgunn, I have one of those wonky dual-GPU things. Right now I'm running on intel, but I also have an nvidia auadro K1100M [13:18] kgunn, s/auadro/quadro/ [13:20] mmm [13:20] kgunn, yeah, if I fire up an VM using the personal.img I made without modifying the config at all, I get lightdm [13:20] oh ok [13:21] kyrofa: but from scrollback, you're seeing mouse offset being an issue as well ? [13:21]