[08:39] <ianclark001> Hi all, today I found myself unable to boot (specifically to get past the full-disk encryption screen). I couldn't find a way to retrieve any meaningful information as to why this was. I'm able to boot using the recovery mode, and everything works fine when using 3.19.0-28-generic, but 3.19.0-30-generic just won't boot.
[08:39] <ianclark001> Would be super-appreciative of any guidance as to how I should approach debugging / resolving
[08:58] <smb> Hm, if people would give a little time to respond...
[09:04] <caribou> apw: smb: do you guys have good ties with the Debian kernel people ?
[09:05] <caribou> I'm thinking of proposing my "small initrd" changes to Debian as well
[09:05] <caribou> I see that dannf is in the team, I'll probably ping him about this later
[09:06] <smb> caribou, We (ok, probably apw more) have talked to Ben a few times...
[09:07] <caribou> smb: on a side note, who "owns" the /boot directory ?
[09:07] <apw> caribou, i'd not call our ties strong no, they should be better than they are, i guess henrix talks to ben a fair bit on security topics
[09:07] <caribou> I mean who whould mostly be concerned about kdump-tools putting stuff there ? the kernel team ?
[09:08] <apw> between us and the bootloader people
[09:08] <smb> Maybe a shared interest between kernel and grub...
[09:08] <caribou> apw: I just don't want to ruffle feathers by adding stuff there
[09:08] <apw> did we decide it had to be in there, i thought they were loaded after we had filesystems
[09:08] <apw> else /var/lib/kdump or whatever is an option
[09:09] <caribou> apw: hmm, true; might be better there, let me test
[09:09] <caribou> apw: I need to test. kexec is mostly concerned there
[09:10] <apw> ack
[09:10] <caribou> apw: ok, thanks for the info
[09:11] <caribou> apw: smb: I will write a blog post about the proposed changes
[09:12] <apw> nice
[09:55] <caribou> apw: FYI - file system availability is not an issue here
[09:55] <caribou> the kexec call at boot time goes and reads the content of vmlinuz & initrd.img in memory for later use
[09:58] <caribou> hmm, well that's only true for the vmlinuz
[10:02] <caribou> nevermind, initrd.img goes in memory too
[10:02]  * caribou is making his way into kexec sources
[10:47] <apw> caribou, right they are both loaded at "setup time"
[10:48] <apw> so its all about the kdump job, where it comes in the boot process, whether it is after wait for filesystems or not
[10:49] <caribou> apw: kdump-config load happens late at boot time
[10:50] <caribou> apw: it happens after network-online.target
[10:50] <apw> then i'd say it matters not where they are in a disk sense
[10:50] <caribou> apw: I had a doubt for a while on wether kexec was loading them only when triggered so I went back to the source to check
[10:51] <apw> caribou, no it definatly has to load them at init time, else it would rely on a lot of the kernel working to dump, which would defeat the purpose
[10:51] <caribou> apw: indeed
=== shirgall_ is now known as shirgall
=== MO is now known as Guest87877
[17:12] <aisrael> I'm running 15.10 and noticed (after a failed reboot) that there's no packaged for the signed kernel for 3.16.0-41-generic (looks like the last signed is -30). Is there something I'm missing, or should I downgrade kernels (this is on a Mac Mini so the signed kernel is important)
[17:16] <apw> aisrael, do you have linux-signed-generic installed ?
[17:17] <aisrael> apw: Yes, sorry. I have 3.16.0-41-generic signed. I meant to say that there's no signed package for 3.19.0-30
[17:18] <apw> aisrael, ok i am utterly confused, you are installinling linux-lts-vivid-generic ?
[17:19] <apw> aisrael, to swithc up from lts-utopic to lts-vivid ?
[17:19] <apw> or did you upgrade utopic to vivid ?
[17:19] <aisrael> apw: I upgraded from trusty -> utopic -> vivid
[17:20] <aisrael> I just found the signed package -- it wasn't installed when I upgraded last, so I might be wasting your time. :(
[17:20] <apw> aisrael, ok and do you have linux-signed-generic package installed
[17:20] <apw> as it is that that makes sure the signed kernels get installed as we release them
[17:20] <aisrael> apw: Aha. I did not have the meta package for the signed kernel installed
[17:21] <apw> and that would account for the lack of a signed one then
[17:21] <aisrael> I'll reboot that machine and verify that worked (and I'll add notes to the Ubuntu on Mac docs to note that requirement)
[17:23] <aisrael> apw: That fixed it, thank you!
[18:14] <lfaraone> jsalisbury: can you also upload a sig on the SHA256SUMs for your latest build in http://kernel.ubuntu.com/~jsalisbury/lp1500751/ ? :) 
[18:14]  * lfaraone is paranoid, sorry.
[18:30] <jsalisbury> lfaraone, sure
[18:33] <jsalisbury> lfaraone, done.  In a file named: signature-lp1500751-commit-90dcba7ee
[21:06] <ogra_> grmpf ... 
[21:07] <ogra_> does anyone know a way to make devtmpfs re-populate /dev ? i ran a broken script that wiped my dev dir and dont want to reboot
[22:15] <apw> ogra_, maybe you can retrigger udev to repopulate it
[23:12] <ogra_> apw, i tried that ... it doesnt recreate the initial nodes 
[23:12] <ogra_> in the end i bit the bullet and rebooted 
[23:12] <ogra_> (i had a semi populated /dev ... but all block devices were missing etc)
=== mamarley_ is now known as mamarley