| === erkules_ is now known as erkules | ||
| === Guest47071 is now known as pitti | ||
| === pitti is now known as Guest48990 | ||
| === Guest48990 is now known as pitti_ | ||
| dholbach | good morning | 06:46 |
|---|---|---|
| fgimenez | good morning | 06:58 |
| rickspencer3 | mvo, https://bugs.launchpad.net/snappy/+bug/1465724 | 08:06 |
| ubottu | Ubuntu bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,New] | 08:06 |
| === davmor2_ is now known as davmor2 | ||
| JamesTait | Good morning all; happy Monday and happy Onion Rings Day! 😃 | 09:00 |
| === rbasak_ is now known as rbasak | ||
| * ogra_ grumbles at lool for including HTML tables in mails | 10:25 | |
| lool | the joys of HTML emails | 10:25 |
| zyga | ogra_: it's the company 2.0 | 10:26 |
| zyga | ogra_: without shell | 10:26 |
| zyga | ogra_: with html | 10:26 |
| zyga | ogra_: about the removal of {dpkg,apt,bash,python} | 10:26 |
| zyga | ogra_: I'd love to have a roadmap for that | 10:26 |
| ogra_ | zyga, and without answering inline in emails :P | 10:26 |
| zyga | ogra_: for people like me | 10:26 |
| zyga | ogra_: to know when something must be ready on my side | 10:26 |
| zyga | ogra_: so that my app continues to work | 10:26 |
| zyga | ogra_: and I think for everyone in the dev community | 10:26 |
| ogra_ | zyga, simpoly dont make use of them :P | 10:26 |
| zyga | ogra_: as any time you remove stuff from the image | 10:26 |
| zyga | ogra_: you break compatiblity | 10:26 |
| ogra_ | then you wont be bitten by their removal | 10:27 |
| zyga | ogra_: that's unrealistic, go rewrite my software for me | 10:27 |
| ogra_ | no we dont | 10:27 |
| zyga | ogra_: sure, that's just reality | 10:27 |
| ogra_ | we never guranteed compatibility beyond the snappy command | 10:27 |
| ogra_ | no it is not | 10:27 |
| zyga | ogra_: well, then snappy is a lousy thing to target | 10:27 |
| zyga | ogra_: it's worse than docker | 10:27 |
| zyga | ogra_: just bring your own distro | 10:27 |
| ogra_ | reality ios that the core system is abused as a dependency where it shouldnt | 10:27 |
| zyga | ogra_: well, regardless of what you think about what is in the core and what can be used | 10:28 |
| zyga | ogra_: if the core grants you nothing | 10:28 |
| zyga | ogra_: then it's not a core | 10:28 |
| ogra_ | it doesnt | 10:28 |
| zyga | ogra_: it's not a thing at all | 10:28 |
| ogra_ | it is enough OS to boot and to run the snappy command ... that is all it is | 10:28 |
| zyga | ogra_: great, who wants that? | 10:28 |
| ogra_ | and thats all we promise | 10:28 |
| * zyga is grumpy about that | 10:29 | |
| ogra_ | thats the design of snppy | 10:29 |
| ogra_ | *snappy | 10:29 |
| ogra_ | it hasnt been described differently anywhere | 10:29 |
| zyga | ogra_: this is like putting people in an empty room, not giving them any tools to fill the room and say, 'enjoy' | 10:29 |
| ogra_ | zyga, that is why your snap should include everything it needs, a snap needs to be self contained | 10:29 |
| zyga | ogra_: IMO we should have started with the empty room and added stuff, we started with a room with some things labelled "don't touch" (but nobody stopped you if you did) | 10:30 |
| ogra_ | not dependencies ... not even on core | 10:30 |
| zyga | ogra_: microsoft and apple learned the hard way that's not the way to do it | 10:30 |
| * zyga feels that snappy is not useful withouy stuff like snapcraft being done on day one | 10:30 | |
| ogra_ | we couldnt start with the empty room ... simply because we use legacy tools in core that we cant immediately replace | 10:30 |
| ogra_ | i.e. system-image | 10:30 |
| zyga | ogra_: ha, but you ask everyone to replace theirs | 10:30 |
| zyga | ogra_: I see what you do | 10:30 |
| zyga | ogra_: but it's hard to work in this world | 10:31 |
| ogra_ | we never and nowhere asked anyone to add a dependency on core ... quite the opposite | 10:31 |
| zyga | ogra_: the problem is in wording | 10:31 |
| zyga | ogra_: show me a link on .ubuntu.com that lists what the core provides | 10:31 |
| zyga | ogra_: and a big warning that says everything else is not supported | 10:31 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/wily-preinstalled-core-armhf.manifest | 10:32 |
| zyga | ogra_: and that {insert name of big thing people see and assume it's there} will go away | 10:32 |
| zyga | ogra_: be serious | 10:32 |
| ogra_ | nothing is supported | 10:32 |
| zyga | ogra_: I want high-level thing | 10:32 |
| zyga | ogra_: on ubuntu.com, in html | 10:32 |
| zyga | ogra_: with explanation | 10:32 |
| zyga | ogra_: nobody understands snappy because of failure of communication | 10:32 |
| ogra_ | i am serious, that is the list of bits core provides ... but that doesnt mean you should depend on anything in there ... this isnt dpkg | 10:32 |
| zyga | ogra_: of what snappy is and isnt | 10:32 |
| zyga | ogra_: and each time you ship a new core that has one bit less, something that works now will break -- and that's fine, it's just a failure to communicate this correctly | 10:33 |
| ogra_ | if it breaks the creator of that "something else" made a mistake ... | 10:34 |
| zyga | ogra_: and all those issues just contribute to the fact that snappy is hard to taget today, because of misunderstandings and missing tooling | 10:34 |
| ogra_ | since ... again, a snap needs to be self contained | 10:34 |
| zyga | ogra_: no, we're all people, nobody cares, if to make something great you need to make it great for developers and all the other people, or nobody will care | 10:34 |
| zyga | ogra_: is libc assumed? | 10:34 |
| zyga | ogra_: is this written down anywhere? any design doc? a white paper? anything that I can read apart from being grumpy to collegues? | 10:35 |
| zyga | (which I'd much much rather not do) | 10:35 |
| ogra_ | it surely is ... it is the fundamental design principle of snappy | 10:36 |
| ogra_ | (now dont ask me where in these 100s of google docs ... ) | 10:36 |
| zyga | so how can anyone write a good snap todaty | 10:37 |
| zyga | if we as a company failed to communicate this clearly | 10:37 |
| ogra_ | by including everything you need for execution inside your snap | 10:38 |
| zyga | I shouldn't be doing this, you are not at fault here | 10:38 |
| ogra_ | well, i'm promoting it ... and on purpose (and i knew that there will be resistance but i want to get peoples minds straight before the world falls apart because we remove something) | 10:39 |
| zyga | ogra_: don't mistake resistance | 10:39 |
| zyga | ogra_: with walking blindfolded over a minefield | 10:39 |
| zyga | ogra_: I'm forced to deliver somthing onto a platform I don't fully understand, that is changing, that has no tooling, that is totally barren (by design) -- this is frustrating as a developer experience | 10:40 |
| zyga | ogra_: it seems to me that the best way to do what I want is to just ship a debian chroot until some form of better tooling exists, maybe, someday | 10:40 |
| ogra_ | zyga, well, one reason for me working on py-snapper (or node-snapper) or ted and mike working on snapcraft, is to solve that ... we are just not there yet with the tooling | 10:41 |
| ogra_ | you are a pre-early-adopter here ... | 10:41 |
| ogra_ | you cant ship a debian chroot ... i dont think the security policy will allow chrooting ... you would have to depend on a container framework like docker or lxc | 10:42 |
| zyga | ogra_: and one that has a large app to port | 10:42 |
| zyga | ogra_: neither py-snapper nor anything like that will help me as my app is just more complex than that and relies on a zoo of tools | 10:43 |
| ogra_ | then you need to ship that zoo | 10:43 |
| zyga | ogra_: in docker? | 10:43 |
| ogra_ | by using deb2snap or whatnot | 10:43 |
| ogra_ | or in docker | 10:43 |
| zyga | ogra_: deb2snap ~30-50 packages | 10:43 |
| zyga | ogra_: into one huge snap (if that's possible by deb2snap) | 10:44 |
| zyga | ogra_: then path everything to understand new executable names | 10:44 |
| ogra_ | i think it is, AFIK deb2snap can take a package list | 10:44 |
| ogra_ | and it mangles the executable names, preload and library paths for you | 10:44 |
| sergiusens | ogra_: zyga 15.04 will not break; rolling on the other hand... | 10:52 |
| ogra_ | right | 10:53 |
| ogra_ | but even if it will not break it is wrong to depend on core even there :) | 10:53 |
| ogra_ | sergiusens, btw, putting files into /system/boot/uboot does indeed not work since we have a-b mounted on top :) | 10:55 |
| sergiusens | ogra_: if you are going to put it in /system/boot/uboot maybe just target the file to no where and it will land there (but there would be no a/b logic for these) | 10:57 |
| sergiusens | ogra_: you wont ever be able to get anything in the store that relies on dpkg at least | 10:58 |
| ogra_ | well, i'm pondering to just ship it in /lib/modules somewhere | 10:58 |
| ogra_ | but we should have some plan for changelogs, configs and licenses | 10:59 |
| ogra_ | sergiusens, bug 1467474 | 11:10 |
| ubottu | bug 1467474 in Snappy "hardware.yaml should allow including changelog, kernel-config and license files" [Undecided,New] https://launchpad.net/bugs/1467474 | 11:10 |
| === pitti_ is now known as pitti | ||
| === pitti is now known as Guest84030 | ||
| === Guest84030 is now known as pitti_ | ||
| zyga | ogra_: can I bug you for a moment about snappy and wifi? | 12:44 |
| zyga | ogra_: from what you said earlier | 12:44 |
| zyga | ogra_: it seems that I need to package things like wpa supplicant and all the IP tools | 12:45 |
| zyga | ogra_: is that correct? | 12:45 |
| zyga | ogra_: the goal is to make an app that can use wifi | 12:45 |
| zyga | ogra_: (and to be precise, for certification, what kind of base feature set should I test for when the hardware says that wifi is supported) | 12:47 |
| ogra_ | zyga, wpa_supplicant is shipped (hardware enablement is something that goes into core indeed) | 12:48 |
| ogra_ | (at least generic bits of it ) | 12:48 |
| zyga | ogra_: ah, so what kind of hardware enablement for wifi can any app rely on? | 12:48 |
| ogra_ | and you should have all tools needed to make a wlan come up | 12:48 |
| zyga | ogra_: or networking in general, what kind of IP tools do we plan on supporting | 12:48 |
| zyga | ogra_: ok, that's good to know | 12:48 |
| zyga | ogra_: can you tell me how this is all supposed to work according to you | 12:49 |
| ogra_ | though this should not be done by your snap i guess ... but rather via the owem snap in some way | 12:49 |
| ogra_ | *oem | 12:49 |
| zyga | ogra_: e.g. at which level do apps come in | 12:49 |
| zyga | ogra_: and at which level should we test | 12:49 |
| zyga | ogra_: the oem snap ships kernel image, modules and support bits, correct? can it also ship commands/scripts? | 12:50 |
| ogra_ | no, it ships bootloader and dtb files (and their overlays) | 12:50 |
| ogra_ | kernel is in a separate part | 12:50 |
| zyga | ogra_: ah, so everything goes to os snap? | 12:50 |
| ogra_ | (currently the device tarball) | 12:50 |
| zyga | ogra_: note: please separate current limitations | 12:50 |
| zyga | ogra_: from the design | 12:51 |
| ogra_ | (soon to be its own snap too) | 12:51 |
| zyga | ogra_: as the cert should work beyond 15.04 | 12:51 |
| zyga | ogra_: (at least without major changes) | 12:51 |
| zyga | ogra_: hmm, wait, new snap? (I though minimal system has three snaps: os + oem + gadget) | 12:51 |
| ogra_ | so technically -> hardware enablement should happen inside the core image itself via the owm snap ... wifi configuration should happen via snappy config of the core snap i guess ... your app snap should only make use of the preconfigured hardware then | 12:52 |
| ogra_ | *oem | 12:52 |
| ogra_ | (whats up with me today not being able to type oem) | 12:52 |
| zyga | ogra_: :D | 12:53 |
| zyga | ogra_: ok, so snappy config (yaml) is how apps can reconfigure network? (I didn't know about that part) | 12:53 |
| ogra_ | now there are some grey areas ... where your app snap needs to configure hardware ... (set the default resolution for a webcam that you need to set via echoing into a /sysfs node or some such ... ) not sure how that should be handled | 12:54 |
| zyga | ogra_: it depends on a product, if I wanted to build a STB device on top of snappy I'd have to handle network setup | 12:55 |
| ogra_ | i havent played personally with our hardware access story, i know some bits of that landed though and enable you to use it | 12:55 |
| zyga | ogra_: (though perhaps in a private framework for network that my app could talk to) | 12:55 |
| zyga | ogra_: for certification, I'm trying to see what's the low level stuff we need to test | 12:55 |
| ogra_ | yeah, something like that | 12:55 |
| zyga | ogra_: and verify through the programme | 12:55 |
| zyga | ogra_: when we say "wifi on $product works" what did we test? | 12:55 |
| zyga | ogra_: and what did we specifically left out? | 12:56 |
| ogra_ | the prob here is that all our implementations are still rather theoretic ... while they are there we dont have much code beyond simple examples using them yet | 12:56 |
| zyga | ogra_: in the past I assumed we'd be testing at the framework level but that's no longer true | 12:56 |
| ogra_ | there is a webcam example that might give some insight | 12:56 |
| zyga | ogra_: so what would be your advice, to wait and not create the programme? | 12:56 |
| zyga | ogra_: or to specify $something and just go with it for 15.04 | 12:56 |
| ogra_ | no, to challenge the current implementation by trying to implement it with whats there | 12:56 |
| zyga | ogra_: webcams are going to be under generic USB host capability, along with lots of other products | 12:57 |
| ogra_ | (would be my way) | 12:57 |
| ogra_ | to find the flaws and issues with what we created and fix them | 12:57 |
| zyga | ogra_: ok, if that's what you say then this is important feedback, so far we've been working on different assumptions | 12:57 |
| zyga | ogra_: as in, come up with requirements and start writing tests right now | 12:57 |
| zyga | (btw, I used deb2snap for plainbox, got 154MB archive, didn't test it yet) | 12:58 |
| zyga | (and it looks quite like a chroot I was thinking about earlier) | 12:58 |
| ogra_ | yeah, for now snaps will still be rather big :) | 12:58 |
| ogra_ | deduplication on all levels will help with that some day | 12:58 |
| zyga | ogra_: $now + 1 ;-) | 12:59 |
| ogra_ | (but thats not there yet)) | 12:59 |
| zyga | ogra_: who's working on the hardware design side of snap | 12:59 |
| ogra_ | until then i fear we have to live with giantic snaps on disk :) | 12:59 |
| ogra_ | well, there were some mails from jdstrand_ about that | 12:59 |
| zyga | on the mailing list? | 12:59 |
| ogra_ | yep | 13:01 |
| === dpm_ is now known as dpm | ||
| seb128 | slangasek, you around to help me with some uefi snappy personal boot issues? ;-) | 13:38 |
| ogra_ | about time that x86 switches to uboot :P | 13:39 |
| seb128 | ahah | 13:39 |
| ogra_ | all these UEFI issues all the time | 13:39 |
| seb128 | slangasek, the bios lists the usb stick correctly but selecting it displays a "error: file "/boot/" not found" then gives a grub shell rather that the boot menu | 13:43 |
| elopio | good morning. | 14:09 |
| tedg | Morning elopio! | 14:11 |
| elopio | hey tedg! | 14:15 |
| elopio | fgimenez: lets skip our call today. I have a good bunch of emails to read. | 14:16 |
| fgimenez | hi elopio, ok | 14:17 |
| fgimenez | elopio, any luck with the cross compilation? | 14:45 |
| elopio | fgimenez: I've just had a successful build, a couple of minutes ago. | 14:46 |
| elopio | Chipaca: ^ it seems it was actually a python problem, that maybe barry fixed. | 14:46 |
| fgimenez | elopio, great! should it work with the command we were using? | 14:47 |
| elopio | fgimenez: oh, wait, no, I've just run it in amd, not cross compile. | 14:48 |
| * elopio tries again. | 14:48 | |
| Chipaca | elopio: i'm shocked. will need to sit down for a bit. | 14:49 |
| barry | elopio, Chipaca hi | 14:49 |
| elopio | fgimenez: barry: Chipaca: now I get a problem from golang-go: http://paste.ubuntu.com/11757173/ | 14:52 |
| Chipaca | barry: hi | 14:53 |
| Chipaca | elopio: could you pastebin the postinst? | 14:53 |
| elopio | Chipaca: http://paste.ubuntu.com/11757206/ | 14:59 |
| === pitti_ is now known as pitti | ||
| === pitti is now known as Guest85442 | ||
| zyga | ogra_: I'm on image .3, I see there's wpa_supplicant there, there's no iw* tools though | 15:04 |
| zyga | ogra_: how would one, in practice, get wifi to work? | 15:04 |
| ogra_ | i think there si some blog post about how thats done | 15:06 |
| * ogra_ has never needed wifi yet | 15:06 | |
| elopio | Chipaca: https://www.goodreads.com/book/show/25676397-designing-connected-products | 15:08 |
| === Guest85442 is now known as pitti_ | ||
| zyga | ogra_: any links? I'm looking around but found only similar questions | 15:12 |
| ogra_ | i think rickspencer3 had one recently | 15:12 |
| ogra_ | (thats still from before we added wpa_suppl. to the image though, so it has some ill instructions about making the image writable etc ... the second half should just work though) | 15:13 |
| zyga | ogra_: wpa_supplicant is there but perhaps that's not enough (iwconfig is not there) | 15:14 |
| ogra_ | what for aourl you need iwconfig ? | 15:14 |
| ogra_ | *would | 15:14 |
| ogra_ | tsk .. | 15:14 |
| zyga | ogra_: not sure, probably to set the AP data | 15:14 |
| ogra_ | you dump your wlan config into /e/n/i.d/ and thats it | 15:15 |
| zyga | ogra_: interfaces? | 15:15 |
| zyga | ogra_: to /etc/network/interfaces? | 15:15 |
| ogra_ | there were discussions about moving away from /e/n/i to systemd's network manager tool | 15:15 |
| ogra_ | interfaces.d ... but yeah | 15:15 |
| zyga | ogra_: but that stuff relies on wireless-tools | 15:16 |
| zyga | ogra_: and without it the hooks won't do anything | 15:16 |
| zyga | ogra_: dpkg -L wireless-tools | 15:16 |
| zyga | ogra_: grep | if-post-(up|down) | 15:16 |
| * zyga cannot find anything on google about rick's blog post | 15:18 | |
| ogra_ | http://askubuntu.com/questions/585790/how-to-connect-wifi-network-from-raspberry-pi-2-snappy | 15:19 |
| ogra_ | "then added this file to /etc/network/interfaces.d/wlan0" | 15:19 |
| ogra_ | you should only need the bit below that line | 15:19 |
| ogra_ | (as long as you have a kernel compliant device for which a module exists) | 15:20 |
| zyga | thanks!, let's see | 15:20 |
| ogra_ | (forst hit for "ubuntu snappy wireless" on google btw) | 15:21 |
| zyga | ogra_: nothing like personalized searches ;-) I was googling for beaglebone wifi" | 15:22 |
| zyga | ogra_: works, nice | 15:23 |
| zyga | ogra_: thanks | 15:24 |
| ogra_ | :) | 15:24 |
| zyga | ogra_: one less cable for me to manage ^_^ | 15:24 |
| zyga | I sent a question on how to snapify network-manager to the mailing list, looking forward to see how that could be done | 15:25 |
| * elopio walks the dog before it rains. | 15:25 | |
| * zyga goes to the other desk to desolder some stuff | 15:26 | |
| * davmor2 sees that zyga is after more cables, or is that not what you are trying to say at all ;) | 15:28 | |
| zyga | dholbach: haha | 15:29 |
| zyga | grr | 15:29 |
| zyga | davmor2: ^^ | 15:29 |
| zyga | davmor2: I want to solder angled headers for serial | 15:29 |
| zyga | davmor2: so that I can fit everything in the case I've got | 15:29 |
| davmor2 | zyga: mad fool you ;) | 15:30 |
| zyga | davmor2: why? it's so cute when it fits in the case | 15:30 |
| elopio | dholbach: balloons: rsalveti said we want to make a new stable release next week. | 15:36 |
| elopio | so we need to start planning for the testing session by the end of this week or beginning of the next one. | 15:36 |
| dholbach | elopio, oooooh! | 15:37 |
| elopio | both are ok for me. Any preference on your side? | 15:37 |
| dholbach | both should be fine for me as well | 15:37 |
| balloons | awesome! | 15:39 |
| kyrofa | sergiusens, ping | 15:57 |
| sergiusens | kyrofa: pong | 15:59 |
| sergiusens | bbl pong then :-) | 16:00 |
| kyrofa | sergiusens, haha, okay :) | 16:00 |
| balloons | elopio, so I was just going to ask you if we would see a release next week. Thanks for the heads up. | 16:03 |
| balloons | elopio, so we should probably have a quick chat later this week. Can we pick a date for the open house yet? | 16:05 |
| fgimenez | elopio, i've just sent you a catch up email, one more for your pile ;) | 16:06 |
| elopio | fgimenez: thanks, I'll check. | 16:06 |
| popey | ogra_: do we have a handy guide for putting a snappy image on an sd card to play with on a pi 2? | 16:07 |
| ogra_ | popey, https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2 | 16:08 |
| elopio | balloons: yes, we should meet again to get the final details. We can pick a date, and then tell the team to have an RC ready for that date. | 16:08 |
| popey | ta | 16:08 |
| * balloons notes ogra_ points popey back to d.u.c | 16:10 | |
| balloons | success! | 16:10 |
| ogra_ | :D | 16:10 |
| fgimenez | nice evening everyone o/ | 16:11 |
| balloons | elopio, as soon as you have that date, let's meet. I'll get with Daniel tomorrow to kick off the announcements and line up the onair session, etc.. But that's all easier with a date :-) | 16:12 |
| elopio | balloons: a part of our team is sprinting this week, so I'm inclined to do it early next week. | 16:13 |
| elopio | if they are back on monday, monday sounds good. I'll ask. | 16:14 |
| balloons | elopio, ack. | 16:16 |
| slangasek | seb128: a grub shell rather than the boot menu, interesting. show me the contents of the second partition on the USB stick? | 16:27 |
| slangasek | certainly, "/boot" is not the expected path | 16:27 |
| === jdstrand_ is now known as jdstrand | ||
| seb128 | slangasek, http://paste.ubuntu.com/11757694/ | 16:34 |
| seb128 | slangasek, http://people.canonical.com/~seb128/video20150622_154059164.mp4 is the video from the bios/grub behaviour | 16:35 |
| slangasek | seb128: please pastebin the text of efi/boot/grub.cfg | 16:36 |
| seb128 | slangasek, | 16:37 |
| seb128 | set prefix=($root)'/EFI/ubuntu/grub' | 16:37 |
| seb128 | configfile $prefix/grub.cfg | 16:37 |
| seb128 | EFI/BOOT/grub.cfg yoy mean right? | 16:37 |
| slangasek | yes | 16:37 |
| slangasek | it's a fat partition, so it's the same thing ;) | 16:37 |
| slangasek | seb128: that all looks correct and expected, and does not explain the error message you got | 16:38 |
| seb128 | slangasek, the grub cfg is http://paste.ubuntu.com/11757708/ | 16:38 |
| seb128 | well /EFI/ubuntu/grub/grub.cfg | 16:38 |
| davmor2 | slangasek: calling things fat is so politically incorrect can't we call it larger ;) | 16:38 |
| seb128 | slangasek, it looks like /boot isn't mounted/it doesn't find the kernel maybe? | 16:39 |
| slangasek | seb128: I supposed that's possible. If you look at sda3 and sda4, do you have the expected /boot contents? | 16:40 |
| seb128 | slangasek, hum, no | 16:44 |
| seb128 | wth | 16:44 |
| slangasek | so I guess this error is also reproducible when booting under bios ;) | 16:45 |
| seb128 | slangasek, /system-a/boot has 3.19.0-22 files | 16:45 |
| seb128 | but the grub config has 3.19.0-10 entries | 16:45 |
| seb128 | oh, no | 16:45 |
| sergiusens | kyrofa: pong | 16:45 |
| seb128 | I'm reading the wrong section | 16:45 |
| seb128 | slangasek, seems about right in fact, and that image boots fine under kvm | 16:46 |
| seb128 | I'm going to try on a non uefi machine in a bit | 16:46 |
| seb128 | slangasek, should I be able to ls /boot from grub? | 16:46 |
| seb128 | I wonder if it fails to mount the fs for some reason | 16:46 |
| seb128 | slangasek, brb, trying on my laptop which is not uefi/signed boot | 16:47 |
| kyrofa | Hey sergiusens :) | 16:47 |
| kyrofa | sergiusens, one of the things the snapp scope will eventually need to do is actually launch snaps | 16:48 |
| kyrofa | sergiusens, but lots of snaps don't have the concept of "launching" | 16:48 |
| kyrofa | sergiusens, we need a way to tell which snaps have a GUI, or can be launched | 16:49 |
| sergiusens | kyrofa: you want the equivalent of binaries I guess; I thought tvoss was going to be looking into that | 16:49 |
| kyrofa | sergiusens, I'm really talking about the snappy API. I assume the store doesn't have a way to tell which snaps are launchable, but will that fit into the API when it does? | 16:49 |
| sergiusens | kyrofa: when there is a complete story for it, I guess it will, yes | 16:50 |
| kyrofa | sergiusens, alright. I wasn't sure if that would somehow fit into the "type" field or what | 16:51 |
| sergiusens | kyrofa: well that's a question for the elders of the internet (aka snappy architects) | 16:51 |
| sergiusens | kyrofa: I don't see tvoss here, so maybe olli knows who's dealing with this | 16:52 |
| kyrofa | sergiusens, alright, thanks :) | 17:00 |
| seb128 | re | 17:04 |
| seb128 | slangasek, that key works fine on my latitude | 17:04 |
| seb128 | so the issue seems to be with the signed boot | 17:04 |
| slangasek | oh? there's signed boot in place on the images already? | 17:06 |
| seb128 | slangasek, well, I don't know, maybe it's not properly set up :p | 17:07 |
| seb128 | slangasek, that image has grub-efi-amd64-signed installed | 17:08 |
| seb128 | and is built with goget-u-t 0.23 so with working uefi | 17:09 |
| seb128 | before that the boot menu of the inspiron wouldn't list the device | 17:09 |
| seb128 | maybe it's just the uefi mode which is misconfigured... | 17:10 |
| slangasek | seb128: ok. so if it's booting the signed grub efi binary, one notable difference is that it will not load any modules from the disk but only use those that are built in. So it's possible that there's something funny with your target device to cause it to require some module that's not currently part of the set we build into the signed grub | 17:18 |
| olli | kyrofa, from looking over the thread I think mvo (absent) or alecu can help | 17:20 |
| ogra_ | olli, where is my armhf mir !! | 17:20 |
| ogra_ | :) | 17:20 |
| seb128 | slangasek, how can I tell if there is anything funny/get debug info? | 17:21 |
| slangasek | seb128: let me think about that | 17:25 |
| slangasek | seb128: I do see that this system has both bootx64.efi and grubx64.efi. Is SecureBoot enabled on it? | 17:25 |
| slangasek | seb128: also, what seed are you building from? I guess this isn't in ubuntu.wily yet | 17:26 |
| kyrofa | olli, alright, thank you | 17:28 |
| seb128 | slangasek, "Is SecureBoot enabled on it?", how do I tell? | 17:38 |
| seb128 | slangasek, seed is http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop | 17:39 |
| seb128 | slangasek, you can see a build log on https://launchpadlibrarian.net/209683596/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz | 17:39 |
| slangasek | seb128: checking whether secureboot is enabled: mv /efi/boot/bootx64.efi /efi/boot/bootx64.efi.bak; cp /efi/boot/grubx64.efi /efi/boot/bootx64.efi; try to boot it | 17:40 |
| slangasek | seb128: if you get a different error, you know secureboot is enabled :) | 17:41 |
| seb128 | slangasek, if I do that the device stops being listed as a bootable one | 17:43 |
| slangasek | really? that's interesting | 17:43 |
| seb128 | that inspiron doesn't list non uefi (or non secure) devices | 17:43 |
| seb128 | like back then I first tried to boot a x86 iso and it never listed the device as bootable | 17:44 |
| slangasek | we haven't made it a non-uefi device. | 17:44 |
| slangasek | /efi/boot/bootx64.efi is the magic path | 17:44 |
| slangasek | and I would not expect the firmware to try to validate the signature on /efi/boot/bootx64.efi before it's been asked to boot it | 17:44 |
| seb128 | bah | 17:44 |
| seb128 | sorry, nautilus/fat fail | 17:45 |
| seb128 | the rename didn't work | 17:45 |
| seb128 | k, same issue | 17:45 |
| seb128 | well "same" = file "/boot" not found | 17:46 |
| slangasek | ok | 17:46 |
| slangasek | so that means secureboot is not enabled on the device, and the problem is not related to failure to load external modules | 17:46 |
| seb128 | that's something ;-) | 17:47 |
| slangasek | you probably want to debug this at the grub shell then | 17:47 |
| slangasek | starting with 'ls ($root)' | 17:48 |
| seb128 | (hd0,gpt2): filesystem is fat | 17:49 |
| slangasek | seb128: ok. 'ls $prefix' ? | 17:50 |
| seb128 | error: disk `(hd0,gpt2' not found | 17:50 |
| seb128 | ups | 17:51 |
| seb128 | sorry | 17:51 |
| seb128 | I had extra () | 17:51 |
| seb128 | error: file `/boot/grub' not found. | 17:52 |
| seb128 | ls / -> efi/ | 17:52 |
| seb128 | not sure if /boot should exist/be mounted | 17:52 |
| slangasek | ok that's interesting | 17:55 |
| slangasek | echo $prefix ? | 17:55 |
| slangasek | seb128: ^^ | 17:55 |
| seb128 | (hfb0,gpt2)/boot/grub | 17:56 |
| seb128 | grr | 17:56 |
| seb128 | (hd0,gpt2)/boot/grub | 17:56 |
| slangasek | ok | 17:56 |
| slangasek | no idea where that came from, because that's not what was specified in /efi/boot/grub.cfg | 17:56 |
| slangasek | and your directory listing showed only two grub.cfg on the disk, and both of them appear to be correct | 17:57 |
| slangasek | and you said this same image booted successfully on your UEFI-capable laptop in non-secureboot mode? | 17:58 |
| seb128 | no | 17:59 |
| seb128 | I've 2 laptop, the inspiron which is uefi and the latitude which is older and non-uefi | 18:00 |
| seb128 | it boots fine in kvm and on the latitude in non-uefi | 18:00 |
| slangasek | ah. | 18:00 |
| seb128 | it failes to boot on the inspiron | 18:00 |
| seb128 | secure or not | 18:00 |
| slangasek | seb128: what's the precise version of ubuntu-device-flash you used for creating this image, and what commandline did you use? I'd like to try to reproduce locally | 18:13 |
| seb128 | slangasek, I tried with the hack from http://paste.ubuntu.com/11700710/ but let me try again with trunk, proper support got merged | 18:14 |
| seb128 | before you spend time debugging | 18:15 |
| seb128 | though those changes are just partition size extended and using the correct channel | 18:15 |
| seb128 | so it shouldn't make a difference | 18:15 |
| seb128 | slangasek, command, the one on top of http://paste.ubuntu.com/11719625/ | 18:17 |
| slangasek | seb128: ok - but I should wait for you to test the goget-ubuntu-touch trunk before I try to reproduce? | 18:21 |
| seb128 | slangasek, as you want, I doubt it makes a difference | 18:23 |
| seb128 | but I'm happy to try and let you know | 18:23 |
| seb128 | it might be tomorrow morning for me though | 18:23 |
| _4M8B_ | Hi guys , I was searching howto configure my keyboard layout in snappy but without results... Can somebody help ? | 18:23 |
| seb128 | slangasek, $ strings EFI/BOOT/grubx64.efi | grep /boot | 18:24 |
| seb128 | set prefix=($root)/boot/grub | 18:24 |
| _4M8B_ | https://bugs.launchpad.net/snappy/+bug/1464944?comments=all -- seems to have same issue | 18:25 |
| ubottu | Ubuntu bug 1464944 in Snappy "no way to configure keyboard layout" [Wishlist,Triaged] | 18:25 |
| seb128 | unsure where that comes from though | 18:25 |
| _4M8B_ | ah ok | 18:25 |
| _4M8B_ | I'll wait thanks | 18:27 |
| === Jordan_U_ is now known as Jordan_U | ||
| slangasek | seb128: well, one thing I've confirmed, that grubx64.efi is not the grubx64.efi from the grub-efi-amd64-signed package. | 19:23 |
| slangasek | $ strings /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed |grep prefix= | 19:23 |
| slangasek | $ | 19:23 |
| slangasek | for both wily and vivid | 19:23 |
| seb128 | slangasek, do you get the same issue? | 19:51 |
| seb128 | slangasek, do you have any idea where the grubx64.efi is coming from then? | 19:51 |
| slangasek | seb128: I haven't tried to reproduce it yet, just got udf built from trunk | 19:52 |
| slangasek | seb128: the grubx64.efi is being created by grub-install at udf time | 19:52 |
| === nessita_ is now known as nessita | ||
| slangasek | (apparently with wrong options) | 19:55 |
| slangasek | seb128: I've just run the command from http://paste.ubuntu.com/11719625/ but I don't think it worked, I wound up with cache/ubuntuimages/ubuntu-core/rolling/edge/generic_amd64/version-84.tar.xz. Is 'AME' really the right variable name? | 20:27 |
| slangasek | seb128: looks like that should be UDF_UBUNTU_CORE_NAME but is ignorable; but the command should be 'personal rolling' instead of 'core rolling', since I'm pretty sure you said you were seeing this with personal rather than core | 20:31 |
| slangasek | seb128: reproduced that 'strings | grep prefix' output that you showed, by running 'UDF_UBUNTU_CORE_NAME=ubuntu-personal DEBUG_DISK=1 ~/bin/ubuntu-device-flash --verbose personal rolling --channel edge --output amd64-rolling.img --size 10'. So udf is doing something buggy here | 20:45 |
| slangasek | (or else grub-install itself is) | 20:47 |
| seb128 | slangasek, sorry, I was afaik, yeah unsure about why sergiusens used 'AME' in his command, UDF_UBUNTU_CORE_NAME was the hack name in mvo's patch but I think trunk has a proper option for the new channel? | 20:49 |
| slangasek | I don't know what that option is. So I just reproduced it with the above command | 20:49 |
| seb128 | k | 20:50 |
| seb128 | http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/revision/190 was the merge for personal | 20:50 |
| slangasek | what is DEBUG_DISK=1 supposed to give me? doesn't seem to give me much in the way of new output from grub-install | 20:51 |
| seb128 | the "parted" output I think | 20:52 |
| seb128 | e.g on http://paste.ubuntu.com/11719625/ the lines 17 to 26 | 20:52 |
| seb128 | I don't think it's useful to debug the grub issue | 20:52 |
| seb128 | sergiusens suggested it when I was hitting partitioning errors | 20:53 |
| seb128 | because the partitions were too small for the new image | 20:53 |
| slangasek | that's certainly not the cause of this problem. | 20:53 |
| seb128 | right, that was a previous issue that got resolved by the 10G size bump | 20:53 |
| seb128 | you can drop that env variable afaik | 20:54 |
| slangasek | oh, you mean the grub issue from the pastebin. Yeah I don't know what that is | 20:54 |
| seb128 | it's orthogonal, don't worry about it | 20:54 |
| seb128 | we resolved that one since the pastbin was done | 20:55 |
| slangasek | grub-install: info: copying `/usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' -> `/boot/efi/EFI/BOOT/grubx64.efi'. | 20:56 |
| slangasek | aha | 20:56 |
| slangasek | so apparently when passing --removable it's copying the CD image not the disk image | 20:57 |
| slangasek | and that's where it gets the prefix= | 20:57 |
| slangasek | that may be a regression in grub-install in wily | 20:57 |
| slangasek | hmm nope | 20:59 |
| slangasek | same behavior in vivid, where it was working fine for me on core | 20:59 |
| seb128 | slangasek, k, I'm calling it a day and closing IRC but drop me an email or let me know tomorrow if you figure out more about the issue! | 21:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!