=== robbiew is now known as robbiew_
=== jtisme is now known as jtholmes
[09:42] <ev> superm1: sorry about that (execute_root).  Thanks for the quick fix.
[09:46] <CIA-15> ubiquity: evand * r3602 trunk/ (11 files in 6 dirs): Additional code cleanup from pycheck findings.
=== cjwatson_ is now known as cjwatson
[10:18]  * ev discovers http://people.canonical.com/~scott/daily-installer/, bounces
=== ev changed the topic of #ubuntu-installer to: Don't ask to ask, just ask (and stick around, we aren't all here 24/7) | http://wiki.ubuntu.com/Installer/FAQ | Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/Installer/Development | If nobody answers, try ubuntu-installer@lists.ubuntu.com | http://people.canonical.com/~scott/daily-installer/
[10:41] <cjwatson> hmm, I don't see what broke from the last couple of entries in daily-installer
[10:45] <ev> hrm, I had assumed Mario's fix landed after that, but apparently not.  Not sure either.
[10:45]  * ev digs
[10:48] <cjwatson> the install seems to have completed, from the logs
[11:07] <ev> reading the logs of the meeting last week.  Did Scott ever share the code for the installer automation with you?
[11:12] <cjwatson> don't think so though I imagine it's mostly glue
[11:12] <cjwatson> not really needed for partitioner work anyway ..
[11:20] <ev> ah, I figured his preseed file would be useful for cases like this where the cause of the failure isn't obvious.
[11:21] <cjwatson> oh, for the partitioner I wouldn't be using automated bootcharting anyway, since the stuff I most want to analyse is manual bootcharting
[11:21] <cjwatson> er manual partitioning
[11:21] <ev> gotcha
[11:47] <cjwatson> ev: administrivia on work item formats: each line needs to end with ": TODO" or ": DONE" or ": INPROGRESS"
[11:48] <ev> ah, I thought empty sting would work, given the comments on the wiki page, but I haven't poked at the code.  Noted, will fix.
[11:52] <cjwatson> hm, don't think so, normally I get a mail whining about the work item format :)
[11:52] <cjwatson> (although in this case I haven't yet)
[12:09] <ev> heh
[12:31] <ev> equally curious is why the daily-live build didn't run today
[12:40] <cjwatson> cdimage has been souped up not to bother running the CD build if all the livefs builds failed
[12:41] <ev> ah, cool
[12:43] <cjwatson> the gnome-games and libdns50 problems should be fixed now, but I wonder what's going on with libesd ...
=== persia` is now known as persia
[13:06] <cjwatson> hmm, the region of light spreading out from the Ubuntu logo in the usplash image is wide enough to overlap the text in the CD bootloader image, although only at a very low intensity
[13:06]  * cjwatson prepares for some careful GIMP work ...
[13:07] <cjwatson> actually, I'm not sure this is my forte
[13:07] <cjwatson> michaelforrest: if I gave you guys pointers to each of the images I needed glued together, could you take care of it? I don't spend very much time with image editing normally
[13:08] <cjwatson> I don't mind about the colour depth or format or whatever of what I get back; I can take care of simple things like cropping and reformatting
[13:15] <michaelforrest> cjwatson: yeah you shouldn't need to get image editing
[13:15] <michaelforrest> cjwatson: can you send me a couple of screenshots so I can see the problem clearly?
[13:17] <xivulon> cjwatson, untangling 477169 which is a bit of a mess as there are probably different issues
[13:17] <xivulon> one is that lupin>grub-mkimage writes wubildr onto the wrong devices in some cases
[13:18] <xivulon> many claim that initscripts update breaks the toy (this is the fix for the umount -f issue), but I fail to see how
[13:19] <xivulon> would not think that triggers a grub-update and/or initrd rebuild at all...
[13:20] <cjwatson> michaelforrest: I can just send you the image files ...
[13:22] <xivulon> others claim that grub cannot access files within the loop image, once those files are re-written
[13:22] <cjwatson> xivulon: I didn't think we wrote wubildr to anything other than the filesystem?
[13:22] <michaelforrest> cjwatson: yeah that's fine
[13:23] <xivulon> cjwatson, we write wubildr to the device containing root.disk, which might not be the boot device...
[13:23] <cjwatson> when you say "device" can you be more clear?
[13:23] <cjwatson> as far as I'm aware we only ever write it to a filesystem
[13:23] <cjwatson> as opposed to the raw disk device
[13:24] <xivulon> if a user installs wubi onto D:\\ubuntu, wubildr will still be on C:\\wubildr, we will try to put wubildr onto D:\\wubildr or exit
[13:25] <xivulon> on the linux side D:\\ will be mounted as /host, and C: will not be mounted at all
[13:25] <cjwatson> oh, really? hmm. Is C:\wubildr just completely hardcoded then?
[13:25] <xivulon> not hardcoded, I save wubildr where there is boot.ini
[13:25] <cjwatson> that's going to be almost impossible for lupin's grub-install to discover :(
[13:26] <xivulon> and if more than one device could potentially be a boot device I put it there too
[13:26] <cjwatson> I don't think I have any idea how to soup up our grub-mkimage substitute to handle that ...
[13:26] <xivulon> in boot.ini you always have to call it "C:" but taht is a bug, as that will actually point to the correct windows boot device, whatever letter that has to be
[13:27] <cjwatson> initscripts update> maybe they got a kernel update at the same time or something
[13:27] <xivulon> well we could replace wubildr on all fat/ntfs partitions that contain one to begin with
[13:27] <cjwatson> I don't see why an updated initrd would cause a problem at all here
[13:27] <xivulon> but I do not think that explains the bug
[13:28] <xivulon> yes even if we fail to upgrade wubildr, that should not cause reboot problems, assuming you could boot beforehand
[13:28] <xivulon> ... unless the insmod in grub.cfg overrides the built-in module ...
[13:29] <cjwatson> should only matter if they're actually different
[13:30] <xivulon> wouldn't that be the case in a grub upgrade?
[13:31] <cjwatson> the only post-release change to grub2 was in shell scripts distributed along with grub2
[13:36]  * cjwatson looks over Mark Abene's patches
[13:38] <xivulon> went there, he basically creates a separate /boot.disk
[13:38] <cjwatson> yeah, no reason not to at least support that even if we don't use it by default, AFAICS
[13:38] <xivulon> so I assumed that it might be an issue with grub ntfs module, due to file size and/or fragmentation
[13:39] <xivulon> true
[13:39] <cjwatson> xivulon: are you ok with http://paste.ubuntu.com/332346/ ?
[13:39] <cjwatson> it's almost certainly an issue with either ntfs or loopback, more likely ntfs
[13:39] <cjwatson> going to be a right pain to track down though
[13:45] <xivulon> cjwatson, patch seems good, do you also need to change grub.d scripts? (GRUB_DEVICE_BOOT)
[13:45] <cjwatson> already done
[13:46] <xivulon> ev got you finally, you changed your nick!
[13:46] <xivulon> cjwatson, another theory is that initscripts introduces a regression that casuses fs corruption, which grub cannot sort out
[13:46] <ev> ah, indeed.  Apologies for the lack of notice.
[13:47] <xivulon> how is wubi-r170 doing?
[13:47] <cjwatson> xivulon: I'm not sure I'd go so far as to say fs corruption, but maybe the filesystem is marked dirty
[13:47] <xivulon> yes that is what I meant
[13:47] <cjwatson> and e.g. journal not replayed or something, if it's not being unmounted properly
[13:48] <cjwatson> grub obviously doesn't know how to replay the journal
[13:48] <xivulon> the ntfs driver proper, can mount it anyway
[13:48] <xivulon> but probably the ntfs inside grub can't
[13:48] <xivulon> yet you can access some files inside of the ntfs partition
[13:48] <xivulon> it is files inside of the loopfile that create problems
[13:50] <cjwatson> that does set off faint improper-unmount bells, I must say
[13:50] <xivulon> is there a sort of dirty-flag per file?
[13:50] <cjwatson> not to my knowledge
[13:50] <cjwatson> but if the changes to some particular file are only in the journal, and not written properly to the filesystem ...
[13:50] <xivulon> well root.disk would be that one file, most likely, which would explain why you can see it but not access content in there
[13:51] <cjwatson> should be straightforward to tell whether the filesystem is marked dirty by rebooting from wubi, booting into ordinary Linux, and asking ntfsinfo or whatever it is
[13:52] <xivulon> can't do that now, ev, davmor2 ^
[13:53] <cjwatson> switching over to using a small boot.disk by default is kind of appealing, but we'd have to decide on sizing for it which is always a pain in the arse
[13:55] <ev> xivulon: I've just asked the IS team for an update
[14:03] <xivulon> cjwatson, the separate boot disk seems to confirm theory of dirty flag, it probably works because that partition is not being written to, as opposed to size issues
[14:05] <xivulon> ev thanks
[14:16] <xivulon> could it be that those guys do not have syncio activated for some reason?
[14:18] <cjwatson> isn't the most likely answer that the initscripts lazy unmount stuff really is broken?
[14:19] <cjwatson> since that's the most recent relevant change, it seems to me that it would be better to focus on that ...
[14:19] <xivulon> cjwatson, yes that is the most likely reason
[14:20] <davmor2> xivulon: not sure what you want doing exactly plus need to shoot of for a bit
[14:20] <xivulon> I am a bit surprised though that there are unwritten journal items with syncio
[14:21] <xivulon> davmor2, install wubi and do a full upgrade, in post-install check that you have rootflags=syncio in cat /proc/cmdline
[14:21] <cjwatson> maybe depends just how unceremoniously we're ripping the device out from under ntfs-3g's feet ...
[14:22] <xivulon> then shutdown, and check whether ntfs is corrupted by booting off a live CD and running ntfs-3g.probe
[14:23] <xivulon> cjwatson, the shutdown process is quite lengthy and there is no write operation, so I would expect there is plenty of time for ntfs to be synced out to disk
[14:25] <xivulon> with the syncio patch we tried really bad things (such as pulling the power) and it hold quite well
[14:38] <CIA-15> tasksel: cjwatson * r1426 ubuntu/ (10 files in 3 dirs):
[14:38] <CIA-15> tasksel: * Point Ubuntu task update script at lucid.
[14:38] <CIA-15> tasksel: * Update Ubuntu tasks from seeds:
[14:38] <CIA-15> tasksel:  - Add new finer-grained eucalyptus-* tasks.
[14:38] <CIA-15> tasksel:  - Fix description of edubuntu-dvd-live.
[14:38] <CIA-15> tasksel:  - Rename Kubuntu Netbook Edition to Kubuntu Netbook Remix.
[14:41] <CIA-15> tasksel: cjwatson * r1427 ubuntu/debian/changelog: releasing version 2.73ubuntu24
[15:07] <superm1> ev, no problem. i just happened to be testing a lucid run at the time and it was a pretty ovb fix.
[15:08] <superm1> something weird is going on with the current dailies i think though.  i've been seeing them hang at 95 percent
[15:18] <ev> yeah, me too.  I thought it was just me accidentally using ctrl-alt-left to move away from the window (causes KVM to have a bad time), but I guess not
[15:30] <CIA-15> ubiquity: superm1 * r3603 ubiquity/ (debian/changelog scripts/install.py):
[15:30] <CIA-15> ubiquity: Don't run run_target_config_hooks for OEM config mode. It's
[15:30] <CIA-15> ubiquity: already ran during actual installation and can cause problems
[15:30] <CIA-15> ubiquity: during the OEM config run. (LP: #473241)
[15:32] <superm1> ^that needs to be backported to karmic.  it's causing karmic systems to fail unfortunately. i can get the SRU for it ready
[15:32] <cjwatson> do we have a karmic branch already?
[15:32] <cjwatson> we should check whether there's anything else that needs to go out as well
[15:33] <cjwatson> also that bug is unreadable by me
[15:33] <superm1> i just added a ubiquity task for it, it should be readable now hopefully
[15:34] <superm1> there is a karmic branch already. there were two other things that were causing issues for some systems that ev did an SRU for
[15:38] <CIA-15> ubiquity: superm1 * r3579 karmic/ (debian/changelog scripts/install.py):
[15:38] <CIA-15> ubiquity: Don't run run_target_config_hooks for OEM config mode. It's
[15:38] <CIA-15> ubiquity: already ran during actual installation and can cause problems
[15:38] <CIA-15> ubiquity: during the OEM config run. (LP: #473241)
[15:41] <superm1> If there aren't any other fixes that need to be backported, i'd like to get this SRU uploaded in a few hours
[15:58] <mark> hi
[15:58] <mark> I'm updating our preseeding setup for 9.10, and have a little issue with grub2 in /etc/default/grub
[15:58] <mark> does the installer modify that file?
[15:58] <mark> it has:
[15:58] <mark> GRUB_SERIAL_COMMAND="serial --unit= --speed=9600 --stop=1"
[15:58] <mark> that should be --unit=0 I guess
[16:12] <CIA-15> ubiquity: cjwatson * r3604 ubiquity/scripts/install.py: grammar
[16:12] <CIA-15> ubiquity: cjwatson * r3580 karmic/scripts/install.py: grammar
[16:13] <cjwatson> superm1: I'm fine with that change, target-config was never intended for use in oem-config
[16:13] <cjwatson> mark: it does, in grub-installer
[16:13] <mark> ok
[16:13] <mark> any idea why it might do that?
[16:14] <cjwatson> mark: what's your console=?
[16:14] <mark> otherwise I'll check the source
[16:14] <cjwatson>         local serconsole=${1##console=}
[16:14] <cjwatson>         local device=${serconsole%%,*}
[16:14] <cjwatson>         local unit=${device##ttyS}
[16:14] <cjwatson> ...
[16:14] <cjwatson>         echo serial --unit=$unit --speed=$speed $word $parity --stop=1
[16:14] <mark> console=ttyS1,57600n8
[16:14] <mark> (or ttyS0 on others)
[16:14] <mark> perhaps I should check it from within the installer
[16:14] <cjwatson> I see the bug
[16:14] <cjwatson> (but not yet the fix)
[16:15] <cjwatson> grub_serial_console is being called without arguments in the grub2 case
[16:15] <mark> the strange thing is, I think it worked a few installs ago
[16:15] <mark> not sure what changed :)
[16:16] <mark> while we're at it, is there a good way to not have "quiet splash" added to GRUB_CMDLINE_LINUX_DEFAULT in that file?
[16:16] <mark> currently I'm doing a sed in late_command
[16:16] <cjwatson> this code has never worked
[16:16] <mark> odd then
[16:17] <cjwatson> sed in late_command is probably best unfortunately
[16:17] <cjwatson> (and update-grub)
[16:17] <mark> ok
[16:17] <mark> it works, it's fine ;)
[16:20] <cjwatson> http://paste.ubuntu.com/332431/ is the fix for the sercon bug
[16:20] <cjwatson> maybe sed /usr/bin/grub-installer in early_command or something, to include that fix?
[16:20] <mark> yeah :)
[16:20] <mark> thanks!
[16:20] <cjwatson> I've committed that upstream
[16:21] <mark> you're always so quick with fixes
[16:21] <cjwatson> either very quick or very slow ;-)
[16:23] <cjwatson> ERROR: foundations-lucid-jockey-support-in-ubiquity: invalid work item format: [pitti] Modify jockey to run apt-get update if the package cache is out of date.
[16:23] <cjwatson> ev: ^- yup, it complains :) fixed that lot
[16:23] <ev> ah, sorry about that.  Muscle memory is killing me here.
[16:23] <ev> I'll endeavor to pay closer attention.
[16:38] <mark> hmm, grub_install not present yet during early_command
[16:38] <mark> I guess I'll have to fudge /etc/default/grub again during late_command
[16:38] <cjwatson> it's not "grub_install" ...?
[16:38] <cjwatson> is this a netboot installation?
[16:38] <mark> yes
[16:38] <mark> can I pull it in?
[16:38] <cjwatson> try partman/early_command instead (a hack, but should work)
[16:38] <mark> hmm ok
[16:39] <mark> all of early_command/late_command are hacks in our case, so one more won't hurt ;)
[16:58] <mark> ok, now that is correct, but grub complains during boot that it doesn't recognize the 'terminal' commands from grub.cfg
[16:58] <mark> error:rbad:unit.number.. 14
[16:58] <mark> error:kunknown5command0`terminal'
[16:58] <mark> error:ounknown1command1`terminal'
[16:59] <mark> bad unit number is odd too
[16:59] <mark> --unit=1 should be fine for ttyS1 I'd think
[17:06] <cjwatson> mark: this is one of those points where I might not be quite so quick - could you file a bug on grub-installer, please?
[17:06] <cjwatson> and I'll look into it from there
[17:06] <mark> of course :)
[17:13] <mark> could it be btw, that grub_installer looks at any existing (grub 1?) configuration in any way?
[17:13] <mark> because I'm sure it worked before, probably only during the first 9.10 install that exceeded
[17:17] <CIA-15> debian-installer: cjwatson * r1209 ubuntu/ (16 files in 14 dirs):
[17:17] <CIA-15> debian-installer: Remove all traces of lpia, which is being decommissioned (see
[17:17] <CIA-15> debian-installer: https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-lpia-future).
[17:18] <cjwatson> mark: the grub-legacy code should be fine; if you did an installation that used grub legacy ...
[17:18] <mark> not knowingly, but it was an installation on a system which previously had 8.04 installed
[17:19] <cjwatson> I don't *think* it should matter. TBH I think it's probably less interesting to analyse why it used to work than to fix the bug though :)
[17:19] <mark> agreed ;)
[17:21] <CIA-15> debian-installer: cjwatson * r1210 ubuntu/ (9 files in 3 dirs): Move to 2.6.32-6 kernels.
[17:26] <CIA-15> ubiquity: superm1 * r3581 karmic/debian/changelog: release 2.0.10 into karmic-proposed
[17:29] <cjwatson> superm1: (debcommit -r, please?)
[17:30] <superm1> oh neat, i didn't actually know about that.  i just manually tag usually
[17:31] <superm1> (so the tag is there at least)
=== robbiew_ is now known as robbiew-afk