| === Martyn_ is now known as Martyn | ||
| hallyn | apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1531747 more overlay fun | 07:53 |
|---|---|---|
| ubot5 | Launchpad bug 1531747 in linux (Ubuntu) "overlay: mkdir fails if directory exists in lowerdir" [Undecided,New] | 07:53 |
| hallyn | too wiped at this point to look at the source | 07:53 |
| mjg59 | hallyn: Oh ouch | 07:59 |
| 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:11 |
| mjg59 | hallyn: That's especially weird | 08:19 |
| 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 | 08:22 | |
| === lool- is now known as lool | ||
| 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:43 |
| 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:44 |
| 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:45 |
| manjo | as a valid syntax for root= | 16:46 |
| manjo | or acceptable "root=" formats ... any ideas why root=PARTUUID= does not work but root=/dev/disk/by-partuuid/<partuuid> works? | 16:47 |
| manjo | you can find the valid acceptable syntax under init/do_mounts.c | 16:49 |
| manjo | I have tried MSDOS and GPT partuuids but neither work with PARTUUID= | 16:51 |
| manjo | and I am passing initramfs .. so thatis not the issue | 16:54 |
| manjo | could it be that initramfs does not fetch these identifiers ? | 16:55 |
| manjo | could this be a regression in initramfs-tools ? | 17:00 |
| manjo | anyone know ? | 17:00 |
| JanC | sure it's not UUID instead of PARTUUID ? | 17:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| manjo | apw, AH! I found a bug ... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801154 | 17:10 |
| ubot5 | Debian bug 801154 in initramfs-tools "[debian] initramfs-tools: add PARTUUID to resolve_device" [Normal,Fixed] | 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:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| manjo | apw, https://bugs.launchpad.net/initramfs-tools/+bug/1531928 | 17:26 |
| ubot5 | Launchpad bug 1531928 in initramfs-tools "[Xenial] root=PARTUUID=<partuuid> is not recognized as valid syntax." [Undecided,New] | 17:26 |
| 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? | 17:50 |
| apw | dobey, hangs hard with no output? have you tried sysrq ? | 18:04 |
| 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:05 |
| JanC | IME the Intel video drivers are really badly tested | 18:08 |
| 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:09 |
| JanC | PrtScr ? | 18:10 |
| dobey | i have a happy hacking lite 2 | 18:10 |
| 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:11 |
| dobey | ah, ok, found prntscr | 18:12 |
| dobey | https://mjbdiver.files.wordpress.com/2011/09/304964-full.gif | 18:13 |
| dobey | hah :) | 18:13 |
| === neunon_ is now known as neunon | ||
| === bdmurray_ is now known as bdmurray | ||
| === mjg59` is now known as mjg59 | ||
| === swordsma- is now known as swordsmanz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
