[01:55] <cr3> might there be a way to hook into the installer so that when a step in the installation fails, some action can be taken such as sending an email message? of course, this assumes the failing step occurs after network configuration
[02:05] <xivulon> evand, have started the lupin gutsy branch https://code.launchpad.net/~ago/lupin/gutsy
[02:07] <xivulon> so far I only added some patches vs casper to allow finding a preseed on the HD, boot from an ISO, and "remap" windows drives to linux devices within preseed.
[02:07] <xivulon> the code is broken at the moment since I did not have time to test it at all, but at least you can have a quick glance so that we do not overlap
[02:07] <xivulon> I should hopefully have a working version later on tonight
[02:13] <xivulon> The missing bits will probably go into lupin.deb. I added a temporary hook so that the package can be put on the filesystem as opposed to be in the CD.
[02:14] <xivulon> Main content of lupin.deb will probably be 1) remapping of menu.lst paths, 2) sysctl settings to improve fs robustness
[02:18] <xivulon> Main outstanding issues: 1) remounting the loop file rw, 2) grub
[03:47] <xivulon> evand I think I found an elegant solution for the remapping of menu.lst in loopinstallations !
[03:48] <evand> xivulon: great!
[03:49] <evand> cr3: I don't believe there is, at least I don't believe there's a nice debconf key for it.  I'll look into it in a bit.
[03:50] <xivulon> the issue is that when menu.lst is generated the path appers '/boot/vmlinuz' but when menu.lst is used by grub4dos vmlinuz will be under '/ubuntu/disks/boot/vmlinuz'
[03:50] <cr3> evand: at this point, I don't really mind if it's not so nice :) I'm looking into it as well, I'll let you know of my progress... if any
[03:51] <xivulon> it occurred to me that instead of trying to remap from within linux, it would be much easier to ask grub4dos to support a groot_prefix parameter
[03:52] <xivulon> so if you have groot=(hd0,0), groot_prefix=/ubuntu/disks, kernel /boot/vmlinuz
[03:53] <evand> nice
[03:53] <evand> thanks cr3
[03:53] <xivulon> grub4dos would actually first look into (hd0,0)/ubuntu/disks/boot/vmlinuz
[03:54] <xivulon> The only restriction is that when you bindmount, the folder has to be the same name. Hence /ubuntu/disks/BOOT -> /BOOT
[03:54] <xivulon> I have already asked grub4dos devs to add that
[03:55] <evand> and they're receptive to this patch?
[03:55] <xivulon> I just sent the email, by the devs so far have been fantastic
[03:56] <xivulon> Unless they are on holidays I would expect that within a few days
[03:56] <evand> great
[03:57] <xivulon> not sure if you saw https://code.launchpad.net/~ago/lupin/gutsy , it's not great and probably not working, but it's a first go at what we discussed
[03:57] <xivulon> should be ok tonight
[03:57] <evand> I haven't had a chance to look it over yet, but I should find time later today to.
[04:04] <cr3> evand: I can't even find some of the error strings returned by the installer in initrd.gz, any suggestions where to look?
[04:07] <evand> quite a bit gets dumped to syslog, but that doesn't really help if you're just interested in the errors
[04:07] <evand> hrm
[04:07] <evand> oh, or do you mean the log of errors in the initrd?
[04:09] <cr3> evand: I was looking at both the syslog and the curses installer interface. In the interface, I have the string "An error was returned while trying to install" and in syslog I have "base-installer: error: exiting on error"
[04:09] <cr3> evand: I'm trying to find what catches those errors, hoping that I could trap the error somehow
[04:10] <evand> indeed, not sure though.  I'd have to poke around a bit.
[04:10] <cr3> evand: if I can introduce an isolated hack to trap all errors, that'd be perfect
[04:43] <xivulon> evand does ubiquity support initrd preseeding? My code should dump the preseed into the root.
[04:49] <evand> checking
[05:01] <evand> xivulon: you need to specify the location using file=
[05:02] <evand> it will not automatically detect the preseed file
[05:21] <superm1> evand, it would appear that the mythbuntu frontend is stuck in an endless loop on the partitioning step, when using those resize recipes.  offhand do you know what the cause of this would have been (some major changes to the partitioner i'd expect)?  I'll investigate it later on myself to see if i can resolve it
[05:22] <superm1> doesn't occur in the ordinary GTK frontend
[05:23] <evand> superm1: from trunk?  I haven't modified mythbuntu to use the new page handling code yet, as I keep getting caught up in other work.  I'm quite surprised it gets that far.
[05:23] <superm1> Yes evand i merged trunk yesterday and built it on a PPA, tested this morning
[05:23] <superm1> i'll have a look over the page handling code in gtk-ui
[05:23] <superm1> and see if i can adapt it
[05:24] <superm1> mind you that we only have one mythbuntu debconf step
[05:24] <evand> great, that would help quite a bit
[05:24] <superm1> all the earlier steps are simply pages in the GTK notebook
[05:24] <evand> hrmm
[05:25] <superm1> the debconf step occurs right before the partitioner for us
[05:37] <superm1_> ick evand, i might be looking back a few revisions too far, but it looks as though i'm going to have to derivate from ubiquity/filteredcommand.py now?
[05:40] <evand> superm1_: you're probably looking back too far.  You only need to add a set_page function
[05:40] <evand> well, and redo run() and a few other places a bit
[05:40] <superm1_> Okay phew.
[05:41] <evand> latest revision is 2195
[05:41] <superm1_> i was on latest revision, but working my way forward from all the bzr log entries that were related to pages
[05:42] <evand> ahh
[05:42] <superm1_> ah yes i see the upload on 8-20-07 cleans that up
[05:42] <evand> indeed
[05:42] <superm1_> much better
[05:42] <evand> yeah, it was messy at first
[05:42] <evand> I cleaned it up when I realized I broke kde_ui hardcore
[05:42] <superm1_> haha
[05:42] <superm1_> okay well i've got to run to my next course.  i'll let you know when i've got mythbuntu working again then
[05:43] <evand> great, thanks
[05:59] <xivulon> evand, I am not too keen on using file=, since what I am doing is copying from find_preseed=frompath to file=topath
[06:00] <xivulon> So it will be difficult to distinguish when find= is intended as an actual preseed or whether it is supposed to be a destionation_path
[06:01] <xivulon> I mean discriminating the case is pretty easy (just check if there is a file in topath before copying there the preseed file from find_preseed), but this double use makes it a bit confusing
[06:03] <xivulon> At the moment I am copying from find_preseed -> ${rootmount}
[06:10] <xivulon> Hmm my english was quite bad, quite I mean is that file= will end up having a double role of pointing to an existing preseed file and indiacate the destination to which to copy any preseed find via find_preseed
[07:32] <cr3> what part of the installer calls /usr/lib/base-installer/kernel.sh?
[07:33] <evand> cr3: base-installer
[07:34] <cr3> evand: odd, I can't find that script on the filesystem in busybox
[07:35] <cr3> maybe it's just a shell function in one of the installation scripts, but I can't find that either
[07:35] <evand> kernel.sh or base-installer?
[07:36] <cr3> base-installer, I just have it in the cdrom pool and the directory under /usr/lib
[07:37] <evand> If it's loaded, you should have "Install the base system" in the menu
[07:39] <cr3> evand: yep, so I guess it's a shell function. now I need to determine where it's defined
[07:39] <superm1> evand, This warning may be trouble "            # Non-debconf steps are no longer possible as the interface is now
[07:39] <superm1>             # driven by whether there is a question to ask."  Is this only because of the --automatic feature?  If so, then i'll just reimplement around it
[07:45] <evand> superm1: I am probably wrong in that assertion as the first step is a non-debconf step.
[07:46] <superm1> that's right. stepWelcome
[07:46] <evand> but yes, the main reason for the change was to support skipping pages entirely
[07:46] <evand> that may still work as it's somewhat special-cased, I'd have to poke around but I'm currently occupied with another task
[07:47] <evand> special-cased before we enter the loop, that is
[07:47] <superm1> not a big deal, i'll try it, and see if it "Just Works" after the other changes i've put in
[07:47] <superm1> and if it doesnt look more closely at it
[07:47] <evand> ok
[09:41] <xivulon> evand, I am back
[09:42] <evand> xivulon: hi
[09:44] <evand> I'm reading over what you wrote earlier, I'm just having a hard time following it.
[09:48] <evand> I'm not sure what you mean by file= indicating the destination to copy the preseed file.  file= in capser takes the file pointed to, runs debconf-set-selections on it and exists, not anything more.
[09:48] <evand> exits*
[09:52] <xivulon> evand, sorry was doing 2 conversations at the same time
[09:52] <evand> not a problem, there's no rush
[09:53] <xivulon> what I mean is that at the moment I find a preseed file on HD via heuristics using find_preseed and copy it onto / for initrd preseeding
[09:53] <xivulon> What I will have to do to use file=, is to read the value of file= and copy over there the preseed I fetched in the previous step
[09:54] <xivulon> In this context file= is used as a destination path
[09:55] <evand> ohhh
[09:55] <xivulon> No big deal
[09:56] <xivulon> But it might be a bit confusing, if you use file=/path/to/preseed1 and find_preseed=/path/to/preseed2, preseed2 will be copied on top of preseed1
[09:59] <xivulon> provided you are aware of that I am happy
[09:59] <xivulon> There where a few bugs in the code, I can go a bit further in the process now
[10:01] <evand> I'm still confused, but I think it stems from the deeper issue that I'm not getting how this works with read only media like a CD.  How can you possibly place a preseed file there?
[10:02] <xivulon> find_preseed allows you to place preseed2 in the hard disk, but you may have a file preseed in the ISO
[10:03] <xivulon> In fact at the moment there is a file preseed in the iso
[10:03] <xivulon> /cdrom/preseed/ubuntu.seed
[10:03] <evand> indeed
[10:03] <evand> ok, so your concern is over choosing both or between the two?
[10:04] <xivulon> With this scheme find_preseed will always overwrite preseed/file
[10:04] <xivulon> It's not a big deal since the frontend can easily incorporate whatever seed is on the HD
[10:05] <evand> well, casper does it, not ubiquity, but yes
[10:06] <xivulon> That is only an issue if you want to use 2 preseeds, which I think is not a good idea anyway
[10:08] <xivulon> by the way, with the patch, since you can use an ISO on HD, you should be able to use the live initrd for hd-media/netinstallations as well
[10:09] <evand> neat
[10:10] <xivulon> I am uploading a couple of fixes, it does not boot the ISO yet
[10:11] <evand> I'm going to hopefully peruse the code a bit after I finish this other work tonight so I have a much better understanding during these conversations.
[10:11] <xivulon> basically put a preseed in say /ubuntu/install/preseed.cfg, put the iso in say /ubuntu/install/gutsy.iso then use the following boot parameters
[10:12] <xivulon> find_iso=/ubuntu/install/gutsy.iso find_preseed=/ubuntu/install/preseed.cfg
[10:13] <evand> ok
[10:13] <xivulon> That will scan all block devices and use the first file it finds, not 100% safe, but will do for now
[10:16] <xivulon> as mentioned there are still a couple of things to fix, have to go eat something and will try to patch it properly
[10:23] <cr3> evand: so, I found that I can patch individual programs such as bin/apt-install in initrd.gz to report errors without significantly affecting the installer
[10:24] <cr3> evand: but, that's the best I got so far which doesn't cover all the other cases where the installation might fail
[10:25] <evand> cr3: ok
[10:28] <evand> cr3: if I understand correctly, you just want the error itself, right?  Or do you want to be able to jump in when the error happens and respond somehow?
[10:46] <cjwatson> cr3: evand says you're having some trouble?
[10:47] <cr3> evand: the latter, I want to hook into the installer somehow to run a command when an error occurs
[10:47] <superm1> evand, so now if i preseed the debconf questions that would have been asked on a page, does that page automatically get skipped?
[10:48] <superm1> or do i need to do something else too?
[10:48] <cjwatson> cr3: as in whenever debconf displays an error? no hook for that, sorry
[10:48] <cr3> cjwatson: yep. as you know, I have the installation of daily images automated in vmware and now I'm working on reporting problems when there is an error
[10:49] <cjwatson> best you can do is watch the syslog really ...
[10:49] <cr3> cjwatson: would you recommend a place where I can hack a hook somehow? I have been toying with modifying apt-file in initrd.gz, but that only covers errors relating to that command
[10:50] <cr3> cjwatson: hm, so I could have a process reading syslog on a pipe and then reacting when some string(s) is detected
[10:50] <evand> superm1: --automatic
[10:50] <evand> it should only skip the page when --automatic is passed on the command line
[10:50] <superm1> evand, what if i just want to skip a page based on choices chosen in the UI though?
[10:51] <superm1> i had to migrate every one of my pages over to have a debconf step with it
[10:51] <superm1> but still don't want them all to necessarily come up
[10:51] <evand> if you don't call a page's dbfilter, then it wont try to switch to that page.  Alternatively, if a dbfilter has no questions to ask, it wont show a page
[10:51] <cr3> cjwatson: I could then spawn that process from preseed/early_command
[10:52] <superm1> evand, hm.  my run() function may have to be fairly elaborate then.  i'll chew on that for a bit
[10:52] <evand> cr3: cjwatson what about watching the debconf database for errors with the seen flag?
[10:53] <cr3> evand: where's/what's the debconf database?
[10:55] <evand> cr3: /var/lib/cdebconf/questions.dat
[10:56] <evand> arr, nevermind
[10:56] <evand> I should think things through before I blurt them out.
[10:57] <cr3> evand: heh, I just had a look at questions.dat and came to the same conclusion :)
[10:57] <cjwatson> cr3: early_command is reasonable enough
[10:57] <cjwatson> evand: I wouldn't recommend it ...
[10:58] <cr3> cjwatson: the only problem is what strings to search in the syslog
[10:58] <cjwatson> cr3: I was thinking of just having it time out if it stalls with no activity for too long
[10:58] <cjwatson> cr3: at DEBCONF_DEBUG=developer it would sit there stuck at a GO command ...
[10:59] <cjwatson> so conceivably you could spot that
[10:59] <cr3> cjwatson: sounds like a plan, I will try a first iteration and refactor when it breaks down. at least I'm happy not having to touch the existing installer files
[11:01] <cr3> cjwatson: in what language would you recommend I write the script so that it could run from early_command? I'm thinking my only options are C and shell, but I'm not sure I could pull off this kind of logic strictly in shell
[11:02] <cjwatson> C or shell are your only options
[11:02] <cjwatson> whichever you're comfortable in
[11:03] <cr3> both, but reading on a pipe and then breaking out of a loop after a timeout doesn't seem feasible in shell
[11:03] <cjwatson> well, not the timeout, but you wouldn't need that if you did the DEBCONF_DEBUG=developer thing
[11:04] <cjwatson> (and actually it's feasible with a small helper program to send you the SIGALRM)
[11:05] <cr3> actually, I think I can pull it off in shell! quicker to give it a try and then revert to C if necessary
[11:12] <xivulon> cjwatson: I was mentioning to evand earlier that I might have a solution for the problem of different paths whenever menu.lst is generated by linux but used within windows
[11:13] <xivulon> have grub4dos support a groot_prefix argument which gets prepended to the kernel/initrd path
[11:13] <xivulon> I sent an email to grub4dos devs
[11:33] <cr3> darn, my preseed/early_command calls a function with & to set in the background but the installer stalls, it's probably not detaching from the controlling terminal or something :(
[12:02] <xivulon> evand I have uploaded xinit-ubiquity, a simple init.d script based on gdm to start ubiquity automatically. You have to put it in /etc/rc2.d before gdm
[12:02] <xivulon> As usual it's untested and probably won't work yet
[12:06] <cr3> hehe, I found the reason! log-output polls the file default descriptors created by the process!