[07:53] <hallyn> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1531747   more overlay fun
[07:53] <hallyn> too wiped at this point to look at the source
[07:59] <mjg59> hallyn: Oh ouch
[08:11] <hallyn> mjg59: oh it's only in a user ns
[08:11] <hallyn> i failed to point that out in the bug, bad me
[08:19] <mjg59> hallyn: That's especially weird
[08:22] <hallyn> yeah a bit funky :)
[08:22] <hallyn> i'll look at the src tomorrow in the unlikely event apw doesn't have it sorted out :)
[08:22]  * hallyn out
[16:43] <manjo> apw, you have a few mts for me to pick your brain about something related to using root=PARTUUID ?
[16:43] <apw> manjo, best to just ask, you never know who might know
[16:43] <manjo> :) 
[16:44] <manjo> I have a UEFI system and form the uefi shell if I say root=PARTUUID=<partuuid> it does not seem to find root but if I say root=/dev/disk/by-partuuid/<partuuid> it finds root and mounts it 
[16:44] <manjo> in the former case I get an initramfs prompt 
[16:45] <manjo> comments in kernel source says  6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
[16:45] <manjo> 194 * unique id of a partition if the partition table provides it.
[16:46] <manjo> as a valid syntax for root=
[16:47] <manjo> or acceptable "root=" formats ... any ideas why root=PARTUUID= does not work but root=/dev/disk/by-partuuid/<partuuid>  works? 
[16:49] <manjo> you can find the valid acceptable syntax under init/do_mounts.c
[16:51] <manjo> I have tried MSDOS and GPT partuuids but neither work with PARTUUID=
[16:54] <manjo> and I am passing initramfs .. so thatis not the issue 
[16:55] <manjo> could it be that initramfs does not fetch these identifiers ?
[17:00] <manjo> could this be a regression in initramfs-tools ? 
[17:00] <manjo> anyone know ? 
[17:02] <JanC> sure it's not UUID instead of PARTUUID ?
[17:03] <manjo> JanC, I have tried both  UUID and PARTUUID .. UUID If initrd is not used and partuuid if using initrd .. is waht I gather from the source 
[17:05] <apw> because you have an initramfs isn't it that which is parsing thigns like UUIDs, and so it would need to support them i think
[17:05] <apw> which is why the by-partuuid works, because udev is running in the initrd to make them
[17:05] <TJ-> manjo: as apw just said; initramfs-tools function resolve_device() doesn't support PARTUUID
[17:06] <manjo> that is s bug then ? 
[17:06] <manjo> coz it is supposed to as per kernel source 
[17:06] <apw> initramfs-tools isn't meant to do anything because there are comments in the kernel ?
[17:06] <apw> you have an initrd, the kernel useds the initrd as root, it is happy
[17:07] <apw> it has no concept of the real root you mount later by hand in the initrd and then chroot into
[17:07] <apw> that is just you messing about with root etc, it doesn't really know that is being found, mounted and switched to
[17:07] <apw> now, why do you care if PARTUUID does or does not work
[17:08] <apw> should you not be gettting the real UUID of the contents of that parittion and using that
[17:08] <apw> as that (if it has a filesystem on it) will have a separate UUID which is more normal to want to boot
[17:08] <apw> so if you move the contents to a new drive you still mount the right contents
[17:09] <manjo> apw, fair enough .. but the kernel supports partuuid as a valid syntax 
[17:09] <apw> and
[17:09] <apw> ?
[17:09] <apw> it isn't a useful syntax really, you _should_ be using the filesystem uuid
[17:10] <manjo> apw, AH! I found a bug ... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801154
[17:10] <manjo> apw, that was fixed in December .. 
[17:10] <apw> then we have that fixed in xenial
[17:10] <apw> that still doesn't make it sensible
[17:11] <TJ-> it strikes me as a hidden gotchya! partition may contain no valid file-system
[17:11] <apw> and in fact we have 0.120 in wily as well
[17:12] <JanC> well, I guess it's more of a feature request for special cases than a bug fix also then?  :)
[17:12] <apw> i can't see any valid use for that other than having a filesystem in there which does not have a UUID, which ... i can't think of one off hte top of my head
[17:14] <TJ-> The bug seems to be more aimed at taking a pass-through from a bootloader that may not know file-systems 
[17:14] <manjo> yeah like when booting from shell prompt on efi systems
[17:14] <manjo> ie command line 
[17:15] <apw> when you are typing in random strings nayhow to make it work, hrm
[17:15] <apw> manjo, well either way the bug is fixed so you should have no problems right
[17:15] <manjo> apw, yes looks like it .. I will update my initramfs-tools to latest and see if that makes it work 
[17:16] <apw> manjo, that version has been default for a very long time
[17:16] <manjo> oh as per the bug report the fix went to debian on Sun, 27 Dec 2015
[17:17] <apw> manjo, then i don't thnk it can be in 120
[17:17] <TJ-> 0.121~rc1
[17:17] <manjo> apw, ok so I will need to wait for you guys to referesh ? 
[17:17] <apw> that is more believeable
[17:18] <apw> manjo, i am waiting for 1.121 to leave -rc and will merge that when it doe
[17:18] <apw> s
[17:18] <apw> manjo, if it is urgent then i can prolly pull that one fix 
[17:18] <manjo> ok as long as xeniel has it coming .. I am ok ... I can ask the people to wait for a bit 
[17:19] <apw> manjo, no idea as to timescales tho. for debian
[17:19] <manjo> apw, if you can make that patch available in xenial by end of Jan ... I can hold down the fork here 
[17:21] <apw> manjo, can't make any guarentees of that nature against debian, so ... 
[17:21] <apw> manjo, you need to file a bug against initramfs-tools in xenial and link the bug report, and assign it to me, and let me knwo the bug# here
[17:21] <apw> (link the debian one)
[17:21] <manjo> yep doing as we speak you read my mind 
[17:26] <manjo> apw, https://bugs.launchpad.net/initramfs-tools/+bug/1531928
[17:50] <dobey> hi. anyone have ideas on how to figure out why the lowlatency kernel hangs, but only when intel video is driving the monitor at 30Hz, and not at 60Hz?
[18:04] <apw> dobey, hangs hard with no output?  have you tried sysrq ?
[18:05] <dobey> apw: yeah, just all of a sudden the system would be locked hard, and i can't even ssh in
[18:05] <dobey> didn't try sysrq
[18:05] <dobey> (totally forgot about sysrq actually)
[18:08] <JanC> IME the Intel video drivers are really badly tested
[18:09] <dobey> i won't disagree with that. this certainly isn't my only problem with intel, but it is a more important one to me
[18:09] <dobey> hmm, actually, i'm not even sure if i have a sysrq on my keyboard
[18:10] <JanC> PrtScr ?
[18:10] <dobey> i have a happy hacking lite 2
[18:11] <JanC> PrtScr is the same key, but the SysRq label is sometimes left off
[18:11] <JanC> and on some small form factor / laptop keyboards you might need Fn
[18:11] <dobey> well, most of the function key text has been worn off, so i'm not sure
[18:12] <dobey> ah, ok, found prntscr
[18:13] <dobey> https://mjbdiver.files.wordpress.com/2011/09/304964-full.gif
[18:13] <dobey> hah :)