Bug 1168118
| Summary: | Custom UEFI layout with /boot/efi on second disk fails: is_valid_stage1_device not called on disks after the first | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sumit Rai <sumitrai96> | ||||||||||||||||||||||||||||||
| Component: | anaconda | Assignee: | Vendula Poncova <vponcova> | ||||||||||||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||||
| Version: | 30 | CC: | an0nym, anaconda-maint-list, awilliam, bcotton, bmourelo, bugzilla, butirsky, demiobenour, denis, dubtsov, elreydetodo, extras-qa, germano.massullo, g.kaviyarasu, hellis_waitin, jonathan, jreznik, jtakahashi2, kparal, lmacken, mattdm, maurizio.antillon, mbw227, mddeff, metst13, mkolman, pedro.a34195, pschindl, robatino, samuel-rhbugs, satellitgo, sbueno, ssuehle, sumitrai96, vanmeeuwen+fedora, vedran, vponcova, wjlljam, ZarakaAngel, znmeb | ||||||||||||||||||||||||||||||
| Target Milestone: | --- | Keywords: | CommonBugs, Reopened, Triaged | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||||||||||||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F21_bugs#bootloader-target-disk PrioritizedBug | ||||||||||||||||||||||||||||||||
| Fixed In Version: | anaconda-32.4-1 anaconda-31.22.4-1.fc31 | Doc Type: | Bug Fix | ||||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||||
| Clone Of: | 1010495 | ||||||||||||||||||||||||||||||||
| : | 1488204 (view as bug list) | Environment: | |||||||||||||||||||||||||||||||
| Last Closed: | 2019-09-21 00:02:36 UTC | Type: | Bug | ||||||||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||||||||
| Bug Depends On: | |||||||||||||||||||||||||||||||||
| Bug Blocks: | 1277290 | ||||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||||
|
Description
Sumit Rai
2014-11-26 08:03:03 UTC
Created attachment 961526 [details]
Anacond program.log.
Created attachment 961529 [details]
Anacond storage.log.
Created attachment 961530 [details]
Anaconda ifcfg.log.
Created attachment 961531 [details]
dmesg
Created attachment 961532 [details]
parted logs.
The issue doesn't occur if you select just one disk instead of two. In my intance when I just selected the /dev/mmcblk0 as the disk with custom partitioning instead of /dev/mmcblk0 and /dev/sda. It's very clear from the below logs that the anaconda don't query the Linux EFI partition /dev/mmcblk0p1 for stage1 device as it should. It just queries partitions of disk sda for stage1 device. 23:51:54,174 DEBUG anaconda: new disk order: [] 23:52:19,707 DEBUG anaconda: stage1 device cannot be of type lvmvg 23:52:19,707 DEBUG anaconda: device.format.name is 'Unknown' 23:52:19,707 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora_20) returning False 23:52:19,708 DEBUG anaconda: stage1 device cannot be of type lvmlv 23:52:19,708 DEBUG anaconda: device.format.name is 'ext4' 23:52:19,708 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora_20-root) returning False 23:52:19,708 DEBUG anaconda: stage1 device cannot be of type disk 23:52:19,709 DEBUG anaconda: device.format.name is 'partition table (GPT)' 23:52:19,709 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda) returning False 23:52:19,710 DEBUG anaconda: _is_valid_disklabel(sda1) returning True 23:52:19,711 DEBUG anaconda: _is_valid_size(sda1) returning True 23:52:19,711 DEBUG anaconda: _is_valid_location(sda1) returning True 23:52:19,712 DEBUG anaconda: _is_valid_format(sda1) returning False 23:52:19,712 DEBUG anaconda: is_valid_stage1_device(sda1) returning False 23:52:19,712 DEBUG anaconda: device.format.name is 'EFI System Partition' 23:52:19,712 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda1) returning False 23:52:19,713 DEBUG anaconda: _is_valid_disklabel(sda2) returning True 23:52:19,714 DEBUG anaconda: _is_valid_size(sda2) returning True 23:52:19,714 DEBUG anaconda: _is_valid_location(sda2) returning True 23:52:19,714 WARN anaconda: sda2 not bootable 23:52:19,715 DEBUG anaconda: _is_valid_format(sda2) returning False 23:52:19,715 DEBUG anaconda: is_valid_stage1_device(sda2) returning False 23:52:19,715 DEBUG anaconda: device.format.name is 'hfs+' 23:52:19,715 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda2) returning False 23:52:19,716 DEBUG anaconda: _is_valid_disklabel(sda3) returning True 23:52:19,717 DEBUG anaconda: _is_valid_size(sda3) returning True 23:52:19,717 DEBUG anaconda: _is_valid_location(sda3) returning True 23:52:19,717 WARN anaconda: sda3 not bootable 23:52:19,718 DEBUG anaconda: _is_valid_format(sda3) returning False 23:52:19,718 DEBUG anaconda: is_valid_stage1_device(sda3) returning False 23:52:19,718 DEBUG anaconda: device.format.name is 'hfs+' 23:52:19,718 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda3) returning False 23:52:19,719 DEBUG anaconda: _is_valid_disklabel(sda4) returning True 23:52:19,720 DEBUG anaconda: _is_valid_size(sda4) returning True 23:52:19,720 DEBUG anaconda: _is_valid_location(sda4) returning True 23:52:19,720 WARN anaconda: sda4 not bootable 23:52:19,721 DEBUG anaconda: _is_valid_format(sda4) returning False 23:52:19,721 DEBUG anaconda: is_valid_stage1_device(sda4) returning False 23:52:19,721 DEBUG anaconda: device.format.name is 'hfs+' 23:52:19,721 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda4) returning False 23:52:19,722 DEBUG anaconda: _is_valid_disklabel(sda5) returning True 23:52:19,723 DEBUG anaconda: _is_valid_size(sda5) returning True 23:52:19,723 DEBUG anaconda: _is_valid_location(sda5) returning True 23:52:19,723 WARN anaconda: sda5 not bootable 23:52:19,723 DEBUG anaconda: _is_valid_format(sda5) returning False 23:52:19,724 DEBUG anaconda: is_valid_stage1_device(sda5) returning False 23:52:19,724 DEBUG anaconda: device.format.name is 'hfs+' 23:52:19,724 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda5) returning False 23:52:19,725 DEBUG anaconda: _is_valid_disklabel(sda6) returning True 23:52:19,725 DEBUG anaconda: _is_valid_size(sda6) returning True 23:52:19,725 DEBUG anaconda: _is_valid_location(sda6) returning True 23:52:19,726 WARN anaconda: sda6 not bootable 23:52:19,726 DEBUG anaconda: _is_valid_format(sda6) returning False 23:52:19,726 DEBUG anaconda: is_valid_stage1_device(sda6) returning False 23:52:19,726 DEBUG anaconda: device.format.name is 'physical volume (LVM)' 23:52:19,726 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda6) returning False 23:52:19,727 DEBUG anaconda: _is_valid_disklabel(sda7) returning True 23:52:19,728 DEBUG anaconda: _is_valid_size(sda7) returning True 23:52:19,728 DEBUG anaconda: _is_valid_location(sda7) returning True 23:52:19,728 WARN anaconda: sda7 not bootable 23:52:19,728 DEBUG anaconda: _is_valid_format(sda7) returning False 23:52:19,728 DEBUG anaconda: is_valid_stage1_device(sda7) returning False 23:52:19,729 DEBUG anaconda: device.format.name is 'physical volume (LVM)' 23:52:19,729 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(sda7) returning False 23:52:19,729 ERR anaconda: BootLoader setup failed: failed to find a suitable stage1 device 23:52:19,735 INFO anaconda: Thread Done: AnaExecuteStorageThread (140213584131840) Fixing blocker fields - moving to proposed. PS Sumit Rai: This bug would be easier to read if you simply created a new one and referenced to the old one, rather than cloning all existing comments. An idea for next time. Thanks. > PS Sumit Rai: This bug would be easier to read if you simply created a new
> one and referenced to the old one, rather than cloning all existing
> comments. An idea for next time. Thanks.
You are right, I will take this into account while reporting bugs in future. Thanks.
"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." I'm not following this as described. The parted output shows both devices are fully partitioned, and I'm not seeing in the report that any existing partition has been deleted first. So how was /boot/efi added if there's not enough space? The existing ESP's on the two devices cannot be used. Both of them have parted 'boot,esp' flags which is incorrect on Macs, even though the one on the sdcard is HFS+ it still won't work because the partitiontypeGUID is set to EFI System partition. Seems like a step removing existing partitions is missing? (In reply to Chris Murphy from comment #9) > "The installer must be able to create and install to any workable partition > layout using any file system and/or container format combination offered in > a default installer configuration." > > I'm not following this as described. The parted output shows both devices > are fully partitioned, and I'm not seeing in the report that any existing > partition has been deleted first. So how was /boot/efi added if there's not > enough space? Partition /dev/mmcblk0 was marked for refromatting with Linux HFS+ ESP fs_type and /boot/efi as mount. I don't understand the rational behind deleting existing partitions and not reusing them. Most OS installer I have used allows you to use existing partions after reformatting. > > The existing ESP's on the two devices cannot be used. Both of them have > parted 'boot,esp' flags which is incorrect on Macs, even though the one on > the sdcard is HFS+ it still won't work because the partitiontypeGUID is set > to EFI System partition. Seems like a step removing existing partitions is > missing? I was receiving this error even before the boot,esp flag was present on /dev/mmclkb0p1. Trying to guess a workaround I marked /dev/mmcblk0p1 as boot,esp. But it didn't work. Chris Murphy: I have reproduced this bug to answer your concerns. Steps 1. Boot from live cd. 2. /dev/sda has one Mac OS X EFI partition. /dev/mmcblk0 has no partitions. 3. I selected custom partion, and created three partitions. a.) Root LV of size 10000MiB. b.) /boot of size 500MiB on /dev/mmcblk0p2. c.) /boot/efi of 200MiB on /dev/mmcblk0p1. FS Type set to Linux HFS+ ESP as required. 4. Click done and I get the error:- No valid bootloader target device found. See below for details. For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi. You have not specified a swap partition. Although not strictly required in all cases, it will significantly improve performance for most installations. Please find attachment titled 'Reproduced without boot,esp flag' with file 'anaconds_bug_reproduced.tar.gz' containing all the logs. Thanks. Created attachment 961749 [details]
Reproduced without boot,esp flag
Comment on attachment 961749 [details]
Reproduced without boot,esp flag
To answer Chris Murphy's concerns about boot,esp flag set on existing partition.
I have reproduced the bug w/o boot,esp flag set on more than one partition, and not existing partitions on /dev/mmcblk0. Marking old logs as obsolete.
Again, If I select only one disk instead of two the bug is not reprocuded. Case 1. Two disks /dev/sda and /dev/mmcblk0 are used. MacEFIGRUB.is_valid_stage1_device() is never called on /dev/mmcblk0p1 which is stage1 device. Case 1. Only one disk /dev/mmcblkp0 is used. MacEFIGRUB.is_valid_stage1_device() is called on /dev/mmcblk0p1 at some point and returns True. But even in this case Logical Volume 'fedora-root' and 'fedora-swap' are quried first. I suggest you pick up the block device marked as /boot/efi in Anaconda GUI and call MacEFIGRUB.is_valid_stage1_device() on that device to begin with. It correctly finds /dev/mmcblk0p1 as stage 1 device. 12:29:12,262 DEBUG anaconda: updated device_container_raid_level to None 12:29:12,262 DEBUG anaconda: updated device_container_encrypted to False 12:29:12,262 DEBUG anaconda: updated device_container_size to 0 12:29:12,269 DEBUG anaconda: populate_raid: 2, None 12:29:14,921 DEBUG anaconda: new disk order: [] 12:29:14,975 DEBUG anaconda: stage1 device cannot be of type lvmvg 12:29:14,975 DEBUG anaconda: device.format.name is 'Unknown' 12:29:14,975 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora) returning False 12:29:14,976 DEBUG anaconda: stage1 device cannot be of type lvmlv 12:29:14,976 DEBUG anaconda: device.format.name is 'ext4' 12:29:14,976 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora-root) returning False 12:29:14,977 DEBUG anaconda: stage1 device cannot be of type lvmlv 12:29:14,977 DEBUG anaconda: device.format.name is 'swap' 12:29:14,977 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(fedora-swap) returning False 12:29:14,978 DEBUG anaconda: stage1 device cannot be of type disk 12:29:14,978 DEBUG anaconda: device.format.name is 'partition table (GPT)' 12:29:14,978 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0) returning False 12:29:14,979 DEBUG anaconda: _is_valid_disklabel(mmcblk0p1) returning True 12:29:14,980 DEBUG anaconda: _is_valid_size(mmcblk0p1) returning True 12:29:14,980 DEBUG anaconda: _is_valid_location(mmcblk0p1) returning True 12:29:14,981 WARN anaconda: mmcblk0p1 not bootable 12:29:14,981 DEBUG anaconda: _is_valid_format(mmcblk0p1) returning True 12:29:14,981 DEBUG anaconda: is_valid_stage1_device(mmcblk0p1) returning True 12:29:14,981 DEBUG anaconda: device.format.name is 'Linux HFS+ ESP' 12:29:14,981 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0p1) returning True 12:29:14,986 DEBUG anaconda: _is_valid_disklabel(mmcblk0p1) returning True 12:29:14,986 DEBUG anaconda: _is_valid_size(mmcblk0p1) returning True 12:29:14,987 DEBUG anaconda: _is_valid_location(mmcblk0p1) returning True 12:29:14,987 WARN anaconda: mmcblk0p1 not bootable 12:29:14,987 DEBUG anaconda: _is_valid_format(mmcblk0p1) returning True 12:29:14,987 DEBUG anaconda: is_valid_stage1_device(mmcblk0p1) returning True 12:29:14,987 DEBUG anaconda: device.format.name is 'Linux HFS+ ESP' 12:29:14,987 DEBUG anaconda: MacEFIGRUB.is_valid_stage1_device(mmcblk0p1) returning True 12:29:14,988 DEBUG anaconda: _is_valid_disklabel(mmcblk0p2) returning True 12:29:14,988 DEBUG anaconda: _is_valid_size(mmcblk0p2) returning True 12:29:14,989 DEBUG anaconda: _is_valid_location(mmcblk0p2) returning True 12:29:14,989 DEBUG anaconda: _is_valid_partition(mmcblk0p2) returning True 12:29:14,989 DEBUG anaconda: _is_valid_format(mmcblk0p2) returning True : Discussed in 2014-11-26 Blocker Review Meeting [1]. Voted as a Punt. More information is needed to decide on this bug. Please retest this attempted to use the guided install. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-26/ Discussed in 2014-11-26 Blocker Review Meeting [1]. Voted as a RejectedBlocker. This bug doesn't violate any specific criteria due to sdcards not being a supported storage type. Supported storage types are SATA, PATA and SCSI for locally connected storage. We can revisit this for F22. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-26/ (In reply to Scott Suehle from comment #16) I agree with the result in this case, but the rationale is a catch-22. For ARM we need to have either mmc/sdcard or USB supported because those boards only offer those connections - so that needs updating. But on Macs, I've found mmc/sdcard is unreliable for booting due to, I think, proprietary firmware issues. I can install Fedora on mmcblk0 on my Mac, but booting from it fails even though I can boot OS X from that same sdcard. Everytime proprietary firmware isn't available I usually, but not always, get spurious errors preventing mmc/sdcard functionality. These errors never happen when the firmware is available. This is the same firmware required for wifi functionality, btw. This bug is probably legitimate, but it's reasonable that it needs to be reproduced on supported storage types. Clearly the problem isn't using mmcblk0, because installation proceeds when only mmcblk0 is used; the bug is only triggered when there are two devices selected for installation. I think I was intending, with the wording "Locally connected storage interfaces include PATA, SATA and SCSI.", to suggest that those weren't the *only* locally connected storage interface, just examples (of the most common ones). I agree with cmurf that it'd be a mistake to say only those interfaces can block. I also agree with rejecting this as a blocker, though, because it seems to require just too many unusual conditions: installing to *both* a hard disk *and* an SD card, on a Mac. That's a bit of a lottery-winner situation, too rare to block on. (Why do it at all?) (In reply to Chris Murphy from comment #17) > (In reply to Scott Suehle from comment #16) > But on Macs, I've found mmc/sdcard is unreliable for booting due to, I > think, proprietary firmware issues. Yes, from my experience mmc/sdcard on Mac does seem to have some issues. e.g. https://bugzilla.kernel.org/show_bug.cgi?id=79301 >I can install Fedora on mmcblk0 on my > Mac, but booting from it fails even though I can boot OS X from that same > sdcard. Everytime proprietary firmware isn't available I usually, but not > always, get spurious errors preventing mmc/sdcard functionality. These > errors never happen when the firmware is available. This is the same > firmware required for wifi functionality, btw. However these problems have not prevented me from Booting Fedora Linux directly from mmc on my Mac. I used to boot an earlier version of Fedora from mmc all the time w/o any problems. In fact, flexibility to install Linux on USB/mmc is one of the things I find very useful about Linux, so do a lot of other Linux users in my opinion. After installing Fedora 21 beta on mmc (via use only one disk workaround), I tried booting from mmc w/o any problems untill I hit the bug https://bugzilla.redhat.com/show_bug.cgi?id=1040669 In this case behaviour of mmc is not very different from internal ssd which also failed to boot Fedora 20 due to this LVM modules missing from initrd. > This bug is probably legitimate, but it's reasonable that it needs to be > reproduced on supported storage types. Clearly the problem isn't using > mmcblk0, because installation proceeds when only mmcblk0 is used; the bug is > only triggered when there are two devices selected for installation. I do agree that the problem isn't mmcblk0. It's resonable from user prospective to expect that anaconda search the device configurated as /boot/efi for stage1 lable before initiating scan of all the supported devices and at least let it install the OS. However, If you think it's reasonable to reproduce it on supported storage types. I wil try to reproduce it and get back to you soon. Also, after looking at logs of 2014-11-26 Blocker Review Meeting I have a question. >16:33:13 <sgallagh> Is this Guided or is it custom? Could you please explain what you mean by Guided? By guided are you refering to automatically configure partition option. Current anaconda installer only gives two options when it comes to partitioning. 1. Automatically configure partitioning. 2. I will configure partitioning. (custom). Option 1. Automatically configure cannot be considered guided since it by default uses free space to automatically create partitions w/o any inputs from user. (In reply to Adam Williamson (Red Hat) from comment #18) > I think I was intending, with the wording "Locally connected storage > interfaces include PATA, SATA and SCSI.", to suggest that those weren't the > *only* locally connected storage interface, just examples (of the most > common ones). I agree with cmurf that it'd be a mistake to say only those > interfaces can block. > > I also agree with rejecting this as a blocker, though, because it seems to > require just too many unusual conditions: installing to *both* a hard disk > *and* an SD card, on a Mac. That's a bit of a lottery-winner situation, too > rare to block on. (Why do it at all?) I am trying to have my Fedora Linux Boot (stage1 and stage2) partition on Memory Card, and have my root partition on internal ssd so that I don't have to resize/repartition internal ssd and risk losing data. How is this any different from situation where you want to install Linux with boot partition on primary master disk1, and root partition on secondary slave disk2? "Option 1. Automatically configure cannot be considered guided since it by default uses free space to automatically create partitions w/o any inputs from user." Guided is what we call it. It does require user input when sufficient unpartitioned space is not available. "How is this any different from situation where you want to install Linux with boot partition on primary master disk1, and root partition on secondary slave disk2?" Dunno, but I just tried that, and it works - I did an install in a UEFI VM (not a Mac) with /boot , /boot/efi and swap on one (VirtIO) disk and / on a second (VirtIO) disk, and the installer was fine with that, and the installed system boots. (In reply to Adam Williamson (Red Hat) from comment #22) > Dunno, but I just tried that, and it works - I did an install in a UEFI VM > (not a Mac) with /boot , /boot/efi and swap on one (VirtIO) disk and / on a > second (VirtIO) disk, and the installer was fine with that, and the > installed system boots. I tried it on non-Mac UEFI system with two disks sda and sdb and custom partitioning. 1. When /boot/efi partition is on disk sda. It let's you proceed with installation. 2. When /boot/efi partition is on disk sdb it fails with stage1 boot device not found error as sdb partitions are never queried using is_valid_stage1_device(dev) function. Again, I would expect anaconda to pick up 'dev' argument to is_valid_stage1_device() from device corresponding to /boot/efi mount point specified in anaconda GUI rather than defaulting to sda. I do agree that it's very unlikely scenario and should not be a blocker. However, I would really appreciate it if it can be fixed in future. Thanks. I think you're misunderstanding that the is_valid_stage1_device() check is not somehow specific to UEFI, it's a much more generic check than that, so your recommended fix really just wouldn't work, because that's really just...not the way around that code works (AIUI anyway). But it's clearly a bug if the disk/partition which is expected to be the 'stage1' device is not always considered as a candidate, yes. I'll see if I can reproduce your result. yeah, I can reproduce it with the ESP on the *second* disk of a two-disk system. Interesting, let me dig in. Still looking into this, but for now, here's my reproducer: * Boot a UEFI system with two empty disks attached (Xda and Xdb) * Select both disks and go to custom partitioning * Create a layout of simple partitions with /boot and /boot/efi on Xdb, / and swap on Xda, all correct (sufficient size, /boot/efi as ESP filesystem) * Try to complete custom partitioning It'll hit the error condition, as Sumit says. No valid stage1 device. I'll attach logs shortly. Logs have a 'crash' at the end which was just me triggering one so I could see if I could do any debugging from pdb, but of course it doesn't have the relevant environment...d'oh. Created attachment 961841 [details]
anaconda.log from my reproduction with Final TC4
Created attachment 961842 [details]
storage.log from my reproduction with Final TC4
I'm still working on this one as it worries me a bit; so far I've worked out that we're failing when custom.py runs _do_check(). We hit the exception here:
# set up bootloader and check the configuration
try:
self.storage.setUpBootLoader()
except BootLoaderError as e:
log.error("storage configuration failed: %s", e)
What happens there is blivet/blivet/__init__.py's setUpBootLoader() calls self.ksdata.bootloader.execute(), which is the execute() method in anaconda/pyanaconda/kickstart.py's Bootloader() class. By throwing some debug logs into *that*, I've determined that when it's run, self.bootDrive is not set, which causes it to just use the first disk as the bootDrive. I think that's the problem, I'd expect that *something* should have set bootDrive at that point. I'm now trying to figure out why that's not happening.
I also tested and found that this works in Fedora 20; it got broken somewhere between 20 and 21. That should help us narrow down the cause.
Ah, correction: it's broken in F20 as well, you just don't see the error until you get back to the hub in F20's design. You can't work around this by going into the disk summary and picking Xdb as the boot drive before you enter custom partitioning, because that doesn't work. Somehow when you enter custom partitioning, gui/spokes/storage.py's _doExecute() is run, fails when it does try: doKickstartStorage() , and resets the bootDrive to "". (As a side note, picking Xdb as the boot drive from the summary page and then using guided partitioning *does* work, by the looks of things - it looks like it would put /boot/efi on Xdb - but that's not really relevant here, just thought I'd test it.) So, I have a change that fixes this, I think. AFAICS bootDrive has never really been set except by user interaction, so I decided trying to make that get set during partitioning was the wrong way to go, and instead I made the execute() method of the Bootloader() class smarter. Here it is:
=====================
diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py
index 9c96d59..9dd6e44 100644
--- a/pyanaconda/kickstart.py
+++ b/pyanaconda/kickstart.py
@@ -379,9 +379,19 @@ class Bootloader(commands.bootloader.F21_Bootloader):
if self.timeout is not None:
storage.bootloader.timeout = self.timeout
+ disks = storage.disks
+ if platform.bootStage1ConstraintDict["mountpoints"]:
+ # reduce the set of possible 'boot disks' to the disks containing
+ # a valid stage1 mount point, if there are any
+ disks = [p.disk for p in storage.devices if getattr(p.format, "mountpoint", None) in platform.bootStage1ConstraintDict["mountpoints"]]
+ if not disks:
+ # but if not, just go ahead and use the set of all disks or
+ # else we'll error out later
+ disks = storage.disks
+
# Throw out drives specified that don't exist or cannot be used (iSCSI
# device on an s390 machine)
- disk_names = [d.name for d in storage.disks
+ disk_names = [d.name for d in disks
if not d.format.hidden and not d.protected and
(not blivet.arch.isS390() or not isinstance(d, blivet.devices.iScsiDiskDevice))]
diskSet = set(disk_names)
======================
there's probably a more elegant way to do the first bit (maybe sort disk_names with disks that have a stage1 mount point on them first?), but it gets the job done. If this is a platform where the stage1 device is a mounted partition, and there's at least one valid stage1 mount point configured, we use the set of disks that has valid stage1 mount points on it as the set of candidates for bootDrive.
If not, we just go back to using the full set of disks - if there's no valid mount point we'll never actually manage to set a valid stage1 device, but we still need execute() to run without crashing because it gets run when we first enter the custom part screen, and probably on other paths too. It might be cleaner to make execute() indicate inevitable failure somehow in this case, instead of returning a bootDrive for us to run some pointless is_valid_stage1_device() checks on, but I wanted to change existing behaviour as little as possible for now.
Really this whole behaviour is a bit bizarre for the UEFI case as there's no such thing as the 'boot disk' in that case, it's all a bit artificial.
Sumit: can you please test with https://www.happyassassin.net/updates/updates-1168118.img ? Boot a Final TC4 install image with this parameter: inst.updates=https://www.happyassassin.net/updates/updates-1168118.img and see if it works. Thanks! I'm re-proposing this as at least a freeze exception issue. You can argue it's a blocker under Final "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.", but we found it a bit late and we appear to have shipped F20 with this bug and it hasn't ended the world. But it *is* pretty bad. (In reply to Adam Williamson (Red Hat) from comment #33) > Sumit: can you please test with > https://www.happyassassin.net/updates/updates-1168118.img ? Boot a Final TC4 > install image with this parameter: > > inst.updates=https://www.happyassassin.net/updates/updates-1168118.img > > and see if it works. Thanks! I tried to reproduce it on non-Mac UEFI system by booting the Fedora-Live-Workstation-x86_64-21-TC4.iso with the parameter you mentioned. Your patch seems to fix the issue. Thanks. Title: TC4 With Patch 1168118 Log File: anaconda_TC4.tar.gz For the sake of being through before reporting back to you, I tried to reproduce this bug on Fedora-Live-Workstation-x86_64-21-TC4.iso WITHOUT your patch. I was able to successfully reproduce it. But, I was able to workaround the issue, it's interesting to note that the same workaround didn't work for you on RHEL 7, but it works on Fedora 21 TC4. From Bug 1168777: "I wondered if it at least works if you go into the "Full disk summary" page and set the appropriate disk as the 'boot disk' before going into custom partitioning, but it doesn't,..." I went back to "Full disk summary" page and set the disk sdb as boot disk before going back into custom, and it seems to find the stage1 device now. Title: TC without Patch Log: anaconda_TC4_workaround.tar.gz I will try to reproduce it on my original Mac + mmc setup soon with your patch as well as the workaround and get back to you. Created attachment 962428 [details]
TC4 With Patch 1168118
Created attachment 962430 [details]
TC4 without Patch
New anaconda build with the patch included is available at: http://koji.fedoraproject.org/koji/taskinfo?taskID=8251513 I'm intentionally not creating a bodhi update for it so that it doesn't affect the current release process before it is officially tested and approved as necessary and applicable for F21 Final. Petr Schindler tested this today, the new anaconda build from comment 38 fixes the problem, according to him. I vote +1 FE. Yep. I reproduced this without fix and then I tested updated anaconda from koji. It fixes this bug. +1 FE Sumit: are you able to test this on the originally-affected Mac configuration? I strongly believe the problem there is the same as the non-Mac reproducer, but it'd be good to have confirmation. Testing the 'workaround' a bit more, you can workaround this from the "Full disk summary" screen indeed, at least in the following way: 1. Trigger the bug, after the warning about the layout is shown, just click Done again and it'll let you back to the hub, with the Installation Destination spoke in the error state 2. Go back into Installation Destination, go to the summary screen, pick Xdb as the boot disk 3. Go back through custom part, changing nothing this works, but it's messy and unnecessarily difficult. For me, trying to do it by going into the summary screen *before* you go to custom partitioning the first time definitely doesn't work. If we want to ship RC1 or anaconda folks decide patching this is a bad idea so late after all, we can document it at least. https://www.happyassassin.net/updates/updates-1168118-rc1.img is a slightly different version of the fix (generated against 21.48.18, the anaconda in Final RC1) which I like a bit more. It would be great if folks can test that, and also test cases *other* than the reproducer of the bug - this codepath is hit on absolutely all install attempts, so it'd be very good for folks to test it with a range of different scenarios (normal UEFI installs, BIOS installs, really any kind of install at all) and make sure it didn't inadvertently break anything. https://www.happyassassin.net/updates/updates-1168118-tc2.img is the same fix against anaconda 21.48.16, as included in F21 PPC TC2 - this new version of the fix should solve the same problem for PPC users with the prepboot/appleboot partition. Testing of that would also be helpful. The PPC reproducer is very similar to the UEFI case, just put the prepboot partition on a disk other than the first and don't explicitly choose a boot disk. Created attachment 962606 [details]
Anaconda GUI Manual Partitioning screen
Mount point /boot is not updated on partiotion map box to the left even after clicking update settings.
Adam: I was testing update 1168118-rc1.img on my origninal Mac setup and I have come across another bug. FYKI #cat /proc/cmdline BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-T4 ro rd.live.image inst.updates=https://www.happyassassin.net/updates/updates-1168118-rc1.img I selected both mmc and internal ssd, and proceeded to manual partitioning. I accidently set the mountpoint of partition /dev/mmcblk0p2 to / instead of /boot. When I changed the mountpoint back to /boot and clicked "Update Settings" icon, it still shows mountpoint as / in the left part of screen. I have attached GUI snapshot in my above comment and will upload full anaconda logs below. Please don't. If it's reproducible, please file it as a new bug. We deal with one bug per bug report, anything else is unmanageable. Created attachment 962607 [details]
All anaconda logs + dmesg
Logs for GUI "Update Settings" Bug.
Comment on attachment 962606 [details]
Anaconda GUI Manual Partitioning screen
Removing this attachment since it's not SOP to mix up two bugs.
I have not been able to reproduce stage 1 partition not found issue on MacBook with two disks(mmc + ssd) with updates-1168118-rc1.img. However issue is not fixed in updates-1168118-tc2.img. The tc2.img is the same code as rc1.img but built against a different anaconda, so I could test it on PPC64, where the latest available images were based on an older anaconda. There's no need to test the tc2 image on Final RC1 for x86. I think we can count your experience as a +1 for the patch. Created attachment 962610 [details] Anaconda logs for updates-1168118-tc2.img [liveuser@localhost tmp]$ cat /proc/cmdline BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-T4 ro rd.live.image quiet rhgb inst.updates=http://www.happyassassin.net/updates/updates-1168118-tc2.img Adam: +1 for the patch. those logs look like somehow the updates.img was not applied, if you had used it then there should be "Disks with potentially valid stage1 volumes:" messages in anaconda.log (even if the fix didn't actually work), but there aren't. check if /tmp/updates exists and has a pyanaconda/kickstart.py with this bit in it:
# sort the list of disks with those that contain possibly-valid
# stage1 partitions first, so we'll pick a disk with one as
# bootDrive if it has not been explicitly set: RHBZ #1168118
(In reply to Adam Williamson (Red Hat) from comment #53) > those logs look like somehow the updates.img was not applied, if you had > used it then there should be "Disks with potentially valid stage1 volumes:" > messages in anaconda.log (even if the fix didn't actually work), but there > aren't. check if /tmp/updates exists and has a pyanaconda/kickstart.py with > this bit in it: > > # sort the list of disks with those that contain possibly-valid > # stage1 partitions first, so we'll pick a disk with one as > # bootDrive if it has not been explicitly set: RHBZ #1168118 I tried again, I found "Disks with....." string in anaconda logs as well as pyanaconda/kickstart.py in tmp/updates. I could not reproduce e bug this time. +1. Discussed in 2014-12-01 blocker review meeting. Accepted as a FE: people are understandably worried about tweaking this at this point, but the affected case is clearly bad behaviour and would be good to improve, and there's a reasonable consensus the patch is unlikely to cause bugs or unexpected behaviour changes. The fix for this was reverted by the anaconda team today. Setting back to ASSIGNED, and to CommonBugs, unless we need an RC3 and a fix for this is included, we will need to document the bad behaviour of anaconda with stage1 target partitions on devices beyond the first in CommonBugs. Moving to Rawhide, this is still valid there. Latest version of the patch, a substantially changed version of my v2 by Anne: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-December/014909.html This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 So I tried a bit more to get this through. I revived and slightly revised the patch Anne and I came up with to be more conservative (applying only to platforms where stage1 must be a partition with a particular mount point): https://github.com/rhinstaller/anaconda/pull/21 However, dlehman is still not sure. We discussed one of the complicating factors on IRC and he would like to fix that first. To re-explain that, as this bug is long. This does not work: 0. Boot a UEFI system with two empty disks, vda and vdb 1. Enter INSTALLATION DESTINATION, select both disks as targets 2. Click 'Full disk summary and boot loader...' 3. Select vdb and click 'Set as Boot Device', click Close 4. Click "I will configure partitioning." 5. Click Done 6. Create /boot 7. Create /boot/efi, click 'Modify...', allow it to be only on vdb, click Update Settings 8. Create swap and / 9. Click Done You would expect "PROFIT!" to be step 10, right? No. What happens is: 10. Orange warning bar appears which says "Error checking storage configuration. Click for details or press Done again to continue." 11. Clicking the bar shows the error message "No valid boot loader target device found. See below for details. For a UEFI installation, you must include an EFI System Partition on a GPT-formatted disk, mounted at /boot/efi." To actually make anaconda happy, you now have to do this: 12. Click Done again 13. Click Accept Changes (you are now at the hub, with INSTALLATION DESTINATION in an error condition: "Error checking storage configuration") 14. Click INSTALLATION DESTINATION 15. Click "Full disk summary and bootloader..." vda, not vdb, is shown as the boot disk at this point. 16. Select vdb and click 'Set as Boot Device', click Close 17. Click Done (to go back to the custom partitioning screen) 18. Change nothing, click Done 19. Click Accept Changes *Finally*, you are now at the hub and anaconda is happy. I believe I figured out what was going on in this case: when you try and set vdb as the 'boot disk' before running through custom partitioning, anaconda runs the is_valid_stage1_device() checks when you enter custom partitioning and rejects your choice because vdb does not yet contain a 'valid' stage1 target device (i.e. a partition of type EFI mounted at /boot/efi). So it resets the 'boot disk' to vda. Effectively it's a catch 22: you can't set the boot disk as vdb until you've created a valid /boot/efi on vdb, but putting /boot/efi on vdb will always cause anaconda to complain until you've selected vdb as the 'boot disk'. If we could somehow 'fix' that so it at least works to select the disk on which you want to place /boot/efi as the 'boot disk' *before* entering custom partitioning, and avoid the need to click through scary warnings *then* set the 'boot disk' *then* click through custom partitioning again, that would definitely be an improvement. But I still believe it is an artificial and unnecessary requirement to require the user to select a 'boot disk' on platforms where the stage1 device must be a mounted partition in any case. So I don't ever have to reconstruct the codepath that leads to the behaviour seen in #c59 again (twice was enough), here it is: 1. At step 5 in the reproducer, pyanaconda/ui/gui/spokes/storage.py class StorageSpoke method _doExecute calls doKickstartStorage(self.storage, self.data, self.instclass) , wrapped in a try/except block. 2. doKickstartStorage() is in pyanaconda/kickstart.py (at the bottom). It calls ksdata.bootloader.execute(), which leaves bootDrive set to vdb and sets storage.bootloader.stage1_disk to vdb. doKickstartStorage() then calls storage.setUpBootLoader(), without early=True. 3. That's actually blivet/__init__.py setUpBootLoader(). It calls ksdata.bootloader.execute() again (which just does the same thing it did before), then calls self.bootloader.set_stage1_device(). 4. That's pyanaconda/bootloader.py class BootLoader method set_stage1_device(), which runs self.is_valid_stage1_device() on all storage devices on vdb (because it was set as bootloader.stage1_disk in step 2). 5. is_valid_stage1_device() determines that none of them is valid - because none of them has a mount point yet! - and so set_stage1_device() raises BootLoaderError. 6. The exception gets back to StorageSpoke _doExecute(), which unsets self.data.bootloader.bootDrive, as it's written to do that when it encounters a BootLoaderError exception. 7. We finish doing our partitioning and click Done. The sanity check method pyanaconda/ui/gui/spokes/custom.py class CustomPartitioningSpoke _do_check() is run on completion of the screen. 8. The sanity check code runs setUpBootLoader() again. setUpBootLoader() calls ksdata.bootloader.execute(). Because bootDrive was unset at step 6, execute() guesses vda. (If my patch is applied, this is the point at which it kicks in and guesses vdb instead and makes things work.) 9. setUpBootLoader() calls self.bootloader.set_stage_1_device() as before, it now checks all the partitions on vda, determines that none of them is valid, and raises BootLoaderError again. 10. _do_check() catches the BootLoaderError exception and sets the "Error checking storage configuration." message which we see in step 10 of the reproducer. If the user goes through steps 12 to 19 of the reproducer, then because the /boot/efi mount point is now set, set_stage1_device() works each time it's called and things become happy. I use Fedora since version 2. I've been very happy using especially version 4. But since version 5 I never was happy with Fedora, which I use to this day, always in trouble, even in the versions considered "stable". Every time I lose time in installation and after updates. This issue is ridiculous. Never Anaconda was worse. Can not work with two disks? Ridiculous. should be mature For me the solution above did not solve. I am outraged and leaving aside the Fedora in version 21. I was very patient, but always had to spend much time in all versions with matters which should long be mature. Especially me currently interested spin JAM, but there ubuntu studio making fame now right? I will follow with my JAM in opensuse. I concluded that the problem is not in Fedora, but the current development pattern. I'm tired. This time I can not apologize. I agree with William. I am not abandoning Fedora yet though. I literally spent whole evening, night and morning trying to reinstall Fedora 21 into 22 on a two-internal-disk (i. e. not an SD card or USB flash) Mac Mini with striped btrfs over luks. I've added second disk after installing Fedora 21, for some reason it became sda (and the main one became sdb), but it worked. So I could not even think disk bootloader placement could be the problem (but it turned out Anaconda looked for bootloader on the first disk and EFI partitions - both standard and HFS+ - were on second disk). And actually such a situation (not this exact bug) occurs for the second time. When I installed Fedora 21 I spent somewhat similar amount of time understanding why standard EFI partition was not working. Considering the common error message that gives not a single hint about HFS+ necessity, I had no clue it was the problem. Until being exhausted I found a similar bug report and an explanation how to workaround. I understand Macs are effing ugly in the way they implement UEFI and everything but still Anaconda installer leaves a perception of an alpha version for 3 releases in a row and it seems not to be getting better. So I fully support what William said as I can relate to his words. Adam, thank you for your time. Your workaround worked after a sleepless night. The underlying assumption of the installer's custom UI is provably wrong: - "Custom is custom, you're expected to know what you are doing", and therefore the user must always manually create an ESP mount point. See bug 1022316. So long as there's no change in that assumption, users will continue to fall into boot loader traps. I am a new user to Fedora but this bugzilla report seems to my issue as well.. I had fedora 20 installed which during the installation process for Fedora 21 I removed it by accepting changes during installation process of Fedora 21 and I am really fond of Fedora now so I really need to install it . Issue :: 1) I am using USB bootable to boot fedora 21 and install it. It freezes but it worked however when I install with manual partition in it chosen automatic partition method LVM, installation completes itself though it completes but I am not able to get into Fedora 21 boot menu. 2) After installation process gets complete when trying to get into boot menu removing USB it gets into grub rescue console every time. I have re-configured as per the instructions mentioned above but still can't able to make it work. Installation process gets complete with lots of lagging and freezing of screen. I am not very much technical with Linux but looking for assistance to get it installed. Using Fedora_21_x86_64.iso to boot and install. Thank you for any help. Shivam Gupta, post you hardware and filesystem config. Like how many disks, which one gets initialized as sda, sdb, etc, what partitions you created on what disks, have you created LVM yourself or just removed all the partitions in the installer and let it create them, have you created luks (cryptography), manually or using installer? I don't guarantee I will be able to help you but this information is necessary to start trying to help you. Thank you for reply, I got it fixed actually secure boot is enabled on my system so it requires gpt disk partition for UEFI firmware to boot. So i converted my disk from MBR to GPT and it boots. Now I am using Fedora 22. This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. I don't believe this was ever fixed. dlehman did have plans to work on it at one point, IIRC. *** Bug 1384627 has been marked as a duplicate of this bug. *** Please fix this already, I just spent two hours figuring this out on Fedora 25 Live install This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'. It also fails if your /boot partition is not on the primary disk even if your /boot/efi is. (My test case had /boot in mdadm raid1 between both disks) Installed Fedora 26 on MacBook Pro. Faced this problem. After hours of pain read carefully this post and in the middle of that found "So the required "Linux HFS+ ESP" is what this error message is referring to. You need to create a standard partition, ~100-200MB in size, and set the type to Linux HFS+ ESP. That's where GRUB will go, and the installer will stop complaining." This solved the problem (just used this partition type instead of ESP). However I must add that on my another (HP) laptop the ESP is called EFI System Partition and that caused no problems with an installation of Fedora Core 24 before. The maintainers should make the error message in Anaconda very clean and precise to save people's time, and avoid new/(incompatible with previous versions) behaviour. This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This bug stil exists today in Fedora 28. Very difficult to install Fedora on a brand new Dell G5, as it has, like many laptops today, two internal disks, an on-board 128G SSD and a regular 2.5"" disk. Trying to use the internal SSD to hold the ESP is nearly impossible as it's mapped as sdb by the linux kernel, triggering that false positive "No EFI partition error" by Anaconda. Let's assign this back to anaconda-maint-list as I'm guessing dlehman probably isn't going to fix it now. Anaconda folks, I put a summary of the problem and the code paths behind it in comments #59 and #60, that's a good place to start. *** Bug 1589332 has been marked as a duplicate of this bug. *** I have this too - HP Omen dual-boot Windows 10 Pro with a terabyte spinning disk and a 128 GB SSD which has a 256 MB EFI partition formatted FAT32. Both Antergos and Ubuntu installers mount it as /boot/efi successfully and give me a successful dual-boot. Fedora 29 Anaconda (custom - not the Blivet partitioner) claims it's NTFS and won't use it. Is there a fix? Is there a workaround? I want to switch the Linux boot on this machine over to Fedora 29 but I'm blocked - Anaconda is telling me I can't do it. Summary of the problem and work around is in comment 59. People still run into this on ask.fpo and #fedora and users@ - They have to use custom in order to put home on one of the drives and boot off another; which then gets them into the trap, and lacking knowledge of esoteric bootloader things they become stuck. Further the failure happens only at the end of the installation process. The user does the exact correct thing in custom partitioning, they indicate they want the bootloader on the 2nd drive, but the hidden "Full disk summary and bootloader" menu is still pointing to the 1st drive. This has been nominated as a Prioritized Bug. We will discuss it in IRC on Wednesday, 27 February. https://apps.fedoraproject.org/calendar/meeting/9468/?from_date=2019-02-25 For more information about the Fedora Prioritized Bug process, see https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process For the record, this was accepted as a PrioritizedBug on 27 March. I just forgot to leave a comment to that effect. Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/2108 It is a little difficult to understand what this bug is about, but the pull request should fix the case from the comment 59. The custom partitioning spoke should be able to choose a boot drive with a valid stage1 device now. The boot drive set with 'Full disk summary and boot loader...' is still not going to be used in this case. The problem is that we "execute the partitioning" before we enter the custom partitioning spoke, but that is for another bug. I'm a little unclear on the flow, here. Vendula, will this fix be in the F31 beta? Hi, the fix is in Rawhide and it will be in F31 final. It cannot get to F31 beta without a freeze exception. Sounds good. Thanks! Too late for the beta now, I guess. :) FEDORA-2019-2cabc3f936 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2cabc3f936 anaconda-31.22.4-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2cabc3f936 anaconda-31.22.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. |