[02:15] <lifeless> cjwatson: So I have a puzzler; grub2 (quantal), 3TB drives, GPT, ef02 + mdraid 1.2 metadata, lvm on that - grub2 doesn't seem to see the md volume (ls doesn't show anything other than (hd*,gpt*) items.
[02:16] <lifeless> cjwatson: AFAICT it *should* all work, the raid is raid6 left symmetric, the diskfilter,mdraid1x,raid6rec drivers are in the core image.
[02:16] <lifeless> cjwatson: I would appreciate some pointers on how to pinpoint why its not working; I don't know if its PEBKAC or a bug - should I file a bug ?
[02:24] <Dimensional> hmm
[02:24] <Bluefoxicy> I guess Chromium was destroying my drive.
[02:25] <Bluefoxicy> iotop said "[jbd2/sdb1-8] was eating 80% of whatever it's measuring
[02:25] <Bluefoxicy> while my drive is cranking and cranking loudly by itself
[02:25] <Bluefoxicy> so I started killing things until it stopped.
[02:26] <Bluefoxicy> This happens sometimes.  The system just decides to do something that hammers a spinning drive, with no explanation.  :|  Don't know if that's a bug or not.
[02:26] <lifeless> blktrace will let you track more details about it down
[02:30] <Bluefoxicy> ah ok
[02:48] <psusi> lifeless, your bios is limited to 32 bit lbas?  what does ls -l show the size to be at the grub prompt?
[03:22] <lifeless> psusi: BIOS shows 3TB in its config, will check ls -l and report back.
[05:54] <lifeless> psusi: 1565563759 sectors
[05:56] <lifeless> psusi: at 512 byte sectors I make that to be 746G which is very bogus, and at 4K (the native size), 6TB, which would also be wrong.
[10:09] <cjwatson> lifeless: perhaps if you can manage to dump enough bits of the disk that I could reconstruct it in a test environment, then a bug would be handy
[10:10] <lifeless> cjwatson: I'll try and trigger it in qemu then
[10:11] <cjwatson> you're right that in principle that assembly should work
[10:13] <cjwatson> debugging this sort of thing by teleoperation takes eons though :)
[10:13] <cjwatson> ideally grub-probe/grub-fstest would reproduce it somehow; if not it would involve an image built with --debug-image=all (or less verbose) and then staring at the output for a while ...
[10:15] <lifeless> cjwatson: psusi suggests that the BIOS may be failing to honour > 2TB LBA BIOS int13h (or whatever the interface is these days) calls
[10:16] <lifeless> cjwatson: ls -l in a grub image on a usb stick does return an odd sector count - doesn't match disk size for either 512 or 4K sector sizes
[10:16] <lifeless> cjwatson: anyhow, I'll fiddle round a few times and see if I can make a reproducable emulated setup
[10:17] <lifeless> cjwatson: how does one use grub-fstest
[10:18] <cjwatson> it's possible, but the 1.2 mdadm metadata lives at the start of the device ...
[10:18] <cjwatson> start with grub-probe, grub-fstest is less interesting most of the time
[10:19] <cjwatson> and I can never remember its interface :)
[10:26] <lifeless> heh :)
[10:26] <lifeless> so grub-probe returns the (AFAIK) correct list of modules - mdraid1x, raid6rec, ext2, diskfilter, part_gpt
[10:27] <lifeless> I think it returns lvm too, I can double check
[10:28] <lifeless> sudo grub-probe -t abstraction /boot/grub/
[10:28] <lifeless> diskfilter mdraid1x raid6rec lvm
[10:28] <lifeless> ext2 from the fs probe
[10:30] <cjwatson> which indeed suggests that it's understood the device well enough to parse the fs
[10:30] <lifeless> while the array was rebuiling that would fail
[10:30] <lifeless> I saw a bug report in debian about that though
[10:30] <cjwatson> anyway, sorry, I have to go and do family stuff - like I say if you want me to debug it it's probably better done asynchronously by way of dumps of disk metadata
[10:30] <lifeless> yeah
[10:31] <lifeless> I'm not sure what disk data you want though.
[10:31] <lifeless> e.g. first <x bytes> of the drive + each partition ?
[10:31] <cjwatson> where x is say 2^20, yeah
[10:31] <cjwatson> that's usually enough
[10:31] <lifeless> ok, I'll file a bug and arrange that
[10:32] <cjwatson> ta
[10:32] <lifeless> hmm, that may pickup some user data too
[10:32] <lifeless> I'll make it a private bug i think, though I will eyeball it for personal stuff.
[10:32] <cjwatson> well, the md data's fairly close to the start.  64KB is probably enough
[10:33] <lifeless> ok; if you need more I can add that later
[10:34] <lifeless> I will probably file it tomorrow - thanks for the chat.
[14:37] <jtaylor> is it intentional that phonon-backend-gstreamer and libphonon-dev are not coinstallable?
[14:37] <jtaylor> seems somewhat weird
[14:40] <jtaylor> ok seems intentional phonon-backend-null has Conflicts: phonon-backend
[14:40] <jtaylor> weird
[14:40] <jtaylor> so how to fix pyside now
[17:56] <hyperair> when should an arch: all package be marked as m-a: allowed rather than foreign?
[18:19] <JanC> slangasek / wookey / lool : ^^^ sounds like a question one of you can best answer (as you were involved in creating the multiarch spec :) )
[19:27] <shadeslayer> is there a channel for ubuntu touch development?
[19:30] <shadeslayer> I keep getting : http://paste.ubuntu.com/5559201/
[19:33] <JanC> shadeslayer: there is #ubuntu-touch & #ubuntu-phone
[19:35] <shadeslayer> ack
[19:51] <slangasek> hyperair, JanC: when it's a package like 'python', which exists as an abstraction over python2.x which itself provides both architecture-dependent (extensions) and architecture-independent (interpreter) interfaces
[22:28] <jbicha> I believe uploads are broken, I mentioned it on #launchpad but it's the weekend and SCALE and everything https://answers.launchpad.net/launchpad/+question/222660
[22:29] <tumbleweed> uploads are overrated :)
[22:34] <elmo> jbicha: try now, please?
[22:40] <jbicha> elmo: sftp uploads don't seem any different but I think ftp uploads are working now