| cjwatson | infinity: Hmm? There sure is a reboot, always has been. | 00:03 |
|---|---|---|
| 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:04 |
| infinity | It all blends together after a while... | 00:05 |
| 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:50 |
| 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:51 |
| 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 | 00:59 |
| veebers | I'm confident that it's the dist-upgrade in the preseed installing the newer kernel (was watching the logs during install) | 01:01 |
| 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:11 |
| 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:15 |
| 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:17 |
| cjwatson | Probably not desperately easily | 01:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| veebers | hmm, I wonder if Utah is doing something to dirty the waters then | 01:25 |
| veebers | cjwatson: will this preseed command work as expected in ubiquity? "d-i pkgsel/upgrade" | 01:39 |
| 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:40 |
| 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 | 01:41 |
| veebers | random question, (in a VT during install) is there a reason why 'tail -f' doesn't actually follow the file? | 02:47 |
| infinity | veebers: On a live install? | 03:41 |
| infinity | veebers: If so, yes. | 03:41 |
| 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:42 |
| 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:43 |
| 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:45 |
| infinity | StevenK: So, Foundations, 1; Kernel, 0 | 03:46 |
| StevenK | Breaking Leann is not nice. | 03:46 |
| infinity | She was in a room full of nerds. Would you rather she had to tolerate us sober? Whiskey seemed like the sane choice. | 03:47 |
| smartboyhw | cjwatson, strange now I can't build wubi.... | 08:49 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| smartboyhw | ev, er actually I re-downloaded the source code... | 09:49 |
| === smartboyhw_ is now known as smartboyhw | ||
| 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:08 |
| 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:09 |
| ev | bzr add is producing a traceback? | 10:10 |
| 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:12 |
| cjwatson | try 'svn upgrade' in that directory | 10:13 |
| cjwatson | (/home/smartboyhw/wubi/src/grub4dos) | 10:14 |
| smartboyhw | cjwatson, OK | 10:14 |
| smartboyhw | cjwatson, next upgrade to grubutil... So many outdated ones | 10:15 |
| smartboyhw | Yeah I got the bzr add problem solved | 10:15 |
| cjwatson | we should probably nuke the grub4dos-based stuff from the wubi tree | 10:16 |
| cjwatson | I'm sure it's bitrotted anyway | 10:16 |
| xnox | cjwatson: in #ubuntu-arm ogra brought up an interesting question. oem-config depends on ubiquity, which recommends lvm2/dmraid/btrfs-tools. | 10:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| xnox | ogra_: drop python2 =) | 10:37 |
| ogra_ | heh | 10:37 |
| xnox | ogra_: who cares about software centre right =) | 10:37 |
| xnox | oh wait..... we need that. | 10:38 |
| ogra_ | yeah, how else would you install steam on your arm device :P | 10:38 |
| ogra_ | or skype | 10:39 |
| cjwatson | xnox: I've long thought that oem-config's dependencies should be restructured | 10:56 |
| 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 | 10:57 |
| xnox | ack | 11:00 |
| * ogra_ curses | 11:25 | |
| ogra_ | i seem not to be able to get the quoting of my abootimg call right in lvecd-rootfs | 11:25 |
| 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:26 |
| ogra_ | err | 11:31 |
| ogra_ | [ ] livecd.ubuntu-nexus7.initrd-nexus7 20-Nov-2012 10:39 1.7M | 11:31 |
| 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 | 11:32 |
| === mdeslaur_ is now known as mdeslaur | ||
| bg | cjwatson: UEFI network installs are working pretty well for me. Now the problems move downstream ;) | 18:45 |
| 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 | 19:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!