I have tried this with the server net install and the server DVD.I haven't been following this list that closely, but a cursory look at archives doesn't show this problem.
On two laptops when I start to run the install, I choose let me configure partitioning. In both cases, I wanted to remove an old Linux installation (these laptops are mostly used for testing, so it might be Fedora on xfs, some Debian or Ubuntu variant, or Arch, most of those on extfs4.)
The only existing partitions it sees, however, are some UFS FreeBSD partitions. It doesn't see any of the existing Linux partitions.
It seems odd that I'd be the only one to run into this, so I'm wondering if there is some change I've overlooked. (Or, quite possibly, missed postings on this list about it.)
On Sat, 2016-09-03 at 14:21 -0400, Scott Robbins wrote:
I have tried this with the server net install and the server DVD.I haven't been following this list that closely, but a cursory look at archives doesn't show this problem.
On two laptops when I start to run the install, I choose let me configure partitioning. In both cases, I wanted to remove an old Linux installation (these laptops are mostly used for testing, so it might be Fedora on xfs, some Debian or Ubuntu variant, or Arch, most of those on extfs4.)
The only existing partitions it sees, however, are some UFS FreeBSD partitions. It doesn't see any of the existing Linux partitions.
It seems odd that I'd be the only one to run into this, so I'm wondering if there is some change I've overlooked. (Or, quite possibly, missed postings on this list about it.)
No, that's not usual, I've done many F25 installs to drives with existing partitions and they have been detected. (We also have several openQA tests that do this).
There may be something unusual about the layout of the disks in question which is causing anaconda/blivet trouble. The contents of /tmp/storage.log from an install attempt on the affected systems, and 'fdisk' or 'parted' output for the disks, would probably be useful. It might also be useful to know if earlier Fedoras detect the partitions correctly. Probably best to put all of that in a bug report. Thanks!
On Sat, Sep 03, 2016 at 12:55:04PM -0700, Adam Williamson wrote:
On Sat, 2016-09-03 at 14:21 -0400, Scott Robbins wrote:
On two laptops when I start to run the install, I choose let me configure partitioning. In both cases, I wanted to remove an old Linux installation (these laptops are mostly used for testing, so it might be Fedora on xfs, some Debian or Ubuntu variant, or Arch, most of those on extfs4.)
The only existing partitions it sees, however, are some UFS FreeBSD partitions. It doesn't see any of the existing Linux partitions.
There may be something unusual about the layout of the disks in question which is causing anaconda/blivet trouble. The contents of /tmp/storage.log from an install attempt on the affected systems, and 'fdisk' or 'parted' output for the disks, would probably be useful. It might also be useful to know if earlier Fedoras detect the partitions correctly. Probably best to put all of that in a bug report. Thanks!
I stop installation when it doesn't detect the partitions, but I can cetainly give fdisk and parted. I'll make the bug report. (I should add that due to various and sundry issues, I don't know how much help I can give anyone trying to debug, and yes, I realize how that makes it less likely that this gets fixed)
On 09/03/2016 01:14 PM, Scott Robbins wrote:
I stop installation when it doesn't detect the partitions, but I can cetainly give fdisk and parted. I'll make the bug report. (I should add that due to various and sundry issues, I don't know how much help I can give anyone trying to debug, and yes, I realize how that makes it less likely that this gets fixed)
Even though you don't finish the installation process, the important logs have already been created. You can either switch to the provided console or (my preference) add "inst.sshd" to the boot command line in which case you can ssh to the system you're trying to install to. Either way, the logs are in /tmp, so copy them to either a USB drive or another computer. At least one of them contains information on what the installer discovered about the disks and partitions.
On Sat, Sep 03, 2016 at 01:33:49PM -0700, Samuel Sieb wrote:
On 09/03/2016 01:14 PM, Scott Robbins wrote:
likely that this gets fixed)
Even though you don't finish the installation process, the important logs have already been created. You can either switch to the provided console or (my preference) add "inst.sshd" to the boot command line in which case you can ssh to the system you're trying to install to. Either way, the logs are in /tmp, so copy them to either a USB drive or another computer. At least one of them contains information on what the installer discovered about the disks and partitions.
Great, thank you. I will see if I have another chance tonight. The bug report has been created, I can add the logs by tomorrow. https://bugzilla.redhat.com/show_bug.cgi?id=1372919
It sounds to me like liblkid is confused somehow. If you could boot the install media, get to a shell and
blkid | fpaste
You'll get a URL, post that here.
Chris Murphy
On Sun, Sep 04, 2016 at 01:20:31AM +0000, Chris Murphy wrote:
It sounds to me like liblkid is confused somehow. If you could boot the install media, get to a shell and
blkid | fpaste
You'll get a URL, post that here.
Here it is. https://paste.fedoraproject.org/421501/29537041/
I may not be able to do any further updates till tomorrow afternoon.
On Sat, Sep 3, 2016 at 7:50 PM, Scott Robbins scottro@nyc.rr.com wrote:
On Sun, Sep 04, 2016 at 01:20:31AM +0000, Chris Murphy wrote:
It sounds to me like liblkid is confused somehow. If you could boot the install media, get to a shell and
blkid | fpaste
You'll get a URL, post that here.
Here it is. https://paste.fedoraproject.org/421501/29537041/
Does that seem to describe the layout for the intended target? The only semi-odd thing I see off hand is there's no sda2. I'll look at the storage.log in a bit.
-
Adam Williamson -
Chris Murphy -
Samuel Sieb -
Scott Robbins