If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set. --- fedora-cloud-base-vagrant.ks | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-cloud-base-vagrant.ks b/fedora-cloud-base-vagrant.ks index f7f1518..855bfee 100644 --- a/fedora-cloud-base-vagrant.ks +++ b/fedora-cloud-base-vagrant.ks @@ -19,7 +19,7 @@ rootpw vagrant # even on VirtualBox virt, we get a primary network device with "eth0" as the name # This simplifies things and allows a single disk image for both supported Vagrant # platforms (virtualbox and kvm) -bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0" +bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0" --extlinux
%packages # The default koji Vagrantfile configuration uses rsync to sync files between
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Peter
On 05/03/2016 07:34 PM, Peter Robinson wrote:
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Hey Peter,
Thanks for bringing this up. I'll check that it works on the various targets.
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
I'd like to keep the cloud base and the cloud base vagrant image using the same bootloader for consistency. If we hit problems with extlinux for vagrant then I'd prefer we switch both cloud base and cloud base vagrant images back to grub2. I'd prefer to not have them differ on that front.
What do you think?
On 05/03/2016 07:34 PM, Peter Robinson wrote:
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Hey Peter,
Thanks for bringing this up. I'll check that it works on the various targets.
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
I'd like to keep the cloud base and the cloud base vagrant image using the same bootloader for consistency. If we hit problems with extlinux for vagrant then I'd prefer we switch both cloud base and cloud base vagrant images back to grub2. I'd prefer to not have them differ on that front.
What do you think?
Personally not bothered either way. I know a lot of hypervisors are now defaulting to uEFI for virtual BIOSes now because it's needed for recent versions Windows etc and I'm not sure extlinux works in that use case. So it's probably worth seeing where VMware/Parallels/VirtualBox/HyperV are headed in this regards and if it works there. We can now actually distribute a uEFI firmware with Fedora (edk2-ovmf package currently in f25, built for f24) so it might be worth even starting with that to see if extlinux boots with it.
From a non x86 cloud image using grub2 would be preferable for me with my secondary arches hat on as it means we could end up using a single kickstart, but it's a minor point/advantage.
Peter
On 05/04/2016 05:03 AM, Peter Robinson wrote:
On 05/03/2016 07:34 PM, Peter Robinson wrote:
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Hey Peter,
Thanks for bringing this up. I'll check that it works on the various targets.
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
I'd like to keep the cloud base and the cloud base vagrant image using the same bootloader for consistency. If we hit problems with extlinux for vagrant then I'd prefer we switch both cloud base and cloud base vagrant images back to grub2. I'd prefer to not have them differ on that front.
What do you think?
Personally not bothered either way. I know a lot of hypervisors are now defaulting to uEFI for virtual BIOSes now because it's needed for recent versions Windows etc and I'm not sure extlinux works in that use case. So it's probably worth seeing where VMware/Parallels/VirtualBox/HyperV are headed in this regards and if it works there. We can now actually distribute a uEFI firmware with Fedora (edk2-ovmf package currently in f25, built for f24) so it might be worth even starting with that to see if extlinux boots with it.
From a non x86 cloud image using grub2 would be preferable for me with my secondary arches hat on as it means we could end up using a single kickstart, but it's a minor point/advantage.
I just want to make sure I understand that last point correctly:
- For non-x86 arches it is better if we are using grub
Is that a correct statement?
Dusty
On Wed, May 4, 2016 at 1:13 PM, Dusty Mabe dusty@dustymabe.com wrote:
On 05/04/2016 05:03 AM, Peter Robinson wrote:
On 05/03/2016 07:34 PM, Peter Robinson wrote:
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Hey Peter,
Thanks for bringing this up. I'll check that it works on the various targets.
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
I'd like to keep the cloud base and the cloud base vagrant image using the same bootloader for consistency. If we hit problems with extlinux for vagrant then I'd prefer we switch both cloud base and cloud base vagrant images back to grub2. I'd prefer to not have them differ on that front.
What do you think?
Personally not bothered either way. I know a lot of hypervisors are now defaulting to uEFI for virtual BIOSes now because it's needed for recent versions Windows etc and I'm not sure extlinux works in that use case. So it's probably worth seeing where VMware/Parallels/VirtualBox/HyperV are headed in this regards and if it works there. We can now actually distribute a uEFI firmware with Fedora (edk2-ovmf package currently in f25, built for f24) so it might be worth even starting with that to see if extlinux boots with it.
From a non x86 cloud image using grub2 would be preferable for me with my secondary arches hat on as it means we could end up using a single kickstart, but it's a minor point/advantage.
I just want to make sure I understand that last point correctly:
- For non-x86 arches it is better if we are using grub
Is that a correct statement?
Sort of, more correct is "for non x86 arches grub is the only option" IE there's no extlinux for Power64 for example, and in the arm* case the extlinux support is not really the same as it is on x86 (it's not a bootloader per say there, but more the firmware supports the extlinux config to boot linux directly).
Peter
On Tue, May 03, 2016 at 11:50:13PM -0400, Dusty Mabe wrote:
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
Just to be clear: if we can get grub2 packaging to a reasonable size, I don't have a strong opinion.
On 05/04/2016 11:30 AM, Matthew Miller wrote:
On Tue, May 03, 2016 at 11:50:13PM -0400, Dusty Mabe wrote:
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
Just to be clear: if we can get grub2 packaging to a reasonable size, I don't have a strong opinion.
Looks like part of the secret here is to break the grub2 dependency on the fedora-logos package, among other things.
On Wed, May 04, 2016 at 03:30:36PM -0400, Dusty Mabe wrote:
Just to be clear: if we can get grub2 packaging to a reasonable size, I don't have a strong opinion.
Looks like part of the secret here is to break the grub2 dependency on the fedora-logos package, among other things.
Yes. https://bugzilla.redhat.com/show_bug.cgi?id=875144
On 05/03/2016 11:50 PM, Dusty Mabe wrote:
On 05/03/2016 07:34 PM, Peter Robinson wrote:
On Tue, May 3, 2016 at 10:27 PM, Dusty Mabe dusty@dustymabe.com wrote:
If we don't do this it will try to use grub2 but will fail because we removed the packages from the package set.
And does extlinux work in all the Vagrant use cases (I've never used it)? My understanding of using extlinux was because it was small and works on AWS for those images, in the case of vagrant it's 40Gb in size so size is not really an issue here and grub2 likely works better in the developer workstations (what ever Windows/Mac user use for hypervisors) use case so it might be better to explicitly add the packages to the vagrant image rather than move it to extlinux.
Hey Peter,
Thanks for bringing this up. I'll check that it works on the various targets.
This works on both virtualbox and libvirt vagrant providers. These are the two we cover right now so that should suffice.
I had previously suggested that we go back to using grub2 (like we did in F23) for fedora cloud base (both base and vagrant images) but dgilmore/mattdm, and I decided to stick with extlinux for the space savings. This assumes that we don't hit any problems in testing.
I'd like to keep the cloud base and the cloud base vagrant image using the same bootloader for consistency. If we hit problems with extlinux for vagrant then I'd prefer we switch both cloud base and cloud base vagrant images back to grub2. I'd prefer to not have them differ on that front.
What do you think?
-
Dusty Mabe -
Matthew Miller -
Peter Robinson