[03:20] <sbeattie> erk, what's supposed to create the /dev/disk/by-uuid paths? I just tried a (minimal vm) server install with the current candidate and on reboot, got dropped to busybox; the only path under /dev/disk/ is by-path/
[03:21] <sbeattie> going in to rescue mode and selecting the ubuntu-server task didn't fix it, either.
[04:00] <sbeattie> hggdh: have you done a test install of the latest server isos yet?
[04:04] <hggdh> sbeattie: I did presseded installs of the 0426.1 ISOs
[04:07] <hggdh> six of them, to be exact
[04:07] <sbeattie> hggdh: and they all rebooted fine? I've got a virtualbox guest that's dropping me to busybox on reboot.
[04:08] <sbeattie> after installing the 0426 iso.
[04:09] <sbeattie> basically, none of the /dev/disk/by-uuid paths are getting set up in the initramfs.
[04:09] <hggdh> sbeattie: they did reboot fine, yes, no problems *there*
[04:10] <hggdh> what I had was -- sometimes -- the kvm modules would not be leaded
[04:10] <sbeattie> hggdh: were any of them side-by-side installs?
[04:11] <hggdh> no, they were all installs in the lab, the UEC test rig. I followed 4 of them via serial console, and there were no visible problems
[04:11] <hggdh> weird. If you are seeing that, I should also
[04:13] <hggdh> sbeattie: OTOH -- if you run gnome, and you are up-to-date, please check if gnome-keyring is listing your GPG keys. Mine is not, none of them
[04:14] <hggdh> and pretty much none of the ~400 public keys I have in the keyring
[04:14] <sbeattie> I don't make use of gnome-keyring, sorry.
[04:14] <hggdh> heh. *I* do not use it, bloody evolution does
[04:14]  * sbeattie uses mutt which uses gnupg directly.
[04:15] <hggdh> yeah, I know... shoulda
[04:15] <hggdh> anyway -- g'night, sbeattie
[04:16] <sbeattie> hggdh: thanks, g'night.
[06:40] <sbeattie> bah, worked it out; virtual kernels don't include the ahci driver, which is what virtualbox needs for its sata drives.
[06:57] <ara> good morning!
[07:05] <sbeattie> morning ara!
[07:05] <ara> hey sbeattie!
[07:06] <ara> Let's start the day with some alternate testing
[08:12] <ara> sbeattie, how long (~) does it take for you an alternate installation in virtualbox?
[08:13] <sbeattie> depends; my guess would be 30-45min typically.
[08:15] <ara> thanks
[08:31] <ara> mvo, morning
[08:31] <mvo> hey ara, good morning
[08:32] <ara> mvo, do you keep reading upgrade bugs from the launchpad team?
[08:33] <mvo> ara: I'm subscribed to the page, but haven't had updates recently
[08:33] <mvo> ara: maybe it got spammed :/ is there a lot of new stuff?
[08:33] <sbeattie> there hasn't been much activity there recently, right (I'm also subscribed)
[08:33] <sbeattie> ?
[08:33] <ara> mvo, I just had some updates to previous exisitng reports
[08:34] <ara> I am subscribed to anything behind it
[08:34] <mvo> could you /msg me the links please? I have  a look then
[08:51]  * ara goes for a coffee
[09:25] <slangasek> ok folks, y'all might want to take five on the ISO testing... we've got a plymouth bug that's being ruled critical enough to respin everything
[09:26] <slangasek> (bug #570289)
[09:26] <ubot4> Launchpad bug 570289 in plymouth (Ubuntu) "mountall assertion failure breaks boot process (affects: 1) (heat: 6)" [High,Incomplete] https://launchpad.net/bugs/570289
[09:26] <sbeattie> everything? bah.
[09:26] <slangasek> yes :/
[09:26] <slangasek> sorry - the plymouth change that caused the regression only landed on Sunday
[09:29] <ara> oops
[10:22] <slangasek> publisher is running for plymouth update; getting some regression testing here around the table at the release sprint, ISO spins should be able to start again in < 30min, so first (alternate) ISOs will be available in ~1h
[10:27] <ara> slangasek, thanks for the heads-up
[10:46] <ara> good morning davmor2
[10:46] <davmor2> morning ara
[10:47] <ara> davmor2, we are respining due to bug 570289
[10:47] <ubot4> Launchpad bug 570289 in plymouth (Ubuntu) "mountall assertion failure breaks boot process (affects: 1)" [High,Fix released] https://launchpad.net/bugs/570289
[10:48] <davmor2> ara: wounder I was gonna make a start on wubi :(
[10:48] <ara> davmor2, you will need to wait a bit, I am afraid
[10:49] <davmor2> I got 2 releases going to productions probably today too so I'll just do what I can as I can but I'll hit the wubis and migration-assistant
[10:54] <ara> davmor2, thanks
[10:55] <davmor2> ara, slangasek: I might not hit the starting button on the tests so just assume they have all been ticked ;)
[11:11] <slangasek> ubuntu alternate posted
[11:16]  * ara syncs
[11:23] <slangasek> kubuntu alternate posted
[11:23] <slangasek> next up are xubuntu alternate, ubuntu-netbook
[11:42] <slangasek> ubuntu-netbook, xubuntu up
[11:42]  * ara resyncs 
[11:46]  * persia considers `while true; do ubucdimage; done`
[11:49] <ara> hehe
[11:50] <slangasek> kubuntu-netbook up
[11:51] <slangasek> next: ubuntustudio, ubuntu desktop
[11:51] <slangasek> correction - ubuntustudio posted
[12:24] <slangasek> ubuntu desktop up
[12:25] <slangasek> ubuntu-server up
[12:25] <xdatap> hello
[12:26] <xdatap> ara: ping
[12:26] <ara> xdatap, hey, how is it going?
[12:26] <xdatap> ara: fine :)
[12:27] <xdatap> ara: just a clarification, it's my first release as a tester...
[12:27] <xdatap> ara: i'm receiving notification mail from tracker but then they are in rebuilding
[12:27] <ara> xdatap, like what?
[12:28] <ara> xdatap, there are some that were already posted, but others still rebuilding
[12:28] <ara> xdatap, can you give an example?
[12:28] <xdatap> ara: let me see...
[12:29] <xdatap> ara: i received mail for 20100426.2
[12:29] <davmor2> xdatap: that is because the tracker will issue a mail everytime there is an iso spun.  However if a fault is found it will be respun to fix the issue
[12:29] <ara> xdatap, yes, because a bug was found and there was a respin
[12:30] <ara> that's why
[12:30] <xdatap> but my question is, there will be another iso test before the release?
[12:30] <ara> you get the notifications, but you have to check in the tracker if it is going to be respin again
[12:30] <ara> xdatap, yes, we need to test the final isos
[12:30] <ara> so, everytime a respin is made, we need to resync our images, and test again
[12:31] <ara> xdatap, it is important to always resync the images
[12:31] <xdatap> ara: basically before to start a test during these hours we need to ask here before to start
[12:32] <xdatap> or we're expecting 20100427.1 to be tested?
[12:32] <xdatap> ...to be the final image to be tested
[12:32] <davmor2> xdatap: no you can just look at the tracker.  If it says respining just wait a bit.  But hopefully these will be the last ones
[12:33] <xdatap> i never seen "respining" in the iso track, where is this indication
[12:34] <davmor2> xdatap: basically if it has a line through it on iso.qa.ubuntu.com it means it is being respun
[12:35] <xdatap> ok! understood. Thanks everybody
[12:35] <ara> xdatap, many of them have been already posted in the tracker
[12:36] <xdatap> ara: no, I haven't understood. them who?
[12:36] <ara> xdatap, the new builds that need testing
[12:37] <ara> xdatap, if you check the tracker now, you will see that there are a lot there already, to begin with
[12:37] <xdatap> ara: perfect, thanks! :)
[12:38] <ara> xdatap, any time
[12:53] <slangasek> kubuntu desktop up
[13:13] <ara> I am going to switch to virtualbox when the two test that I am running finish, KVM is slow slow for me. I will ask kirkland why during UDS
[13:46] <davmor2> ara: present him with your laptop and don't let him leave till it flies ;)
[13:46] <davmor2> morning fader_
[13:46] <fader_> davmor2: Hey dude
[13:46] <davmor2> fader_: hows life?
[13:47] <fader_> davmor2: Can't complain, but I still do... you?
[13:48] <davmor2> fader_: about the same to be honest :D
[13:49] <slangasek> ara: can you have a look at the error on http://iso.qa.ubuntu.com/qatracker/test/4132 ?
[13:49] <slangasek> other pages load fine, but this one breaks reliably
[13:49] <slangasek> spot-checking, I only find this one page that's broken
[13:51] <ara> slangasek, which one is that?
[13:51] <slangasek> ara: Ubuntu desktop i386
[13:52] <ara> slangasek, F5? I can't reproduce
[13:52] <slangasek> ara: ah - shift-reload cleared it
[13:53] <slangasek> ara: I guess it was a cached bad page here in the office
[13:53] <slangasek> thanks for sanity-checking :)
[13:55] <persia> slangasek: When you find some spare time, could you generate some powerpc images as well?  (that said, I don't really have means to test, but I'll try to get some folks to look at them)
[13:55] <davmor2> morning cr3
[13:55]  * ara -> lunch
[13:57] <slangasek> persia: yes, will do later today after all the critical-path stuff is out of the way
[13:57] <slangasek> persia: not much urgency, since no arch-specific problems that turn up there are going to result in new uploads...
[13:57] <persia> No huge rush: just noticed it was the lagging arch of the four I mirror (for a subset of flavours)
[13:57] <persia> heh.  That sounds more like a declaration than a prediction :)
[13:59] <slangasek> yes, it is
[13:59] <slangasek> :)
[14:00] <slangasek> we're not going to derail the release process for arch-specific bugs that should've been found and fixed in RC
[14:01] <slangasek> mythbuntu up shortly
[14:01] <persia> Makes sense.  The three that affect me have already been determined to be SRUs.  I know at least some other folks are happy with the RCs.  The finals just need a sanity check (and unfortunately I failed to allow virtual testing from within Ubuntu for this cycle)
[14:07] <slangasek> mythbuntu posted
[14:12] <fader_> w00t, an excuse to watch Dr. Horrible again!
[14:12] <fader_> Er, I mean, an important image to test.
[15:23] <mdeslaur> hmmm...anyone else notice that netbook-launcher is using the short name for icons in the Favorites section?
[15:41] <ara> mdeslaur, I haven't tried netbook edition
[15:51] <jdstrand> ara: fyi, I started experimenting with using fully allocated, raw images with qemu-kvm using 'cache=writethrough'. for running one iso test at a time, it seems to make a difference
[15:51] <ara> jdstrand, thanks! I'll try that :)
[15:52] <jdstrand> :)
[15:54] <bladernr> Hey...  what do I file a bug under when the installer does not set up Windows during a dual-boot install?
[15:56] <bladernr> Grrr...  and what do I file bugs for migration-assistant under? sigh...
[15:57] <sbeattie> bladernr: ummm, for the latter, https://bugs.launchpad.net/ubuntu/+source/migration-assistant is insufficient?
[15:58] <persia> bladernr: Unless you know better, filing bugs against "ubiquity" or "debian-installer" is probably the best place to start for *all* installer bugs.
[15:58] <bladernr> hrmmm...
[15:58] <persia> use "ubiquity" if it's a liveCD, and "debian-installer" if it's not.
[15:59] <bladernr> ok... it's just me... was not including /ubuntu/+source in the URL... works now.  Head > Desk
[15:59] <persia> sbeattie: The issue with only filing aginst migration-assistant is that it may also affect other bits of the complete install, or need other bits tweaked to fix the issue (although the installer team may reassign, or if one is *sure* of the component, one may do differently)
[16:01] <sbeattie> persia: yep, you are correct. The installer team are quite good about directing bugs from ubiquity and d-i to the right component after they've tracked down what's going on.
[16:01] <persia> I've always been impressed with their handling, indeed.
[16:02] <ara> bladernr, but don't don't comment your symptoms on an already filed bug, create a new one.
[16:03] <bladernr> ara: ack. wouldn't dream of it ;-)
[16:05] <davmor2> bladernr: what is the m-a issue
[16:06] <bladernr> davmor2:  A: items in the "Shared Documents" folder are not migrated on Windows systems with multiple users
[16:07] <bladernr> B: when I have multiple users, they are all migrated to a single account on the Ubuntu install.  I had expected to see two users, not one user with everyone's data
[16:08] <davmor2> bladernr: I don't think shared is in the migration path to be honest I'll check
[16:08] <bladernr> probably not, it wasn't listed in the m-a page in Ubiquity, and that's a bit surprising...
[16:09] <bladernr> B is a much larger issue, IMHO.  a security one to some degree...
[16:09] <davmor2> I think is might be because it is then a samba share so should be easily accessible maybe don't know just guessing
[16:10] <bladernr> If I have two users, each with their own data, that data get's merged into one user in Ubuntu, who has ownership of all data...
[16:10] <davmor2> NIce that is a definate bug
[16:12] <slangasek> security> nack, the user doing the migration is already a local admin by definition
[16:12] <slangasek> it may not be desirable, but it's not a security bug
[16:13] <bladernr> slangasek:  mmmkay... you are correct.  definitely NOT desirable.
[16:13] <bladernr> but I see your point too.
[16:13] <bladernr> I'll not set it as a security issue
[16:17] <davmor2> bladernr: have a word with ev about it on u-installer
[16:26] <slangasek> there will be a slight delay in posting the Ubuntu and Kubuntu DVD images, we're slotting in a valgrind no-change rebuild to get it up-to-date on armel
[16:27] <slangasek> (they wouldn't have been done for another 2h at least, regardless)
[16:30] <bladernr> davmor2:  ^^^ thanks.  I filed a bug about the mixing of the users hoping that that behaviour will be revisited in the next cycle.
[16:43] <bladernr> I did have to fail the auto-resize test case, by the way.  Bug #570765
[16:43] <ubot4> Launchpad bug 570765 in ubiquity (Ubuntu) "[Lucid] Installer fails to configure grub for dual boot (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/570765
[16:44] <bladernr> and apparently, someone else tested after me and noted the same behaviour against a second Lucid install
[16:45] <davmor2> bladernr: check that u-installer are aware of that it might cause a respin + they might ask you for missing info etc
[16:46] <bladernr> davmor2:  will do
=== ogasawara_ is now known as ogasawara
[16:54] <slangasek> bladernr, davmor2: escalated to the installerers
[16:54] <bladernr> slangasek:  ack... I just added logs that were requested too
=== ara_ is now known as ara
=== ara is now known as Guest4805
=== Guest4805 is now known as ara
[17:18] <bladernr> Has anyone had success in installing via Wubi in a virtualbox VM?
[17:19] <sbeattie> bladernr: I can try, give me a bit to set things up.
[17:21] <bladernr> sbeattie:  ok... thanks.  I'm running a 64bit VM with 64bit XP.  Wubi ran inside XP just find, but it's the reboot that I'm having trouble with.  The VM hangs regardless of what boot options I try (even combinations of disabling acpi and apic fail)
[17:28] <sbeattie> bladernr: okay; all I have is win2k/32 but I'll try a xubuntu/64bit wubi install.
[17:43] <bladernr> sbeattie:  thanks... heck even if you do a 32bit wubi install it's a data point.
[17:43] <sbeattie> bladernr: bah, the wubi installer just hung. :-(
[17:44] <bladernr> after rebooting, or during the "Inside Windows" portion?
[17:44] <bladernr> IOW, did it hang after the first reboot when you choose Ubuntu from the Win boot manager to continue the installation
[17:46] <sbeattie> during the inside windows portion.
[17:46] <sbeattie> making sure it's not an infrastructure issue on my part.
[17:50] <bladernr> ahhh.. ok.  that part went fine for me :(
[17:50] <bladernr> ok.. off to eat
[18:20] <sbeattie> bladernr: bah, keeps hanging for me.
[18:23] <bladernr> sbeattie:  ok... thanks
[19:09]  * stgraber starts working on both edubuntu
[19:10] <stgraber> slangasek: any reason edubuntu isn't on the tracker
[19:27] <sbeattie> bladernr: still around? 64bit xubuntu is failing here after rebooting to finish the install as well.
[19:28] <bladernr> sbeattie:  rhmmm... thanks.  I'm wondering if this is a problem with VMs only... in Beta 2 davmor2 was successful on bare metal
[19:28] <bladernr> sbeattie:  I'd filed a bug in that timeframe
[19:29] <sbeattie> bladernr: virtualbox up and aborts for you?
[19:30] <sbeattie> Nice, the last line in the vbox log for that guest: 00:00:20.999 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'.
[19:30] <bladernr> depends... if I muck with acpi settings or set nousb (in my case, it alway seems to hang when looking at USB devices) then yeah... otherwise, just a quiet hang with no error from VBox.
[19:30] <bladernr> BUT, I get the same GURU_MEDITATION message in the VM logs too
[19:31] <sbeattie> bladernr: ah, I'm using virtualbox-ose from the archive, so no USB for me.
[19:32] <bladernr> ??  no, I meant if I set nousb on the boot line for Ubuntu when I boot the VM (and pick Ubuntu from the Win bootloader)
[19:32] <bladernr> e.g. telling the kernel to not configure any USB controllers
[19:33] <sbeattie> ah, I see.
[19:35] <sbeattie> It's always failing (with verbose enabled) at the point right after it tells me it write-protected kernel read-only memory and then "Loading, Please Wait", and ker-boom!
[19:36] <bladernr> ahhh.. ok.  ker-boom?  does yours just hang, or do you get a stack trace?
[19:36] <sbeattie> bladernr: what bug number?
[19:37] <sbeattie> bladernr: ker-boom means virtualbox pops up a dialog that the guest has aborted.
[19:37] <bladernr> sbeattie:  bug 557448
[19:37] <ubot4> Launchpad bug 557448 in wubi "[Lucid Beta2] Wubi hangs on first reboot after installing inside windows on amd64 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/557448
[19:38] <bladernr> sbeattie:  ack... I get that about 70% of the time ;-)  YAY!
[19:38] <sbeattie> oh, I get that 100% of the time; don't get anything else.
[20:17] <stgraber> edubuntu dvd amd64 done, doing i386 now (Installed amd64 in simplified chinese and doing i386 in greek for some i18n testing)
[20:44] <slangasek> stgraber: hrm, no reason - did you post it then, I guess?
[20:55] <stgraber> slangasek: yep
[21:29] <MTecknology> I screwed up a little. I used a tool for editing run levels but it turns out that's not how upstart works. How can I make sure any scripts I have are upstart jobs instead of rc jobs?
[21:33] <charlie-tca> Wouldn't you be able to check in /etc/init.d for them? upstart scripts are usually in /etc/init instead now
[21:43] <MTecknology> charlie-tca: thanks, I didn't know where upstart jobs were heald
[21:43] <MTecknology> held*
[21:45] <charlie-tca> Well, to the best of my knowledge, they start there anyway
[21:48] <sbeattie> yes, upstart jobs are held there, unless you move them elsewhere to disable them (I have /etc/init.disabled/ on my more permanent hosts)
[21:48] <MTecknology> sbeattie: nifty idea :)
[21:49] <MTecknology> So.... if I want to completely drop sysv then I need to convert everything to an upstart job
[21:50] <MTecknology> That means 1) identify what sysv scripts I still depend on - which I can figure out with that .disabled directory idea; then 2) convert then 3) push upstream
[21:50] <MTecknology> probably in a debdiff at first with a bug report on launchpad?
[21:53] <sbeattie> MTecknology: erm, I use /etc/init.disabled for upstart jobs that I want to disable, as upstart doesn't provide any management tools for such things.
[21:53] <MTecknology> sbeattie: oh :P - I'm trying to use upstart for everything
[21:54] <MTecknology> I'm gonna run off and tackle this when I get homework done tonight..
[21:54] <sbeattie> But yes, you'd want to see what you have in /etc/init.d that's still a script; IIRC, placeholder symlinks are (typically?) put in place for sysv scripts that have already been converted to upstart.
[21:56] <sbeattie> well, you'd want to make sure it was enabled as well; /me spies an /etc/init.d/sysklogd that'sno longer relevant.
[21:57] <MTecknology> sbeattie: I don't see that at all
[21:57] <MTecknology> the sysklogd i mean
[21:58] <sbeattie> MTecknology: deritrus left behind from jaunty->karmic's conversion from sysklogd to rsyslogd; I meant on my laptop.
[21:58] <MTecknology> anyway - I'm going to run off and see my gf - I'll start converting tonnight
[21:58] <MTecknology> oh
[21:58] <sbeattie> MTecknology: have fun!
[21:58] <MTecknology> sbeattie: thanks for the info
[22:05] <MTecknology> sbeattie: I guess she's not back yet... I'll start now - I removed any symlinks in init.d; boots find - I have something at least :)
[22:13] <MTecknology> sbeattie: the more I'm reading, the harder it's seaming to actually convert them
[22:16] <sbeattie> it's... non-trivial.
[22:16] <sbeattie> or can be, depending on the initscript.
[22:17] <MTecknology> sbeattie: I was lookin at wicd and wdm
[22:21] <MTecknology> sbeattie: I guess this is why it has been a long migration
[23:03] <charlie-tca> humm, problem with the xubuntu desktop image. 'use the entire disk' partitioning results in all other grub entries not seen except that installation. It doesn't matter how many other installs are present
[23:04] <charlie-tca> Reinstalling with any other partition method allows you to see the other installations again
[23:05] <charlie-tca> I think this is critical, since it makes it appear that existing partitions with anything on them disappeared during the install
[23:05] <sbeattie> charlie-tca: I'm assuming the others are on another disk?
[23:06] <charlie-tca> negative. It doesn't matter if they are on the same disk or other disk
[23:06] <charlie-tca> Tried this twice.
[23:06] <charlie-tca> oops. I guess they are on the other disk. It is a entire disk partition
[23:06] <charlie-tca> heh
[23:07] <charlie-tca> Got a bug already?
[23:07] <sbeattie> nope
[23:09] <charlie-tca> Both drives/systems had multiple partitions in the drive used
[23:10] <charlie-tca> even better, ubuntu-bug fails too
[23:14] <sbeattie> charlie-tca: how so?
[23:14] <charlie-tca> errors as soon as I click on 'send report'
[23:15] <charlie-tca> AssertionError
[23:17]  * sbeattie starts up a xubuntu manual disk install to see if he can reproduce the ubuntu-bug error.
[23:18] <charlie-tca> not manual install; 'use entire disk' is the only partitioning that fails
[23:20] <sbeattie> charlie-tca: I got that; ubuntu-bug failing to submit bug reports is what I was trying to reproduce.
[23:21] <charlie-tca> oh
[23:21] <charlie-tca> heh
[23:21] <sbeattie> What's the assertion you see? I can't reproduce in the live environment.
[23:21] <charlie-tca> Yeah, I should report that too
[23:22] <charlie-tca> File "/usr/lib/python2.6/dist-packages/apport/REThread.py", line 46, in return_value
[23:22] <charlie-tca> assert not self._exception