Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
The bad news is that we're still some way from a viable Beta RC. We need work on several blockers, all of which is outlined below. I'll start with bugs that need work from developers; QA folks, there are tasks for us listed later on.
Accepted blockers - anaconda and python-blivet ----------------------------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails to apply lower bound to resize requests in custom spoke" - this bug has been open for a while and needs a fix from anaconda team, when they have time.
* https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI: you have not created a bootloader stage1 target device" - this bug breaks the most common installation scenarios for Apple systems (guided install alongside an existing OS X install). bcl has been working on fixing it: back in September he posted an initial patch, then decided that it was not sufficient - https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/006... . There is no information since then that I can find.
* https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError: Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with certain existing btrfs volumes. dlehman posted a plan on how to fix it, but there is no proposed patch that I can find.
Accepted blockers - other -------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1000891 - "DVD is oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix for this was scheduled for TC3, but it caused the DVD compose to break, and was backed out to produce a testable TC4. TC5 continued without the problematic fix (and hence is still over-size). AIUI, dgilmore was supposed to be looking into the compose issue, but I believe he is now on vacation, so we may need someone else to step in: CCing nirik and notting.
* https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp not found, startup failure" (dracut) - an update containing a fix for this has been submitted - https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 - but one reliable tester has reported that it breaks boot on their system, so further developer work may be required here, harald: https://bugzilla.redhat.com/show_bug.cgi?id=1021083
* https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1 ARM disk images unable to find root filesystem" (dracut) - this bug is marked as an unresolved blocker but has in fact been worked around since, I believe, TC2. We can probably ship Beta with the workaround, and this may just need some Bugzilla Bureaucracy rather than developer attention at this point.
Proposed blockers -----------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly treats a disk with partially corrupt GPT as having no partition at all" (anaconda) - this looks like it could well be accepted as a blocker, so developer attention would be appreciated.
* https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20 fails because of deltarpms" (fedup) - Will posted a proposed fix for informal testing; Will, one of the reporters has confirmed the fix is good, so can you please submit an update? Thanks!
Bugs requiring QA attention ---------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do!
* https://bugzilla.redhat.com/show_bug.cgi?id=1013800 - "devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool" (python-blivet) - this is believed to be fixed by the https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... update (and hence in TC5). We need to verify the fix and add karma to the update so it can be pushed stable and the bug closed.
* https://bugzilla.redhat.com/show_bug.cgi?id=1019500 - "device factories need to set a default name if empty name given for defined device" - exactly the same as 1013800: this should be fixed in TC5, please confirm the fix and up-karma the update.
This has been your blocker bug news, folks - if everyone can help out with fixing the remaining issues and testing the anaconda/blivet update, that'd be a great help. Thanks!
On 10/19/2013 07:20 AM, Adam Williamson wrote:
Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
The bad news is that we're still some way from a viable Beta RC. We need work on several blockers, all of which is outlined below. I'll start with bugs that need work from developers; QA folks, there are tasks for us listed later on.
Accepted blockers - anaconda and python-blivet
- https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails
to apply lower bound to resize requests in custom spoke" - this bug has been open for a while and needs a fix from anaconda team, when they have time.
- https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI:
you have not created a bootloader stage1 target device" - this bug breaks the most common installation scenarios for Apple systems (guided install alongside an existing OS X install). bcl has been working on fixing it: back in September he posted an initial patch, then decided that it was not sufficient - https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/006... . There is no information since then that I can find.
- https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError:
Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with certain existing btrfs volumes. dlehman posted a plan on how to fix it, but there is no proposed patch that I can find.
Accepted blockers - other
oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix for this was scheduled for TC3, but it caused the DVD compose to break, and was backed out to produce a testable TC4. TC5 continued without the problematic fix (and hence is still over-size). AIUI, dgilmore was supposed to be looking into the compose issue, but I believe he is now on vacation, so we may need someone else to step in: CCing nirik and notting.
- https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp
not found, startup failure" (dracut) - an update containing a fix for this has been submitted - https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 - but one reliable tester has reported that it breaks boot on their system, so further developer work may be required here, harald: https://bugzilla.redhat.com/show_bug.cgi?id=1021083
- https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1
ARM disk images unable to find root filesystem" (dracut) - this bug is marked as an unresolved blocker but has in fact been worked around since, I believe, TC2. We can probably ship Beta with the workaround, and this may just need some Bugzilla Bureaucracy rather than developer attention at this point.
Proposed blockers
- https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly
treats a disk with partially corrupt GPT as having no partition at all" (anaconda) - this looks like it could well be accepted as a blocker, so developer attention would be appreciated.
- https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20
fails because of deltarpms" (fedup) - Will posted a proposed fix for informal testing; Will, one of the reporters has confirmed the fix is good, so can you please submit an update? Thanks!
Bugs requiring QA attention
- https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do!
There are two problems with this update and I have submitted patches for both:
1. The fix for handling existing btrfs subvolumes does not work (yet), small fix needed.
2. The change in the way swap definitions are handled for additions to fstab omits handling the case for existing noformat swap definitions on both regular partitions and logical volumes.
Without these patches or equivalent, this is definitely a blocker.
Gene
"devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool" (python-blivet) - this is believed to be fixed by the https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... update (and hence in TC5). We need to verify the fix and add karma to the update so it can be pushed stable and the bug closed.
factories need to set a default name if empty name given for defined device" - exactly the same as 1013800: this should be fixed in TC5, please confirm the fix and up-karma the update.
This has been your blocker bug news, folks - if everyone can help out with fixing the remaining issues and testing the anaconda/blivet update, that'd be a great help. Thanks!
On Sat, 2013-10-19 at 09:45 -0400, Gene Czarcinski wrote:
- https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do!
There are two problems with this update and I have submitted patches for both:
- The fix for handling existing btrfs subvolumes does not work (yet),
small fix needed.
- The change in the way swap definitions are handled for additions to
fstab omits handling the case for existing noformat swap definitions on both regular partitions and logical volumes.
Without these patches or equivalent, this is definitely a blocker.
It's not a blocker unless someone files a bug and proposes it as a blocker: that's how the process works. Is there a bug report? And are these *new* problems compared to 20.24/20.25?
Would the idea that the user can't select the correct keyboard layout for terminal mode be a blocker?
The layout is set with the first screen of anaconda and the fact that the English keyboard is replaced by the CA(fr) layout (uniquely I.e. the only layout/keyboard) mean that in the absence of the GUI interface, We are stuck because there is no /etc/X11 directory where in the past that is where the parameters for keyboard definitions were kept.
Sent from Yahoo Mail on Android
On Sat, 2013-10-19 at 17:16 -0700, Leslie S Satenstein wrote:
Would the idea that the user can't select the correct keyboard layout for terminal mode be a blocker?
If it were true, yes. It isn't.
The layout is set with the first screen of anaconda and the fact that the English keyboard is replaced by the CA(fr) layout (uniquely I.e. the only layout/keyboard)
There is a Keyboard spoke you can enter and add any number of keyboard layouts you like, in any order of preference, and configure any key combination you like for switching between them. (Layout switching at the console does not work like X layout switching, and may need some special-casing in langtable following the xkb-to-kbd conversion, but that's kind of a separate topic).
mean that in the absence of the GUI interface, We are stuck because there is no /etc/X11 directory where in the past that is where the parameters for keyboard definitions were kept.
Um. /etc/X11 will usually exist in an F20 install. If, for some reason, it doesn't, you can create it, and configuration in the appropriate places within it will work fine. And nothing in /etc/X11 has ever been relevant to console layout configuration in any case.
Adam I have three F20 Beta installations. I wish to interact with Fedora using English, but two of my systems have CA(FR) as the only keyboard layout. and one has the latam keyboard layout. By selecting English, by default the English keyboard is selected for terminal mode. In the keyboard selection hub, I definitely remove the English keyboard layout and replace it with CA(FR) or Latam, and I complete the installation with only one keyboard showing, the non-English one. And the keyboard mappings are 100% corresponding to the CA(FR) or latam layouts.
But, in terminal mode (ctl-alt-f2..ctl-alt-f6), the fact that within Anaconda I removed the English Keyboard and did the susstitution is not conveyed to update the terminal mode software settings. Ergo the bug report for system-config-keyboard in terminal mode being necessary.
Since I know how to reselect the keyboard, it is, for me, not a show stopper. Has anyone else experienced the same problem as me using 20-Beta tc5 ?
Regards
Leslie
Mr. Leslie Satenstein An experienced Information Technology specialist. Yesterday was a good day, today is a better day, and tomorrow will be even better.lsatenstein@yahoo.com alternative: leslie.satenstein@gmail.com SENT FROM MY OPEN SOURCE LINUX SYSTEM.
From: Adam Williamson awilliam@redhat.com To: lsatenstein@yahoo.com; Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Friday, October 25, 2013 7:03 PM Subject: Re: Fedora 20 Beta blocker bug status: fix and karma requests
On Sat, 2013-10-19 at 17:16 -0700, Leslie S Satenstein wrote:
Would the idea that the user can't select the correct keyboard layout for terminal mode be a blocker?
If it were true, yes. It isn't.
The layout is set with the first screen of anaconda and the fact that the English keyboard is replaced by the CA(fr) layout (uniquely I.e. the only layout/keyboard)
There is a Keyboard spoke you can enter and add any number of keyboard layouts you like, in any order of preference, and configure any key combination you like for switching between them. (Layout switching at the console does not work like X layout switching, and may need some special-casing in langtable following the xkb-to-kbd conversion, but that's kind of a separate topic).
mean that in the absence of the GUI interface, We are stuck because there is no /etc/X11 directory where in the past that is where the parameters for keyboard definitions were kept.
Um. /etc/X11 will usually exist in an F20 install. If, for some reason, it doesn't, you can create it, and configuration in the appropriate places within it will work fine. And nothing in /etc/X11 has ever been relevant to console layout configuration in any case.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
On 10/19/2013 06:36 PM, Adam Williamson wrote:
On Sat, 2013-10-19 at 09:45 -0400, Gene Czarcinski wrote:
- https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda... , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do!
There are two problems with this update and I have submitted patches for both:
- The fix for handling existing btrfs subvolumes does not work (yet),
small fix needed.
- The change in the way swap definitions are handled for additions to
fstab omits handling the case for existing noformat swap definitions on both regular partitions and logical volumes.
Without these patches or equivalent, this is definitely a blocker.
It's not a blocker unless someone files a bug and proposes it as a blocker: that's how the process works. Is there a bug report? And are these *new* problems compared to 20.24/20.25?
That depends on how you define "new"
With 20.25.1, there is a claim that it fixes the problem identified in: https://bugzilla.redhat.com/show_bug.cgi?id=892747 where an existing btrfs subvolume with --noformat specified is ignored rather than being added to fstab. The problem is that it is not fixed. I have attached a tested patch to correct this to the bugzilla report.
Before 20.25.1, if you had an existing swap on a regular partition or a logical volume and you specified --noformat, that swap specification was added to fstab. With 20.25.1, this is no longer the case and you wind up with no swap at all. You might want to not reformat that swap because you are using UUID and you have another system (multiboot) also using that swap and refering to it also by UUID. This problem is reported by: https://bugzilla.redhat.com/show_bug.cgi?id=1020867 Again, I have attached a tested patch to correct the problem to the bugzilla report.
This swap problem was introduced by changes made in 20.25.1.
Gene
On Oct 20, 2013, at 4:38 AM, Gene Czarcinski gene@czarc.net wrote:
Before 20.25.1, if you had an existing swap on a regular partition or a logical volume and you specified --noformat, that swap specification was added to fstab. With 20.25.1, this is no longer the case and you wind up with no swap at all. You might want to not reformat that swap because you are using UUID and you have another system (multiboot) also using that swap and refering to it also by UUID. This problem is reported by: https://bugzilla.redhat.com/show_bug.cgi?id=1020867 Again, I have attached a tested patch to correct the problem to the bugzilla report.
This swap problem was introduced by changes made in 20.25.1.
It might be related to this: http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.h...
Since systemd is auto mounting certain partitiontypeguids, they don't need to be in fstab. There are few bugs filed as a result of the ensuing confusion. So it might be new behavior in anaconda 20.25.1 to ignore the request to reuse existing swap by adding it to fstab since it knows systemd is going to use it in any case.
Chris Murphy
On 10/20/2013 01:11 PM, Chris Murphy wrote:
On Oct 20, 2013, at 4:38 AM, Gene Czarcinski gene@czarc.net wrote:
Before 20.25.1, if you had an existing swap on a regular partition or a logical volume and you specified --noformat, that swap specification was added to fstab. With 20.25.1, this is no longer the case and you wind up with no swap at all. You might want to not reformat that swap because you are using UUID and you have another system (multiboot) also using that swap and refering to it also by UUID. This problem is reported by: https://bugzilla.redhat.com/show_bug.cgi?id=1020867 Again, I have attached a tested patch to correct the problem to the bugzilla report.
This swap problem was introduced by changes made in 20.25.1.
It might be related to this: http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.h...
Since systemd is auto mounting certain partitiontypeguids, they don't need to be in fstab. There are few bugs filed as a result of the ensuing confusion. So it might be new behavior in anaconda 20.25.1 to ignore the request to reuse existing swap by adding it to fstab since it knows systemd is going to use it in any case.
If I specifically specify an existing regular partition or logical volume as swap and specify "--noformat" in the kickstart file, then the way it has been working is that such swap specifications are added to fstab.
Currently, a bigger aggravation to me is that if I am just doing a install using the GUI, I cannot re-use an existing swap without reclaiming the space and thus reformatting it and having it get a new UUID. Of course if I have another system install into different partitions and it is also using that swap by UUID, it now will be screwed. Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
Gene
On Oct 21, 2013, at 7:58 AM, Gene Czarcinski gene@czarc.net wrote:
If I specifically specify an existing regular partition or logical volume as swap and specify "--noformat" in the kickstart file, then the way it has been working is that such swap specifications are added to fstab.
Regression in kickstart? I can't do this in the GUI. I have to reformat swap for some reason.
My speculation is wrong in any case with GUI install, swap is still put in the fstab with anaconda 20.25.1-1 and RHBZ 1017509 still applies.
Of course if I have another system install into different partitions and it is also using that swap by UUID, it now will be screwed.
I agree, not friendly.
Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in the GPT for swap partitions rather than the swap volume format UUID? The UniquePartitionGUID is more stable.
Chris Murphy
On 10/21/2013 11:00 AM, Chris Murphy wrote:
Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in the GPT for swap partitions rather than the swap volume format UUID? The UniquePartitionGUID is more stable.
Is there some underground movement to switch to GPT disks? Doing a little googling, I found this: https://fedoraproject.org/wiki/Features/GUID_Partition_Table which says the targeted release was Fedora 14 and thus it went nowhere.
I am not sure that anaconda is prepared to handle this?
Gene
On Oct 23, 2013, at 2:44 PM, Gene Czarcinski gene@czarc.net wrote:
On 10/21/2013 11:00 AM, Chris Murphy wrote:
Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in the GPT for swap partitions rather than the swap volume format UUID? The UniquePartitionGUID is more stable.
Is there some underground movement to switch to GPT disks? Doing a little googling, I found this: https://fedoraproject.org/wiki/Features/GUID_Partition_Table which says the targeted release was Fedora 14 and thus it went nowhere.
I am not sure that anaconda is prepared to handle this?
Mmm, it was put in for F14 or F15 and then rolled back out for BIOS computers because there were too many instances of BIOS firmware doing a face plant without its beloved MBR. Many such instances are worked around with the pmbr_boot flag (parted terminology) which is setting the active flag on the 0xEE entry in the MBR, which is what you get if you use the gpt flag when booting install media. Otherwise MBR is used for BIOS computers.
For (U)EFI computers, GPT is always used, and other than edge cases and unknowns anaconda is handling this OK, as far as I know.
Chris Murphy
On Wed, 2013-10-23 at 15:07 -0600, Chris Murphy wrote:
On Oct 23, 2013, at 2:44 PM, Gene Czarcinski gene@czarc.net wrote:
On 10/21/2013 11:00 AM, Chris Murphy wrote:
Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in the GPT for swap partitions rather than the swap volume format UUID? The UniquePartitionGUID is more stable.
Is there some underground movement to switch to GPT disks? Doing a little googling, I found this: https://fedoraproject.org/wiki/Features/GUID_Partition_Table which says the targeted release was Fedora 14 and thus it went nowhere.
I am not sure that anaconda is prepared to handle this?
Mmm, it was put in for F14 or F15 and then rolled back out for BIOS computers because there were too many instances of BIOS firmware doing a face plant without its beloved MBR. Many such instances are worked around with the pmbr_boot flag (parted terminology) which is setting the active flag on the 0xEE entry in the MBR, which is what you get if you use the gpt flag when booting install media. Otherwise MBR is used for BIOS computers.
Went in in F16, came out in F17. gpt is still the default for UEFI installs and used when formatting a disk over 2TB in size. You can force a BIOS install to use gpt by passing the 'gpt' kernel parameter.
On 10/25/2013 07:04 PM, Adam Williamson wrote:
On Wed, 2013-10-23 at 15:07 -0600, Chris Murphy wrote:
On Oct 23, 2013, at 2:44 PM, Gene Czarcinski gene@czarc.net wrote:
On 10/21/2013 11:00 AM, Chris Murphy wrote:
Sometimes using UUID is not a good idea. This problem has been bugzill'ed. I was hoping the "swap-fix" would help with that but I believe it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in the GPT for swap partitions rather than the swap volume format UUID? The UniquePartitionGUID is more stable.
Is there some underground movement to switch to GPT disks? Doing a little googling, I found this: https://fedoraproject.org/wiki/Features/GUID_Partition_Table which says the targeted release was Fedora 14 and thus it went nowhere.
I am not sure that anaconda is prepared to handle this?
Mmm, it was put in for F14 or F15 and then rolled back out for BIOS computers because there were too many instances of BIOS firmware doing a face plant without its beloved MBR. Many such instances are worked around with the pmbr_boot flag (parted terminology) which is setting the active flag on the 0xEE entry in the MBR, which is what you get if you use the gpt flag when booting install media. Otherwise MBR is used for BIOS computers.
Went in in F16, came out in F17. gpt is still the default for UEFI installs and used when formatting a disk over 2TB in size. You can force a BIOS install to use gpt by passing the 'gpt' kernel parameter.
I was not previously aware of that. Since we are all going to be honored with EUFI "real soon now", I thought I would give gpt a try now. I cracked up one of my "standard" simple KVM kickstart test installs for F19 but specified gpt on the boot line (this was a fresh install wiping the virtual disk). Looked good until the end when grub2-install failed because it could not install into the gparted disk.
Then, I rebooted and again specified gpt on the boot line but did a regular install with auto partitioning ... that worked and got this special, small "grub_bios" partition.
OK, another try but lets do custom partitioning ... it would not let me proceed until I allocated a 1 MB "bootbios" partition (I specified that as the mountpoint). OK, now I wanted to look at anaconda-ks.cfg to see want anaconda used to specify this special partition ... nothing!
OK, do I write this up as a bug or an RFE. Yes, I know that I can go in and preallocate the partition manually but the whole idea of kickstart is to do all of this stuff automagically. I assume we will be needing this stuff for UEFI and we will be doing UEFI under KVM as well.
Comments?
Gene
On Oct 27, 2013, at 7:06 AM, Gene Czarcinski gene@czarc.net wrote:
OK, now I wanted to look at anaconda-ks.cfg to see want anaconda used to specify this special partition ... nothing!
OK, do I write this up as a bug or an RFE.
Bug against Fedora 20. But aren't the GUI options effectively translated into kickstart commands behind the scenes? I think there must be a way to do this in kickstart, it's just not obvious. I'd say tomorrow you go to IRC on freenode, and ask what flag to use for GPT biosboot on #anaconda. Anaconda is a Monday to Friday thing.
Yes, I know that I can go in and preallocate the partition manually but the whole idea of kickstart is to do all of this stuff automagically.
Well you'd need to look at the code to see what the effect of the 'gpt' line is, there may be some automagic stuff like it causing parted to create gpt instead of msdos disklabels. But there's also code to identify if the platform is UEFI or BIOS, and if the disk is bigger than 2TB, either of which will also trigger the use of gpt instead of msdos disklabels - presumably without having to inform the installer via kickstart.
I assume we will be needing this stuff for UEFI and we will be doing UEFI under KVM as well.
Yes, via OVMF. http://www.linux-kvm.org/page/OVMF
But there's supposedly a FAT license issue that prevents that project from being included with Fedora. For the purposes of implementing UEFI, it's a free license, so I don't understand what the problem is. https://fedoraproject.org/wiki/Testing_secureboot_with_KVM#EDK2_Licensing_Is...
Chris Murphy
On 10/27/2013 01:49 PM, Chris Murphy wrote:
On Oct 27, 2013, at 7:06 AM, Gene Czarcinski gene@czarc.net wrote:
OK, now I wanted to look at anaconda-ks.cfg to see want anaconda used to specify this special partition ... nothing!
OK, do I write this up as a bug or an RFE.
Bug against Fedora 20. But aren't the GUI options effectively translated into kickstart commands behind the scenes? I think there must be a way to do this in kickstart, it's just not obvious. I'd say tomorrow you go to IRC on freenode, and ask what flag to use for GPT biosboot on #anaconda. Anaconda is a Monday to Friday thing.
I liked the idea of the partition being automagically added but, well, that was overcome by reality and the fact that "biosboot" has already been implemented. The documentation of "part or partition: should be updated to include it buit it is in there buried under "bootloader" where it says that if a gpt partition is to be used, then part biosboot --fstype=biosboot --size=1 needs to be added to the kickstart file. This is only necessary for a new disk.
Gene
Yes, I know that I can go in and preallocate the partition manually but the whole idea of kickstart is to do all of this stuff automagically.
Well you'd need to look at the code to see what the effect of the 'gpt' line is, there may be some automagic stuff like it causing parted to create gpt instead of msdos disklabels. But there's also code to identify if the platform is UEFI or BIOS, and if the disk is bigger than 2TB, either of which will also trigger the use of gpt instead of msdos disklabels - presumably without having to inform the installer via kickstart.
I assume we will be needing this stuff for UEFI and we will be doing UEFI under KVM as well.
Yes, via OVMF. http://www.linux-kvm.org/page/OVMF
But there's supposedly a FAT license issue that prevents that project from being included with Fedora. For the purposes of implementing UEFI, it's a free license, so I don't understand what the problem is. https://fedoraproject.org/wiki/Testing_secureboot_with_KVM#EDK2_Licensing_Is...
Chris Murphy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Oct 27, 2013, at 1:51 PM, Gene Czarcinski gene@czarc.net wrote:
I liked the idea of the partition being automagically added but, well, that was overcome by reality and the fact that "biosboot" has already been implemented. The documentation of "part or partition: should be updated to include it buit it is in there buried under "bootloader" where it says that if a gpt partition is to be used, then part biosboot --fstype=biosboot --size=1 needs to be added to the kickstart file. This is only necessary for a new disk.
Right, it's reused automatically by grub when found by partitiontypeGUID, and has no format. I think kickstart workflow doesn't require things like GUI does, where the lack of biosboot can fail rather than cause it to be automatically created if not already present.
https://bugzilla.redhat.com/show_bug.cgi?id=1022316
Chris Murphy
anaconda-devel@lists.stg.fedoraproject.org