| infinity | BenC: When you get a chance, can you test the new ppc kernel on one or two of your freescale platforms? Seemed happy on my IBM kit. | 02:50 |
|---|---|---|
| === smb` is now known as smb | ||
| smb | infinity, I may do when I could stop holding my breath for some progress by others on other things. Bah! | 07:27 |
| * apw yawns | 07:57 | |
| * ppisati reboot | 08:10 | |
| ppisati | almost | 08:10 |
| apw | smb, heads up ... luks encrypted partitions seem to have a size ... so when you have an fs in an ecrypted lvm one needs to resize the volume, the luks, and the fs | 09:47 |
| smb | apw, nifty | 09:48 |
| apw | i had assumed that it would be 'sizeless' that it would be encrypt data, write to block number +1 | 09:49 |
| apw | and not care how big it is, seems not | 09:49 |
| smb | Hm, there seems to be a resize for cryptsetup plain... not found anything obvious for luks prefix yet | 09:50 |
| xnox | apw: it is sizeless, but it needs a tiny bit of header padding in the beginning. | 09:51 |
| * xnox did a successfully shrank encrypted lvm without causing data loss. | 09:52 | |
| apw | xnox, there is a 'resize' command at the cryptsetup which 'collected wisdom' (read googling) implies you should run that, so e2fsresize smaller, cryptsetup resize smaller, lvm resize smaller | 09:52 |
| apw | xnox, but it sounds like you missed the middle step and still have your data :) | 09:53 |
| apw | smb, do you know what happens if you snapshot an LV and then resize the original smaller | 09:53 |
| smb | apw, no | 09:53 |
| apw | smb, i assume there is a way to take a snapshot and promote it to a full LV with its own blocks ? | 09:54 |
| xnox | well I had: partition -> crypt -> lvm -> volumes. So yeah, i did e2fsrezise, vgresize, and partition resize. I guess i should have used cryptsetup resize =)))))) | 09:54 |
| smb | apw, Sure you can dd it... :-P | 09:55 |
| smb | xnox, vgresize ? not lvresize? | 09:55 |
| smb | hm, eh probably implies | 09:56 |
| xnox | smb: implies, i had enough spare extends. | 09:56 |
| xnox | or whatever lvm measures it's vgs in. | 09:56 |
| smb | xnox, just was wondering about one of the things sounding odd without being clear which. If all volumes are in the vg and that has enough spare extents, one would not need to resize any fs | 09:59 |
| xnox | smb: depends where physically extends are allocated for used volumes. So for me i had ||||||||________|||____|| so I had to move extends in the VG to make it look like |||||||||||||___||______ and then I was able to shrink it to |||||||||||||___|| | 10:01 |
| smb | apw, For that dreaded vg on loop and dd on snapshot bug I would be glad if there was a quick snapshot to full lv (or actually any). But as the snapshot is reference to origin plus delta it is not that simple | 10:01 |
| smb | xnox, Sure that just needed to ensure that all lvs only use extends before the parts you want to reduce. If there is enough free that is just moving some blocks and making the mapping a bit more complex. As long as the lvs can stay the same e2fsresize is not needed. So you had the dm device that crypt produces as a pv for lvm? | 10:06 |
| smb | (just wondering whether that did not also require a crypt resize) | 10:06 |
| xnox | i believe yes. just the default encrypted install which d-i / ubiquity produce. | 10:08 |
| === fmasi_afk is now known as fmasi | ||
| smb | Ah, hm that may actually have been part->lvm->lvs->crypt... (though I would need to do an install again to be sure) Somehow I think it was a bit hard(er) to convince lvm to expect pvs in device-mapper volumes... | 10:17 |
| xnox | smb: there is a single crypt device which contains one vg which has volume for rootfs and a volume for swap. | 10:19 |
| xnox | that's how d-i/ubiquity does it in automatic partitioning. | 10:19 |
| xnox | but one can in the manual partitioning setup the scheme you described. | 10:20 |
| === fmasi is now known as fmasi_afk | ||
| apw | rtg_, i am just prepping a saucy upload, as there is some doubt over the overlaysfs fixes, so i am reving it to v18 | 12:32 |
| apw | (as overlayfs is key for the CDs) | 12:32 |
| rtg_ | apw, ack | 12:32 |
| apw | rtg_, it'll carry your debug change as well | 12:33 |
| rtg_ | that one wasn't all that important | 12:33 |
| apw | nope but it may as well go in, otherwise there is nothing and that is probabally good, so i can just touch test this | 12:34 |
| rtg_ | apw, did 3.10.0-0.7 break the dailies ? | 12:41 |
| psivaa | hello, I reported bug #1195710 that is impacting multi-lvm saucy server installations of today's image | 12:41 |
| ubot2` | Launchpad bug 1195710 in linux (Ubuntu) "'Kernel bug - invalid opcode: 0000 [#1] SMP' is reported at 'Preparing linux-image-extra-3.10.0-0-generic' stage of multi-lvm installations of amd64 saucy server " [Undecided,Confirmed] https://launchpad.net/bugs/1195710 | 12:41 |
| apw | rtg_, i don't think it did, but rather than there be any risk of it being wrong i think i'll update it | 12:42 |
| psivaa | a failed installation is active in one of our servers, aldebaran if anyone would like to look into | 12:42 |
| psivaa | this appears to happen during kernel installation stage | 12:44 |
| apw | psivaa, have we had any good installs on anything today ? | 12:44 |
| psivaa | apw: yes, apart from multi-lvm on amd64 server images, the other server installs are good | 12:45 |
| psivaa | apw: desktop had some other ubiquity issues though | 12:45 |
| apw | psivaa, ok good thanks | 12:45 |
| apw | psivaa, and this only happens on complex lvm installs, what does multi-lvm mean in this context | 12:54 |
| smb | funnily most of that backtrace is about ext4 | 12:58 |
| apw | smb, i know odd isn't it, odd that it only appears on lvm | 12:58 |
| rtg_ | seems like an indirect op's pointer got corrupted ? | 12:59 |
| smb | psivaa, It might help us a lot if you could elaborate in the bug what multi-lvm actually means in the way of setup | 12:59 |
| === fmasi_afk is now known as fmasi | ||
| apw | smb, and only on 64 bit as well | 13:01 |
| === fmasi is now known as fmasi_afk | ||
| psivaa | smb: ok, ill try to include that info | 13:02 |
| * henrix -> back in 15 mins | 13:02 | |
| apw | there is only one BUG in that routine | 13:03 |
| apw | so i guess it has to be that one, which implies we found non-preallocate space on the list to free | 13:03 |
| psivaa | apw: so it appears that this is occurring in i386 as well, saw that on the second attempt. ill update the bug | 13:08 |
| apw | psivaa, but only on lvm, very odd | 13:14 |
| * apw can see no way overlyfs could be in involved in that error at least | 13:17 | |
| apw | psivaa, in hte i386 failure, the same stack trace ? | 13:17 |
| psivaa | apw: yes to my eyes, but please see http://pastebin.ubuntu.com/5807755/ | 13:19 |
| apw | it may be hinting at one layer deeper, but feeling related | 13:20 |
| apw | a slightly different manifestation, but here we are complaiing that osmething on the never allocated list is marked as deleted | 13:22 |
| apw | psivaa, and nothing like this on non lvm testing | 13:22 |
| psivaa | apw: i'm running a couple of more tests just to confirm that. will update once the tests finish | 13:23 |
| rtg_ | apw, want me to wrap up Ubuntu-3.10.0-1.8 while you are messing with that LVM bug ? | 13:30 |
| apw | rtg_, i have pushed the tag, and built some test kernels | 13:31 |
| rtg_ | ok, np | 13:31 |
| apw | and have it ready to upload, so prolly i can just ocmplete it | 13:31 |
| rtg_ | fireaway | 13:31 |
| apw | i have the source package ready to go now, just do this boot test, and touch test overlayfs | 13:32 |
| rtg_ | hallyn, USER_NS seems to be getting close in 3.10. Only XFS_FS is left in the UIDGID_CONVERTED dependencies. Perhaps by 3.11 ? | 13:34 |
| ppisati | brb | 13:35 |
| hallyn | rtg_: perhaps. Dwight at oracle is actually trying to get that done right now, but the xfs folks have some problems... | 13:39 |
| hallyn | most of all, they're wondering what to do with bulkstat | 13:39 |
| rtg_ | hmm, well its getting close to the 3.11 merge window. | 13:40 |
| hallyn | yeah :( | 13:40 |
| hallyn | does anyone here have terrific insights into xfs? | 13:41 |
| hallyn | and its peculiarities? | 13:41 |
| apw | rtg_, do you have saucy linux-meta sitting unpushed ? | 13:53 |
| rtg_ | apw, checking | 13:53 |
| apw | rtg_, ta | 13:53 |
| rtg_ | apw, ok, pushed | 13:54 |
| apw | rtg_, thanks | 13:58 |
| psivaa | apw: no other server installations see this bug not even single lvm. only multi-lvm tests installations are failing. Incidentally only the failing (multi-lvm) installations use "d-i base-installer/kernel/override-imagestring linux-generic-pae" | 13:59 |
| psivaa | all the other installations (which pass) use linux-server | 14:00 |
| apw | psivaa, but in both of those cases linux-generic-pae and linux-server are meta packages to linux-generic, so there sould be no difference in the version running | 14:01 |
| apw | (in saucy) | 14:02 |
| === kentb-out is now known as kentb | ||
| apw | psivaa, so multi-lvm just means use LVM and to split root into various partitions | 14:07 |
| psivaa | apw: yes as far as i understood. | 14:08 |
| psivaa | "d-i partman-auto/choose_recipe select Separate /home, /usr, /var, and /tmp partitions" in multi-lvm as opposed to "d-i partman-auto/choose_recipe select All files in one partition (recommended for new users)" | 14:08 |
| apw | which doesn't sound overly differnet really | 14:09 |
| psivaa | ok, i have run the latter a number of times, 6 in total but could not see the failure | 14:10 |
| apw | and of the multi-lvm ones whats the failure rate there | 14:11 |
| psivaa | apw: 3 out of 4 | 14:12 |
| apw | o.O is all i can say to that | 14:13 |
| apw | psivaa, which image are you testing, so i can test the saem one, and do i see you testing in kvm yes? | 14:22 |
| psivaa | apw: yes that's in kvm and today's saucy server images (20130628) | 14:23 |
| === kentb is now known as kentb-afk | ||
| === kentb-afk is now known as kentb | ||
| * smb -> EOW | 16:26 | |
| === rtg_ is now known as rtg | ||
| * henrix -> EOW | 17:14 | |
| * rtg_ -> lunch | 17:56 | |
| === hggdh_ is now known as hggdh | ||
| * rtg -> EOW | 20:00 | |
| phillw | Hi, a very quick question... Someone installs 10.04 via the netboot / mini.iso from, say, http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/ and then drops a DE onto it. They will get no security updates for the DE, but they will they still get kernel updates? | 20:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!