Description of problem: When trying to install F25-ALPHA from Server-netinstall or Server.iso, I choose custom partitioning. When I select I will choose partitions, it doesn't show me existing Linux partitions. It does show a FreeBSD USF partition, with the option to delete that. Version-Release number of selected component (if applicable): How reproducible: Start an installation from a server or server-netinstall image. Choose custom partitioning after selecting a disk. Steps to Reproduce: 1.See above. :) 2. 3. Actual results: It will create a partition in free space if such exists, and also show a FreeBSD UFS partition with the option to delete and use that space. It doesn't show existing Linux partitions as available. This is new with F25, I haven't had this issue with Fedora 24 installs. Expected results: Existing partitions, such as sda1 (Linux on ext4 or sda5 (also ext4) should be shown as available to delete and use. Additional info: Output of fdisk on one of the two machines where I have had this issue. disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 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 Disklabel type: dos Disk identifier: 0xb271bbd4 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 48828415 48826368 23.3G 83 Linux /dev/sda2 48830462 117186889 68356428 32.6G f W95 Ext'd (LBA) /dev/sda3 * 117188608 169617407 52428800 25G a5 FreeBSD /dev/sda4 169617408 250068991 80451584 38.4G 83 Linux /dev/sda5 48830464 87889057 39058594 18.6G 83 Linux /dev/sda6 87891968 117186889 29294922 14G 83 Linux Partition table entries are not in disk order. Output of parted in case it helps. GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA M4-CT128M4SSD2 (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 25.0GB 25.0GB primary ext4 2 25.0GB 60.0GB 35.0GB extended lba 5 25.0GB 45.0GB 20.0GB logical ext4 6 45.0GB 60.0GB 15.0GB logical ext4 3 60.0GB 86.8GB 26.8GB primary boot 4 86.8GB 128GB 41.2GB primary ext4
Created attachment 1197520 [details] syslog from the installation Not sure which logs were required, so chose sys, anaconda, storage, and program (as it mentions the partition). I have others if desired. I'll make them as separate attachments.
Created attachment 1197521 [details] program log
Created attachment 1197522 [details] storage log
Created attachment 1197523 [details] Anaconda log
From the journal: 20:50:50,510 INFO kernel:[ 8.511192] sda: sda1 sda2 < sda5 sda6 > sda3 sda4 20:50:50,510 INFO kernel:[ 8.511192] sda3: <bsd:bad subpartition - ignored 20:50:50,510 INFO kernel:[ 8.511192] > From blkid: https://paste.fedoraproject.org/421501/29537041/ sda2 is extended, and sda3 is reported by blkid as ufs. But the logs seems to recognize there are Linux volumes; they get fsck'd and mounted. But then confusion, as they are not displayed?
That is accurate. It only displays the FreeBSD partition. As mentioned on the testing-list, blkid doesn't show sda2. The actual layout is sda1, sda2 as an extended partiton, whihc has 5 and 6, then sda3 and sda4, 3 holding FreeBSD on UFS and sda4 another (undisplayed) Linux partition.
I played around creating a VM (with VirtualBox) that had extended partitions. I'm wondering if the problem may have to do with the FreeBSD install. All machines that I've tried have a UFS partition. On a couple of other laptops at work, with more normal partitioning, F25 has detected the existing Linux partitions and consistently on 3 laptops that have a Free and/or OpenBSD installation, not detected existing partitions.
So far I can't reproduce with FreeBSD 10.3 which defaults to GPT partitioning, and Anaconda sees all of the partitions of the drive - so I can delete any of them. In your case, the drive uses MBR partitioning, with a mix of UFS and ext4 volumes, so I'm not sure how it got into this state in order to see what might be confusing the installer.
On the laptops with the issue, in each case, I first installed Linux, then FreeBSD on a UFS partition. (With an MBR scheme.) As it seems to not happen on any other laptops around here, it may just be an edge case, and not worthy of your time. In the next day or so, I have another laptop where I can do a few quick installs with and without a BSD partition, and I'll see what I get. Thanks for your effort on this. If it does turn out to be something only affecting people with an MBR scheme and a UFS partition, I apologize for taking your time and effort.
OK I have a partial reproducer, and looks related to bug 873155 closed as wontfix. While I get the "bsd:bad subpartition" message from the kernel, Anaconda shows all primary partitions in manual partitioning; I deleted a non-FreeBSD partition, and did an LVM based installation, and it boots fine. The source of the problem is when FreeBSD uses MBR partition scheme, it creates a BSD subpartition scheme on its primary partition. In that partition are FreeBSD-UFS and FreeBSD-swap subpartitions. But the kernel only enumerates one of those subpartitions. It's like it partly honors it rather than either completely ignoring or supporting it. So I can see how a different layout would cause a different result that'd end up with installer confusion.
(In reply to Scott Robbins from comment #9) > On the laptops with the issue, in each case, I first installed Linux, then > FreeBSD on a UFS partition. Gotcha, I did it in reverse. > Thanks for your effort on this. If it does turn out to be something only > affecting people with an MBR scheme and a UFS partition, I apologize for > taking your time and effort. It's an edge case but that doesn't necessarily mean it's not a legit bug. It might even be a beta blocker because the MBR itself is still a completely legit MBR. I question whether the kernel and liblkid handle this properly. It seems to me that they should either completely support or completely ignore the BSD subpartition; but they're sorta partially honoring it? And maybe that's why blivet then gets confused? We'll have to see what David says about what's going on.
From storage log: 'ID_PART_ENTRY_NUMBER': '2', 'ID_PART_ENTRY_TYPE': '0xf', This type is W95 Ext'd (LBA); Anaconda uses 0x5 for these. Curious, but either alone or with BSD 0xa5 subpartitions (and UFS fs present) I still can't reproduce this.
Well, I tried removing a BSD partition from another laptop, (all MBR though), and reinstalling on that partition with CentOS. After that, Anaconda couldn't see any partitions. :) If you're unable to reproduce it, I'm not sure how to go about troubleshooting further. I have found that it sees UFS formatted partitions, so, if the problem doesn't somehow fix itself between now and release, I'll just format the target partition in UFS before installing. If there's anything else you want from me on this though, please let me know.
I'm not sure I need to reproduce it; the program.log and storage.log shows blivet sees these partitions, they're just not being displayed to the user for some reason I'm not following. The gotcha that sorta makes it important to sort out is wiping these signatures is necessary to avoid even more confusion down the road. Note that your sda3 partition that shows up as UFS isn't really the UFS volume; sda3 is a BSD type of EBR and within that are at least two partitions, one of which is UFS. So at the moment I'm still fairly convinced there's more than one thing going on here.
Well, let me know if there is more I can do.
As F25 is released, I'll just mention a workaround in case someone else finds this bug. Assuming one wants to use /dev/sda1 and it is a Linux partition, boot into FreeBSD, (or use their installer, which includes a shell and run newfs /dev/ada0s1 (or whatever partition or partitions that you wish to use for installation.) Simply using Linux fdisk and changing the partition type to FreeBSD isn't enough, one has to newfs the partition.
Failing environments Intel 64 bit UEFI non-secure boot GPT standard ext4 partitions, Intel NUC 5i7-ryh all in one and an Intel skylake based workstation. No partition that contains an existing installation of Fedora 24 or 25 shows up so installation to a partition which is permitted with Fedora 23 and 24 is not allowed. Is there a way to execute the Fedora TryMe LiveCD installation process using X.Org rather than wayland? Also, might there be a significant difference in code execution between the TryMe followed by clicking the install icon versus just clicking install at the earliest opportunity?
I used a Gparted via SystemRescueCD (USB) to format a partition that contained a current Fedora 25 installation. After that, the installer allowed me to install to that partition.
For what it's worth, after F25 was released I tried clicking the install link from a live CD. I found the same issue, it did not see Fedora (or other Linux) partitions.
Because I often install when exhausted or under time pressure on systems where multiple linux OS's have been installed, I believe a case could be made to call this a feature rather than a bug. HOWEVER, this feature is missing an all important checkbox which would cause it to be temporarily disabled. Checking that box would allow a user to either install/reinstall into a partition containing an OS.
ernie_07 I don't think your bug is related to this bug. Yours might be https://bugzilla.redhat.com/show_bug.cgi?id=825236 if LVM is being used with the previously installed OS's that are not being added automatically to the GRUB menu.
Chris, ALL of my installed linux OS's that are not detected are UEFI GPT ext4 standard rather than LVM. The current state protects installed linux OS's from accidently being overwritten during a subsequence install which is great if the person activating the install is under pressure, exhausted or multi-tasking. I hope that modification resulting in this changed behavior between Fedora 24 and Fedora 25 was written in modular fashion so temporarily disabling it via a checkbox mechanism can be a straight forward task.
@ernie_07 This bug report related to MBR partitioned disks, not GPT. And the central problem has to do with a BSD subvariant that's causing confusion, as I mention in comment 10. You can't assume that your bug relates to this one just because the bug title makes it seem like it's related. I've done a bunch of Fedora 25 installations on a GPT partitioned disk with ext4 volumes created by Fedora 23 and 24 installations, and the Fedora 25 installer sees those partitions by default. So I have no idea why you're experiencing what you describe. I suggest filing a bug report, include screen shots, and the log files in /tmp/ while you're still booted in the installation environment so we can get some idea where the confusion is.
The change from Fedora 24 to Fedora 25 REQUIRES an entry in fstab that mounts an appropriate UEFI system partition or the related Fedora installation will be hidden. My environment is 64-bit Intel GPT standard ext4. This comment is being provided to illustrate a method for user control of which partitions may be used as targets for an installation.
To expand on Comment #24 above, a CentOS 7.3 GPT standard ext4 partition will also be hidden during a Fedora 25 installation if no valid entry exists in its fstab which mounts an appropriate UEFI system partition. Although this change protects a user from accidently overwriting an existing partition, the new behavior and how to disable it should be documented!
There's a chance this may be fixed. I just tried the latest nightly, and it saw partitions on one of the laptops that has given me this issue. This was with the server boot, https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170521.n.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-26-20170521.n.0.iso. I'll update as time goes on, but this is the first time in awhile where I didn't have to run FreeBSD's newfs on the partition I planned to use.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.