On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Dennis
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
josh
On Thu, Feb 27, 2014 at 04:03:06PM -0500, Josh Boyer wrote:
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
Right, and as I understand it, there actually _is_ some level of support, and there was a GSoC project related to it a couple of years ago.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 16:03:06 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
josh
the issue we have with u-boot is that we may have to change how we do some things. Some hardware we have relied on vendor provided u-boots. likely we would need to ship and update the u-boot the vendor provides to add functionality. the trimslice for instance has a u-boot that only boots from ext2 or ext3 and lacks ext4 support. the vendor has said that they will not be shipping any more u-boot updates, so in the case there we are going to have to ship our own update to support the work that has been going on upstream to unify features and boot support. I have been working upstream to get things moved over to using the available pxe/extlinux linux support.
longer term /boot on xfs may be possible, but it will take work
Dennis
cloud@lists.stg.fedoraproject.org
-
Dennis Gilmore -
Josh Boyer -
Matthew Miller