8): avc: denied { sys_admin } for pid=1635
> comm="systemd-gpt-aut" capability=21
> scontext=system_u:system_r:systemd_gpt_generator_t:s0
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
> permissive=0
>
> I can’t find any impairments from it
On Sat, Oct 15, 2022 at 6:03 PM Peter Boy wrote:
> With branch 20221012 as well as 20221014 I get with Fedora Server on BIOS
> boot Hardware several AVC events like
>
> type=AVC msg=audit(1665848517.93:288): avc: denied { sys_admin } for
> pid=1635 comm="systemd-gpt-aut"
With branch 20221012 as well as 20221014 I get with Fedora Server on BIOS boot
Hardware several AVC events like
type=AVC msg=audit(1665848517.93:288): avc: denied { sys_admin } for pid=1635
comm="systemd-gpt-aut" capability=21
scontext=system_u:system_r:systemd_gpt_generator_t:s0
should have a test case to verify
> this behavior for all three Anaconda install modes (MBR+BIOS,
> GPT+BIOS, UEFI). If this is truly something we care about, then we
> should have communicated this need to the Anaconda team so that they
> would care about it, independent of this feature.
I don't understand why you stubbornly insist on this
> change proposal as is, instead of looking for solutions that keep mischief
> away from our users and change to GPT as default (which is undoubtedly the
> future standard).
GPT is already the default when the drive size is > 2 TB, fo
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy wrote:
>
>
>
> > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek
> > :
> >
> > On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
> >>
> >> ...
> >>
> >> And even those who can continue to use Fedora Server via update are under
> >>
f software RAID.
If we care about this behavior, we should have a test case to verify
this behavior for all three Anaconda install modes (MBR+BIOS,
GPT+BIOS, UEFI). If this is truly something we care about, then we
should have communicated this need to the Anaconda team so that they
would care abou
difficult) who have relied (and could rely) on us
so far to continue using Fedora Server. I consider this irresponsible. And I
don't understand why you stubbornly insist on this change proposal as is,
instead of looking for solutions that keep mischief away from our users and
change to G
eature.
>
It's going to replace inst.gpt. This is described in the Change document.
> And do we really want our users to fiddle around with editing boot line
> options as a standard procedure for using a standard use case?
>
It's not standard at all. We don't even test for this setup regu
> Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek
> :
>
> On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
>>
>> ...
>>
>> And even those who can continue to use Fedora Server via update are under
>> the threat of having to switch distributions overnight in the event of
ed the proposal and insists that the proposal be
> >> deferred until Anaconda can install software raid on biosboot systems with
> >> GPT (see https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
> >> https://lists.fedoraproject.org/archives/list/ser...@lists.fedo
> Am 30.05.2022 um 11:39 schrieb Colin Walters :
>
> Just a note: Fedora CoreOS has used a hybrid BIOS/UEFI setup since its
> inception, and also supports this "mirrored boot" setup:
>
> https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem
>
On Sun, May 29, 2022, at 6:55 AM, Peter Boy wrote:
>
> Fedora Server WG discussed the proposal and insists that the proposal
> be deferred until Anaconda can install software raid on biosboot
> systems with GPT (see
> https://bugzilla.redhat.com/show_bug.cgi?id=20881
own somewhere in Anaconda to force using MBR instead of GPT?
> but it wouldn't be a release blocking bug
That only makes the issue worse. If the bug were release-blocking, the
feature could be pushed forward under the (implied by default) condition
that the release-blocking bug be addressed
> Am 30.05.2022 um 04:28 schrieb Chris Murphy :
>
> On Sun, May 29, 2022 at 6:56 AM Peter Boy wrote:
>>
>>
>>
>>
>> Fedora Server WG discussed the proposal and insists that the proposal be
>> deferred until Anaconda can install software rai
gt; process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > This Change makes it so that Fedora Linux systems installed
is proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> This Change makes it so that Fedora Linux systems installed on legacy
> x86 BIOS systems will get GPT partitioning by default instead of
> legacy MBR partitioning. Th
On Mon, May 16, 2022 at 9:25 AM Gerd Hoffmann wrote:
>
> > == Benefit to Fedora ==
> > This simplifies our default code path by using the same partitioning
> > scheme as UEFI systems and aligns us more to how Fedora variants that
> > are delivered as disk images, which all use a similar setup. It
> == Benefit to Fedora ==
> This simplifies our default code path by using the same partitioning
> scheme as UEFI systems and aligns us more to how Fedora variants that
> are delivered as disk images, which all use a similar setup. It also
> paves the way to implement hybrid BIOS+UEFI boot for
Committee.
== Summary ==
This Change makes it so that Fedora Linux systems installed on legacy
x86 BIOS systems will get GPT partitioning by default instead of
legacy MBR partitioning. This makes x86 BIOS installs more similar to
x86 UEFI installs.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa
Committee.
== Summary ==
This Change makes it so that Fedora Linux systems installed on legacy
x86 BIOS systems will get GPT partitioning by default instead of
legacy MBR partitioning. This makes x86 BIOS installs more similar to
x86 UEFI installs.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa
On Thu, May 27, 2021 at 11:38 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
>
This proposal has been withdrawn by the owner.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
FWIW virt-builder uses:
zerombr
clearpart --all --initlabel --disklabel=gpt
autopart --type=plain
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual
On Fri, May 28, 2021 at 12:37 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > I don't know why we all missed it. Butt that appears to be the case.
> >
> > However, the end goal is to create hybrid BIOS+UEFI cloud images via
> > kickstart. (Maybe down the road it could be generally useful, if/when the
>
Hi,
> I don't know why we all missed it. Butt that appears to be the case.
>
> However, the end goal is to create hybrid BIOS+UEFI cloud images via
> kickstart. (Maybe down the road it could be generally useful, if/when the
> existing bootloader UI bits go away.)
On Thu, May 27, 2021, 10:28 AM Brian C. Lane wrote:
On Thu, May 27, 2021 at 11:38:56AM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
> >
> >
> > == Summary ==
> > Add support for configuring GPT partition table in k
On Thu, May 27, 2021 at 11:38:56AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
>
>
> == Summary ==
> Add support for configuring GPT partition table in kickstart without
> requiring a custom pre-installation script or a
https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
== Summary ==
Add support for configuring GPT partition table in kickstart without
requiring a custom pre-installation script or a custom boot script.
[[Category:SystemWideChange]]
== Owners ==
* Name: [[User:Davdunc|David Duncan
https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
== Summary ==
Add support for configuring GPT partition table in kickstart without
requiring a custom pre-installation script or a custom boot script.
[[Category:SystemWideChange]]
== Owners ==
* Name: [[User:Davdunc|David Duncan
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com wrote:
I have a system that corrupts the backup GPT on every reboot.
Certain RAID implementations write metadata at the end of the disk and
step on the backup GPT
On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian jbast...@redhat.com wrote:
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com wrote:
I have a system that corrupts the backup GPT on every reboot.
Certain RAID
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The fsck would just check the checksums of primary
secondary tables, and if an error in either (but not both) is
detected it would restore from
On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The fsck would just check the checksums of primary
secondary tables, and if an error
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
The bottom line question is, would it be useful to have an fsck_gpt
run by systemd at either startup or shutdown time?
I have a system that corrupts the backup GPT on every reboot: the CRC32
in the backup GPT is always 0. I run
On Thu, Oct 24, 2013 at 4:59 PM, John Reiser jrei...@bitwagon.com wrote:
On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The fsck would just
On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The fsck would just check the checksums of primary
secondary tables
edit of extent fields.
The tool also should diagnose protective MBR situations and
understand common values for partition type entries (both GPT and MBR).
It should provide the ability to overwrite any existing checksum
with the calculated correct checksum. The tool also should be able
to erase
the backup GPT on every reboot.
Certain RAID implementations write metadata at the end of the disk and step on
the backup GPT in this manner. But that was on computers with BIOS firmware
that weren't GPT aware. UEFI firmware obviously should be GPT aware so it'd be
quite a bungling if its firmware
. If anything, a heuristic more sophisticated than checksum pass-fail,
might indicate when NOT to do something in an unattended use context.
For instance if a valid GPT contains overlaps, yet the invalid one contains
entries that do not, and that invalid entry happens to be the primary GPT which
The bottom line question is, would it be useful to have an fsck_gpt run by
systemd at either startup or shutdown time? This wasn't needed for MBR, so it
seems kinda silly to suggest it, but there are some cases of one or the other
GPT being stepped on in a way that probably never happened
It sounds like your entry in your UEFI boot manager was erased. Did
you perform a UEFI update or clear it?
To fix it in the future run efibootmgr -c to reinsert the entry.
Aaaah. Thanks for pointing me at efibootmgr.
-benjamin
--
devel mailing list
devel@lists.fedoraproject.org
When my UEFI/GPT-based Fedora 17 box refused to boot yesterday, I ran
into the following trouble. The disk looked reasonably well from a
rescue system, so I naively figured that something might be wrong with
its initial sectors, and that grub2-install might magically fix that again.
First
UEFI is not BIOS. The command you were looking for is grub2-efi-install,
whereas grub2-install is for BIOS systems. The package you should already have
is grub2-efi. And on UEFI systems there are no boot sectors, there is a
partition dedicated for boot managers/loaders as EFI applications
On 12/12/2012 10:39 AM, Chris Murphy wrote:
UEFI is not BIOS. The command you were looking for is grub2-efi-install,
whereas grub2-install is for BIOS systems. The package you should already have
is grub2-efi. And on UEFI systems there are no boot sectors, there is a
partition dedicated for
Stephan Bergmann wrote:
Then, grub2-install /dev/sda still failed to work with this GPT
partition label contains no BIOS Boot Partition; embedding won't be
possible. In the end, I managed to get things working again with
re-installing Fedora 17 onto itself via CD, which has apparently
On Wed, 2012-12-12 at 14:23 +0100, Stephan Bergmann wrote:
On 12/12/2012 10:39 AM, Chris Murphy wrote:
UEFI is not BIOS. The command you were looking for is grub2-efi-install,
whereas grub2-install is for BIOS systems. The package you should already
have is grub2-efi. And on UEFI systems
On Sun, Apr 22, 2012 at 10:39:52PM +0100, Adam Williamson wrote:
I'm wondering if there is a grub option to force gpt for anaconda.
I'm not sure, but try 'gpt' maybe? I know 'nogpt' exists but I don't
know if there's a parameter to override the blacklist.
There is no cmdline option
On Apr 23, 2012 1:12 AM, Chris Murphy li...@colorremedies.com wrote:
On Apr 22, 2012, at 2:55 PM, Nikos Roussos wrote:
I already have a GPT partition (from my previous installation), but
Anaconda complains that my boot partition should be of type msdos. The
only way to proceed seems
I just tried to do a fresh installation with the F17 Beta Installation DVD
(x86_64). On the partitions stage I chose to use all space, discarding all
preexisting partitions, but it creates an msdos partition table instead of
gpt.
Is something changed on the default anaconda configuration since
On Apr 22, 2012, at 8:17 AM, Nikos Roussos wrote:
I just tried to do a fresh installation with the F17 Beta Installation DVD
(x86_64). On the partitions stage I chose to use all space, discarding all
preexisting partitions, but it creates an msdos partition table instead of
gpt
, but it creates an msdos partition table instead
of gpt.
Is something changed on the default anaconda configuration since F16?
What hardware do you have? It may be gpt blacklisted. I can't reproduce
your results, even starting out with a disk that's MBR using All Space
flips it to GPT.
It's
On 22/04/12 18:04, Nikos Roussos wrote:
I'm wondering if there is a grub option to force gpt for anaconda.
Unsure, I've always formatted as GPT (if applicable) before install.
--
Regards,
Frank
Jack of all, fubars
--
devel mailing list
devel@lists.fedoraproject.org
https
On Sun, Apr 22, 2012 at 08:04:48PM +0300, Nikos Roussos wrote:
It's a lenovo thinkpad (edge). I remember a bug about some thinkpad models
having problem with gpt, but it would seem to me as an extreme action if
all lenovo models were blacklisted. Gpt was working just fine on F16 on the
same
On Apr 22, 2012, at 11:04 AM, Nikos Roussos wrote:
It's a lenovo thinkpad (edge). I remember a bug about some thinkpad models
having problem with gpt, but it would seem to me as an extreme action if all
lenovo models were blacklisted. Gpt was working just fine on F16 on the same
hardware
Is there a compelling reason to want GPT? The format itself is better
than MBR, but unless I required (a) disk 2TB or (b) lots of primary
partitions, I wouldn't worry ...
GPT is more robust in some ways. GPT keeps a redundant copy of its info:
at the far end as well as at the beginning
On Sun, Apr 22, 2012 at 11:23:55AM -0700, John Reiser wrote:
Is there a compelling reason to want GPT? The format itself is better
than MBR, but unless I required (a) disk 2TB or (b) lots of primary
partitions, I wouldn't worry ...
GPT is more robust in some ways. GPT keeps a redundant
On Sun, Apr 22, 2012 at 8:20 PM, Chris Murphy li...@colorremedies.com wrote:
On Apr 22, 2012, at 11:04 AM, Nikos Roussos wrote:
It's a lenovo thinkpad (edge). I remember a bug about some thinkpad models
having problem with gpt, but it would seem to me as an extreme action if all
lenovo models
I already have a GPT partition (from my previous installation), but
Anaconda complains that my boot partition should be of type msdos. The
only way to proceed seems to be discarding all partitions and creating
an msdos partition table.
It worked for me on a white-box clone with exactly one
chose to use all
space, discarding all preexisting partitions, but it creates an msdos
partition table instead of gpt.
Is something changed on the default anaconda configuration since
F16?
What hardware do you have? It may be gpt blacklisted. I can't
reproduce your results, even
On Sun, 2012-04-22 at 11:20 -0600, Chris Murphy wrote:
On Apr 22, 2012, at 11:04 AM, Nikos Roussos wrote:
It's a lenovo thinkpad (edge). I remember a bug about some thinkpad
models having problem with gpt, but it would seem to me as an
extreme action if all lenovo models were blacklisted
On Apr 22, 2012, at 2:55 PM, Nikos Roussos wrote:
I already have a GPT partition (from my previous installation), but
Anaconda complains that my boot partition should be of type msdos. The
only way to proceed seems to be discarding all partitions and creating
an msdos partition table.
Well
On 02/07/2012 12:54 AM, Adam Williamson wrote:
On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
On 02/06/2012 10:40 PM, Brian C. Lane wrote:
In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo hardware, we found
On Mar 2, 2012, at 10:37 AM, Pádraig Brady wrote:
Yep as expected F17 alpha is broken in the same way on my laptop.
Your laptop is what hardware? Any install media kernel parameters used? What
installation type? Can you provide both an fdisk and parted (or gdisk) listing
of the
/optimal): 512 bytes / 512 bytes
Disk identifier: 0x
Device Boot Start End Blocks Id System
/dev/sda1 * 1 976773167 488386583+ ee GPT
Model: ATA ST9500420AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk
On Mar 2, 2012, at 2:20 PM, Pádraig Brady wrote:
Model: ATA ST9500420AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End SizeFile system Name Flags
1 1049kB 2097kB 1049kB
On Fri, 2012-03-02 at 17:37 +, Pádraig Brady wrote:
On 02/07/2012 12:54 AM, Adam Williamson wrote:
On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
On 02/06/2012 10:40 PM, Brian C. Lane wrote:
In Fedora 16 we changed to using GPT as the default disklabel for new
installs
In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo hardware, we found
that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
back to msdos labels in order to solve this.
Thanks to Matthew Garrett we found
On Feb 6, 2012, at 3:40 PM, Brian C. Lane wrote:
In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
so that pmbr_boot is always set on GPT labeled installs. This should
ensure that thing boot correctly.
Is this happening only for Lenovo hardware? Or all hardware? I ask
On 02/06/2012 10:40 PM, Brian C. Lane wrote:
In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo hardware, we found
that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
back to msdos labels in order
On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
On 02/06/2012 10:40 PM, Brian C. Lane wrote:
In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo hardware, we found
that some BIOS's would not boot from GPT. We
On Mon, Feb 06, 2012 at 04:54:01PM -0800, Adam Williamson wrote:
On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
On 02/06/2012 10:40 PM, Brian C. Lane wrote:
In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo
Fedora does not
touch the
partition table at all. On all other systems GPT is the way to go I'd
say...
In F16 is it still possible to force creation of MSDOS partition table
without GPT using a kickstart script ?
Or with some boot/cmdline option?
Afaik
to agree on what that happens to be.
On systems with legacy operating systems installed Fedora does not touch the
partition table at all. On all other systems GPT is the way to go I'd say...
In F16 is it still possible to force creation of MSDOS partition table
without GPT using a kickstart
. Fedora installation must by default do
the right thing. We need to agree on what that happens to be.
On systems with legacy operating systems installed Fedora does not touch
the
partition table at all. On all other systems GPT is the way to go I'd say...
In F16 is it still possible
Fedora does not
touch the
partition table at all. On all other systems GPT is the way to go I'd
say...
In F16 is it still possible to force creation of MSDOS partition table
without GPT using a kickstart script ?
Or with some boot/cmdline option?
Afaik
On Fri, Aug 26, 2011 at 10:04 PM, Lars Seipel
lars.sei...@googlemail.com wrote:
btw, I just installed F16 on an EFI machine and got Grub Legacy. Are there any
major problems with Grub 2's EFI support?
From a brief conversation I had earlier this week, yes there are. The
plan is grub2 for BIOS
- intentionally, as I don't know the answer -
is whether Windows will boot if you have a BIOS boot partition on a
GPT-labelled drive. It may do.
Windows and GPT FAQ:
Q. Can Windows 7, Windows Vista, and Windows Server 2008 read, write,
and boot from GPT disks?
A. Yes, all versions can use GPT
On 08/25/2011 08:11 PM, Adam Williamson wrote:
To boot to a GPT disk from BIOS (rather than EFI) you need a BIOS boot
partition. If you use one of the automatic partitioning methods, rather
than manual partitioning, F16's installer will create one for you. If
you choose manual partitioning
On Fri, Aug 26, 2011 at 04:29:55PM +0200, Karel Zak wrote:
Windows and GPT FAQ:
Q. Can Windows 7, Windows Vista, and Windows Server 2008 read, write,
and boot from GPT disks?
A. Yes, all versions can use GPT partitioned disks for data.
Booting is only supported for 64-bit
On Friday, August 26, 2011, 3:35:52 PM, Andrew McNabb wrote:
On Fri, Aug 26, 2011 at 04:29:55PM +0200, Karel Zak wrote:
Windows and GPT FAQ:
Q. Can Windows 7, Windows Vista, and Windows Server 2008 read, write,
and boot from GPT disks?
A. Yes, all versions can use GPT partitioned
systems installed Fedora does not touch the
partition table at all. On all other systems GPT is the way to go I'd say...
On a related topic, why in heaven's name is Fedora not including the
simple grub setup commands that are familiar to Ubuntu users? Making
folks remember a long form
While installing Fedora 16 Alpha, I ran into some problems that turned
out to be caused by the installer formatting with a GPT rather than an
MBR partition table.
I would like to understand the change and its implications, and I have
unsuccessfully tried to track down more information. I haven't
On Thu, 2011-08-25 at 16:17 -0600, Andrew McNabb wrote:
While installing Fedora 16 Alpha, I ran into some problems that turned
out to be caused by the installer formatting with a GPT rather than an
MBR partition table.
I would like to understand the change and its implications, and I have
On Thu, 2011-08-25 at 17:11 -0700, Adam Williamson wrote:
On Thu, 2011-08-25 at 16:17 -0600, Andrew McNabb wrote:
While installing Fedora 16 Alpha, I ran into some problems that turned
out to be caused by the installer formatting with a GPT rather than an
MBR partition table.
I would
On Thu, Aug 25, 2011 at 07:17:58PM -0500, David Lehman wrote:
It's also true that if you create an msdos/mbr partition table on your
disk prior to installation and then choose any option except for Use
All Space (or clearpart --all in kickstart) anaconda will not destroy
your existing
On Thu, Mar 18, 2010 at 11:25:45PM -0500, Matt Domsch wrote:
On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote:
Hi,
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1
partition, that contains the new GPT header and partitions.
Regards
Till
pgp17WgkrZOL9.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote:
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1] and it seems to work nicely already on F12. I just
partitioned a new HD using gdisk
On Fri, Mar 19, 2010 at 01:04:29PM +, David Woodhouse wrote:
On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote:
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1] and it seems
of partitioning tables? Why /not/ go
forward to GPT, I think that's the more appropriate question.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
Am 19.03.10 17:52, schrieb Jesse Keating:
Why deal with two different types of partitioning tables? Why /not/ go
forward to GPT, I think that's the more appropriate question.
No all operating systems are able to support GPT, so there may be nice
to have
a hybrid partition schema
On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote:
Hi,
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1] and it seems to work nicely already on F12. I just
partitioned a new HD
On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote:
Yes!
Hopefully BIOS support won't be a problem because of gptsync. Can we
also get gptsync packaged separately, instead of having an odd version
bundled with Anaconda ...
A first incomplete Feature page is available here:
On Fri, Mar 19, 2010 at 09:39:05PM +0100, Till Maas wrote:
On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote:
Yes!
Hopefully BIOS support won't be a problem because of gptsync. Can we
also get gptsync packaged separately, instead of having an odd version
bundled
Hi,
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1] and it seems to work nicely already on F12. I just
partitioned a new HD using gdisk and the kernel seems to recognise it
without any
On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote:
Hi,
how about using GPT[0] partitions for F14 for all installations that wipe
the whole disk to install Fedora? It is also considered to be good by
Tejun Heo[1] and it seems to work nicely already on F12. I just
partitioned a new HD
On 03/18/2010 09:25 PM, Matt Domsch wrote:
Very few BIOSes can boot from a GPT disk. EFI/UEFI can, as can legacy
BIOS if you do something ugly like gptsync so the MBR partition table
and the GPT partition table at least somewhat agree.
Does this mean that the presence of a GPT partition table
97 matches
Mail list logo
