So,
I'm playing with the thought of installing Rawhide (the frozen one; it's the time of year for me to start testing it again) and the quickest way seemed to download a nightly snapshot of desktop live, weep F11 partition (I dual boot with F12) and install on it. However, I have all the partitions, sans /boot, in a LV Group... And the live installer does not seem to be able to reuse it and since I want to wipe only two partitions out of the four in the lvg, I'm stuck.
In more detail -- I've chosen custom layout and the installer detected two partitions -- ext3 /boot and physical lvm partition, but not the volume group and volumes inside it :( Gnome tools see those partitions though and are able to mount them without issues...
So, I figured it would be best to ask here first whether this is expected (or if it might be issue on my side) and if not, I'll file a bug report.
Thanks, Martin
On 02/28/2010 03:41 PM, Martin Sourada wrote:
So,
I'm playing with the thought of installing Rawhide (the frozen one; it's the time of year for me to start testing it again) and the quickest way seemed to download a nightly snapshot of desktop live, weep F11 partition (I dual boot with F12) and install on it. However, I have all the partitions, sans /boot, in a LV Group... And the live installer does not seem to be able to reuse it and since I want to wipe only two partitions out of the four in the lvg, I'm stuck.
In more detail -- I've chosen custom layout and the installer detected two partitions -- ext3 /boot and physical lvm partition, but not the volume group and volumes inside it :( Gnome tools see those partitions though and are able to mount them without issues...
So, I figured it would be best to ask here first whether this is expected (or if it might be issue on my side) and if not, I'll file a bug report.
Thanks, Martin
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
On Sun, 2010-02-28 at 15:51 -0500, Clyde E. Kunkel wrote:
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
Indeed, there's 13.27 even though it's yesterday's snapshot... I'll try to update the anaconda and see if it helps.
Martin
On Sun, 2010-02-28 at 15:51 -0500, Clyde E. Kunkel wrote:
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
Indeed, there's 13.27 even though it's yesterday's snapshot... I'll try to update the anaconda and see if it helps.
Indeed,
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100227....
clearly indicates anaconda 13.27 was used:
Retrieving http://infrastructure.fedoraproject.org/pub/fedora/linux/development/13/x86_... ...OK
It would appear something is broken in the nightly build process, when anaconda 13.31 is already in the (updates-testing) repository with a date of February 24.
I should think the primary purpose of the nightly build is to incorporate the latest software, but we may learn more from the people directly involved with this process.
On Sun, 2010-02-28 at 19:34 -0500, Richard Ryniker wrote:
On Sun, 2010-02-28 at 15:51 -0500, Clyde E. Kunkel wrote:
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
Indeed, there's 13.27 even though it's yesterday's snapshot... I'll try to update the anaconda and see if it helps.
Indeed,
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100227....
clearly indicates anaconda 13.27 was used:
Retrieving http://infrastructure.fedoraproject.org/pub/fedora/linux/development/13/x86_... ...OK
It would appear something is broken in the nightly build process, when anaconda 13.31 is already in the (updates-testing) repository with a date of February 24.
I should think the primary purpose of the nightly build is to incorporate the latest software, but we may learn more from the people directly involved with this process.
Well, as I outlined in the previous mail, I tried updating it (on the Live DVD) to 13.32, but it didn't help. So I d/l-ed install DVD of Alpha RC4 and after some minor difficulties the install went fine (btw. it takes ages to install from install media, I already forgot how tedious the wait is, especially compared to install from Live Media).
Martin
On Mon, 2010-03-01 at 10:31 +0100, Martin Sourada wrote:
On Sun, 2010-02-28 at 19:34 -0500, Richard Ryniker wrote:
On Sun, 2010-02-28 at 15:51 -0500, Clyde E. Kunkel wrote:
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
Indeed, there's 13.27 even though it's yesterday's snapshot... I'll try to update the anaconda and see if it helps.
Indeed,
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100227....
clearly indicates anaconda 13.27 was used:
Retrieving http://infrastructure.fedoraproject.org/pub/fedora/linux/development/13/x86_... ...OK
It would appear something is broken in the nightly build process, when anaconda 13.31 is already in the (updates-testing) repository with a date of February 24.
I should think the primary purpose of the nightly build is to incorporate the latest software, but we may learn more from the people directly involved with this process.
Well, as I outlined in the previous mail, I tried updating it (on the Live DVD) to 13.32, but it didn't help. So I d/l-ed install DVD of Alpha RC4 and after some minor difficulties the install went fine (btw. it takes ages to install from install media, I already forgot how tedious the wait is, especially compared to install from Live Media).
I filed a bug related to *only* the live installer not recognizing previous logical volumes. I think this captures your experience.
https://bugzilla.redhat.com/show_bug.cgi?id=568460
Thanks, James
On Mon, 2010-03-01 at 07:37 -0500, James Laska wrote:
I filed a bug related to *only* the live installer not recognizing previous logical volumes. I think this captures your experience.
Yup, that's exactly it. I've added myself to CC.
Thanks, Martin
On Mon, 2010-03-01 at 13:55 +0100, Martin Sourada wrote:
On Mon, 2010-03-01 at 07:37 -0500, James Laska wrote:
I filed a bug related to *only* the live installer not recognizing previous logical volumes. I think this captures your experience.
Yup, that's exactly it. I've added myself to CC.
There is a one line fix in git if you'd like to test it out. I've tried the change linked below and it resolves the reported issue.
http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=0c496dc1069cb56ce...
Thanks, James
On Sun, 2010-02-28 at 19:34 -0500, Richard Ryniker wrote:
On Sun, 2010-02-28 at 15:51 -0500, Clyde E. Kunkel wrote:
Which version of anaconda is in the liveinst? I have seen this same behavior with the liveinst and the install DVDs, but, for the install DVDs the problem was fixed. Anaconda in F13 Alpha RC4 is 13.32 and it detects VGs and LVs.
Indeed, there's 13.27 even though it's yesterday's snapshot... I'll try to update the anaconda and see if it helps.
Indeed,
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100227....
clearly indicates anaconda 13.27 was used:
Retrieving http://infrastructure.fedoraproject.org/pub/fedora/linux/development/13/x86_... ...OK
It would appear something is broken in the nightly build process, when anaconda 13.31 is already in the (updates-testing) repository with a date of February 24.
I should think the primary purpose of the nightly build is to incorporate the latest software, but we may learn more from the people directly involved with this process.
There's nothing wrong with it exactly. The nightlies build from dist-f13, they do not use updates-testing. This is intentional. It's somewhat inconsistent given that updates-testing is enabled as a repository by default, but it's how it's been designed to work, so far.
The RC builds used some packages from updates-testing or Koji via a side repo Jesse set up for the purpose, once the RC rush calmed down a bit we got all those changes moved into dist-f13, though.
There's nothing wrong with it exactly. The nightlies build from dist-f13, they do not use updates-testing. This is intentional. It's somewhat inconsistent given that updates-testing is enabled as a repository by default, but it's how it's been designed to work, so far.
The RC builds used some packages from updates-testing or Koji via a side repo Jesse set up for the purpose, once the RC rush calmed down a bit we got all those changes moved into dist-f13, though.
Thank you, Adam, for the cogent explanation of a source of possible confusion. Is "got all those changes moved into dist-f13" the reason there was no nightly build yesterday (March 1)?
Should "critical path" be an issue for nightly builds? If a new version of a critical path package is available, should it be copied from updates-testing or Koji for nightly builds, while other packages wait until they graduate from testing? I do not argue it should, just thought to raise the question.
Moving forward, now that there is a version of F13 that (most) people can install, the exact composition of the nightly builds should be less important - one can install something, then update as desired. Still, your explanation of some nightly build details is valuable.
-Richard Ryniker
On Tue, 02 Mar 2010 15:56:14 -0500 Richard Ryniker ryniker@alum.mit.edu wrote:
Thank you, Adam, for the cogent explanation of a source of possible confusion. Is "got all those changes moved into dist-f13" the reason there was no nightly build yesterday (March 1)?
See my blog post today:
http://scrye.com/wordpress-mu/nirik/2010/03/02/fedora-nightly-live-composes/
It's due to anaconda haveing a broken dep.
Should "critical path" be an issue for nightly builds? If a new version of a critical path package is available, should it be copied from updates-testing or Koji for nightly builds, while other packages wait until they graduate from testing? I do not argue it should, just thought to raise the question.
I would say no. The reason they are forced to go to updates-testing is to be tested and get positive feedback before going into the base repo. If they cause issues it could break all the nightly composes. (Of course if it was enabled right now it could cause them to work).
In any case I think it's more important to test the bits that would be used to compose the final product than the bits that might be, but could be removed.
kevin
-
Adam Williamson -
Clyde E. Kunkel -
James Laska -
Kevin Fenzi -
Martin Sourada -
Richard Ryniker