[00:00] <tkamppeter> slangasek, where are you flying to? Are available on IRC next week?
[00:51] <xnox> slangasek: cjwatson: jdstrand: mdeslaur: with updated ovmf, SecureBoot keys survive OVMF cold-boot. Also efi manager "ubuntu" entry is set/saved, but fails to boot -> investigating.
[00:52] <xnox> slangasek: cjwatson: mdeslaur: we should be able to automate smoketesting in uefi / SecureBoot / modes, once boot entry is sorted.
[01:18] <xnox> slangasek: cjwatson: filed bug #1275162 with boot entries that generated update-grub and don't work + working entries as added from efi shell using "fs1:\EFI\ubuntu\shimx64.efi" and the mapping that resulted from doing that.
[01:18] <xnox> stgraber: ^ might find interesting as well =)
[13:00] <jhenke> Hi!
[13:00] <jhenke> is by chance anybody here feeling responsible for the boot process/uefi boot entries/grub?
[18:51] <slangasek> tkamppeter: flying to> I'm flying home from a sprint; so yes, I'll be on IRC next week, in my usual timezone (US/Pacific)
[18:51] <slangasek> xnox: ovmf> huzzah! what options do we need to pass to give the qemu session somewhere to write the nvram to?
[18:52] <slangasek> (and can we make it COW so that we can distribute a pre-configured nvram blob?)
[18:52] <xnox> slangasek: cp /usr/share/ovmf/OVMF.fd .; qemu -pflash OVMF.fd -cdrom ubuntu-desktop.iso
[18:53] <slangasek> so you have to copy the whole firmware image?  Not ideal
[18:53] <xnox> slangasek: you can "boot" ovmf.fd and enroll keys the usual way.
[18:53]  * slangasek nods
[18:53] <xnox> slangasek: yeah, parts of the firmware image is reserved memory for nvram.
[18:54] <xnox> slangasek: not sure if one can make it a qcow2 image with 3 snapshots (empry, microsoft keys, custom keys)
[18:54] <xnox> but due to efibootmgr / update-grub bug it doesn't generate the correct boot entry on install.
[18:55] <xnox> maybe we should ship keys in the installer and allow pre-seeding key enrollment at install time.
[18:55] <TJ-> xnox: So with some jigging about with loop and md linear we could create a writable firmware that puts the NVRAM in a separate file... cool!
[18:55] <xnox> TJ-: interesting idea. let me talk to #edk2 people on OFTC about it.
[18:57] <TJ-> xnox: I use that approach for repairing broken block devices; create a 1MB file and chain the file-system onto it, to enable booting block devices that do not contain partition tables.
[19:02] <slangasek> xnox: was that bug reproducible when using a *not* nvme disk?
[19:02] <xnox> slangasek: correct.
[19:02] <slangasek> ok
[19:03] <xnox> slangasek: ubuntu-custom -> is the working nvme disk; ubuntu-custom-normal -> is the working -hda qemu default disk; ubuntu is the entry that update-grub generated.
[19:03] <slangasek> ok
[19:03] <xnox> slangasek: since update-grub does work correctly on real uefi laptops, i wonder if OVMF is being funny here.
[19:05] <xnox> i guess there a multiple ways of addressing UEFI hardware, cause my laptop is using Boot0000* ubuntu	HD(1,800,8e800,ad01ebb3-3866-4648-b8a0-e126abbc6817)File(\EFI\ubuntu\shimx64.efi)
[19:05] <xnox> which is partuuid addressed HD.
[19:08] <slangasek> multiple ways> indeed
[19:09] <xnox> slangasek: so for some reason update-grub is using "short fs-uuid" (mbr style), instead of "full gpt partition uuid" (gpt style)
[19:09] <xnox> under ovmf.
[19:09]  * slangasek nods
[19:10] <slangasek> actually, that should be all efibootmgr, shouldn't it?  I didn't think update-grub did the calculation
[19:21] <tkamppeter> slangasek, I am flying to a sprint tomorrow. I have tested socket triggered CUPS start with Upstart, CUPS gets actually started, but is not able to overtake the socket FD.
[19:22] <slangasek> tkamppeter: you know that the upstart and systemd socket activation protocols are different?
[19:23] <slangasek> (this is something we intend to fix on the upstart side, but not immediately)
[19:24] <tkamppeter> slangasek, did not know that and started systemd-like, now I have seen in the man page that one has to accept() the FD and so I have done an upstart_checkin function like this: http://paste.ubuntu.com/6856965/
[19:26] <tkamppeter> slangasek, but this still not works and I get "upstart_checkin: Unable to get local address - bad file descriptor", so the accept() failed.
[19:28] <slangasek> tkamppeter: ok.  I don't know the answer offhand; I've never written code to use upstart's socket activation (and didn't write the upstart code either), I would have to dig into it
[19:29] <tkamppeter> slangasek, the original author is Scott James Remnant?
[19:30] <slangasek> tkamppeter: yes, and he's no longer involved in upstart development.  I believe jodh did the landing of the code in upstart upstream, so he might be able to help
[19:44] <xnox> tkamppeter: i did write code that successfully used upstart-socket activation.
[19:44] <xnox> tkamppeter: it was a python daemon however, but semantics are the same across any language.
[19:45] <tkamppeter> xnox, can you send me the code or a link to it?
[19:46] <tkamppeter> slangasek, thank you very much, will talk with jodh (James Hunt?) and xnox. I will come back to you next week if needed.
[19:46] <xnox> tkamppeter: http://cheesehead-techblog.blogspot.co.uk/2013/12/upstart-socket-bridge.html
[19:47] <xnox> tkamppeter: article was updated with my patches, so all should be good.
[19:47] <xnox> tkamppeter: i'll be in Bluefin on monday, if you are there as well.
[19:47] <xnox> tkamppeter: yeah, jodh is James Hunt.
[19:48] <xnox> here is uwsgi support for using socket activation with upstart
[19:49] <xnox> http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html
[19:50] <tkamppeter> xnox, thank you very much!
[19:50] <tkamppeter> xnox, I will be in Bluefin next week, too. So we can meet and get it working.
[19:51] <xnox> tkamppeter: i'm there on monday only, not all week.
[20:13] <tkamppeter> xnox, no problem, we can meet on Monday.
[20:43] <tkamppeter> xnox, I have looked in your C code and it seems to be the same as I did in CUPS (see http://paste.ubuntu.com/6856965/) but in CUPS it does not work.
[20:44] <xnox> tkamppeter: i'm not in the mood to dive into it, can you push a branch with it and i will look into it on monday?
[20:45] <xnox> tkamppeter: i'm deep in python3 porting at the moment.
[21:13] <tkamppeter> xnox, we should also talk about HPLIP then ...
[21:15] <xnox> tkamppeter: ha, yeah =) doko was at bluefin last week.
[21:15] <Noskcaj> xnox, on the topic of python3, the new pidgin is out. I've made a basic debdiff, but there's probably extra changes needed
[21:19] <jhenke> hi, is by chance somebody here who could take a look at a bug related to efibootmgr/grub? bug #1272664
[21:19] <xnox> Noskcaj: well, have you fixed Bug #1272455 yet?
[21:20] <xnox> jhenke: is the VM booted in UEFI?
[21:20] <jhenke> affirm
[21:20] <jhenke> the problem is the creation of the uefi boot entry
[21:20] <xnox> jhenke: it creates a wrong one or overrides existing ones?
[21:20] <xnox> jhenke: i found with OVMF that wrong entries are generated.
[21:21] <xnox> jhenke: so efibootmgr "manages" "ubuntu" boot entry, i've successfully created a different one, e.g. "ubuntu-custom" that works and those tend to persist.
[21:21] <jhenke> not sure, as soon as an entry is generated the VM configuration becomes corrupted so you cannot access the VMs properties anymore nor does Hyper-V recognize it
[21:21] <Noskcaj> xnox, no, sorry. I barely know C, let alone gtk
[21:22] <Noskcaj> I'd not been able to reproduce the bug locally as i understood it, but i'm not sure there's anything i can do to that package
[21:23] <jhenke> *not does Hyper-V recognize the VM any longer, sorry
[21:23] <xnox> jhenke: i see. I'll ask cjwatson about it.  it's best not to corrupt VMs just because a package gets installed (abeit called efibootmgr)
[21:23] <jhenke> indeed it is
[21:24] <jhenke> basically right now you cannot properly install ubuntu in a gen 2 VM, which I think is very bad
[21:25] <jhenke> thanks for pinging the right person :)
[21:25] <xnox> cjwatson: assigned Bug #1272664 to you based on ^ maybe you can take a look at it.
[21:28] <wgrant> It's a bit of a worry that a VM can affect the hypervisor like that.
[21:28] <wgrant> Sounds like a Hyper-V bug...
[21:30] <xnox> slangasek: edk upstream says that they are working with qemu to provide external variable storage, but it's not implemented in qemu yet. So current storage arrangement is the current state of the art.
[21:35] <jhenke> I guess it is proably due to the facct that efibootmgr interacts slightly differently with the uefi than windows does
[21:36] <jhenke> since installing windows 2012r2 works well and the uefi boot entry is created correctly
[21:36] <jhenke> so efibootmgr must doing it a bit differently which causes this problem
[21:55] <tkamppeter> xnox, doko, reported HPLIP upstream bug https://bugs.launchpad.net/hplip/+bug/1275353.
[21:56] <xnox> tkamppeter: that bug is not new.
[21:56] <xnox> tkamppeter: some dependencies are ported but not all, and needs further investigation.
[21:56] <tkamppeter> xnox, but is it already reported to HPLIP upstream?
[21:56] <xnox> tkamppeter: barry was involved it in.
[21:56] <xnox> tkamppeter: i believe doko did talk with hplip upstream about it, yes.
[21:57] <xnox> tkamppeter: you need hplip urgently on the phone?
[21:57] <tkamppeter> xnox, important is that we do not carry a huge Debian/Ubuntu patch but upstream switches over.
[21:58] <tkamppeter> xnox, HPLIP is not needed on the phone at all, I thought they talked to me because of getting rid of Python 2 in general, also on the normal desktop.
[21:59] <tkamppeter> xnox, on the phone printing will only be done to network printers with known standard languages, not with tons of printer-model-specific drivers.
[22:02] <xnox> tkamppeter: cool. yeah getting off python2 is a general goal on touch/server/desktop.
[22:02] <xnox> tkamppeter: so any help on that front is greatly appreciated.
[22:16] <slangasek> xnox: ack