Re: Current test branch: Error message systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
> Am 17.10.2022 um 10:44 schrieb Zdenek Pytela :
>
>
>
> 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" 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 so far.
>
> ….
> Hello Peter,
>
> I believe this AVC is harmless, refer to a systemd bz for more details:
> https://bugzilla.redhat.com/show_bug.cgi?id=2083900
>
> and related kernel one:
> https://bugzilla.redhat.com/show_bug.cgi?id=2122888
>
Hi Zdenek,
thanks for the info. I’ll add a corresponding note to our Fedora Server
Documentation (unfortunately, when installing ServerVM via the console, it is
very visible and could irritate a user).
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Current test branch: Error message systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
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" 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 so far.
>
> I couldn’t find anything about it besides an old bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1499479
>
>
> Does anyone have information on whether this can be safely ignored?
>
>
>
> Some Details:
>
> Deploying the ServerKVM immediately after completing the first boot
> configuration I get 2 times the message
>
> systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
>
> The system proceeds with any problem and finally shows the login prompt.
>
> Accordingly I find in audit.log:
>
> type=AVC msg=audit(1665836956.540:288): avc: denied { sys_admin } for
> pid=1249 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
>
>
> The same happens with a standard installation of Fedora Server on
> hardware. The system boots to login without issues. But as soon as I
> perform a file operation, e.g. creating log. volume and a filesystem I get
> the same AVC event.
>
> 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
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
> permissive=0
>
Hello Peter,
I believe this AVC is harmless, refer to a systemd bz for more details:
https://bugzilla.redhat.com/show_bug.cgi?id=2083900
and related kernel one:
https://bugzilla.redhat.com/show_bug.cgi?id=2122888
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Zdenek Pytela
Security SELinux team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Current test branch: Error message systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
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
tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
permissive=0
I can’t find any impairments from it so far.
I couldn’t find anything about it besides an old bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1499479
Does anyone have information on whether this can be safely ignored?
Some Details:
Deploying the ServerKVM immediately after completing the first boot
configuration I get 2 times the message
systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
The system proceeds with any problem and finally shows the login prompt.
Accordingly I find in audit.log:
type=AVC msg=audit(1665836956.540:288): avc: denied { sys_admin } for pid=1249
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
The same happens with a standard installation of Fedora Server on hardware. The
system boots to login without issues. But as soon as I perform a file
operation, e.g. creating log. volume and a filesystem I get the same AVC event.
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
tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
permissive=0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 03.06.2022 um 07:17 schrieb Neal Gompa : > > > It's not *that* typical in my experience. Most of the SME server > environments I know of don't have that. It's more common in larger > server environments, but they also typically use hardware RAID there > instead of software RAID. We don’t have detailed numbers how Fedora is used. But we know from questions and discussions that people use software raid. And software raid is supported by Anaconda for years now. And in my memory, these were all cases in the private or SME environment, and often with rented hardware in some commercial data centers, where hardware raid is usually offered at a considerable price premium. Anyway, we have users who use software raid and rely on us as a distribution, and they should be able to continue to do so in my opinion. > 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 about it, independent of this feature. We have test cases for the former 2 in issue #87 (https://pagure.io/fedora-server/issue/87) and Stephen Gallagher copied it to a bugzilla bug report (https://bugzilla.redhat.com/show_bug.cgi?id=2092116). I’ll add a UEFI test case to a separate issue this weekend. I’ve it already in place on my test equipment here and have just to copy and paste it. > dmraid has been unmaintained … Yes, of course, it’s mdadm. That was a slip into the good old days. Don’t mind. > calling it "mischief" is disingenuous, since until this week, nobody > ever mentioned this case at all. We even discussed the GPT thing > before I proposed the Change and it did not come up. > Yes, when we discussed this in the server IRC meeting before the change proposal was published, I hadn't thought of it either. But all of us know it since about one year. But we missed to pick it up carry it forward. > You know why I want this Change, and I even wrote it into the > proposal. We have to do *something* to start preparing new installs > for a world when legacy BIOS is *gone*, and switching to GPT is a > simple first step to doing that. Yes, I know, and we completely agree on that from the very beginning. My only suggestion is to organize this changeover process in such a way that our users are not negatively affected in any way. And about this there were (hopefully just) misunderstandings, which we could clarify by now. The changeover only affects Workstation and Server anyway. All others are either spins of Workstation or do not use Anaconda. So, let’s try to convince the Anaconda team to fix the GPT biosboot issue until beta. And if they need more time, let’s either postpone the switch to F38 or switch Workstation now (provided there are no software raid users) and switch Server as soon as the Anaconda bug is fixed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > It's not standard at all. We don't even test for this setup regularly. > > It's not a test case, and it's not even supposed to work right now. > > It’s standard as it is a typical use case in private or SME environments. If that's true there should be plenty of people willing to put in the work to make this work reliably. So far they haven't, in particular on UEFI. > And do you really think we distribute dmraid for years now "and it's not even > supposed to work right now.“? dmraid is deprecated in favor of either mdadm or LVM based RAID (both use the kernel's md driver as the backend), for a very long time. dmraid is even deprecate at least as far back as RHEL 7.6 > And don't hide behind formalistic arguments that just suit you by chance. > Your change proposal deliberately makes it impossible for existing server > users (or 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 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, for about a decade. GPT is the default on UEFI since the start. So the problem you're talking about, while real, seems to be a low enough of a priority that no one really wants to fix the problem - so far. You continue to use emotionally charged language as both a distraction from the real issue as well as a motivator to stop a feature. The reality is MBR support is going away, because BIOS support is going away. This feature is part of moving forward with that reality. We cannot make people do work they don't want to do. The solution to the degraded raid problem is actually relatively well understood, it's just that insufficient resources have come forward to actually solve the issue. But that cannot be an impediment for making other necessary changes. > > Also, any system with drives >=2TB will get GPT automatically, you > > can't have MBR in those setups. All this does is remove the default > > special case for smaller disks. > > This is a completely different case. For disks > 2 TB simply nothing changes, > neither better nor worse. For disks < 2 TB your change proposal results in a > deterioration. Why do you want it so badly? It's not completely different, it results in the *exact* problem you're complaining about. You don't get to say the effect of GPT > 2T is OK, but it's a negative when applied to < 2T as if your entire strategy for working "standard" and "typical" use cases means < 2T drives are mandatory. If the use case is important, the issue needs to be fixed. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
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 threat of having to switch distributions overnight in the event of a > >> technical error. Fedora will become unusable for them. A great "feature", > >> that you would like to introduce, obviously at all costs. > > > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > > the issue.) > > > According to the latest Anaconda documentation [1] there is no option > inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. > > 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? Define standard. I can't tell what you mean by it here. Bootable degraded raid is not a common use case. It's not a default and preset configuration in the installer. You really have to know what you're doing, and you have to know the installer's idiosyncrasies to make the installation work this way. This use case is not in the Server edition product requirements doc, or technical spec doc, or in Fedora release criterion It is true that the use case is reasonable and useful, but it is also unusual. If it's really important, then it at least needs a discussion on the test@ list, with QA folks about how to go about making it a release criterion, which minimally involves (a) writing up the criterion, using unambiguous language, narrowly defining the requirement (b) documentation changes (c) creating test cases (d) resources to actually run the test cases every release cycle (e) optionally+hopfully some portion of the testing can be automated but all the previous items are prerequisites to that. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Fri, Jun 3, 2022 at 12:19 AM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > It's not standard at all. We don't even test for this setup regularly. > > It's not a test case, and it's not even supposed to work right now. > > It’s standard as it is a typical use case in private or SME environments. > It's not *that* typical in my experience. Most of the SME server environments I know of don't have that. It's more common in larger server environments, but they also typically 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 Anaconda team so that they would care about it, independent of this feature. > And do you really think we distribute dmraid for years now "and it's not even > supposed to work right now.“? > dmraid has been unmaintained for over 15 years, so yes I do. It was dropped from RHEL 8 as well. It only exists in Fedora because someone decided to not retire the package, but upstream has been dead since the early 2000s. > And don't hide behind formalistic arguments that just suit you by chance. > Your change proposal deliberately makes it impossible for existing server > users (or 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 from our users and change to GPT as default (which is undoubtedly the > future standard). > Outside of having Anaconda create BIOS boot partitions and install the bootloader on every disk, there's no solution for this problem. Also, calling it "mischief" is disingenuous, since until this week, nobody ever mentioned this case at all. We even discussed the GPT thing before I proposed the Change and it did not come up. > > > Also, any system with drives >=2TB will get GPT automatically, you > > can't have MBR in those setups. All this does is remove the default > > special case for smaller disks. > > This is a completely different case. For disks > 2 TB simply nothing changes, > neither better nor worse. For disks < 2 TB your change proposal results in a > deterioration. Why do you want it so badly? > You know why I want this Change, and I even wrote it into the proposal. We have to do *something* to start preparing new installs for a world when legacy BIOS is *gone*, and switching to GPT is a simple first step to doing that. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > It's not standard at all. We don't even test for this setup regularly. > It's not a test case, and it's not even supposed to work right now. It’s standard as it is a typical use case in private or SME environments. And do you really think we distribute dmraid for years now "and it's not even supposed to work right now.“? And don't hide behind formalistic arguments that just suit you by chance. Your change proposal deliberately makes it impossible for existing server users (or 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 from our users and change to GPT as default (which is undoubtedly the future standard). > Also, any system with drives >=2TB will get GPT automatically, you > can't have MBR in those setups. All this does is remove the default > special case for smaller disks. This is a completely different case. For disks > 2 TB simply nothing changes, neither better nor worse. For disks < 2 TB your change proposal results in a deterioration. Why do you want it so badly? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 9: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 threat of having to switch distributions overnight in the event of a > >> technical error. Fedora will become unusable for them. A great "feature", > >> that you would like to introduce, obviously at all costs. > > > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > > the issue.) > > > According to the latest Anaconda documentation [1] there is no option > inst.mbr, there is just inst.gpt. Maybe, it is an 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't even test for this setup regularly. It's not a test case, and it's not even supposed to work right now. Also, any system with drives >=2TB will get GPT automatically, you can't have MBR in those setups. All this does is remove the default special case for smaller disks. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> 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 a >> technical error. Fedora will become unusable for them. A great "feature", >> that you would like to introduce, obviously at all costs. > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > the issue.) According to the latest Anaconda documentation [1] there is no option inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. 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? [1] https://anaconda-installer.readthedocs.io/en/latest/boot-options.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > > > > 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 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.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > >> - at least for Fedora Server where software raid is a common use. > > > > What's the basis for holding up this feature though? > > Sorry, under the current circumstances your „feature“ is effectively a > regression. It would make it impossible for many Fedora Server users to > continue using Fedora Server as soon as they have to re-install or just want > to set up a new additional server. > > 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 a > technical error. Fedora will become unusable for them. A great "feature", > that you would like to introduce, obviously at all costs. Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger the issue.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> 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://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.md > https://github.com/coreos/butane/pull/162 Thanks for the hint! I could curiously just take a quick look at it (due to a very tight schedule). According to my impression - It is not a ready-to-use solution to empower an Anaconda based installation - We would have to develop a lot of adjustments or replace Anaconda I hope I have understood this reasonably correctly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
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=2088113 and > https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > > - at least for Fedora Server where software raid is a common use. 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://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.md https://github.com/coreos/butane/pull/162 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
Chris Murphy wrote: > What's the basis for holding up this feature though? Yes it's a bug, Making the setup with the bug the default turns the longstanding bug into a regression (for the default setup) though. There also seems to be no reasonable workaround, or is there a checkbox 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 bug be addressed before the release goes out, or otherwise the change rolled back as per the contingency plan. > because there's no release criteria covering degraded boot. If the release criteria do not cover "a common use" (according to Peter Boy), then that is an issue in the release criteria and needs to be addressed there, i.e., a suitable criterion added. > but I don't think it's OK to hold up a release indefinitely while > insisting other people do the work required to bring such functionality to > Fedora. The whole point of pushing the feature to a later release is to not hold up the entire release because of it. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> 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 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.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) >> - at least for Fedora Server where software raid is a common use. > > What's the basis for holding up this feature though? Sorry, under the current circumstances your „feature“ is effectively a regression. It would make it impossible for many Fedora Server users to continue using Fedora Server as soon as they have to re-install or just want to set up a new additional server. 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 a technical error. Fedora will become unusable for them. A great "feature", that you would like to introduce, obviously at all costs. > Yes it's a bug, > but it wouldn't be a release blocking bug because there's no release > criteria covering degraded boot. Degraded boot? According to our tests it results in an non-bootable state on physical servers. > And on UEFI we already have this > problem because multiple ESPs aren't created or populated (sync'd). And why would we intentionally and deliberately impose this problem on non-UEFI boot systems, as well? > I > think it's a worthwhile use case to improve the current behavior so > that it works, but I don't think it's OK to hold up a release > indefinitely while insisting other people do the work required to > bring such functionality to Fedora. Wouldn't it be a better order for our users to solve the problem first and then make the feature the default? We have to discuss with the Anaconda team. Maybe they are able to solve it, but need some time to develop and test ist. What is the problem with introducing the change with F38 instead of (prematurely) with F37? Maybe, Anaconda can’t fix it. Then we have to find another solution. Maybe we have to give up on Anaconda for Server and distribute as preinstalled image (like we currently do with Aarch64) or develop a pre-installation step as on option in the boot screen (like previously with memtest), or something else that we can't come up with at the moment. But we have to resolve it ==first==! (and soon) You have thankfully created a bug report on this and thus opened the discussion about a solution. We both have known about the problem for more than a year now, when we first discussed it. We both should have done this earlier (the bug report). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Sun, May 29, 2022 at 6:56 AM Peter Boy wrote: > > > > > Am 14.05.2022 um 18:45 schrieb Ben Cotton : > > > > https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault > > > > This document represents a proposed Change. As part of the Changes > > 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 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]], [[User:Dcavalca| Davide > > Cavalca]], [[User:Salimma| Michel Alexandre Salim]], > > [[User:Chrismurphy| Chris Murphy]] > > * Email: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, > > chrismur...@fedoraproject.org > > > > > > == Detailed Description == > > Once implemented, Anaconda will create a GPT disk table on > > non-partitioned disks or when the disk is being completely reset when > > Fedora x86 install/live media is booted in BIOS mode. > > 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=2088113 and > https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > - at least for Fedora Server where software raid is a common use. What's the basis for holding up this feature though? Yes it's a bug, but it wouldn't be a release blocking bug because there's no release criteria covering degraded boot. And on UEFI we already have this problem because multiple ESPs aren't created or populated (sync'd). I think it's a worthwhile use case to improve the current behavior so that it works, but I don't think it's OK to hold up a release indefinitely while insisting other people do the work required to bring such functionality to Fedora. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 14.05.2022 um 18:45 schrieb Ben Cotton : > > https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault > > This document represents a proposed Change. As part of the Changes > 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 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]], [[User:Dcavalca| Davide > Cavalca]], [[User:Salimma| Michel Alexandre Salim]], > [[User:Chrismurphy| Chris Murphy]] > * Email: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, > chrismur...@fedoraproject.org > > > == Detailed Description == > Once implemented, Anaconda will create a GPT disk table on > non-partitioned disks or when the disk is being completely reset when > Fedora x86 install/live media is booted in BIOS mode. 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=2088113 and https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) - at least for Fedora Server where software raid is a common use. The issue is known to all server WG members at least since F32 and is mentioned in the server user documentation. A hybrid boot configuration may be useful for cloud because the same image is to be used for different runtime environments. For physical servers it is irrelevant and for VMs in a libvirt virtualization it is completely pointless. It would only introduce an additional potential source of errors for Fedora servers, without any benefit at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
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 also > > paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS > > installs to enable future conversion to UEFI boot or emulated UEFI > > boot on legacy BIOS. > > Any reasons to not go straight to a hybrid BIOS+UEFI setup? As far > I know anaconda already has support for that as it is needed to build > cloud images, so it probably isn't that difficuilt. > > Additional benefit: It is possible to switch between BIOS and UEFI mode > without reinstall. > I want to, I just don't know how yet to make Anaconda do it for BIOS installs. I sent an email to Anaconda development mailing list[1] asking about it. If someone wants to help make it happen, I'd love to get it done in one go. [1]: https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/thread/SISDA5JBUO6ORO3GKD7TZPEG3WUO73RF/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> == 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 legacy BIOS > installs to enable future conversion to UEFI boot or emulated UEFI > boot on legacy BIOS. Any reasons to not go straight to a hybrid BIOS+UEFI setup? As far I know anaconda already has support for that as it is needed to build cloud images, so it probably isn't that difficuilt. Additional benefit: It is possible to switch between BIOS and UEFI mode without reinstall. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault This document represents a proposed Change. As part of the Changes 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 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]], [[User:Dcavalca| Davide Cavalca]], [[User:Salimma| Michel Alexandre Salim]], [[User:Chrismurphy| Chris Murphy]] * Email: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, chrismur...@fedoraproject.org == Detailed Description == Once implemented, Anaconda will create a GPT disk table on non-partitioned disks or when the disk is being completely reset when Fedora x86 install/live media is booted in BIOS mode. == 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 legacy BIOS installs to enable future conversion to UEFI boot or emulated UEFI boot on legacy BIOS. This is a step toward a longer transition to eventually eliminate direct BIOS boot support, as identified in the discussion for [[Changes/DeprecateLegacyBIOS|the rejected Change to deprecate BIOS support in Fedora Linux 37]]. == Scope == * Proposal owners: ** Submit code changes to Anaconda to use GPT by default on BIOS systems ([https://github.com/rhinstaller/anaconda/pull/4104 gh#rhinstaller/anaconda#4104]) * Other developers: ** Anaconda developers need to review and merge the pull request * Release engineering: [https://pagure.io/releng/issue/10796 #10796] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (not needed for this Change) == Upgrade/compatibility impact == There will be no impact for existing Fedora Linux systems that upgrade. We will not convert the partitioning on upgrade. However, some very old systems have buggy EFI implementations that do not handle legacy BIOS boot on GPT well, and on those systems, users will need to request Anaconda to create a legacy MBR partition table by using inst.mbr on the boot command-line. == How To Test == Currently, users can test by booting Fedora media on BIOS systems with the inst.gpt option to try installing Fedora Linux on a legacy BIOS boot system with a GPT disk. After the change is merged and released, this behavior will be the default, and inst.mbr would be required to go back to the previous behavior. == User Experience == In general, there should nothing materially changing for users. If users look at the disk with fdisk or parted, they'll see a GPT disk instead of an MBR one and a BIOS boot partition will be present, which stores the GRUB boot code on a GPT disk. == Dependencies == This is isolated to Anaconda and is principally dependent on getting the changes into Anaconda. == Contingency Plan == * Contingency mechanism: Revert the change in upstream Anaconda * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == The upstream documentation will be updated as part of the change in Anaconda. == Release Notes == Fedora Linux now uses GPT (GUID Partition Table) partitioning by default for x86_64 systems that use legacy BIOS instead of UEFI. This brings a more modern method of partitioning disks and aligns closer with UEFI-based installations, which already use GPT partitioning. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault This document represents a proposed Change. As part of the Changes 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 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]], [[User:Dcavalca| Davide Cavalca]], [[User:Salimma| Michel Alexandre Salim]], [[User:Chrismurphy| Chris Murphy]] * Email: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, chrismur...@fedoraproject.org == Detailed Description == Once implemented, Anaconda will create a GPT disk table on non-partitioned disks or when the disk is being completely reset when Fedora x86 install/live media is booted in BIOS mode. == 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 legacy BIOS installs to enable future conversion to UEFI boot or emulated UEFI boot on legacy BIOS. This is a step toward a longer transition to eventually eliminate direct BIOS boot support, as identified in the discussion for [[Changes/DeprecateLegacyBIOS|the rejected Change to deprecate BIOS support in Fedora Linux 37]]. == Scope == * Proposal owners: ** Submit code changes to Anaconda to use GPT by default on BIOS systems ([https://github.com/rhinstaller/anaconda/pull/4104 gh#rhinstaller/anaconda#4104]) * Other developers: ** Anaconda developers need to review and merge the pull request * Release engineering: [https://pagure.io/releng/issue/10796 #10796] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (not needed for this Change) == Upgrade/compatibility impact == There will be no impact for existing Fedora Linux systems that upgrade. We will not convert the partitioning on upgrade. However, some very old systems have buggy EFI implementations that do not handle legacy BIOS boot on GPT well, and on those systems, users will need to request Anaconda to create a legacy MBR partition table by using inst.mbr on the boot command-line. == How To Test == Currently, users can test by booting Fedora media on BIOS systems with the inst.gpt option to try installing Fedora Linux on a legacy BIOS boot system with a GPT disk. After the change is merged and released, this behavior will be the default, and inst.mbr would be required to go back to the previous behavior. == User Experience == In general, there should nothing materially changing for users. If users look at the disk with fdisk or parted, they'll see a GPT disk instead of an MBR one and a BIOS boot partition will be present, which stores the GRUB boot code on a GPT disk. == Dependencies == This is isolated to Anaconda and is principally dependent on getting the changes into Anaconda. == Contingency Plan == * Contingency mechanism: Revert the change in upstream Anaconda * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == The upstream documentation will be updated as part of the change in Anaconda. == Release Notes == Fedora Linux now uses GPT (GUID Partition Table) partitioning by default for x86_64 systems that use legacy BIOS instead of UEFI. This brings a more modern method of partitioning disks and aligns closer with UEFI-based installations, which already use GPT partitioning. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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 machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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 > > existing bootloader UI bits go away.) > > https://git.kraxel.org/cgit/imagefish/tree/kickstart/el8.ks > > (for rhel8/centos8, probably wouldn't work as-is in f34+ because > the unified grub feature changed the grub cfg file arrangements). > That does look like what we're after. Thanks! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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/imagefish/tree/kickstart/el8.ks (for rhel8/centos8, probably wouldn't work as-is in f34+ because the unified grub feature changed the grub cfg file arrangements). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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 kickstart without > > requiring a custom pre-installation script or a custom boot script. > > [[Category:SystemWideChange]] > > Doesn't 'clearpart --disklabel gpt' work? It should. IIRC at the time it > was added we didn't make GPT the default because some BIOS systems were > confused by it and refused to boot. > > https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#clearpart 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.) I'll start a new thread on anaconda-devel@ about that. -- Chris Murphy > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructureqq@ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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 custom boot script. > [[Category:SystemWideChange]] Doesn't 'clearpart --disklabel gpt' work? It should. IIRC at the time it was added we didn't make GPT the default because some BIOS systems were confused by it and refused to boot. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#clearpart Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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]], [[User:Chrismurphy|Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]], [[User:Dustymabe|Dusty Mabe]] * Email: davd...@amazon.com, chrismur...@fedoraproject.org, mic...@michel-slm.name, dcava...@fb.com, ngomp...@gmail.com, du...@dustymabe.com * Products: Fedora Cloud Edition * Responsible WGs: Fedora Cloud WG == Detailed Description == Fedora Cloud Edition wants to use a GPT partition table; however, it is not possible to force the creation of an image with the GPT partition table with our current tooling because Anaconda requires setting inst.gpt as a kernel boot parameter to do it. This Change proposes to add a way to declare this via kickstart so that the Cloud Edition image builds can create images using the GPT partition table using the current tooling (which is built on Anaconda). == Benefit to Fedora == Users will be able to install systems with a GPT partition table via kickstart without requiring an extensive custom pre-installation script or a custom boot script. Disk images produced using the Anaconda tooling (Oz/ImageFactory, Lorax) can also trivially make images with GPT partition tables. This makes it possible to create hybrid BIOS+UEFI boot images, given [[Changes/UnifyGrubConfig|the changes to GRUB configuration from Fedora Linux 34]]. == Scope == * Proposal Owners ** Review and discuss with the Anaconda maintainers and determine the next steps for support of the inst.gpt in pykickstart ** Work with Anaconda maintainers to implement in Anaconda * Release engineering: [https://pagure.io/releng/issue/10137 #10137] * Policies and guidelines: N/A * Trademark approval: N/A == How to test == Build images using virt-install with kickstarts that have the option set. Verify that the disk partition table is properly configured as GPT. Verify that without the option set, it uses legacy MBR. == User Experience == * Allows for the use of the standard pykickstart directive for specifying the preference for GPT partition. == Dependencies == * Anaconda [https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-gpt inst.gpt] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
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]], [[User:Chrismurphy|Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]], [[User:Dustymabe|Dusty Mabe]] * Email: davd...@amazon.com, chrismur...@fedoraproject.org, mic...@michel-slm.name, dcava...@fb.com, ngomp...@gmail.com, du...@dustymabe.com * Products: Fedora Cloud Edition * Responsible WGs: Fedora Cloud WG == Detailed Description == Fedora Cloud Edition wants to use a GPT partition table; however, it is not possible to force the creation of an image with the GPT partition table with our current tooling because Anaconda requires setting inst.gpt as a kernel boot parameter to do it. This Change proposes to add a way to declare this via kickstart so that the Cloud Edition image builds can create images using the GPT partition table using the current tooling (which is built on Anaconda). == Benefit to Fedora == Users will be able to install systems with a GPT partition table via kickstart without requiring an extensive custom pre-installation script or a custom boot script. Disk images produced using the Anaconda tooling (Oz/ImageFactory, Lorax) can also trivially make images with GPT partition tables. This makes it possible to create hybrid BIOS+UEFI boot images, given [[Changes/UnifyGrubConfig|the changes to GRUB configuration from Fedora Linux 34]]. == Scope == * Proposal Owners ** Review and discuss with the Anaconda maintainers and determine the next steps for support of the inst.gpt in pykickstart ** Work with Anaconda maintainers to implement in Anaconda * Release engineering: [https://pagure.io/releng/issue/10137 #10137] * Policies and guidelines: N/A * Trademark approval: N/A == How to test == Build images using virt-install with kickstarts that have the option set. Verify that the disk partition table is properly configured as GPT. Verify that without the option set, it uses legacy MBR. == User Experience == * Allows for the use of the standard pykickstart directive for specifying the preference for GPT partition. == Dependencies == * Anaconda [https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-gpt inst.gpt] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: various mishandlings of corrupt GPT
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 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 RAID were writing metadata where the backup GPT goes. But it's worth seeing if the firmware is up to date. Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I checked my system UEFI settings and indeed it was configured for RAID. I switched it to AHCI and that solved the problem! No more backup GPT corruption! I switched it back to RAID just to be sure and the backup GPT was corrupt again. I guess I'll leave it in AHCI since I wasn't using the hardware RAID anyway. Thank you! Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt 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 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 RAID were writing metadata where the backup GPT goes. But it's worth seeing if the firmware is up to date. Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I checked my system UEFI settings and indeed it was configured for RAID. I switched it to AHCI and that solved the problem! No more backup GPT corruption! I switched it back to RAID just to be sure and the backup GPT was corrupt again. I guess I'll leave it in AHCI since I wasn't using the hardware RAID anyway. What ought to happen, with the feature enabled, is the combined devices appear as a logical device that's then partitioned. This puts the GPT in the proper location for the logical device. It so happens the primary GPT in the logical device is the same location as for the physical devices, so if the logical device breaks, the physical devices have a primary GPT that's intact. The backup GPT for the logical device is in the correct location for only the logical device, it will be too far in on the physical device which has the IMSM RAID metadata at the end of the physical device instead. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
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 the other one? Does such an fsck tool exist already or would you just run gdisk (doesn't appear to be automatic)? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
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 in either (but not both) is detected it would restore from the other one? Such a tool also should diagnose both overlap and unclaimed space, and provide some means for repair of these conditions. For example in the case of minor overlap: repair might be minimum wins, 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 calculated correct checksum. The tool also should be able to erase both GPT tables (overwrite all bytes to 0x00.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
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 parted or gdisk to fix it, verify that everything is good (even by dd'ing the backup GPT and manually inspecting it), then reboot and bam, it's corrupt again (i.e., set to 0). I don't know if it's an OS bug, a firmware bug, or something with the actual disk. This was causing some headaches for me with anaconda: https://bugzilla.redhat.com/show_bug.cgi?id=950145 https://bugzilla.redhat.com/show_bug.cgi?id=951244 -- especially this So fsck_gpt would indeed be useful. (Although it would probably force me to switch from UEFI back to legacy BIOS emulation and back to MBR partitioning on this one system.) Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
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 check the checksums of primary secondary tables, and if an error in either (but not both) is detected it would restore from the other one? Such a tool also should diagnose both overlap and unclaimed space, and provide some means for repair of these conditions. For example in the case of minor overlap: repair might be minimum wins, 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 calculated correct checksum. The tool also should be able to erase both GPT tables (overwrite all bytes to 0x00.) Please let's not mix the two concepts of tools quoted above. If the proposal is to run something by default on every bootup, it must be overwhelmingly safe, not apply heuristics that may break the system even more. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
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, and if an error in either (but not both) is detected it would restore from the other one? Yes. I think the exception to fixing would be if the MBR is clearly not a protective MBR, i.e. it does not at all have an 0xEE entry. In that case, I'd say leave the stale GPT info alone as the disk is MBR not GPT. There are some challenges interpreting hybrid MBRs correctly, because there's no standard here. So if the MBR contains an 0xEE entry and at least one additional entry, we could safely fix an invalid GPT with information from the valid GPT so long as the entries in the MBR and the valid GPT agree. If they don't, all bets are off and we probably shouldn't touch anything. Does such an fsck tool exist already or would you just run gdisk (doesn't appear to be automatic)? Does not exist as far as I know. Much of this code is in parted, including recognizing stale GPTs (a formerly GPT disk that's repartitioned MBR; which does not wipe out the old GPT information). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
On Oct 24, 2013, at 8:59 AM, John Reiser jrei...@bitwagon.com wrote: Such a tool also should diagnose both overlap and unclaimed space, and provide some means for repair of these conditions. For example in the case of minor overlap: repair might be minimum wins, 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 calculated correct checksum. The tool also should be able to erase both GPT tables (overwrite all bytes to 0x00.) For now the scope is unattended operation at startup or shutdown. I think all of the above suggestions need a user to be directly involved. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com 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 corrupts 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 RAID were writing metadata where the backup GPT goes. But it's worth seeing if the firmware is up to date. You could also use dd and hexdump to read in ~100 of the last sectors of the disk, and see if the metadata written to that area is identifiable. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: various mishandlings of corrupt GPT
On Oct 24, 2013, at 11:51 AM, Miloslav Trmač m...@volny.cz wrote: Please let's not mix the two concepts of tools quoted above. If the proposal is to run something by default on every bootup, it must be overwhelmingly safe, not apply heuristics that may break the 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 happens to be the primary GPT which is obviously working or it wouldn't be booting the system to get to the fsck… well that'd be pretty adorable in that I don't anticipate such a possibility. But a particularly smart tool should probably just sound a klaxon somehow but otherwise alter nothing on disk; or possibly it halts boot at this point to really get the attention of the user. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
various mishandlings of corrupt GPT
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 to MBR for the obvious reason that if it did, the computer would be busted. A recent bug came up in QA that made me go down a bit of a rabbit hole, corrupting one or the other GPT to see how different things behave, starting with the various partition tools. This is a summary: parted does the right thing, identifies which GPT is corrupt and says it's using the other one, and fixes the problem on the next write to disk. gdisk does the right thing also. fdisk sees a disk with corrupt primary GPT as being an MBR disk, RHBZ 1022217, fix now available although I haven't tested it yet. anaconda sees such a disk as totally blank, RHBZ 1020974 is in progress. grub2 only uses the primary GPT table, it doesn't check to see if it's valid, RHBZ 1022743. So a bit flip probably won't cause a computer to not boot. It'd have to be something that alters just the start LBA of /boot or / (or both), or stomps on the whole table data. In either case the result is an unbootable system. It's an open question if a bootloader should be able to determine the validity of the primary GPT since that means it needs CRC32 code. And then whether it should know to use the backup GPT. I've raised this on grub-devel@. And just now, I found the kernel nose dives if the primary GPT table is altered by even one byte. kernel.org bug 63591. Anyway, as rare as this is, it might be nice if the system can self-heal from such problems, because it's pretty much guaranteed the user will never know about it until the other GPT is toast. And the UEFI spec amusingly requires the user be asked for confirmation before restoring a primary GPT, which is probably not in either the kernel nor systemd's job description. So that's why I ask if it makes sense to have an fsck for GPT disks. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: grub2-tools and UEFI/GPT
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://admin.fedoraproject.org/mailman/listinfo/devel
grub2-tools and UEFI/GPT
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, grub2-install (which wasn't installed on my box, so I installed grub2-tools) kept asking about --target or --directory switches that didn't make much sense to me, until I figured that it found no data in /usr/lib/grub, and that installing the grub2 package would solve that, putting /usr/lib/grub/i386-pc there. Is that a missing dependency of grub2-tools on grub2, or is that by design? 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 corrected any corrupted data in some way. What would the manual way to do that have looked like? Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2-tools and UEFI/GPT
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 the EFI System partition which must be specified when using the install command. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2-tools and UEFI/GPT
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 boot managers/loaders as EFI applications called the EFI System partition which must be specified when using the install command. Ah, turns out my machine was still on legacy grub (grub-efi package) rather than grub2-efi after all. (Though neither of the two packages appears to contain a grub[2]-efi-install tool, at least not the Fedora 17 rpms; but then again, I hopefully won't need to fiddle with that again anyway...) Thanks, Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2-tools and UEFI/GPT
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 corrected any corrupted data in some way. What would the manual way to do that have looked like? 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2-tools and UEFI/GPT
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 there are no boot sectors, there is a partition dedicated for boot managers/loaders as EFI applications called the EFI System partition which must be specified when using the install command. Ah, turns out my machine was still on legacy grub (grub-efi package) rather than grub2-efi after all. (Though neither of the two packages appears to contain a grub[2]-efi-install tool, at least not the Fedora 17 rpms; but then again, I hopefully won't need to fiddle with that again anyway...) grub-efi was still default for F17. We are only going to grub2-efi with F18. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 to override it. If you really want GPT on a blacklisted system you can use parted in tty2 to make the disk GPT and then do a custom partition on top of that. If you want msdos pass nogpt on the kernel cmdline. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpRaf9RG7hSH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 to be discarding all partitions and creating an msdos partition table. Well that's kinda unfortunate behavior. I think the blacklist should cause just Use All Space to force a new or existing GPT to be MBR. But really, I've advocated the exact opposite you are, which is I think BIOS hardware with disks 2TB should default to MBR, not GPT. There's minimal advantage, and more trouble. However, if you're really committed to GPT, convert the MBR to GPT using gdisk after the fact. I suggest custom partitioning to reserve 1MB unallocated. Post install, gdisk to add a BIOS Boot partition, gdisk type code 0xEF02. Then when you reinstall GRUB2, it will automatically stuff core.img in it. Well.. considering that I have no special reason to want GPT, I guess it's easier to go with the Msdos partition table. It's just that it surprises me that there is no obvious way to override the default Anaconda behaviour within the installation DVD, since my laptop supports GPT. My previous installation, where GPT worked just fine, was done with F16 Beta, so maybe at the time Lenovos were not blacklisted yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GPT
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 F16? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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. 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. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
On Apr 22, 2012 6:35 PM, Chris Murphy li...@colorremedies.com wrote: 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. 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 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. I'm wondering if there is a grub option to force gpt for anaconda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 hardware. I'm wondering if there is a grub option to force gpt for anaconda. 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 ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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. I'm going to guess that it's easier to blacklist a make, than individual models. I'm wondering if there is a grub option to force gpt for anaconda. One way to opt in is to use parted or gdisk to make a GPT without a partition, then tell Anaconda to use the Use Free Space installation type. Actually, only the Use All Space causes a change in partition scheme, so you could also make a single partition GPT disk with parted or gdisk, and also use the Replace Existing Linux System option. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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. [To erase a GPT requires zeroing out both copies.] GPT info has a checksum which aids detection of inadvertent changes. Each partition can be accessed in only two seeks (GPT then destination) as opposed to searching a linked list (1 seek per link after the first 4); reading fewer blocks lowers exposure to media errors. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 copy of its info: at the far end as well as at the beginning. [To erase a GPT requires zeroing out both copies.] GPT info has a checksum which aids detection of inadvertent changes. Each partition can be accessed in only two seeks (GPT then destination) as opposed to searching a linked list (1 seek per link after the first 4); reading fewer blocks lowers exposure to media errors. Yeah I'm well aware of precisely how GPT works, and I said it's a better format. My point is that it's not necessary if you're _not_ using the two main advantages (a) and (b) above. In practice the PT format makes no difference to seeks or speed, because the kernel reads it once and keeps it in memory. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 were blacklisted. Gpt was working just fine on F16 on the same hardware. I'm going to guess that it's easier to blacklist a make, than individual models. I'm wondering if there is a grub option to force gpt for anaconda. But there should be an easy way to override it. One way to opt in is to use parted or gdisk to make a GPT without a partition, then tell Anaconda to use the Use Free Space installation type. Actually, only the Use All Space causes a change in partition scheme, so you could also make a single partition GPT disk with parted or gdisk, and also use the Replace Existing Linux System option. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 harddrive to use gparted LiveCD to write a GPT partition label, and create a FAT16 partition of 100MB of type EFI System Partition with boot flag. Then in Fedora 17 anaconda: mount the EFI System Partition as /boot/efi, then create the usual root and other partitions. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
On Sun, 2012-04-22 at 20:04 +0300, Nikos Roussos wrote: On Apr 22, 2012 6:35 PM, Chris Murphy li...@colorremedies.com wrote: 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. 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 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. They are, because lots of them are known to be broken. Gpt was working just fine on F16 on the same hardware. GPT was in fact blacklisted for Thinkpads in F16. We blacklisted it for F16, disabled the blacklist for a while with F17, but enabled it again before Beta. If you got a GPT install from F16 you must either have done your install before we instituted the blacklist, installed with a 2TB+ drive present (in which case the blacklist is overridden), installed native EFI (ditto), or the 16 blacklist must have somehow not hit your model while the 17 one does. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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. Gpt was working just fine on F16 on the same hardware. I'm going to guess that it's easier to blacklist a make, than individual models. Implementing a per-model blacklist isn't technically difficult. The problem is we don't know for sure exactly which Thinkpads are broken and which aren't, and it'd be very difficult to compile and maintain an accurate list (there are a lot of Thinkpad models, with all sorts of regional variations, and there may be some models for which there are different firmware revisions, some of which work and some of which don't). So long as we know that substantial numbers of Thinkpad models are broken, the only practical option is to blacklist the lot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT
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 that's kinda unfortunate behavior. I think the blacklist should cause just Use All Space to force a new or existing GPT to be MBR. But really, I've advocated the exact opposite you are, which is I think BIOS hardware with disks 2TB should default to MBR, not GPT. There's minimal advantage, and more trouble. However, if you're really committed to GPT, convert the MBR to GPT using gdisk after the fact. I suggest custom partitioning to reserve 1MB unallocated. Post install, gdisk to add a BIOS Boot partition, gdisk type code 0xEF02. Then when you reinstall GRUB2, it will automatically stuff core.img in it. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 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 that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 Fingers crossed I just missed something at the time. I'll try out again tomorrow maybe. Yes, I remember that. Please do test the change out and let us know the results, we'd definitely like to know. Yep as expected F17 alpha is broken in the same way on my laptop. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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-installation disk? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
On 03/02/2012 07:09 PM, Chris Murphy wrote: 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-installation disk? For earlier in the thread: Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31; You can see the boot flag is set to no avail in the disk and parted output below: Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/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 (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot Number Start End SizeFile system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 526MB 524MB ext4 ext4 boot 3 526MB 500GB 500GB lvm I've confirmed that installing with the nogpt flag is OK. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 bios_grub 2 2097kB 526MB 524MB ext4 ext4 boot 3 526MB 500GB 500GB lvm 1. What happens if you remove the GPT boot flag from sda2? 2. What happens if you add the GPT legacy_boot flag to sda2? 3. While I wouldn't recommend supporting such a solution, but I'm curious what happens if you use gdisk to create a hybrid MBR, and add only partition 3 (lvm), set it as bootable instead of the PMBR. GPT fdisk (gdisk) can do this. It's now on the F17 LiveCD. Menu 'r' option 'h'. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 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 that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 Fingers crossed I just missed something at the time. I'll try out again tomorrow maybe. Yes, I remember that. Please do test the change out and let us know the results, we'd definitely like to know. Yep as expected F17 alpha is broken in the same way on my laptop. So it seems the boot flag on protective MBR does not, in fact, fix all Lenovos, Brian... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GPT and Fedora 17
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 that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpFx8Vynj3RH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 because my Apple hardware fails to boot any OS including pre-existing Mac OS, if the protective MBR (MBR entry 1) has an active (boot) flag set. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 to solve this. Thanks to Matthew Garrett we found that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 Fingers crossed I just missed something at the time. I'll try out again tomorrow maybe. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 blacklisted Lenovo, falling back to msdos labels in order to solve this. Thanks to Matthew Garrett we found that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 Fingers crossed I just missed something at the time. I'll try out again tomorrow maybe. Yes, I remember that. Please do test the change out and let us know the results, we'd definitely like to know. Brian, this change takes effect from Alpha TC2 (whenever we spin it), it's not in Alpha TC1, correct? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
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 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 that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 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. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, and it didn't help. I.E. point (1.) from the link referenced here: https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 Fingers crossed I just missed something at the time. I'll try out again tomorrow maybe. Yes, I remember that. Please do test the change out and let us know the results, we'd definitely like to know. Brian, this change takes effect from Alpha TC2 (whenever we spin it), it's not in Alpha TC1, correct? Correct. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpabuhMJpSxx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 12:47:58PM -0700, Adam Williamson wrote: On Fri, 2011-10-14 at 22:44 +0300, Pasi Kärkkäinen wrote: On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: On systems where 32-bit is XP is running, one by definition is running 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 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 for example rhel5 Xen pygrub has issues with GPT, and it'd be good to be able to install F16 domUs on rhel5 Xen by forcing creation of msdos partition table.. As of Final TC1 (anaconda 16.21) this should be possible by passing 'nogpt' as a kernel parameter to the installer. I tried F16 Final TC1 with nogpt boot option but it didn't work unfortunately.. More info here: https://bugzilla.redhat.com/show_bug.cgi?id=735733 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: On systems where 32-bit is XP is running, one by definition is running 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 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 ? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: On systems where 32-bit is XP is running, one by definition is running 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 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 for example rhel5 Xen pygrub has issues with GPT, and it'd be good to be able to install F16 domUs on rhel5 Xen by forcing creation of msdos partition table.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 12:47:58PM -0700, Adam Williamson wrote: On Fri, 2011-10-14 at 22:44 +0300, Pasi Kärkkäinen wrote: On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: On systems where 32-bit is XP is running, one by definition is running 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 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 for example rhel5 Xen pygrub has issues with GPT, and it'd be good to be able to install F16 domUs on rhel5 Xen by forcing creation of msdos partition table.. As of Final TC1 (anaconda 16.21) this should be possible by passing 'nogpt' as a kernel parameter to the installer. This is great! Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 based machines, grub for EFI in F16. There are EFI changes in grub that need to be ported to grub2 and that is an F17 target. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Thu, Aug 25, 2011 at 08:12:21PM -0700, Adam Williamson wrote: On Thu, 2011-08-25 at 21:13 -0500, Andrew McNabb wrote: 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 partition table. But if you first install 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. 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 editions on UEFI-based systems. http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 a BIOS system and don't create a BIOS boot partition, anaconda will pop up a (somewhat cryptic) warning. FWIW, there are bugs on Macintoshes of the sort can't have GPT, but also can't have MBR, and the Linux-on-Mac people came up with the hybrid GPT/MBR partitioning, i.e. partition data that looks simultaneously like a valid GPT and MBR: http://www.rodsbooks.com/gdisk/hybrid.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 editions on UEFI-based systems. http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx I don't know for sure, but this may be a case where progress is more important than compatibility. In any case, it would be comforting to have this issue documented in the Fedora 16 Release Notes. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 disks for data. Booting is only supported for 64-bit editions on UEFI-based systems. http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx I don't know for sure, but this may be a case where progress is more important than compatibility. In any case, it would be comforting to have this issue documented in the Fedora 16 Release Notes. I disagree. This is a bogus argument, similar to those which have repeatedly stripped away Fedora's ability to support older hardware (especially video) in the past few releases. Hopefully Ajax's recent work on software 3D should restore that a bit so those of us with older but still useful systems can run Gnome 3's full Shell. The magnitude of impact depends on whether the typical Linux user who also runs some variant of Windows is at those levels. In my experience personally and in a corporate environment, that would typically be 32-bit XP. Those folks who pay the Danegeld to upgrade to the later Windows releases on a given system are less likely to also be Linux users. On systems where 32-bit is XP is running, one by definition is running 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 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 instead of providing a few helper scripts seems short-sighted at best, and arrogant/NIH at worst. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: On systems where 32-bit is XP is running, one by definition is running 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 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 instead of providing a few helper scripts seems short-sighted at best, and arrogant/NIH at worst. Are those commands included in the upstream Grub 2 tarball? In this case you should file a bug to get them included in the Fedora package I think. If not, you have a perfect example why people should improve software by working upstream. btw, I just installed F16 on an EFI machine and got Grub Legacy. Are there any major problems with Grub 2's EFI support? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GPT in Fedora 16
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 been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 unsuccessfully tried to track down more information. I haven't been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. 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 a BIOS system and don't create a BIOS boot partition, anaconda will pop up a (somewhat cryptic) warning. If you're installing alongside an existing copy of Windows I believe anaconda ought to leave the disk label alone (MSDOS) anyway, though I'm not sure we've tested that. It should only write a new one if you're blowing away any existing partitions on the disk, I think. (IMBW on this one). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 like to understand the change and its implications, and I have unsuccessfully tried to track down more information. I haven't been able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 feature page. The only definitive reference I've been able to find is the comment x86 uses GPT disklabels by default on all machines, even non-EFI on the Anaconda/Changes wiki page. There seem to be some complications associated with the change. For example, Windows can only support GPT on UEFI machines, so dual-booting appears to be unsupported (I could not find an option for MBR partition tables in the installer). Where should I look for more information? Thanks. 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 a BIOS system and don't create a BIOS boot partition, anaconda will pop up a (somewhat cryptic) warning. This is changing from a suggestion to a requirement, based on the fact that grub2 will not even try to install itself without the bios boot partition. If you're installing alongside an existing copy of Windows I believe anaconda ought to leave the disk label alone (MSDOS) anyway, though I'm not sure we've tested that. It should only write a new one if you're blowing away any existing partitions on the disk, I think. (IMBW on this one). This is correct. 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 partition table. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
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 partition table. But if you first install Fedora to a clean disk, then it will never be possible to later install Windows, right? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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] 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 problems. Very few BIOSes can boot from a GPT disk. Urban legend... 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. The problem is old grub. Karel -- Karel Zak k...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, Mar 19, 2010 at 12:22:56PM +0200, Manuel Wolfshant wrote: Till Maas wrote: On Fri, Mar 19, 2010 at 10:34:59AM +0100, Karel Zak wrote: I am also pretty sure that a BIOS does not consider the partition table to boot, I can vouch for at least 2 Intel based motherboards which do not boot unless a) there exists a partition table and b) one partition is marked as active There still will be a partition table, but it will always show a partition that starts at sector 1. By default it seems not to be marked as active, but this should be possible. This is then the old style 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
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 and the kernel seems to recognise it without any problems. Are there any good reasons to do this _other_ than so we can cope with larger disks? How about doing it only for disks which are too large to cope with the DOS-style partition tables? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. Are there any good reasons to do this _other_ than so we can cope with larger disks? Afaik it is also required in case one uses EFI instead of a BIOS. Doing this soon would make Fedora ready once it is required. Other nice features are checksums for the partition table and file system independent uuids for the partitions and file system independent clear text names for partitions. These can be used to easier identify partitions that do not contain a file system, e.g. because they are encrypted or they have been wiped. Then they could be easier identified to be used again, e.g. in the installer. How about doing it only for disks which are too large to cope with the DOS-style partition tables? For large disks it would be required anyhow. But it does not need to be default, at least support for it in the installer would be nice. Regards Till pgpLj7KHXno2A.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, 2010-03-19 at 13:04 +, David Woodhouse wrote: Are there any good reasons to do this _other_ than so we can cope with larger disks? How about doing it only for disks which are too large to cope with the DOS-style partition tables? Why deal with two different types 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 https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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. Aspecial if you want a tripple boot system on a Macaintosh system, there will be nice to have this feature, because you can only have four partition in the MBR, which may be assigned as follow: Partitiona #1EFI system partition Partition #2:Mac OX X Partition #3:Linux Partition #4:Windows Anyone in the future we may not have this discussion because all computer have moved to a UEFI systen caused by the 2 TB limitation of the MBR partition schea, but now we have the issue, that we have to support OS which are unable to support GPT partition hard discs. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 using gdisk and the kernel seems to recognise it without any problems. 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 ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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: https://fedoraproject.org/wiki/Features/GUID_Partition_Table Regards Till pgpjbS1ETkSKd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 with Anaconda ... A first incomplete Feature page is available here: https://fedoraproject.org/wiki/Features/GUID_Partition_Table I added a section summarising the issues with gptsync AIUI: https://fedoraproject.org/wiki/Features/GUID_Partition_Table#gptsync Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 problems. Regards Till [0] http://de.wikipedia.org/wiki/GUID_Partition_Table [1] http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues#Random_thoughts_and_comments_.28mostly_for_distros.29 pgpzeDWF2QxQb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 using gdisk and the kernel seems to recognise it without any problems. 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. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
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 somehow prevents the BIOS from reading the first sector into memory, jumping to it, and afterwards reading other sectors (with LBA48 addresses) into memory? -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
