[00:21] <smoser> veenenen, i'm not sure i understand the question
[00:21] <smoser> they should reboot, do they not ?
[00:22] <veenenen> yeah, but after the reboot there's no more console
[00:22] <veenenen> i can still ssh in though
[00:22] <veenenen> I just wanted to make sure that was intended behaviour
[00:24] <veenenen> It makes sense to me why that would be, but I just wanted to make sure I wasn't doing anything wrong
[00:25] <smoser> hm.. really, no more console.
[00:25] <veenenen> well, I'm not prompted to login
[00:25] <veenenen> I guess I still get a console
[00:25] <smoser> hm.. i would have thought youd still get console.
[00:26] <smoser> i can try to test this tomorrow.
[00:26] <smoser> i'd appreciate it if you'd open a bug
[00:26] <veenenen> sure
[00:26] <smoser> ideally, just run 'ubuntu-bug cloud-init' from inside the instance
[00:26] <veenenen> also, do you always have to boot from the floppy image when running it on kvm?
[00:50] <veenenen> nevermind, it just took several minutes for it to show up
[00:53] <smoser> hm... that is strange.
[00:53] <smoser> the reason you boot from a floppy is that what you have is a disk image with no partition table
[00:53] <smoser> so there is no place to put a boot loader
[00:53] <smoser> so the floppy provides that.
[00:54] <veenenen> that's what I figured
[00:54] <smoser> i know.
[00:54] <smoser> seriously, floppies.
[00:54] <smoser> :)
[00:54] <veenenen> haha
[00:54] <smoser> if you'd like you can do the same thing easily enough with a cdrom
[00:55] <smoser> the floppy image that is there actually doubles as a cdrom (other than it is padded to 2880K)
[00:55] <smoser> you will still likely have to "clean" your image before you put it up on ec2, if you're booting into it and doing things.
[00:55] <veenenen> I'm booting it as a cdrom already. virt-install doesn't have the option of floppies
[00:55] <smoser> oh. i'm glad that worked then.
[00:56] <smoser> ie, you will wan to un-set the password and such. there are some other things that 'uncloud-init' does, or that 'cloud-init' does that you'd want to to un-do.
[00:56] <veenenen> I was just planning on using the standard ec2-bundle-vol command
[00:56] <smoser> hm..
[00:56] <smoser> i dont knwo if that would work or not.
[00:56] <smoser> i really apologize for not being able to give as much help here.
[00:56] <veenenen> you've been great
[00:56] <smoser> i wish this was better documented or all "just worked" better.
[00:57] <smoser> in general, i don't like the "bundle-vol" approach
[00:57] <smoser> it tries to "un-boot" an image
[00:57] <smoser> i would much prefer modifying a pristine one without booting it.
[00:57] <smoser> ie, extracting, mounting loopback, and either modifying the contents or chroot'ing in and doing things.
[00:57] <smoser> ideally via scripts.
[00:58] <smoser> i do realize, though,t hat people want to do what you want to do
[00:58] <veenenen> I just want to get this all working then I can dig in and figure out better ways of doing everything
[00:58] <smoser> yeah.
[00:58] <smoser> i got to run
[00:58] <smoser> good luck.
[00:58] <veenenen> thanks for all your help
[07:14] <ttx> smoser: yes, someone should have tested that. I was on vacation that week, so I can't tell you who.
[07:15] <ttx> smoser: that said, the error is probably not a permanent error
[07:15] <ttx> and not linked specifically to 10.04.1
[07:16] <ttx> it's generally because it detects two CLCs or two CCs on the same network
[07:16] <ttx> the second one is detected as #2
[15:51] <crazy> hello all
[15:52] <crazy> i am facing problems in deploying applications to unbuntu cloud
[15:52] <crazy> smby help me....
[15:54] <crazy> hey i am new t0 irc help me guys......
[16:51] <smoser> crazy, well, what is your problem ?
[22:33] <SpamapS> hmm.. I wonder if we can get newer ec2 utils into maverick to support m1.micro
[22:43] <erichammond> SpamapS: What changes need to be made to support t1.micro?
[22:44] <SpamapS> is it t1.micro? Not sure. Maybe I just need to use the right type...
[22:44] <SpamapS> I know in the past regions had to be added at the tool level.
[22:56] <SpamapS> erichammond: ok, so that solves that. :)
[22:56] <SpamapS> Client.UnsupportedOperation: AMIs with an instance-store root device are not supported for the instance type 't1.micro'.
[22:56] <SpamapS> so you have to do EBS for micro? :(
[22:59] <SpamapS> Oh I guess thats because these have more capability.. cool
[23:16] <veenenen> also changes had to be made to the fstab to remove mounting sdb
[23:16] <veenenen> but that may have been fixed since I started one yesterday
[23:28] <erichammond> SpamapS: Yes, t1.micro must be EBS boot, 32- or 64-bit.
[23:29] <SpamapS> I just got one up and running
[23:29] <erichammond> smoser: I suppose that may create a case for a smaller EBS boot volume size than 15GB.
[23:29] <SpamapS> I may leave it for a while... why not? ;)
[23:34] <erichammond> $1.50 per month wasn't that big of a deal when you were paying at least $60 per month for an m1.small, but $1.50 per month is a big percentage increase when you start at $8 per month for t1.small, 3yr reserved.
[23:34] <erichammond> It's possible to increase the size of the root EBS volume at run time, but not decrease it.
[23:38] <veenenen> even with the 15 GB size it's still in line with the smallest offering at rackspace