I have changed the title to "Anaconda Installer Using GPT on all
architectures by Default" and updated the description as well. I'll be
happy to work with Neil to extend the scope to image creation as well,
but my original idea was to cover only the installer defaults the same
way
t appear in
> > the title, Summary, or Detailed Description at all. One needs to read
> > until the very end to understand that this would only apply to images
> > created with Anaconda.
> >
>
> Well, I'd rather we actually did the same thing elsewhere too.
&g
y to images
> created with Anaconda.
>
Well, I'd rather we actually did the same thing elsewhere too.
Consistency here is valuable wherever we can achieve it.
I was surprised to learn we can use GPT on IBM Z, so it's being
explored to support it in kiwi:
https://github.com/OSInsi
On Thu, Dec 12, 2024 at 07:59:28PM +0100, Simon de Vlieger wrote:
> On 12/12/24 5:04 PM, Vojtech Trefny wrote:
> > The default we have in blivet actually applies only to systems
> > installed with Anaconda so this would not be true for many ARM
> > systems. The images used with arm-image-installer
Support for discoverable partitions was added in Fedora 40:
https://anaconda-installer.readthedocs.io/en/latest/release-notes.html#discoverable-gpt-partitions
On Thu, Dec 12, 2024 at 8:22 PM Simon de Vlieger wrote:
>
> Would it make sense to also change to the use of DDI [1] partition type
On 12/12/24 5:04 PM, Vojtech Trefny wrote:
The default we have in blivet actually applies only to systems
installed with Anaconda so this would not be true for many ARM
systems. The images used with arm-image-installer are different.
While it is mentioned under scope the title of the change pro
Would it make sense to also change to the use of DDI [1] partition types
in these GPT tables if we're about to go through them?
[1]:
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Regards,
Simon
--
___
On 12/12/24 6:32 PM, Neal Gompa wrote:
A hybrid GPT+MBR environment could fix this, couldn't it? In general,
I would prefer to use GPT everywhere, and I know there are
compatibility schemes for supporting MBR "stuff" with GPT.
A hybrid MBR+GPT would fix this and would be ne
On Thu, Dec 12, 2024 at 12:05 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > We can technically do this, but it will cut off a bunch of ARM boards.
> > In particular, we discovered that Raspberry Pis had problems with
> > pure-GPT[1], so I forced pure MBR for now[2] while w
Hi,
> We can technically do this, but it will cut off a bunch of ARM boards.
> In particular, we discovered that Raspberry Pis had problems with
> pure-GPT[1], so I forced pure MBR for now[2] while we figure out if
> there's even a reasonable path to GPT for ARM images.
On Thu, Dec 12, 2024 at 4:32 PM Chris Adams wrote:
>
> Once upon a time, Aoife Moloney via devel-announce
> said:
> > Because GPT was already the default
> > for ARM64
>
> FYI this doesn't appear to be the case - I have a fresh install of
> Fedora 41 on
On Thu, Dec 12, 2024 at 10:25 AM Chris Adams wrote:
>
> Once upon a time, Aoife Moloney via devel-announce
> said:
> > Because GPT was already the default
> > for ARM64
>
> FYI this doesn't appear to be the case - I have a fresh install of
> Fedora 41 on
Once upon a time, Aoife Moloney via devel-announce
said:
> Because GPT was already the default
> for ARM64
FYI this doesn't appear to be the case - I have a fresh install of
Fedora 41 on a Raspberry Pi 4B, using arm-image-installer to write the
server image to a microSD card, and i
Wiki - https://fedoraproject.org/wiki/Changes/GPTforAllByDefault
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-install-using-gpt-on-all-architectures-by-default-system-wide/139538
This is a proposed Change for Fedora Linux.
This document represents a proposed
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
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 about it, independent of
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 GPT as default (which is undoubtedly the
> future standard).
GPT is alread
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
> >> the
y use hardware RAID there
instead of 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 Anacond
makes it unnecessarily overly 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
undocumented feature.
>
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&#
> 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
> https://gi
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
or
dropdown 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 bu
> 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
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
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. This
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 lega
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.)
https://git.kraxel.org/cgit/i
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 kic
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
On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian wrote:
> On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
>> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian wrote:
>>> I have a system that corrupts the backup GPT on every reboot.
>>
>> Certain RAID impleme
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian 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
> system even more.
Right. 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 happen
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian wrote:
> 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 corru
quot;maximum wins", or arbitrary 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 ca
On Oct 24, 2013, at 2: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 primar
On Thu, Oct 24, 2013 at 4:59 PM, John Reiser 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 sensibl
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.
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
&
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
det
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 happen
> 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
https
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 sy
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-installin
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 bo
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 called
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
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
On Apr 23, 2012 1:12 AM, "Chris Murphy" 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
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 par
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 act
D (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
> F16?
> >>
> >>
> 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 cl
On Sun, Apr 22, 2012 at 8:20 PM, 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 mod
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 r
> 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
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 F
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 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.fed
itions, 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 tha
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
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 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
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
/physical): 512 bytes / 512 bytes
I/O size (minimum/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 (lo
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 post-installa
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 lim
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 f
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'
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 l
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
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
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
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
ting 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
> > with
; with a disk of 2 TB or less. 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 al
; 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 to force creation of MSDO
On Fri, Aug 26, 2011 at 10:04 PM, Lars Seipel
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 based machines, grub for
th 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...
> 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
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?
>>
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
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
>
Fedora to a clean disk, then it will never be
> > possible to later install Windows, right?
>
> One thing I didn't answer - 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.
Window
answer - 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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.
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 existin
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
> >
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 impl
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&#
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
> >
1 - 100 of 114 matches
Mail list logo
