I appear to have been hit by a change in the way anaconda & blivet initialization work. I could install just fine with the Fedora-20-Beta DVD but hit huge problems with Fedora-20-TC5 on real hardware.
The systems involved are real hardware and each have multiple installs into different partitions (a mixture of regular partitions, logical volumes and BTRFS subvolumes). Not all of these install can still boot. An example: 1. a system installed on lvm-root1 with /boot on /dev/sda6 2. later, a new ssd was added and /dev/sda6 was used for /boot with the rootfs on a subvol on the new ssd. 3. This left lvm-root1 still existing but with a UUID for /boot which no longer existed on ths hardware.
The result: anaconda/blivet barf all over the place with very strange errors. saying it cannot find a UUID. Of course not, it is gone. So what!
Not good, not good. If nothing else, this needs to be documented so other folks do not spend a lot of time chasing their tails.
Gene
On Dec 11, 2013, at 11:07 AM, Gene Czarcinski gczarcinski@gmail.com wrote:
I appear to have been hit by a change in the way anaconda & blivet initialization work. I could install just fine with the Fedora-20-Beta DVD but hit huge problems with Fedora-20-TC5 on real hardware.
The systems involved are real hardware and each have multiple installs into different partitions (a mixture of regular partitions, logical volumes and BTRFS subvolumes). Not all of these install can still boot. An example:
- a system installed on lvm-root1 with /boot on /dev/sda6
- later, a new ssd was added and /dev/sda6 was used for /boot with the rootfs on a subvol on the new ssd.
- This left lvm-root1 still existing but with a UUID for /boot which no longer existed on ths hardware.
The result: anaconda/blivet barf all over the place with very strange errors. saying it cannot find a UUID. Of course not, it is gone. So what!
Not good, not good. If nothing else, this needs to be documented so other folks do not spend a lot of time chasing their tails.
Needs a bug with at least program.log and storage.log attached, and anaconda-tb if there was a crash.
Chris Murphy
On 12/11/2013 01:39 PM, Chris Murphy wrote:
On Dec 11, 2013, at 11:07 AM, Gene Czarcinski gczarcinski@gmail.com wrote:
I appear to have been hit by a change in the way anaconda & blivet initialization work. I could install just fine with the Fedora-20-Beta DVD but hit huge problems with Fedora-20-TC5 on real hardware.
The systems involved are real hardware and each have multiple installs into different partitions (a mixture of regular partitions, logical volumes and BTRFS subvolumes). Not all of these install can still boot. An example:
- a system installed on lvm-root1 with /boot on /dev/sda6
- later, a new ssd was added and /dev/sda6 was used for /boot with the rootfs on a subvol on the new ssd.
- This left lvm-root1 still existing but with a UUID for /boot which no longer existed on ths hardware.
The result: anaconda/blivet barf all over the place with very strange errors. saying it cannot find a UUID. Of course not, it is gone. So what!
Not good, not good. If nothing else, this needs to be documented so other folks do not spend a lot of time chasing their tails.
Needs a bug with at least program.log and storage.log attached, and anaconda-tb if there was a crash.
The current bug report closed ... it was a special condition. I am created tests which will demonstrate the problem and create a new report. See BZ#1040148 final comments from me for more info.
Gene
On Wed, 2013-12-11 at 13:07 -0500, Gene Czarcinski wrote:
I appear to have been hit by a change in the way anaconda & blivet initialization work. I could install just fine with the Fedora-20-Beta DVD but hit huge problems with Fedora-20-TC5 on real hardware.
The systems involved are real hardware and each have multiple installs into different partitions (a mixture of regular partitions, logical volumes and BTRFS subvolumes). Not all of these install can still boot. An example: 1. a system installed on lvm-root1 with /boot on /dev/sda6 2. later, a new ssd was added and /dev/sda6 was used for /boot with the rootfs on a subvol on the new ssd. 3. This left lvm-root1 still existing but with a UUID for /boot which no longer existed on ths hardware.
The result: anaconda/blivet barf all over the place with very strange errors. saying it cannot find a UUID. Of course not, it is gone. So what!
Are you talking about crash, error message dialog, or log contents? Please clarify and provide the actual/exact messages.
David
Not good, not good. If nothing else, this needs to be documented so other folks do not spend a lot of time chasing their tails.
Gene
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 12/11/2013 01:45 PM, David Lehman wrote:
On Wed, 2013-12-11 at 13:07 -0500, Gene Czarcinski wrote:
I appear to have been hit by a change in the way anaconda & blivet initialization work. I could install just fine with the Fedora-20-Beta DVD but hit huge problems with Fedora-20-TC5 on real hardware.
The systems involved are real hardware and each have multiple installs into different partitions (a mixture of regular partitions, logical volumes and BTRFS subvolumes). Not all of these install can still boot. An example: 1. a system installed on lvm-root1 with /boot on /dev/sda6 2. later, a new ssd was added and /dev/sda6 was used for /boot with the rootfs on a subvol on the new ssd. 3. This left lvm-root1 still existing but with a UUID for /boot which no longer existed on ths hardware.
The result: anaconda/blivet barf all over the place with very strange errors. saying it cannot find a UUID. Of course not, it is gone. So what!
Are you talking about crash, error message dialog, or log contents? Please clarify and provide the actual/exact messages.
I am in the process of creating one (possibly two) test cases which will demonstrate what I believe is the problem cause by commit 29448424d5eb638ab1841b07a6a32d3cb085fa30
For now, I added a bit more info in RHBZ#1040148
Gene
David
Not good, not good. If nothing else, this needs to be documented so other folks do not spend a lot of time chasing their tails.
Gene
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.fedoraproject.org
-
Chris Murphy -
David Lehman -
Gene Czarcinski