[01:11] ubiquity: cjwatson * r2818 ubiquity/ (debian/changelog ubiquity/filteredcommand.py): [01:11] ubiquity: Fix mysterious crash if a debconffilter doesn't get started for some [01:11] ubiquity: reason (LP: #125538). [04:17] usb-creator: evand * r12 usb-creator/ (7 files in 5 dirs): [04:17] usb-creator: * Properly set the labels of the progress dialog on install startup. [04:17] usb-creator: * Do not make the dialogs modal. [04:17] usb-creator: * Elevate privileges using gksu. [04:17] usb-creator: * Added a .desktop file (LP: #267788). [08:13] is cdimages.u.c down? [09:00] 02:39 Is cdimage.ubuntu.com down intentionally? [09:00] 02:41 MattJ: http://91.189.88.34/ should get you there [09:00] 02:41 james_w: thank you so much :) [09:00] 02:41 only some of the servers behind cdimage are down, so going directly to one that isn't works [09:17] cjwatson: ta :) Rsync still worked so I got the images I just need to see if they would work :) [09:44] cjwatson: Are you familiar with di-live? [09:44] no [09:44] https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002239.html [09:45] beyond a general awareness that they've gone down a road I investigated and decided was ultimately doomed [09:45] Ah :) [09:45] er, hmm, this doesn't seem to be the same as the live CD stuff based on d-i [09:46] ok, in this case I'm actually not familiar with it at all, sorry [09:46] These people have devised a system for creating live CD's for servery kinds of things, and then use this "di-live" thing to run the installer from that running system. [09:46] It might be worth a look. [09:47] it looks fairly competently done [09:48] they've taken quite a similar approach to ubiquity in some ways [09:49] soren: yeah, I quite like the look of that. Certainly don't reject it out of hand [09:49] you could invite them in here [09:49] Certainly. [09:52] done [10:02] cjwatson would it be feasible to avoid O_DIRECT flags in parted_server? [10:03] did upstream say they couldn't fix it to actually work? [10:04] we could make parted fall back from O_DIRECT to !O_DIRECT [10:05] we can't just drop it - it was added for a reason [10:05] I have asked both szaka and cking but got no reply so far, szaka mentioned in the bug he would add it to the todo list, but I am not sure how long that will take nor if he means honouring O_DIRECT or ignoring O_DIRECT [10:06] fall back will do! [10:06] that should be straightforward [10:06] I doubt it matters much whether it's honoured or ignored, for loopback [10:07] it just needs to be not rejected [10:07] (at least from parted's point of view; I can see why szaka might feel it's hard to do properly) [10:07] that is what I asked him to do indeed [10:08] hmm, open(2) documents that some file systems may ignore it [10:08] sorry, may not implement it - and may fail with EINVAL [10:08] so maybe working around it in parted is actually the right thing to do [10:12] I have opened bug #269947 [10:14] something like http://paste.ubuntu.com/47108/ should do it [10:18] looks good, I could test that tonight [10:19] I'll upload it once I've done some basic testing [10:19] thanks a lot [10:20] oh, hang on, soren already disabled O_DIRECT altogether [10:20] soren: would a fallback not be better? [10:20] Guys give me a ping when you have a working solution that I can test and I'll run it on all versions of windows :) [10:20] cjwatson: That's what I started out with, but Jim Meyering thought otherwise. [10:21] Well, actually some dude from SuSE though otherwise, and Jim agreed. [10:21] really? interesting. so in that case why is the bug still open? :) [10:22] It's not. [10:22] * soren whistles [10:22] bug 252684 [10:23] I'll dup, thanks [10:23] http://lists.alioth.debian.org/pipermail/parted-devel/2008-August/002392.html [10:24] Sorry about the lack of paperwork. [10:25] davmor2: today's image should already have Soren's fix [10:28] cjwatson: cool I'll see how things go then :) [10:28] xivulon: has the latest wubi been included on the cd yet? [10:37] should be rev 507 [10:37] check also that busybox is the right version (ubuntu6 if I recall correctly) [10:38] yes busybox is there too [10:41] ubiquity: cjwatson * r2819 ubiquity/ (apport/ubiquity.py debian/changelog): Add /var/log/casper.log to apport-generated bugs. [10:42] davmor2 all seems in order, please test [10:42] xivulon: Np's I'll give it a whirl after I get some smoke tests out of the way :) [11:31] OK. If you have a casper branch (assuming it's just following trunk, and that you don't have any extra revisions on it), then please remove it and check it out again. [11:32] If you have a non-trivial branch with some unmerged revisions, then please talk to me and we'll get it sorted out [11:39] cjwatson: I've got issues with the display of the new partition viewer on ubiquity [11:41] I'll take an image of it after and post it somewhere so you can see what I mean. [11:52] Hmmm an attempt to configure apt to install additional packages from the CD failed not good :( [12:06] hi, im trying to use ubuntu-installer to install hardy on xen domU [12:06] (as described in here: http://wiki.debian.org/DebianInstaller/Xen) [12:07] the problem is d-i partitioning is not working so I'm looking for a way around it [12:08] i started terminal, created partitions and filesystems, and mounted the rootfs on /mnt [12:09] is there a way do say d-i that partitioning is already done and it can proceed with base system installation? [12:13] yes, but with caveats [12:13] you'll need to mount it on /target, not /mnt [12:13] you will need to create /target/etc/fstab [12:14] with that in mind, edit /var/lib/dpkg/info/partman-base.postinst and put 'exit 0' on the second line [12:14] stuff might go wrong later; this is not a usual path ... [12:14] cjwatson: I will check that, thx a lot! === alonswartz is now known as alonswartz_ === alonswartz_ is now known as alonswartz [12:27] are there any plans for future to make d-i working under xen? [12:32] I thought it was mostly a matter of providing a suitable kernel, but honestly I know very little about it [12:36] soren: I'm one of the developers behind TurnKey Linux, and the author of di-live. I heard you had some questions so I thought I'd drop in here and say hi. [12:55] cjwatson: Any idea why if you try installing ubuntu on the live cd directly (rather than through live session) you get the wrong theme? [12:56] you get the default gnome theme (grey/blue bar etc) [13:07] xivulon: Yay it worked :) Wubi in XP installed :) [13:13] davmor2 good news :) [13:13] davmor2: couple of things to test a) install a new kernel b) see if suspend/hibernation works [13:14] the latter was disabled, but it __might__ be that the 27 kernel supports suspending to a swap file [13:15] you might to enable hibernation manually or run the underlying commands (let me have a quick look) [13:26] apparently uswsusp can support hibernation to a swap file... [13:30] davmor2: I've noticed that it seems to be a sort of halfway house (it's not quite the default GNOME theme, I don't think, but it's certainly not ours either), but I don't know why [13:31] alonswartz: I don't have any specific questions about di-live (I've only had a chance to glance over it), but I noticed there was some inspiration from ubiquity there and it seemed to be rather well-written, so I thought you should be invited in here and that this would be the best place for discussions of it [13:33] cjwatson: thanks for the invitation, and compliment. [13:34] also in case there was anything you were stuck on ... [13:34] Yes, I built heavily on ubiquities design in leveraging d-i code. I originally thought that I would patch ubiquity to support installation from the console, but when I got into the thick of things, I realized that the way to go was modular... [13:35] the reimplementation of main-menu is a nice idea; I did try that sort of approach originally for oem-config (whose general design grew into ubiquity) but found there were too many crossovers [13:35] actually, if I were doing ubiquity over again I'd probably take that kind of approach. The current ubiquity main loop came from Guadalinex' code and I was never very happy with it. [13:36] most of ubiquity's complexity is due to the requirement for a designed UI rather than one generated from the debconf protocol, though. [13:36] I take it you're just using debconf's dialog interface? [13:37] yes, i noticed that. I understand that ubiquity came out of the need for a GUI installer, it was just a pity that d-i got wrapped up in that [13:37] mm, I didn't want to maintain two partitioners. :) [13:37] hehe... [13:37] in the long run it would have been easier ;) [13:37] in fact there were a lot of things where I felt the, uh, business logic was the hard bit and I still feel it's worth not duplicating that [13:38] plus I like d-i and wanted to make use of it. :) [13:38] in the future, it might be an idea to consider seperating the GUI code from the d-i code for maintainance and modular reasons [13:39] re-using d-i code is definately the way to go [13:39] no point in re-inventing the wheel [13:39] I'd like to figure out a clearer way to do debconffilter. I think it's the right general approach but it's undeniably hard to program in. Maybe the problem is that it isn't really testable [13:39] (automatically) [13:40] or maybe the problem is that most programmers have trouble wrapping their heads around state machines [13:41] the reason it's interwoven is that there are lots of cases where we need to advance the d-i code just a little bit (rather than by a whole component) in order to figure out how to update the UI [13:41] the partitioner is the really obvious case, but e.g. keyboard configuration too [13:42] originally I wanted to do it by way of cdebconf custom widgets [13:46] its a really interesting concept - creating a debconf filter layer for interception (and possibly injection), but undoubtably complex [13:49] how did you perform testing, seems to me like a nightmare, especially if you say that auto-testing is out of the questions [13:54] unfortunately most of the testing I did was system testing, just plug it in, watch the debug information, and see if it's driving it the right way [13:54] I don't think auto-testing is out of the question, but I'm not very good at building test harnesses [13:54] the trick is figuring out how to isolate the d-i code, I think [13:55] and instrument the bits you can't isolate [13:55] we've managed successful unit testing of some small bits of d-i, like the kernel selection code in base-installer, but nobody's managed to build a test harness for the partitioner yet [13:56] the usual failure mode with debconffilter is that the d-i code heads off down some path you didn't predict [13:56] one of the barriers i found when coding di-live, was testing. Most of my testing was done in a segregated chroot, but testing the partitioner was done in a vm. I can only imagine the extra hurdles you had to jump over with the debconf filtering layer... [13:59] have you thought of any other approaches than the filtering layer ? [14:01] only custom widgets (i.e. "Type: timezone_map" in a templates file that invokes special debconf plugin, that sort of thing) [14:01] the problem with that is that it tends to involve substantial changes to the d-i code, and you end up basically copying and pasting chunks of it into the GUI plugin since it needs to do much the same job [14:02] so in the end I rejected that idea as not viable [14:06] i have not given GUI interaction much thought, but it seems like an interesting problem to solve, especially the priority of code-reuse [14:14] when performing the copy of the live filesystem, you use /rofs as the source. From what I understand you do this for "maximum reproducability" - have you considered adding the option of copying the overlay aswell ? [14:17] overlay = live overlay (with possibly a white or black list) [14:24] I'm open to suggestions, but I've never seen a way to do it well [14:24] xivulon: it's todays cd and seems to be the most up-to-date kernel suspend failed to restart [14:24] mostly people want to copy user-level customisations and such, and those aren't just a matter of copying the overlay in a desktop environment; the username is different, and gconf has a habit of embedding the username into its database as well [14:25] so it would have to be quite a sophisticated operation [14:25] it's possible that it would work better in serverland [14:28] its a feature that i plan on working on in near future for di-live. implementing it in serverland should be easier though. [14:30] besides for user customizations, did you come across any instability issues regarding certain live content that you *don't* want in the installed system ? [14:32] well, the thing to be careful of with copying the live overlay is that the user's quite able to change files in e.g. /usr [14:33] you definitely can't copy the whole overlay, because it includes the customisations made by casper to make the system bootable as a live CD; you don't want those on the installed system [14:33] so you have to be selective. The easiest way to be selective is just to copy things in /home [14:34] then what if the user upgraded a package from backports (not that uncommon) on the live CD, and used it? That could easily result in data in /home that the installed system can't read, unless you figure out how to copy everything except for casper's modifications [14:35] at some point of course you might decide that you don't care, but I didn't want to have to deal with the sort of wildly complicated bug report that this could result in [14:35] I figured KISS was the way forward :) [14:37] davmor2 did it use to work on your machine/vm in 8.04? [14:37] i suppose it depends on what the objective of copying the live system state to the hard disk would be. [14:38] xivulon: can't remember I think it worked on the intel based machine I'll try it on vista after and see [14:38] in the case of a server type appliance the user might want to test out the system live, maybe configure a database, install or configure a cms or what ever, and then decide thats what he wants. it would then be nice to have the option whether to install the vanilla system, or the customized system [14:39] right, I agree that the appliance case is very different [14:39] i suppose its a all or nothing situation, if the user installs packages, customizes configurations, etc. then you have to take all the data across [14:39] one approach would be to extend casper to be able to reverse all its modifications reliably [14:40] we have highly customized casper btw, so its not really an issue [14:40] oh, of course you also have to figure out how to reliably remove di-live itself from the target system; the ease of that depends on how many dependencies it has [14:41] in ubiquity's case we remove it using python-apt, which is easier since we know the state of the copied filesystem [14:41] nice catch, its on my todo list... [14:42] don't you do i diff of the installed packages and the manifest, or something like that? [14:43] we do a diff of two manifests [14:44] you could do it even if further packages had been installed if you were careful; only resolve problems by removing packages if those packages are in the diff between the two manifests [14:46] can you point me to the code that uninstalls ubiquity ? [14:50] yes, remove_extras in scripts/install.py [14:51] thanks ;) [14:57] it seems pretty involved. i was thinking of just passing a list of packages to be removed to apt in the target chroot - what am i missing ? [14:58] usb-creator: evand * r13 usb-creator/ (debian/changelog gui/usbcreator.glade scripts/install.py): [14:58] usb-creator: Work around a bug in syslinux wherein it can only find the configuration [14:58] usb-creator: file for the option labels in the root of the device. [14:59] alonswartz: robustness - if you do that and just one of them fails, apt may not remove any of the rest, or may leave the system in some kind of half-broken state [15:00] is their any reason it would fail? the system should be in prestine state, as its a direct copy of /rofs [15:01] and if it does fail, we could intercept the exception - which would then be a bug, and should be reproducable... [15:04] cjwatson: unfortunately i gotta run off to a meeting. it was great to finally meet you, and thanks for the informative chat. i'm sure we'll be chatting soon again... === superm1 is now known as superm1|away [15:28] cjwatson: I thought the landscape-client was being dropped from desktop installs? === superm1|away is now known as superm1 [17:44] cjwatson: fyi, i have tested the latest ISO, and mdadm/boot-degraded fix is verified \o/ [17:44] excellent [17:47] cjwatson: i just thought i'd note that, since I was unable to verify one small part of that, before publication of the updated package [17:59] hey cjwatson. im picking up from last week. http://pastebin.com/d14f645a7 shows how the installer is failing when trying to join the domain using my script as part of late_command. the error is: Error: Unable to start daemon [code 0x00080018]. Is there some reason likewise wouldn't start? Should I try starting it manually even though it says it tried to start it? [17:59] Goosemoose: I'm honestly not sure how much I can help with this. I don't know likewise at all [18:01] Goosemoose: maybe putting 'mount /proc' at the start of your post_install_tasks script and 'umount /proc' at the end would help; it's possible /proc isn't mounted in the chroot at that point [18:03] ok [18:03] ill try that [18:03] i cant find much on preseed and likewise on the forums at all [18:03] I did get this as well: Sep 12 22:18:03 log-output: /target/etc/nsswitch.conf: No such file or directory [18:04] as I was trying to remove the nsswitch.conf so I could wget a new copy. Does this just mean it hadn't been created by that point in the install process? [18:04] did you put /target/etc/nsswitch.conf in your post_install_tasks script, rather than /etc/nsswitch.conf? [18:04] yes [18:04] you shouldn't have done that [18:04] put it back to /etc/nsswitch.conf [18:04] oh, I thought you said everything was installed in the /target dir until reboot [18:04] my mistake [18:04] and I also said that putting 'chroot /target' in front of the call to post_install_tasks was all you needed, and said several times that you shouldn't add references to /target to post_install_tasks [18:05] ahh , very true. sorry about that [18:05] 'chroot /target /post_install_tasks' means, roughly, that everything in the post_install_tasks is implicitly done with reference to /target [18:05] so you don't need to, and shouldn't, refer to /target in there [18:05] yeah i forgot I had changed to do that [19:16] what's that kernel parameter I could pass during installation of the alternate to interrupt the installation at some point, perhaps around early command? [19:17] I don't know of such a thing. You could make your early_command return an error :) [19:21] cjwatson: hm, I thought I recalled something of way to interrupt the installer but I guess there's not much use case for that... and there's an easy workaround as you pointed out :) [19:23] cjwatson: I wrote a nifty little program in C this weekend to check the log file for patterns which I will wrap in a shell script to test for specific phases of the installation [19:23] I'm quite anxious to try it out [21:14] cjwatson, it looks like i got it to join the domain, who knows more about likewise though because it through a bunch of pam errors [21:14] and wont let me login as a domain user [21:44] might someone have a good example of a project using autotools and packaged using cdbs both as a deb and a udeb? [22:03] cr3: wireless-tools ? [22:04] maybe not [22:04] hardwire: heh, doesn't use autotools nor cdbs :) [22:04] I'm not on my game today. [22:04] can't you query the source package lists via those fancy dpkg query tools? [22:05] or grep [22:06] cat /var/lib/apt/lists/*Sources | grep cdbs -B 10 | grep autotool -B 10 | grep Package [22:06] maybe I'm insane [22:06] I'd like to think it's a possibility [22:06] for some reason, DEB_DH_INSTALL_SOURCEDIR only applies to the deb which calls dh_install with --sourcedir but that argument is not used for the udeb [22:11] ok, so cdbs seems to be borked when using DEB_DH_INSTALL_SOURCEDIR. using DEB_DH_INSTALL_ARGS := --sourcedir=$(DEB_DESTDIR) seems to work [22:17] cjwatson: Sep 15 17:38:12 log-output: /post_install_tasks: 14: unmount: not found [22:17] cjwatson: looks like unmount /proc isn't valid. i don't see an error for the mount which is strange [22:27] Goosemoose: shouldn't that be umount? [22:27] evand, that might explain it ;) [22:27] thanks [22:28] no problem [22:29] time to restart and try another network install [23:15] wubi 8.10 seems ok now [23:21] hardwire: grep-dctrl is your friend [23:21] Goosemoose: likewise> don't know, you could try #ubuntu-server [23:21] cjwatson: totally.. I totally forgot the command [23:22] cjwatson, that's where im trying right now