[00:03] <cjwatson> infinity: Hmm?  There sure is a reboot, always has been.
[00:04] <cjwatson> No idea why veebers is seeing the wrong kernel version, unless the effect of their netboot setup is to not be booting the kernel they think they are ...
[00:04] <infinity> cjwatson: Hrm.  Maybe I'm confusing it with some other installation method.
[00:05] <infinity> It all blends together after a while...
[00:50] <veebers> cjwatson: thanks for the clarification. It seems odd that it's -17 after the install and a sudo reboot boots us into -18
[00:51] <veebers> cjwatson: or are you suggesting that there is some configuration in the lab which is causing it to boot for the -17 kernel straight after the install which isn't happening for the sudo reboot?
[00:59] <cjwatson> That's the only kind of thing I can think of
[00:59] <cjwatson> Unless there's something post-reboot that does an upgrade
[00:59] <cjwatson> The first reboot after install is supposed to be (and IME is) essentially equivalent to subsequent reboots
[01:01] <veebers> I'm confident that it's the dist-upgrade in the preseed installing the newer kernel (was watching the logs during install)
[01:11] <veebers> cjwatson: I just got confirmation that there should be no interference from anything in the lab with the post-install reboot (i.e. only thing is the netboot, which is what started the install but isn't in effect at the post-install reboot stage)
[01:15] <cjwatson> Well, all I can tell you is what the installer normally does.  I would strongly advise checking what the post-install path to the kernel your infrastructure is actually booting is, rather than what the lab folks say it should be.
[01:17] <veebers> cjwatson: is there a way (using the preseed) to get the installer to install the -18 kernel from the get-go, instead of using a success_command -> dist-upgrade?
[01:18] <cjwatson> Probably not desperately easily
[01:19] <cjwatson> Not going to try to figure it out at this time of night anyway :)
[01:19] <veebers> cjwatson: in case it clarifies anything, the machine in the lab uses dist-upgrade to install the newer kernel (which should setup grub options, right?) and is rebooted. at that point of reboot it's just a standalone machine with no intervention
[01:19] <veebers> cjwatson: ah understood (didn't consider your time of day :) )
[01:19] <cjwatson> It doesn't clarify anything much because I don't know how your infrastructure is shaped.  You are the best-placed person to investigate this.
[01:19] <cjwatson> (Yes, a simple dist-upgrade should update grub.cfg.)
[01:21] <veebers> sure understood. as far as I'm aware at the time of reboot it's effectively a stand alone machine and thus should just boot the first grub option
[01:21] <veebers> "should just" being the operative term :)
[01:22] <cjwatson> Mm.
[01:22] <cjwatson> But I don't actually believe that since it's just as much standalone after the first reboot as after the second.
[01:25] <veebers> hmm, I wonder if Utah is doing something to dirty the waters then
[01:39] <veebers> cjwatson: will this preseed command work as expected in ubiquity? "d-i pkgsel/upgrade"
[01:40] <cjwatson> No.
[01:40] <veebers> oh, is there an equiv?
[01:40] <cjwatson> I think you're barking up the wrong tree.  It shouldn't matter exactly where in the installer (native installer code or your preseed) you do the upgrade.
[01:41] <cjwatson> The equivalent is to DIY using a preseed file ...
[01:41] <veebers> ok
[01:41] <cjwatson> Which is what you're doing.
[01:41] <veebers> understood
[02:47] <veebers> random question, (in a VT during install) is there a reason why 'tail -f' doesn't actually follow the file?
[03:41] <infinity> veebers: On a live install?
[03:41] <infinity> veebers: If so, yes.
[03:42] <veebers> infinity: yes and oh? please tell :)
[03:42] <infinity> veebers: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147
[03:42] <ubot2> Launchpad bug 882147 in linux (Ubuntu Precise) "overlayfs does not implement inotify interfaces correctly" [High,Triaged]
[03:42] <veebers> ah makes sense. Thanks infinity
[03:43] <infinity> apw has a halfway working implementation, but for enough beer, he might be convinced to make it fully-working.
[03:43] <infinity> Or die trying.
[03:43] <infinity> From alcohol poisoning.
[03:43] <StevenK> He's a kernel team member. They're immune.
[03:43] <infinity> So not true.
[03:45] <infinity> StevenK: Andy's about half a Leann, and we broke Leann in Copenhagen, QED.
[03:45] <infinity> StevenK: (drinking-wise, not size-wise, obviously)
[03:45] <StevenK> Haha
[03:46] <infinity> StevenK: So, Foundations, 1; Kernel, 0
[03:46] <StevenK> Breaking Leann is not nice.
[03:47] <infinity> She was in a room full of nerds.  Would you rather she had to tolerate us sober?  Whiskey seemed like the sane choice.
[08:49] <smartboyhw> cjwatson, strange now I can't build wubi....
[09:44] <cjwatson> smartboyhw: Don't ask me, I've never been able to build it
[09:44] <cjwatson> smartboyhw: ev is the expert on that
[09:44] <smartboyhw> cjwatson, oh OK...
[09:44] <ev> oh hi :)
[09:44] <smartboyhw> ev, please do help...
[09:44] <smartboyhw> Got some python23.dll missing thing
[09:44] <ev> sounds like you're trying to build without the dependencies installed in ./wine/
[09:45] <ev> make sure you have the DISPLAY variable set
[09:45] <ev> one very long standing bug is that we could get around this by using MSI installers in automatic mode, like I taught usb-creator for Windows to do
[09:45] <ev> but I've never gotten around to implementing that in Wubi
[09:45] <ev> patches welcome :)
[09:46] <ev> scratch that itch
[09:46] <smartboyhw> ev, er 1. I've been able to build before
[09:46] <smartboyhw> 2. I installed wine-*
[09:47] <ev> oh, hm
[09:47] <ev> smartboyhw: so maybe do a find | grep python23.dll in the wubi source tree
[09:47] <ev> make sure it's tehre
[09:47] <ev> there*
[09:47] <ev> if memory serves, it's just a simple cp in the Makefile
[09:48] <smartboyhw> ev, no....
[09:48] <smartboyhw> ev, can't find it....
[09:48] <smartboyhw> I think it is a wine regression or something...
[09:48] <ev> it should only need to do it once
[09:48] <ev> once you have done the first build, it wont need to run anything under wine
[09:49] <smartboyhw> ev, er actually I re-downloaded the source code...
=== smartboyhw_ is now known as smartboyhw
[10:08] <ev> smartboyhw: hm, maybe it is a regression then. Hard to say without digging into the build on your machine.
[10:08] <ev> Let me know if you get stuck in the build infrastructure and need anything explained
[10:09] <smartboyhw> ev, it just misses the python23.dll file. Probably I will have to report a bug regression...Originally trying to see if the new Bug 1080090 fix works...However I even got a bug in bzr add now......:(
[10:09] <ubot2> Launchpad bug 1080090 in Wubi "When installing Ubuntu Studio in Wubi, it says that it does not match the words in .disk/info" [Undecided,In progress] https://launchpad.net/bugs/1080090
[10:10] <ev> bzr add is producing a traceback?
[10:12] <smartboyhw> ev, yes. I've reported a bug already
[10:12] <smartboyhw> Bug 1081040...
[10:12] <ubot2> Launchpad bug 1081040 in Bazaar "bzr add does not work" [Undecided,New] https://launchpad.net/bugs/1081040
[10:12] <ev> smartboyhw: yikes
[10:12] <smartboyhw> ev, yikes too
[10:12] <ev> heh
[10:13] <cjwatson> try 'svn upgrade' in that directory
[10:14] <cjwatson> (/home/smartboyhw/wubi/src/grub4dos)
[10:14] <smartboyhw> cjwatson, OK
[10:15] <smartboyhw> cjwatson, next upgrade to grubutil... So many outdated ones
[10:15] <smartboyhw> Yeah I got the bzr add problem solved
[10:16] <cjwatson> we should probably nuke the grub4dos-based stuff from the wubi tree
[10:16] <cjwatson> I'm sure it's bitrotted anyway
[10:32] <xnox> cjwatson: in #ubuntu-arm ogra brought up an interesting question. oem-config depends on ubiquity, which recommends lvm2/dmraid/btrfs-tools.
[10:33] <xnox> but those recommends are not wanted in the pre-install images that will not run partitioner.
[10:33] <ogra_> which in turn results in a quite big initrd
[10:34] <xnox> what would be the best way to express for these images install partitioning bits and for the preinstall/"devicy" images do not include partitioning bits
[10:35] <ogra_> i could worst case just apt-get ourge them from livecd-rootfs during preinstalled builds
[10:35] <ogra_> *purge
[10:35] <ogra_> but that feels a bit dirty
[10:35] <xnox> that is not sustainable, because next time I add mdadm, we will have to remember to do this......
[10:36] <ogra_> well, i will need some such code anyway as an interim until we have a split desktop and desktop-core seed
[10:36] <ogra_> (current nexus images get to big with libO and thunderbird on them)
[10:37] <xnox> ogra_: drop python2 =)
[10:37] <ogra_> heh
[10:37] <xnox> ogra_: who cares about software centre right =)
[10:38] <xnox> oh wait..... we need that.
[10:38] <ogra_> yeah, how else would you install steam on your arm device :P
[10:39] <ogra_> or skype
[10:56] <cjwatson> xnox: I've long thought that oem-config's dependencies should be restructured
[10:57] <cjwatson> I'm just not sure how - it gets messy with the frontend axis to consider as well
[10:57] <cjwatson> I don't know whether the right way to think about it is to split out a core package, or to split out the partitioner
[10:57] <cjwatson> Open to reasonable suggestions
[11:00] <xnox> ack
[11:25]  * ogra_ curses
[11:25] <ogra_> i seem not to be able to get the quoting of my abootimg call right in lvecd-rootfs
[11:26] <ogra_> Chroot chroot "abootimg --create /boot/installer-${KVERS}.img -f /boot/b
[11:26] <ogra_> ootimg.cfg -r /boot/initrd.img-${KVERS} -k /boot/vmlinuz-${KVERS}"
[11:26] <ogra_> this one works just fine
[11:26] <ogra_> Chroot chroot "abootimg -u /boot/installer-${KVERS}.img -c 'cmdl
[11:26] <ogra_> ine=root=/dev/mmcblk0p9 ro console=tty1 fbcon=rotate:1 quiet splash'"
[11:26] <ogra_> and this is the next one that always fails
[11:31] <ogra_> err
[11:31] <ogra_> [ ]   livecd.ubuntu-nexus7.initrd-nexus7                    20-Nov-2012 10:39 1.7M
[11:32] <ogra_> now thats funny, the last build resulted in a 2.5M initrd and i dont see any difference in the update-initramfs output during build
=== mdeslaur_ is now known as mdeslaur
[18:45] <bg> cjwatson: UEFI network installs are working pretty well for me. Now the problems move downstream ;)
[19:01] <gpmanrpi> Maybe this is the right place to ask this question, how do I add extended attributes support to my wubi / partition since it is not listed in FSTAB