[00:19] <ejat> hi .. i do the release upgrade on ec2 .. from maverick to natty then i get this
[00:19] <ejat> http://paste.ubuntu.com/676897/
[00:19] <ejat> is it ok for me to reboot or need to fix it 1st then reboot
[00:25] <flaccid> ejat: looks like some bugs. the device is likely /dev/xvda1 not /dev/sda1. grub is also not needed in ec2, so it can not play nice with automagic debian kernels
[00:26] <flaccid> whats in /boot/grub/menu.lst and also pastebin fdisk -l; cat /proc/partitions
[00:29] <ejat> http://paste.ubuntu.com/676902/
[00:30] <flaccid> ejat: that will work as long as the LABELS used exist
[00:30] <ejat> http://paste.ubuntu.com/676904/
[00:30] <flaccid> where is the fdisk?
[00:31] <ejat> no output :(
[00:31] <flaccid> nothing in fdisk -l ?
[00:31] <ejat> yups
[00:31] <flaccid> well that is strange
[00:32] <ejat> opss
[00:32] <ejat> hold on
[00:32] <ejat> http://paste.ubuntu.com/676907/
[00:32] <ejat> sorry ..
[00:34] <flaccid> check the labels
[00:36] <ejat> LABEL=uec-rootfs
[00:36] <ejat> ?
[00:36] <ejat> boot/vmlinuz-2.6.38-11-virtual root=LABEL=uec-rootfs ro console=hvc0
[00:37] <flaccid> yes does that partition have that label
[00:48] <ejat> ?
[00:50] <flaccid> does /dev/sda1 have the label, uec-rootfs ?
[01:04] <ejat> bugs 759545
[01:04] <uvirtbot`> Launchpad bug 759545 in ubuntu-release-notes "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Undecided,Fix released] https://launchpad.net/bugs/759545
[01:05] <ejat> y it stated wont fix for natty ?
[15:04] <smoser> flaccid, i think you got ejat sorted ? those errors are ignorable.
[17:07] <hallyn> smoser: did you work around bug 832123 ?
[17:09] <smoser> hallyn, no.
[17:09] <smoser> but i/you can easily reproduce
[17:10] <hallyn> wait, that's not the one i meant to ask about is it
[17:11] <hallyn> never mind, i got several things confused in my head
[17:58] <smoser> hallyn, but that is a good one
[17:58] <smoser> and you're more than welcome to work on that
[17:58] <smoser> :)
[17:59] <hallyn> smoser: i duno, the bug submitter couldn't be bothered to respond with requested data :)
[17:59] <hallyn> but yes, I'm hoping to reproduce that today
[18:00] <smoser> yeah.. .your data would have been helpful
[18:00] <smoser> sorry id d't post it right away
[18:03] <hallyn> nah, that was to facilitate debug by email.  i can JFDI now, soon as i finish with testing a qemu debdiff
[21:49] <flaccid> smoser: thats what they say about all ubuntu errors :)
[23:14] <SpamapS> smoser: t1.micro's still don't run java, do they?
[23:14]  * SpamapS 's evil plan to not spend too much money for testing is slipping away.. :-P
[23:15] <flaccid> i've used java on t1.micro before without issue
[23:17] <SpamapS> I recall that they lockup during the install
[23:17] <SpamapS> could only be i386
[23:18] <SpamapS> will try 64bit
[23:18] <statim> anyone familiar with the debootstrap process? im trying to modify vmbuilder to install virtualbox guest additions into the image.  ive gotten it really close, but when i run its installer inside the chroot environment it needs /proc.  i mounted the outer /proc into the chroot and that made the install work, but i dont think it stuck (because that /proc isnt going to make it into the image.. its in the outer machine)
[23:18] <flaccid> SpamapS: oh i may not of been using ubuntu heh
[23:19] <flaccid> statim: i mount proc in the chroot
[23:19] <statim> flaccid:  hmm so maybe i just need to not unmount it until after vmbuilder creates the image?
[23:20] <flaccid> i don't use vmbuilder so i can't say, but i mount proc as early as i can inside it and then unmount at end
[23:20] <statim> flaccid:  ok will try something, that gives me an idea
[23:21] <SpamapS> statim: when you boot the VM, it should be mounted the normal way from fstab
[23:21] <SpamapS> proc            /proc           proc    nodev,noexec,nosuid 0       0
[23:21] <flaccid> of course
[23:28] <SpamapS> thw t1.micro bug I was thinking of seems to have a lot of "invalid" in it.. bug 634487
[23:28] <flaccid> you could test it out to see what the go is
[23:28] <SpamapS> I believe at this point we're waiting on Amazon to apply a fix to their dom0's
[23:34] <SpamapS> uca-buntu
[23:34] <SpamapS> arg curse you touchpad!
[23:49] <smoser> SpamapS, you are correct regarding dom0.
[23:50] <smoser> the issue reproducibly occurs on t1.micro and i686 install, but its general user space code that can be triggered elsewhere just as well.
[23:50] <smoser> i've seen reports of it happening in general java use on amd64, and almost certainly a C test case  could trigger it also.
[23:50] <SpamapS> So some other OS's probably hit it on a random basis right?
[23:51] <SpamapS> Wow.. moving 20G from EBS -> instance storage is really.. really slow.. would have expected that to be faster. :-P