[01:20] <crimsun> jbarnes: thanks for the heads-up. we probably want to use update-initramfs instead; i'm checking the logic to make sure it does the right thing when -u is used.
[01:21] <crimsun> jbarnes: otherwise we need (duplicated) logic in installkernel :/
[01:29] <jbarnes> crimsun: oh I haven't tried update-initramfs... I mainly just want my kernel "make install" to work :)
[01:31] <crimsun> jbarnes: yes, i've modified the debianutils source package; i just want to make sure -c is the right thing
[01:31] <jbarnes> cool
[07:24] <tjaalton> the recent kernels fail to detect my disks on install
[07:25] <tjaalton> -4.5 was fine
[07:54] <tjaalton> filed bug 314992
[07:54] <ubot3> Malone bug 314992 in linux "jaunty: installer fails to find the disk, worked with -4.5" [High,New] https://launchpad.net/bugs/314992
[13:25] <cjwatson> tjaalton: might be a d-i bug after all (I notice given the comment about ATA modules you made in the bug). I commented
[13:27] <rtg> cjwatson: fallout from config changes?
[13:33] <cjwatson> rtg: just needed to rebuild the installer, as otherwise its kernel and the module udebs it fetched at runtime were skewed. no big deal
[13:35] <rtg> cjwatson: cool. I think I'm about done making big config changes.
[13:53] <tjaalton> cjwatson: it's still the same
[13:53] <tjaalton> should've mentioned that on the bug..
[13:54] <tjaalton> (ie. it's what I used, and no different from ubuntu8)
[13:54] <cjwatson> hmph, ok
[13:54] <cjwatson> will have to poke about
[13:55] <cjwatson> I'm diving down a series of ext4 rabbit-holes today
[13:55] <tjaalton> is it usable on the alternate installer yet?
[13:55] <cjwatson> no, working on it.
[13:55] <tjaalton> cool
[13:57] <cjwatson> partman-ext3, partman-partitioning, parted, klibc ... it's a little bit complex
[13:59] <tjaalton> :)
[14:06] <tjaalton> cjwatson: hum, actually now I can see the disks after all, but I see that parted_devices has segfaulted
[14:12] <tjaalton> so maybe I didn't have ubuntu9 when I thought I had (used se.a.u.c.. silly me)
[14:14] <cjwatson> *parted_devices* segfaulted?
[14:14]  * cjwatson blinks
[14:14] <cjwatson> that program is 91 lines long, not a lot of room for madness
[14:14] <tjaalton> yep, partman-lvm finished probing for lvm, and then boom
[14:15] <cjwatson> can you run 'anna-install strace-udeb' and strace it?
[14:15] <cjwatson> just run it with no arguments
[14:16] <cjwatson> /dev/sda1 on /target type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
[14:16] <cjwatson> not far now
[14:17] <tjaalton> cjwatson: ok, and post the strace somewhere?
[14:18] <cjwatson> yeah
[14:23] <tjaalton> cjwatson: ok here you go http://users.tkk.fi/~tjaalton/foo/parted-devices-strace
[14:39] <cjwatson> tjaalton: ok, thanks, bit of a head-scratcher but I'm looking at it ...
[14:46] <cjwatson> tjaalton: anything unusual about /dev/mapper/rootvg-root that would save me time if I knew about it?
[14:46] <tjaalton> cjwatson: shouldn't be.. what if I wiped it and tried again?
[14:47] <cjwatson> let's not destroy the evidence eh?
[14:48] <tjaalton> ok :)
[14:48] <tjaalton> it was installed using some earlier jaunty installer, can't remember if it was before christmas
[14:48] <tjaalton> the vg has four lv's (tmp, swap, root, var)
[14:49] <cjwatson> what does 'dmsetup table' say?
[14:49] <cjwatson> maybe 'dmsetup table /dev/mapper/rootvg-root'
[14:50] <tjaalton> nothing..
[14:50] <tjaalton> but just dmsetup table shows an entry about multipath
[14:51] <tjaalton> oh right.. gah
[14:51] <smb_tp> tjaalton, You have multipath hw? :)
[14:51] <tjaalton> smb_tp: I do, but not this box :/
[14:52] <tjaalton> so looks like enabling multipath breaks if trying to install a normal box.. I'll try without
[14:52] <smb_tp> Does our multipath use on disk metadata to coalesce the devices ?
[14:55] <smb_tp> That would be quite odd. Oh, hm, wasn't there somewhere a bug about changed scsi_id arguments...
[14:57] <smb_tp> Gos it seems long time ago. IIRC there was a dry-run argument to multipath and you could increase debug level with -v#
[14:57] <tjaalton> cjwatson: so it was "d-i disk-detect/multipath/enable" which broke it after all
[14:57] <smb_tp> That way you would see the callouts done and the results
[14:57] <cjwatson> hm, still bad that libparted segfaults
[14:58] <cjwatson> (one moment ...)
[15:00] <cjwatson> tjaalton: http://paste.ubuntu.com/102202/ might fix it; I'll put that in my next parted upload
[15:01] <tjaalton> cjwatson: ok, I'll try it once it's out
[15:03] <smb_tp> tjaalton, Just to be sure, what line did dmsetup target put out with multipath?
[15:03] <smb_tp> It would be bad if that could cause normal disks to get grouped
[15:03] <tjaalton> smb_tp: one moment, I'll enable it again
[15:04] <tjaalton> smb_tp: it did "steal" the devices, meaning that rootvg-* were all empty
[15:05] <smb_tp> Hm, might be the problem from the past that lvm normally does not scan dm devices
[15:07] <tjaalton> smb_tp: http://paste.ubuntu.com/102204/
[15:07] <smb_tp> Ah ok
[15:08] <tjaalton> hmm, I wonder if I could install it anyway
[15:09] <smb_tp> So enabling multipath put all disks into multipath groups (so it potentially can add more paths later). But its only one target so thats good. The problem is likely that lvm avoids scanning device-mapper devices since tis could be its own.
[15:09] <smb_tp> Does pvscan -vvv give clues?
[15:12] <tjaalton> /dev/mapper/rootvg-root: Aliased to /dev/dm-4 in device cache
[15:12] <tjaalton> etc
[15:13] <smb_tp> But nothing of actually scanning for metadata?
[15:13] <tjaalton> http://users.tkk.fi/~tjaalton/foo/pvscan-out
[15:16] <cjwatson> this is why multipath isn't on by default in the installer, I guess :)
[15:17] <tjaalton> yeah, I need to isolate the preseed option for the relevant hw :)
[15:17] <smb_tp> It definitely looks nt well tested
[15:20] <smb_tp> The main problem is that partitioning a multipath device does not work. So you have to set up partitions before and then let multipath detect those...
[15:20] <smb_tp> This is not the issue here, though
[15:21] <tjaalton> smb_tp: multipath installation works fine :)
[15:21] <tjaalton> I've got one BL406c here..
[15:22] <tjaalton> grub doesn't support multipath yet though, but it only needs one small patch (bug filed too)
[15:22] <smb_tp> I only worked with ESS6K/8K before. :)
[15:23] <smb_tp> To clarify: multipath installation that work: with or without lvm and for which release?
[15:24] <tjaalton> actually, it's without lvm
[15:24] <tjaalton> there were some problems with lvm, mostly about it being unable to clean up an existing lvm setup
[15:25] <tjaalton> on jaunty
[15:25] <tjaalton> some packages should be promoted to main too, now I need to enable universe udebs
[15:26] <smb_tp> Is it more than libvolume-id1 ?
[15:26] <tjaalton> oh, and udev fails to init the devices properly, I need to run kpartx by hand in initramfs
[15:27] <tjaalton> hmm, libvolume-id1 isn't installed on that system
[15:28] <smb_tp> About lvm, you might try to add "types = [ "device-mapper", 1 ]" to /etc/lvm/lvm.conf and see what happens on vgscan
[15:30] <tjaalton> well it's not using lvm atm
[15:30] <smb_tp> Not sure this hit you as well, but we found this to be in universe this morning, but it should be in main by now
[15:31] <smb_tp> Oh, that was meant for the system where multipath steals the volumes
[15:31] <tjaalton> ah
[15:33] <smb_tp> The kpartx problem might be in udev. There should be a online event which should trgger the kpartx. Historically it was an add event but that caused race conditions
[15:34] <tjaalton> so what should I expect after the vgscan? dmsetup table still shows the same as before
[15:35] <soren> vgscan looks at block devices for lvm superblocks. I don't think device-mapper gets told about them until they're activated.
[15:36] <smb_tp> Sigh, might be jsut not enough then. I am a bit rusted here. It could have been a combination of this and filter rules. 
[15:36] <smb_tp> lvm reads the start of the devices- If yu have multipath you get a device-mapper device that is not controlled by lvm
[15:38] <tjaalton> multipath-udeb and libaio-udeb were the ones that should be moved to main for multipath support to work OOTB
[15:38] <smb_tp> I remember you had to be careful that way. The rules had to exclude the nodes created by lvm otherwise you got strange problems when trying to remove lvs
[15:38] <tjaalton> libaio1-udeb that is
[15:42] <smb_tp> Ah, ok. So that is different to our temporary problem this morning
[15:42] <tjaalton> I don't see why the udebs are in universe when the rest of the packages are in main
[15:44] <smb_tp> That might be something to ask cjwatson.
[15:45] <smb_tp> With respect to the vg which is stolen. I might have been misleaded here. From your log I see that mpath0 is scanned inedeed. But sure kpartx was not run, so we only get the full disk and that does not yealt the metadata
[15:46] <smb_tp> So the solution might be to try after running kpartx -a for it. Which should give a mpath0p1
[15:46] <tjaalton> this is inside the installer, the kpartx problem is when it boots up
[15:46] <tjaalton> ah
[15:47] <smb_tp> But still you only have mpath0 which is the whole disk. And the lvm data is on sda2
[15:48] <tjaalton> yeah, so that's why it fails to remove it?
[15:48] <smb_tp> Fail to remove what? Sorry got lost
[15:49] <tjaalton> it installs lvm on top of multipath fine if I remove the existing lvm setup first
[15:49] <cjwatson> tjaalton: which udebs?
[15:49] <tjaalton> cjwatson: multipath-udeb, libaio1-udeb
[15:50] <cjwatson> well, partman-multipath is in universe too ...
[15:50] <tjaalton> ah, that too :)
[15:50] <smb_tp> If you install on top of mpath0 You end up using the disk just without any partitions. Works for the normal disks as long as you don't have IBM zSeries
[15:50] <cjwatson> did anyone ever write a MIR for it?
[15:51] <tjaalton> cjwatson: let me check
[15:51] <cjwatson> if that gets promoted we can promote multipath-udeb and libaio1-udeb at the same time
[15:52] <tjaalton> cjwatson: no MIR wiki, but I've filed bug 309635 (and forgot about it already)
[15:52] <ubot3> Malone bug 309635 in partman-multipath "Please promote partman-multipath, multipath-udeb and multipath-tools-boot to main" [Undecided,Incomplete] https://launchpad.net/bugs/309635
[15:53] <cjwatson> and lool asked a question there by the looks of things
[15:54] <tjaalton> yes..
[15:55] <tjaalton> it got lost in the d-i bugfolder
[15:55]  * tjaalton needs to change the filtering priorities
[15:56] <tjaalton> well, it's perhaps enough to keep it in universe for now, but without grub support it's useless :)
[16:02] <lool> Updated the bug; happy to revisit when we have a group of people with hardware to support the package
[16:02] <lool> cjwatson: Or did you care for other reasons about multipath?
[16:03] <cjwatson> lool: only because tjaalton's asking for installer support and appears to have hardware necessary to test it
[16:03] <cjwatson> (and has been contributing installer tweaks)
[16:05] <tjaalton> tbh I don't know for how long I have the hw
[16:05] <lool> cjwatson: With your d-i hat on, I wouldn't mind you telling me that it's enough to support it
[16:05] <tjaalton> but it's all coming from debian
[16:05] <tjaalton> er, mp support that is
[16:07] <lool> I don't think this is an extremely strong requirement, but I think we ought to be able to test/fix/support packages in main, and it's not clear to me that it will be possible if we don't have a couple of people with the hardware or shared hardware accessible on request
[16:08] <lool> But I agree the package coming from Debian should already be in a working state
[16:08] <tjaalton> it already works on jaunty
[16:08] <lool> tjaalton: I mean over time
[16:08] <lool> I would expect it to work
[16:08] <tjaalton> lool: sure
[16:09] <tjaalton> all they are lacking (like us) is support in grub, which they'll have in grub2 but not grub1
[16:09] <lool> We discussed Grub 2 again at UDS jaunty
[16:09] <tjaalton> yep
[16:11] <tjaalton> got to go now ->
[16:19] <cjwatson> yay, successful ext4 installation
[16:20] <cking> cjwatson: way to go
[16:20] <cking> cjwatson: booting from ext4 too?
[16:21] <cjwatson> yep
[16:21] <cjwatson> ext4 / + swap
[16:22] <cking> cjwatson: yay!
[17:39] <rtg> apw: fixed your jaunty ABI problem
[17:58] <apw> rtg, what did you do?
[17:59] <rtg> started a new release? I guess that wouldn't have changed the ABI. doh!
[18:00] <rtg> never mind
[18:00] <apw> but that _might_ be my issue actually ... hmm
[18:00] <rtg> apw: no, it would still build. you must have added an ABI changing patch?
[18:01] <apw> yeah hmmm arr ooo, but it might fix my new problem!
[18:01] <apw> which is that the module.ignore is not working
[18:03] <rtg> apw: thats 'cause its called 'ignore.modules'
[18:03] <apw> if (-f "$prev_abidir/../modules.ignore") {
[18:03] <rtg> hmm, i guess there is also a modules.ignore. how confusing
[18:04] <apw> and $flavor.ignore.modules
[18:04] <rtg> oh, modules.ignore is a global ignore, not per flavour
[18:04] <apw> yeah
[18:05] <rtg> apw: seems like it ought to just exit.
[18:05] <apw> by doing the new release have you loaded up the abi files too?
[18:06] <rtg> yep, but they ought to be the same
[18:06] <apw> has not the name of them changed
[18:06] <rtg> 4.8 --> 4.9
[18:07] <apw> so when i have the changelog one element earlier am i not missing the abi or something
[18:07]  * apw isn't sure anymore, more actual testing on going
[18:07] <rtg> apw: but you said you're not having ABI issues, you're having module check problems
[18:08]  * apw is scrapping all his results and starting clean rebased on the newrelease and will report back
[19:04] <cjwatson> cking: thanks so much for that grub work, I'd have hated to have to do that - parted was hard enough ;-)
[19:07] <cking> cjwatson: no probs - all I did was coerce in a patch from Quentin Godfroy - so kudos to Quentin really
[20:32] <lool> update-initramfs: Generating /boot/initrd.img-2.6.28-4-generic
[20:32] <lool> mkdir: cannot create directory `/tmp/mkinitramfs_YJPCAT/etc/udev/rules.d': File exists
[20:32] <lool> Is this known?  I couldn't find it on LP
[20:32] <andersk> Yes, bug 314879 
[20:32] <ubot3> Malone bug 314879 in udev "root on LVM broken since latest udev 136-2" [High,Confirmed] https://launchpad.net/bugs/314879
[20:32] <lool> thanks
[20:52] <sconklin> I'd like to invite comments on our plan to detect and report suspend/resume failures: https://wiki.ubuntu.com/KernelTeam/SuspendResume
[21:03] <jbarnes> sconklin: looks pretty good, I like the idea of the status file, that should help
[21:03] <jbarnes> sconklin: one thing I mentioned at UDS was that it would be good if the test-suspend script also tracked time to suspend and time to resume somehow
[21:04] <jbarnes> it should be able to calculate the total time using the timer since it knows when the wakeup should occur
[21:04] <sconklin> jbarnes: thanks. Doing it this way ends up just being some small hooks between various systems.
[21:04] <jbarnes> yeah
[21:05] <sconklin> Agreed - the same component writes and destroys that files, so should be able to put timestamps in and throw a delta into the log.
[21:05] <jbarnes> new platforms seem to be much faster... my x200s resumes in far less time than my t61, mostly due to bios improvements I think
[21:06] <sconklin> I'll add that to the wiki page and make sure apw sees it, since he's working that side
[21:06] <jbarnes> but I think there's lots of room to improve the kernel too, ideally it should be well under 500ms (about the time it takes to open the lid), so tracking time can help
[21:06] <sconklin> That's very useful information to have.
[21:07] <sconklin> well, here we get into the definition of what "resumed" means. Obviously at 500 mS you're not including wireless connectivity, but probably are including window manager fully usable.
[21:07] <jbarnes> right
[21:08] <jbarnes> though hopefully your wifi driver doesn't take 1m to re-associate :)
[21:08] <jbarnes> if you google around you'll probably find some of the visa/whql platform requirements msft put out recently
[21:08] <jbarnes> might be good to link to them or something
[21:10] <sconklin> yeah. The plan is to have this first cut operational by next week, and then see what we need to focus on from there.
[21:10] <jbarnes> cool
[23:39] <maxb> Is anything that linux-backports-modules does special in terms of overriding modules shipped with the default kernel, or does it only work because the modules it ships are not included in the default kernel packages?