This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things.
But on boot, grub.cfg file always contains timeout=5. Why / how is this happening?
I'm using appliance-creator, in case that's doing anything silly.
On Fri, 9 Nov 2012, Matthew Miller wrote:
This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things.
But on boot, grub.cfg file always contains timeout=5. Why / how is this happening?
I'm using appliance-creator, in case that's doing anything silly.
in your kickstart can you do:
bootloader --timeout=1
-sv
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote:
in your kickstart can you do: bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect _either_.
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote:
in your kickstart can you do: bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect _either_.
hmmm - seems to work for me using ami-creator.
-sv
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote:
in your kickstart can you do: bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect _either_.
hmmm - seems to work for me using ami-creator.
I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders....
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote:
in your kickstart can you do: bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect _either_.
hmmm - seems to work for me using ami-creator.
I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders....
Not sure these two QUITE do the same thing - but they use the installer similarly, I think.
here's what I've been using:
https://github.com/eucalyptus/ami-creator
-sv
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote:
Not sure these two QUITE do the same thing - but they use the installer similarly, I think.
here's what I've been using:
I've got https://github.com/katzj/ami-creator :)
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote:
Not sure these two QUITE do the same thing - but they use the installer similarly, I think.
here's what I've been using:
I've got https://github.com/katzj/ami-creator :)
Jeremy's is older last time I checked - the one from euca is modified by andy grimm and, well, works and stuff.
-sv
On Fri, Nov 09, 2012 at 01:26:44PM -0500, Matthew Miller wrote:
This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things.
But on boot, grub.cfg file always contains timeout=5. Why / how is this happening?
I'm using appliance-creator, in case that's doing anything silly.
I think appliance-creator is pretty much unsupported at this point, isn't it?
livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package.
livecd-creator can also make images instead of iso's so you may have better luck with that. Call image-creator instead of livecd-creator.
On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote:
I think appliance-creator is pretty much unsupported at this point, isn't it?
Yes, so moving to ami-creator might be a good choice.
livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package.
I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us. We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
On another note, Boxgrinder also is based around appliance creator, and it'd be nice to play nicely with those people too.
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote:
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
I'd strongly recommend oz-install ...
https://github.com/clalancette/oz
Depending on what exactly this appliance is going to be used for, then febootstrap & a supermin appliance might be an option for you too.
Rich.
On Sat, Nov 10, 2012 at 05:35:16PM +0000, Richard W.M. Jones wrote:
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote:
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap & a supermin appliance might be an option for you too.
Doesn't Oz have the same issue with needing to launch a virtual machine? I don't think we want to run the install under QEMU.
On Sat, Nov 10, 2012 at 02:40:02PM -0500, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 05:35:16PM +0000, Richard W.M. Jones wrote:
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote:
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap & a supermin appliance might be an option for you too.
Doesn't Oz have the same issue with needing to launch a virtual machine? I don't think we want to run the install under QEMU.
It does, but this isn't a huge problem because installation is so entirely I/O-bound.
Or do you mean it's a problem to run qemu at all? qemu certainly runs inside Koji just fine -- we run that all the time.
febootstrap works off the RPMs directly, but has other limitations.
Rich.
On Sat, Nov 10, 2012 at 05:35:16PM +0000, Richard W.M. Jones wrote:
I'd strongly recommend oz-install ... https://github.com/clalancette/oz
Okay, so, sell me on this. I know Oz is popular, especially in the OpenStack world, so we definitely want to make sure it works with Fedora. But what's the advantage over livemedia-creator, if we were to rework the koji appliance build for either one?
On Sat, Nov 10, 2012 at 06:55:09PM -0500, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 05:35:16PM +0000, Richard W.M. Jones wrote:
I'd strongly recommend oz-install ... https://github.com/clalancette/oz
Okay, so, sell me on this. I know Oz is popular, especially in the OpenStack world, so we definitely want to make sure it works with Fedora. But what's the advantage over livemedia-creator, if we were to rework the koji appliance build for either one?
One advantage is that Oz supports a great many different operating systems (including even Windows). Another is that it uses the actual installer from the OS to do its business, whereas livecd-creator [not used the newer livemedia-* stuff] does some sort of RPM-in-a-chroot install.
oz-install doesn't need root (or shouldn't -- at one point it did, but there was no reason for that and I asked Chris to change this).
So .. they're different things. I'm still unclear what sort of appliances you're trying to build and what for, and that will affect what tool you decide to use.
Rich.
On Sun, Nov 11, 2012 at 04:02:27PM +0000, Richard W.M. Jones wrote:
So .. they're different things. I'm still unclear what sort of appliances you're trying to build and what for, and that will affect what tool you decide to use.
This is the official image produced by Fedora for use in EC2 and for download to run in your own private cloud.
I can see the appeal of using livemedia-creator, presuming we can get it to work with the build system, but what extra would Oz get us for this case?
On Sun, Nov 11, 2012 at 06:35:50PM -0500, Matthew Miller wrote:
On Sun, Nov 11, 2012 at 04:02:27PM +0000, Richard W.M. Jones wrote:
So .. they're different things. I'm still unclear what sort of appliances you're trying to build and what for, and that will affect what tool you decide to use.
This is the official image produced by Fedora for use in EC2 and for download to run in your own private cloud.
I can see the appeal of using livemedia-creator, presuming we can get it to work with the build system, but what extra would Oz get us for this case?
Since it appears that you want a Fedora build only, not much.
BUT for some reason live CD builds have been added as this kind of sideways after-thought to Koji. I guess that's because livecd-creator had to run as root and had to do all sorts of strange stuff with device nodes. None of that is necessary once you've got virtualization, and indeed libguestfs proves we can build and run a complete VM during an ordinary Koji build, with no special permissions required.
Rich.
On Mon, Nov 12, 2012 at 11:13:15AM +0000, Richard W.M. Jones wrote:
BUT for some reason live CD builds have been added as this kind of sideways after-thought to Koji. I guess that's because livecd-creator had to run as root and had to do all sorts of strange stuff with device nodes. None of that is necessary once you've got virtualization, and indeed libguestfs proves we can build and run a complete VM during an ordinary Koji build, with no special permissions required.
Many of the Koji builders are actually virtualized themselves now, so if the build process is planning to spin up a new VM, it needs to either be forced to run on a hardware builder (because I really can't believe that the install under full emulation will be a reasonable use of resources) or grow a new ability to spin up a remote cloud instance.
This discussion should probably be taken over to the Fedora Infrastructure list. I'll start a new thread (because probably many people here aren't subscribed to that list).
On Mon, Nov 12, 2012 at 09:17:53AM -0500, Matthew Miller wrote:
Many of the Koji builders are actually virtualized themselves now, so if the build process is planning to spin up a new VM, it needs to either be forced to run on a hardware builder (because I really can't believe that the install under full emulation will be a reasonable use of resources) or grow a new ability to spin up a remote cloud instance.
This just makes things a lot more complex. I would measure the resources needed before taking any steps like that, because as I said before installers are I/O bound so as long as you use virtio you should be fine.
Maybe one day we'll have good nested virt though ...
Rich.
Richard W.M. Jones wrote:
Maybe one day we'll have good nested virt though ...
Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction.
Kevin Kofler
Am 12.11.2012 21:49, schrieb Kevin Kofler:
Richard W.M. Jones wrote:
Maybe one day we'll have good nested virt though ...
Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction
i think this will be possible in the future
VMware workstation supports ESXi with 64bit guests as long your CPU supports http://en.wikipedia.org/wiki/Extended_Page_Table or the AMD equivalent not having in mind currently
so it is much liekly to have it supported in KVM too over the long if it does not already exist and can only not be used by hardware lacking the cpu-features
On Mon, Nov 12, 2012 at 09:49:58PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Maybe one day we'll have good nested virt though ...
Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction.
We talked about this at the KVM Forum. Apparently Intel nested virt is *hard* .. the code is larger than the rest of KVM combined.
AMD nested virt was much easier, because AMD choose a completely different and much less hairy way to implement virt in the first place.
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Sat, 10 Nov 2012 11:12:20 -0500 Matthew Miller mattdm@fedoraproject.org escribió:
On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote:
I think appliance-creator is pretty much unsupported at this point, isn't it?
Yes, so moving to ami-creator might be a good choice.
livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package.
I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us.
Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening.
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
On another note, Boxgrinder also is based around appliance creator, and it'd be nice to play nicely with those people too.
Boxgrinder is not a viable option at all.
Dennis
On Mon, 12 Nov 2012, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Sat, 10 Nov 2012 11:12:20 -0500 Matthew Miller mattdm@fedoraproject.org escribió:
On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote:
I think appliance-creator is pretty much unsupported at this point, isn't it?
Yes, so moving to ami-creator might be a good choice.
livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package.
I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us.
Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening.
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
On another note, Boxgrinder also is based around appliance creator, and it'd be nice to play nicely with those people too.
Boxgrinder is not a viable option at all.
agreed - if for any reason than too many moving parts and a giant software stack behind it.
Dennis, ami-creator is what I've been using to make imgs for euca and I know it will work for ec2 imgs (provided you have a kernel/ramdisk which works with xen)
And ami-creator only requires a dead-standard stock kickstart file. (well you have to do various things in %post to make the img work when it is spun up in an instance but that's nothing different than normal kickstarty-ness.
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Sat, 10 Nov 2012 14:40:02 -0500 Matthew Miller mattdm@fedoraproject.org escribió:
On Sat, Nov 10, 2012 at 05:35:16PM +0000, Richard W.M. Jones wrote:
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote:
We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap & a supermin appliance might be an option for you too.
Doesn't Oz have the same issue with needing to launch a virtual machine? I don't think we want to run the install under QEMU.
the issue is entirely launching vms inside of chroots nothing else.
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote:
I think appliance-creator is pretty much unsupported at this point, isn't it?
Yes, so moving to ami-creator might be a good choice.
livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package.
I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us. We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17.
On Mon, Nov 12, 2012 at 07:04:29PM -0800, Brian C. Lane wrote:
adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17.
Huh. I guess the question is: *will* it work for F18 or beyond?
On Mon, Nov 12, 2012 at 05:48:05PM -0600, Dennis Gilmore wrote:
Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening.
Actually it was. That's one of the reasons why the --no-virt mode was added. The primary goal for livemedia-creator was to use the same codepath for creating installed systems and livemedia, not to duplicate how livecd-creator works (basically a chrooted yum install).
On Mon, Nov 12, 2012 at 10:05:50PM -0500, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 07:04:29PM -0800, Brian C. Lane wrote:
adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas?
livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17.
Huh. I guess the question is: *will* it work for F18 or beyond?
Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final.
More testing would be appreciated though, especially the EC2 code that I added blind.
On Mon, Nov 12, 2012 at 07:20:52PM -0800, Brian C. Lane wrote:
Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final.
With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19.
On Tue, Nov 13, 2012 at 09:40:06AM -0500, Matthew Miller wrote:
On Mon, Nov 12, 2012 at 07:20:52PM -0800, Brian C. Lane wrote:
Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final.
With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19.
Right, that decision was already made.
On 14/11/12 01:40, Matthew Miller wrote:
With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19.
Have we adopted livemedia-creator for 19, or still using livecd-creator?
-c
On Fri, May 31, 2013 at 10:57:51PM +1000, Chris Smart wrote:
On 14/11/12 01:40, Matthew Miller wrote:
With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19.
Have we adopted livemedia-creator for 19, or still using livecd-creator?
For cloud images, still appliance-tools, which uses livecd-tools. We'll get there (or to _something_ which uses anaconda under virt) eventually.
On Fri, 2013-05-31 at 22:57 +1000, Chris Smart wrote:
On 14/11/12 01:40, Matthew Miller wrote:
With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19.
Have we adopted livemedia-creator for 19, or still using livecd-creator?
Still livecd-creator for F19.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Brian C. Lane -
Chris Smart -
Dennis Gilmore -
Kevin Kofler -
Matthew Miller -
Reindl Harald -
Richard W.M. Jones -
Seth Vidal