[00:11] ubiquity: cjwatson * r3514 ubiquity/ (debian/changelog scripts/check-kernels): Install kernel headers to match the kernel (#413135). [00:57] ubiquity: cjwatson * r3515 ubiquity/debian/changelog: bump to 2.0.0 for Ubuntu 9.10 === NCommander is now known as NC|G1 === NC|G1 is now known as NCommander [03:05] debian-installer: cjwatson * r1192 ubuntu/ (10 files in 3 dirs): Move to 2.6.31-14 kernels. [08:32] evand: any chance of adding a help button to usb-creator? [08:33] evand: or rather, usb-creator-gtk [08:38] wubi: Agostino Russo * r157 trunk/ (debian/changelog src/wubi/backends/common/backend.py): Use ext4 by default (lp: #444214) [09:12] mdke: sure [09:15] evand: Morning, do you know if any changes have gone in to stabilise wubi at all, is it worth testing today? [10:30] davmor2: none that I've made. Remind me what the exact problem you're having is? [10:34] usb-creator: evand * r234 trunk/ (4 files in 3 dirs): Add a help button for the GTK+ frontend. [10:37] ^ rgreening_ I'm not making that change for the kde frontend as kubuntu-docs does not have the relevant usb-creator pages. [10:37] evand: it will randomly work and randomly not. It leaves no errors in the logs, everytime seeming to say it successfully installed. [10:37] define randomly not [10:37] 1 in 9 install correctly [10:38] but you get no idea if it will or not until it does or doesn't [10:38] right, but in terms of it failing [10:38] what happens [10:38] where does it fail [10:38] what do you see [10:38] etc [10:40] multiple issues mostly with grub. you can drop into grub sh:_ or No wubildr on a partition error or occasionally it sails through === dpm_ is now known as dpm [11:50] woo 4.27MB/s to cdimage. [12:26] debian-installer: cjwatson * r1193 ubuntu/ (3 files in 2 dirs): Move Dove images to 2.6.31-208 kernels. [12:27] debian-installer: cjwatson * r1194 ubuntu/ (build/config/armel/imx51.cfg debian/changelog): Move iMX51 images to 2.6.31-105 kernels. [12:28] where do bug reports on the 'alternative' debian install program go? package debian-installer seems to be something different according to the description. [12:30] debian-installer is correct. [12:30] which documentation [12:30] ? [12:32] debian-installer: cjwatson * r1195 ubuntu/debian/changelog: releasing version 20081029ubuntu68 [12:33] you want the description i mentioned? I've lost it. i don't find it again. "You are in a maze of twisty passages, all alike." === TheMuso` is now known as TheMus === TheMus is now known as TheMuso [12:50] wekt: do you mean 'apt-cache show debian-installer'? that's about the binary package, which is a bit different. /ubuntu/+source/debian-installer is the right place to file d-i bugs in Launchpad, anyway. [12:51] hello all - would this be the right place to enquire about live cd customisations? i've spent three days getting increasingly frustrated :) [12:52] sdh: in some cases yes, we may have to redirect you depending on the details [12:54] cjwatson: great thanks. i'm basically trying to make a few adjustments to the stock jaunty desktop i386 cd (as per instructions at https://help.ubuntu.com/community/LiveCDCustomization). specifically i am apt-get dist-upgrading the chroot and then installing lvm2 so i can use the resulting cd to rescue some of my servers (that run lvm). the trouble i'm having is - i think - that the initrd is getting confused. boot fails. i have tried mkinitramfs -o /initrd [12:55] comparing the original initrd with mine i notice teh original has a conf/uuid.conf - but it all seems a bit mysterious [12:55] :) [12:56] if you know enough to help, or can point me in the right direction, i'll basically love you forever :) [12:58] hmm, sounds as though maybe you've removed the casper package? [12:58] oh, no [12:58] nope, heh :) [12:58] try, in the chroot: sudo CASPER_GENERATE_UUID=1 update-initramfs -u [12:58] ooh :) [12:59] that might help, or it might simply get you onto the next problem along [12:59] thanks - humour me, this takes a while to rebuild everything [12:59] also https://wiki.ubuntu.com/DebuggingCasper [12:59] ooh useful, thanks [13:00] back in a few mins then [13:00] base-installer: cjwatson * r385 ubuntu/debian/changelog: releasing version 1.102ubuntu2 [13:01] cjwatson: that command generated /boot/initrd.img-blahblah in the chroot, as opposed to /initrd.gz - do i need to fix that? i am a bit confused about how the squashfs, iso and casper all sit together to be honest [13:02] you'll need to take that /boot/initrd.img-* and put it wherever the initrd actually gets booted from [13:02] or will it be ok so long as i copy it from inside the chroot (squashfs) into casper/initrd.gz [13:02] strictly speaking I think we move it to save space [13:02] ok i think that's casper/initrd.gz [13:02] but copying would be fine too [13:02] yes [13:02] thanks.. [13:03] cjwatson: If you have a minute? Would you mind having a skim over bug 450214? Its to do with the alternate installer hanging when attempting to format a swap partition on powerpc. If you can possibly give me a pointer to where I might start looking, I am happy to find the bug and try to fix it. [13:03] Launchpad bug 450214 in partman-base "Parted server appears to hang when attempting to format a swap partition on powerpc." [Undecided,New] https://launchpad.net/bugs/450214 [13:03] TheMuso: ok, just trying to deal with bug 434173 at the moment but I'll queue that up for afterwards [13:03] Launchpad bug 434173 in language-selector "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [Undecided,Fix committed] https://launchpad.net/bugs/434173 [13:04] cjwatson: As I said, only if you have a minute. [13:04] I completely udnerstand that there are more important things to address. [13:04] cjwatson: for info the uuid comes out differently in the chroot-generated version vs the original - that ok? [13:05] cjwatson: i'm not actually sure what that uuid is for [13:06] squashfs rebuilding... [13:10] cjwatson: i'm guessing the uuid.conf should contain the same as .disk/casper-uuid-generic [13:10] this is far more complex than i had given it credit for [13:11] sdh: the reason for the UUID is so that we can reliably match up the initrd with the squashfs on disk [13:12] cjwatson: sorry, can you elaborate? [13:12] sdh: we can't just look on the CD drive, since there are live USB sticks etc., and there are special cases like people copying live CDs to partitions on the hard disk to act as recovery images [13:12] i think this is precisely the problem i am having [13:12] so we need to make sure that we've actually found the right image [13:12] roger that [13:12] i think that's why it broke when i added lvm support perhaps [13:12] because it saw the lvm disks and tried to mount the wrong one [13:13] not sure. [13:13] conf/uuid.conf in the initramfs needs to match /.disk/casper-uuid-generic on the CD [13:13] cool ok thanks, i'll set that up now [13:13] cjwatson: very much appreciate your help [13:13] this is a rather dark art [13:13] the casper-new-uuid program may help [13:14] TheMuso: wasn't implying anything about importance, just an indication of what I was already doing :) [13:15] righto [13:27] cjwatson: ok this version works, but doesn't have lvm support - i'll try adding that now and let you know how it goes [13:37] god, mksquashfs is painfully slow [13:41] ok cjwatson it fails... :( [13:42] cjwatson: first error on the boot screen is "cp: cannot create '/root/var/log': no such file or directory [13:42] etc [13:42] no init found ... you get the idea [13:43] that's on the box which has an install of ubuntu already (on lvm) [13:43] booting on a blank box (no install) it works just fine [13:43] this is essentially the problem i've been grappling with for 3 days now [13:44] from casper.log: running /scripts/casper-premount (done, done).. then [13:45] /init: line 1: cannot open /dev/sr0: no such file~ [13:46] sdh: Is it a custom kernel? [13:47] sdh: i.e are you using a custom compiled kernel? [13:48] TheMuso: no, it's from apt-get dist-upgrade inside the squashfs [13:48] hrm ok [13:48] because no /dev/sr0 means either no rom drive found, or no sr_mod module loaded, although the ubuntu kernels have that built in. [13:48] what is /dev/sr0, sorry [13:49] oh, should it be the initrd? [13:49] Its the device node used to access CD/DVD drives via the SCSI subsystem in the kernel [13:49] ah hm [13:49] sdh: Have a look in /proc/scsi/scsi to see if anything relating to your CD drive is there. [13:49] TheMuso: i'm booting off usb [13:50] well actually tell a lie [13:50] Note that most IDE and all SATA chipsets use tehe SCSI subsystem in the kernel these days [13:50] i'm booting off an iso in vmware [13:50] Oh and USB [13:50] so "cd" [13:50] Right [13:50] TheMuso: i've got it down to this: [13:50] USB, SATA, and most IDE drivers now use the SCSI subsystem in the kernel [13:50] TheMuso: if i create a blank machine with no install, the "cd" boots just fine on that [13:50] TheMuso: if i boot it on a box (same hardware) with an existing ubuntu install, it doesn't boot [13:51] sdh: Have you run through the initramfs with debugging enabled? [13:51] TheMuso: no, how do i do that? [13:51] There is a command-line variable that can be given on the kernel command-line. [13:52] Can't remember what it is off hand however., [13:52] i'll try debug [13:52] I think "debug" will log to a file, "debug=anything" will log to the tty [13:53] ok it dropped me to (initramfs) without seeming to do anything before hand [13:53] can i single step from here? [13:53] don't think so [13:54] this is a real nightmare i must say :) [13:54] i thought this would be easy, ha! [13:54] Make sure that you pass everything else to the kernel as you would normally but add debug at the end [13:54] TheMuso: that's what i just did - i'm at (initramfs) minus the errors (because presumably it's dropped me to the shell before doing its stuff) [13:55] Ok, try debug=vc, vc can actually be anything, but =something means log to the tty [13:55] oh and use nosplash so you don't get a splash, and get the terminal [13:55] i have taken off splash and quiet, always do [13:56] ok that did what i expected [13:56] i.e. gave me lots of debug [13:57] right [13:57] basically the first error is a failure to mount /dev on /root/dev and it all goes wrong from there [13:57] but im sure that's because something to do with /root is wrong [13:57] you probably need to log the debugging to a file and get the file somewhere else to look at it [13:58] yeah im scrolling through on the terminal === robbiew-afk is now known as robbiew [14:01] basically i know the problem is to do with the box having lvm partitions [14:01] but i can't get past that [14:03] sdh: No idea at this point sorry. [14:04] that's ok thanks for the help [14:04] maybe cjwatson can shine some light on it when he gets back [14:07] it's on the DebuggingCasper page I linked to earlier [14:07] debug) [14:07] oh, sorry, my scrollback was lagged ... [14:09] my next recommendation would be to boot with debug (not debug=vc), and when it eventually crashes out to a shell, mount a real filesystem somewhere and copy /dev/.initramfs/initramfs.debug to it - then reboot so you have networking, and put that file somewhere we can see it [14:10] TheMuso: I can't figure out from the logs why it would be failing at just that point; it's obviously right after a ped_timer_reset but I can't see where that could happen. I think the next step is to run the install afresh, but capture what parted_server is doing across that time interval using strace [14:10] cjwatson: Ok. [14:16] cjwatson: So should I intercept the call to run parted_server and run it through stracem, logging to a file? [14:16] s/stracem/strace/ [14:19] TheMuso: no need for that, just let it start normally and then, just before you tell partman to commit, get the pid of parted_server and run 'strace -o /tmp/parted_server.trace -s 1024 -p whatever-the-pid-was' on tty2 [14:20] cjwatson: ok great. [14:26] Ok no change, retrieving the trace file for further examination. [14:35] cjwatson: I'll see if I can find anything, but I've attached the strace log to the bug in case you're interested. [14:48] hrm can't see anything that stands out, but my strace experience is limited. [14:49] Anyway, gotta sleep, back in 7 hours or so. [16:26] davmor2: next time you test wubi, could you please try adding this boot parameter to wubi's second stage (i.e. after the initial Windows bit and the reboot): [16:26] partman/default_filesystem=ext3 [16:26] cjwatson: sure [16:26] I'll fire up a run now [16:29] based on a hunch that maybe it's not NTFS that's the problem at all [16:47] cjwatson: didn't wubi already create ext3 partitions up until today? [16:52] cjwatson: https://steve.st/tmp/initramfs.debug [16:52] i welcome your thoughts ;) [17:06] evand: I don't think so [17:07] evand: it just uses partman-auto's defaults, as far as I can tell, which were ext3 in jaunty but (as you know :-) ) ext4 now [17:07] cjwatson: Am I planting your line after the rootflags=syncio or after the initrd line? [17:07] so I'm thinking that might account for a change in reliability from jaunty [17:07] davmor2: the former [17:08] davmor2: but not on a line by itself [17:08] davmor2: put it on the same line as rootflags=syncio, at the end, with a space before it [17:08] yeah I got that bit figure thanks :) [17:08] just checking :) [17:09] cjwatson: src/wubi/backends/common/backend.py looks like it wrote filesystem{ ext3 } up until today. [17:09] but perhaps I'm just misreading all of this [17:09] sdh: hmm, whoops, I forgot about one bit - you'll need to extract /casper.log in the same way [17:09] evand: oh, hmm [17:10] cjwatson: heh, ok. [17:10] in that case maybe I am barking up the wrong tree [17:10] cjwatson: running now [17:10] davmor2: given what evand just pointed out, this is probably a waste of time :( [17:10] cjwatson: with debug? [17:13] cjwatson: https://steve.st/tmp/casper.log [17:16] cjwatson: im struggling to get past this tbh - i might have to resort to knoppix but not sure that would be any different and i am more familiar with ubuntu (or so i thought!) [17:19] sdh: so you've run into a particularly broken piece of code, but the good news is that your problem has at least been worked around in karmic, and you can apply the fix to your customised image [17:19] that seemed to work cjwatson but I'll try again and see if it was just a fluke [17:20] sdh: I'm just digging out the patch for you [17:20] davmor2: hmm, now that is doubly odd :-) [17:20] cjwatson: oh cool, thanks - i'm keen to see this :) [17:21] cjwatson: could just be the kookiness of whether it installs or not that's why I'm retrying. If it works a second time I'll try it on kubuntu [17:22] if it works then the next stage is to figure out *why* :-) [17:25] sdh: http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/706 - the scripts/casper bit of that can be applied to /usr/share/initramfs-tools/scripts/casper, and then you do the initramfs rebuilding dance again [17:26] heheh. [17:26] cheers, let me see [17:27] that's in... the initrd? [17:27] my mind is about to explode ;> [17:43] cjwatson: second run=fail :( [17:45] cjwatson: this isn't going to be something daft like a flaw in the loop module is it? [17:48] I've requested that all the "ubiquity explodes nearly instantly after pressing install" bugs that I'm aware of try libwebkit from my ppa. Fingers crossed. [17:49] cjwatson: ha, good one - that seems to have done it [17:52] hmm thanks [17:52] is that fixed to the same extend in the karmic beta? [18:04] sdh: no, it was fixed after the beta release; it's fixed in current daily builds [18:04] davmor2: no dea [18:04] idea [18:04] seems a bit of a stretch === djsiegel2 is now known as djsiegel [18:22] cjwatson: that's why I said daft :) [18:33] cjwatson: thanks for your help === rbelem_ is now known as rbelem [19:26] hey, i'm having a problem using floppy preseed in karmic beta1 [19:28] i saw that there's been a change in the file-preseed package regarding floppy support [19:35] ah, it looksl ike mountmedia floppy isn't working because the only thing on the floppy is preseed.cfg [19:35] sdh: no problem [19:36] joshk: must admit it's something I'm entirely familiar with; if you track it down I'd be happy to apply fixes ... [19:36] entirely UNfamiliar [19:36] yeah, i'm getting there [19:36] at least once I unbreak my laptop [19:38] oh man, this fix is totally broken [19:38] http://triplehelix.org/~joshk/mountmedia_0.19_0.19ubuntu1.diff [19:39] "WANTDRIVERINJECTIONDISK" should have a $ in front of it [19:39] let me see if that does the trick... i'm live in a VM and i should be able to make the change and rerun it [19:39] that did it. [19:40] should I file a LP bug? [19:40] it's really a 1 character change.. the preseeded install is going fine now [19:42] are all disks/partitions supposed to be automounted on the live CD? [19:43] joshk: please file a bug if you could so that I have an audit trail, but I can apply that as soon as I resurrect my laptop [19:43] tormod: IIRC we ended up with a general consensus of "no" [19:43] cjwatson: okey doke [19:43] assign to you? [19:44] please [19:44] cjwatson, sounds smart, but today's daily does [19:45] tormod: likely to be a desktop bug, though? [19:45] cjwatson, it does not on my up-to-date install for some reason [19:45] (a) I don't think casper's responsible for any of that, except maybe turning things off, and (b) desktop components should really not be doing that by default [19:46] unless there's some crackful bug I've forgotten [19:46] looks like c) then :) [19:47] any hints to what I can check? [19:47] cjwatson: LP 451536 [19:47] Launchpad bug 451536 in mountmedia ""mountmedia floppy" minor typo in driver injection floppy support" [Undecided,New] https://launchpad.net/bugs/451536 [19:47] haha, just beat the bot [19:48] joshk: fixed, thanks [19:48] the bot responded to you [19:48] oh [19:48] neato [19:49] cjwatson, thanks for changing the seeds yesterday for partman-uboot. I take it now I need to extend ubiquity to use partman-uboot, right? [19:49] (or do you want to handle that?) [19:50] NCommander: I don't have cycles, please go ahead if you want it to happen [19:50] cjwatson, sure, I'll take it point on it, and hopefully finish it before Firday [19:52] cjwatson, about dmraid support in Ubiquity: now that dmraid is pretty well integrated on the Desktop CD, the biggest issue is that I have to create /var/lib/disk-detect/activate_dmraid otherwise the partitioner will search for and display everything on the hidden raw devices [19:52] cjwatson: awesome.. will there be a beta2 of karmic? [19:53] joshk, there's soon RC... [19:53] ah, RC? cool. [19:53] what the man said [19:55] tormod: the fugly quick solution would be to copy that chunk of hw-detect to a script that ubiquity runs just as the partitioner starts, so that it can actually ask the question (which IIRC is important in some corner cases) [19:55] tormod: though interestingly when I tried this quickly in kvm it all seemed to work for me out of the box ... [19:56] cjwatson, what corner cases? if somebody has fakeraids they do not want to use the raw devices [19:56] tormod: tell that to the people who've complained about this assumption ;) [19:56] otherwise they can boot with "nodmraid" and be wonderfully on their own [19:56] tormod: usually the corner case is that somebody has some dmraid metadata lying around but they aren't actually intentionally using dmraid [19:56] i.e. the dmraid tools get it wrong [19:57] and I think a kernel parameter is too undiscoverable here [19:57] dmraid tools get it wrong usually means the user has done something bad [19:57] that's as may be but I don't want that to become the installer's problem [19:58] the current situation is that "good" users might get into trouble [19:58] I want to handle both [19:59] what chunk of hw-detect are you referring to? [19:59] the bit in disk-detect.sh that creates activate_dmraid [19:59] I'm copying it over now [20:02] well my clear opinion is that if dmraid has correctly hidden raw partitions away, the installer should not fish them out again. I think a kernel parameter is a light punishment to the people setting up invalid configurations [20:02] and my clear opinion is that anything with a risk of regressions at this point isn't something I want to perpetrate; and I *know* this has been a thorny area in the past. [20:02] but I do want to get this fixed if possible, so I prefer a safe course [20:02] furthermore I insist that d-i and ubiquity have consistent behaviour where possible [20:03] (and reasonable) [20:03] I am not sure what d-i is doing nowadays [20:03] it's acting as I described [20:03] it asks before activating dmraid [20:04] ok, if you get that question into ubiquity I will be happy [20:04] but at one point we have to stop encouraging people running broken setups [20:05] mm, but I'm the sucker who has to field the problem reports when things go wrong [20:05] they will fail in the future when the dmraid starts to autosync for instance [20:06] bug 279288 describes data loss caused by not asking [20:06] Launchpad bug 279288 in partman-base "User interface exception request: Ask the user if they wish to activate dmraid arrays." [High,Fix released] https://launchpad.net/bugs/279288 [20:07] or potential data loss anyway [20:08] and indicates that it's the fault of the BIOS, not of the user [20:08] which makes me a lot more sympathetic to the user [20:08] the thing is that turning off raid in the BIOS does not erase the dmraid metadata.. [20:09] how's a user meant to know that? [20:09] just because the design of dmraid is faulty, doesn't mean I want us to conspire in that faultiness :) [20:10] ubiquity: cjwatson * r3516 ubiquity/debian/changelog: indicate bug closure properly [20:12] well currently we do activate all fakeraids on the live CD, so if the user answers "no" to your new question, then you should maybe deactivate the raid so it does not show up in the partitioner [20:12] currenctly, raid and raw devices show up [20:17] where do we do that? [20:18] udev [20:18] that's unfortunate and may be a serious regression [20:18] I don't think that's new? [20:18] we didn't have dmraid on the live CD until very recently [20:19] the live CD is not meant to affect disks; causing dmraid devices to autosync would be bad. Does it do that? [20:19] well I would not call it regression that raw devices are correctly hidden [20:19] regressions do not necessarily affect everyone [20:19] they do no autosync yet [20:20] many years from that I reckon [20:20] they must never autosync when merely running the live CD, without actively making use of those devices [20:20] that would be counter to the design of the live CD [20:20] without dmraid on the live cd, the live cd is extremely dangerous for us with fakeraids [20:21] please understand that I am trying to satisfy both you and other people [20:21] I understand your point of view, but it is also my responsibility to take other points of view into account [20:21] I am not saying that we need to remove dmraid from the live CD; I think it makes sense there [20:21] I understand, but I dataloss for "my" group is as serious as dataloss for the few others [20:21] s/I/the [20:22] I don't think we need to deactivate dmraid devices to cause them to not show up in the partitioner [20:22] partman-base already takes account of the activate_dmraid flag [20:22] that is sufficient [20:22] but currently the raid shows up, without that flag, right? [20:23] that is the one and only thing that that flag file affects [20:23] it does absolutely nothing else [20:23] actually, no, that's not quite true, it affects grub-installer too [20:24] when I tried, flag on -> hides raw devices and shows raid, flag off -> shows raw devices AND raid [20:24] aha, hang on, I'm misreading the partman-base code [20:24] right [20:25] so I think that will look a bit odd, but people who aren't using the RAID device will probably be OK to go "hang on, that's weird, what the hell is that disk" and they may be confused but as long as they don't use it it won't hurt [20:26] ubiquity: cjwatson * r3517 ubiquity/ (configure configure.ac po/Makefile.in.in): bump to 2.0 [20:26] what happens later in the installation? the raw device partition are hidden by udev, so where does the installation go if someone sets up root on /dev/sda3 for instance [20:27] if they were hidden altogether, then partman wouldn't see them [20:27] so I don't think that can be the case [20:27] they are gone from /dev. does partman go through /sys ? [20:28] I thought that was was taking so utterly long in ubiquity: for partman to sniff through /dev/sda on its own. it does not? [20:29] I mean, it does not do its own partition discovery? [20:30] in my tests here, udev does not hide the raw devices [20:32] oh, though it does hide the partitions [20:32] yes right [20:37] hmm, and 'dmraid -an' doesn't bring them back [20:38] I think the only viable option here is to add nodmraid as an option accessible from the F6 menu on the CD, then [20:39] I'm not happy about this, but I don't see any other way to make it work :( [20:39] the F6 option would be nice, and a note in the release notes [20:40] so indeed that means there's no point asking the question. drat. [20:40] but again: does partman discover e.g. /dev/sda3 and propose it for installation, which fails if /dev/sda3 does not exist? [20:42] well the question could be more of a warning, "dmraid is detected, please reboot with "nodmraid" if this is not intended" [20:42] can't add new translatable text at this point ... [20:42] parted does device scanning [20:42] it does have special dmraid handling; I forget the specifics [20:43] I just noted partman took so long, I have logs if you want [20:44] ubiquity's driving of partman has always been slow [20:44] there's an ancient bug about it [20:45] it's actually intrinsically no slower than the underlying partman code you see in d-i, but it appears longer since ubiquity is basically navigating around partman screens under the hood to construct a unified display [20:45] there's definitely room for optimisation; the trick is to do that without ending up effectively maintaining two partitioners [20:45] I think that parted is observing the existence of /dev/sda and then analysing its partition table (which after all is kind of part of its job) [20:46] but that should vanish if activate_dmraid is set [20:46] that part itself is not actually particularly slow [20:47] LP#441690: Should I try a newer daily and see if this is still happening? [20:47] bug 441690 [20:47] Launchpad bug 441690 in debian-installer "Karmic Server Beta: manual partitioner can't connect to iSCSI targets with HD present" [Undecided,New] https://launchpad.net/bugs/441690 [20:47] yes please [20:48] cjwatson, yes partman is many times faster once activate_dmraid is created [20:50] Nivex: I'm still not sure what's going on with your iSCSI daemon, though, that's weird [20:50] I didn't see that kind of problem [20:51] tormod: precisely N+M times faster where N is the number of raw devices in your dmraid sets and M is the number of dmraid sets, I imagine :) [20:51] I'm zsync'ing the current daily. Hopefully it's gone. It seemed like whatever script wasn't starting the initiator properly. [20:52] oh [20:52] in that case I bet I know [20:52] it works if there is no local hard disk. only breaks when you try to start it from the manual partitioner [20:52] cjwatson, felt like even more :) would be nice to have timestamps in the log... [20:52] hw-detect: cjwatson * r135 ubuntu/debian/changelog: releasing version 1.72ubuntu5 [20:52] ^- helps to upload my fixes [20:53] hw-detect takes a while to get into images, because it needs a reupload of debian-installer [20:54] Nivex: do you think you could try an experiment by hand for me? [20:54] Nivex: boot the installer, and run through it until the hostname prompt; stop there, and switch to tty2 [20:55] Nivex: run 'nano /bin/disk-detect', search for the line that begins 'if db_fget partman-iscsi/login/address', and change that to 'if db_fget partman-iscsi/login/address seen' [20:56] ... actually pretend I didn't say any of that, it's too late and I appear to be having reading comprehension difficulties [20:59] partman-iscsi: cjwatson * r30 ubuntu/ (choose_partition/iscsi/do_option debian/changelog): [20:59] partman-iscsi: Make sure iscsid is running when selecting "Configure iSCSI volumes" [20:59] partman-iscsi: (LP: #441690). [21:00] Nivex: ok, should be fixed by tomorrow's daily build, thanks for the nudge [21:00] partman-iscsi: cjwatson * r31 ubuntu/debian/changelog: releasing version 5 [21:05] ok, I'll try tomorrow's daily and see how it goes [21:05] * Nivex says just as the zsync of today's finishes :) [21:14] hello, am installing Mustajuuri, having problems getting it built with Ubuntu [21:15] was looking for some support especially if anyone has successfully installed the Mustajuuri app before [21:15] http://www.tml.tkk.fi/~tilmonen/mustajuuri/index.html [21:16] dwolfman, this channel is for the development of the Ubuntu installer itself [21:16] oh, so sorry [21:16] what is the user support channel on this server? [21:17] so I don't burst in on anyone else, lol [21:17] ubiquity: cjwatson * r3518 ubiquity/debian/ (changelog control): [21:17] ubiquity: Recommend dmraid to ensure consistent behaviour across Ubuntu flavours [21:17] ubiquity: (it was already present on the Ubuntu desktop CD, but e.g. not on [21:17] ubiquity: Kubuntu). [21:17] nm, will not interrupt, sorry [21:18] ubiquity: cjwatson * r3519 ubiquity/ (3 files in 3 dirs): [21:18] ubiquity: If dmraid devices are active, then create [21:18] ubiquity: /var/lib/disk-detect/activate_dmraid so that partman will exclude slave [21:18] ubiquity: devices, and ensure that dmraid is installed in the target (LP: #90235). [21:19] tormod: hopefully that should take care of it ... [21:19] cjwatson, great! I will test it for real on real devices tomorrow [21:19] I tested it but only in kvm, so yeah, please do [21:19] btw, is grub-installer supposed to work with dmraid as well? [21:19] should do now [21:20] it was busted until relatively recently [21:20] ok, I will test in all tomorrow, clean install, and report back [21:20] s/in/it [21:20] it ought to fall back to grub legacy, since grub2 and dmraid aren't really friends yet [21:20] aha good to know [21:21]