Testing patches made to anaconda is relatively easy given the capability of using an updates image. However, when a change involves anaconda and python-blivet and/or (as in my case) pykickstart, it is more complicated because, to the best of my knowledge, you need to respin an ISO to do the test.
Now a bunch of years ago (ten to twelve to be exact) I did do some work requiring that I rebuild the anaconda boot and found it a faily easy thing to do. Time passes and anaconda code has changed. in addition, we now have pungi, lorax, etc. to help us build ISOs. Well, I have just spent the last three days beating my head against the wall.
First of all, pungi/lorax does not work well if it is working with anything other than the single rawhide repository -- e.g., it expects the syslinux package (and other packages too) to be in the first repository or it cannot find it and the build fails.
Most important for me is that pungi/lorax cannot build an ISO with a working BTRFS.
So ... help ... please!
Can someone tel me how to make pungi/lorax produce an ISO with a working BTRFS?
Or, can someone point me to the software you folks use to build an ISO when you want to test changes to anaconda/pykickstart/python-blivet/etc.? This may not be specifiic software but more of a process or procedure but the current pungi/lorax it is not.
Gene
On Thu, 2013-10-31 at 08:33 -0400, Gene Czarcinski wrote:
Testing patches made to anaconda is relatively easy given the capability of using an updates image. However, when a change involves anaconda and python-blivet and/or (as in my case) pykickstart, it is more complicated because, to the best of my knowledge, you need to respin an ISO to do the test.
As both pykickstart and blivet are pure-python packages, new version can be easily added to the updates image.
There are two possibilities: 1) if you have a RPM with newer pykickstart/blivet version, you can include it using the --add flag: makeupdates --add <path_to_the_rpm>/new_blivet.rpm
2) you can also just copy the the pykickstart/blivet git clone to the updates folder and it will be included in the updates image once it is next generated
example: * blivet Git clone is in ~/devel/blivet/blivet * Anaconda Git clone is in ~/devel/anaconda
cp -r ~/devel/blivet/blivet ~/devel/anaconda/updates/run/install/updates/
IMAGE_COMMIT=anaconda-20.21-1
cd ~/devel/anaconda scripts/makeupdates -k -t ${IMAGE_COMMIT}
The -k flag is important, because it makes makeupdates keep the updates folder around, so you can add additional stuff like pykickstart/blivet to it and it will be included.
Alternatively, you can also use the -f flag, that makes Anaconda automatically fetch from Koji any dependencies added since the $IMAGE_COMMIT corresponding to your compose:
scripts/makeupdates -k -t ${IMAGE_COMMIT} -f x86_64
Let me know if you have any issues with this - we use it all the time when working on changes spanning Anaconda-pykickstart-blivet
PS.: Could be that at least nr. 2 is not really documented anywhere ?
Best wishes Martin
On Thu, Oct 31, 2013 at 01:52:52PM +0100, Martin Kolman wrote:
As both pykickstart and blivet are pure-python packages, new version can be easily added to the updates image. There are two possibilities:
- if you have a RPM with newer pykickstart/blivet version, you can
include it using the --add flag: makeupdates --add <path_to_the_rpm>/new_blivet.rpm
I was trying this earlier (with the extlinux changes), and it wasn't working for pykickstart. Maybe I was doing something wrong (very possible) but it seemed like maybe the kickstart is parsed before the updates are applied?
On Thu, 2013-10-31 at 09:48 -0400, Matthew Miller wrote:
On Thu, Oct 31, 2013 at 01:52:52PM +0100, Martin Kolman wrote:
As both pykickstart and blivet are pure-python packages, new version can be easily added to the updates image. There are two possibilities:
- if you have a RPM with newer pykickstart/blivet version, you can
include it using the --add flag: makeupdates --add <path_to_the_rpm>/new_blivet.rpm
I was trying this earlier (with the extlinux changes), and it wasn't working for pykickstart. Maybe I was doing something wrong (very possible) but it seemed like maybe the kickstart is parsed before the updates are applied?
That could have been Dracut. IIRC Dracut is doing some kickstart parsing before Anaconda is even running - so I guess it has it's own separate version of pykickstart in the initrd. The pykickstart in the updates image only replaces the one used by Anaconda.
On Thu, Oct 31, 2013 at 03:04:26PM +0100, Martin Kolman wrote:
I was trying this earlier (with the extlinux changes), and it wasn't working for pykickstart. Maybe I was doing something wrong (very possible) but it seemed like maybe the kickstart is parsed before the updates are applied?
That could have been Dracut. IIRC Dracut is doing some kickstart parsing before Anaconda is even running - so I guess it has it's own separate version of pykickstart in the initrd. The pykickstart in the updates image only replaces the one used by Anaconda.
Yes, this jogged my pre-coffee memory. That was totally it. That pre-parsing was then rejecting the new kickstart directives as invalid.
That could have been Dracut. IIRC Dracut is doing some kickstart parsing before Anaconda is even running - so I guess it has it's own separate version of pykickstart in the initrd. The pykickstart in the updates image only replaces the one used by Anaconda.
Yeah, a few kickstart commands are processed at dracut-time too. See dracut/parse-kickstart.
- Chris
On Oct 31, 2013, at 7:48 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Oct 31, 2013 at 01:52:52PM +0100, Martin Kolman wrote:
As both pykickstart and blivet are pure-python packages, new version can be easily added to the updates image. There are two possibilities:
- if you have a RPM with newer pykickstart/blivet version, you can
include it using the --add flag: makeupdates --add <path_to_the_rpm>/new_blivet.rpm
I was trying this earlier (with the extlinux changes), and it wasn't working for pykickstart. Maybe I was doing something wrong (very possible) but it seemed like maybe the kickstart is parsed before the updates are applied?
Did this happen while booted from live media? The updates.img as kernel parameter is loaded quite early if netinst or DVD ISO, whereas it only starts being downloaded once anaconda is launched on live media. I have one possible experience where the updates.img wasn't taking when booted from live, but always worked from netinst or dvd.
Chris Murphy
On 10/31/2013 08:52 AM, Martin Kolman wrote:
On Thu, 2013-10-31 at 08:33 -0400, Gene Czarcinski wrote:
Testing patches made to anaconda is relatively easy given the capability of using an updates image. However, when a change involves anaconda and python-blivet and/or (as in my case) pykickstart, it is more complicated because, to the best of my knowledge, you need to respin an ISO to do the test.
As both pykickstart and blivet are pure-python packages, new version can be easily added to the updates image.
There are two possibilities:
- if you have a RPM with newer pykickstart/blivet version, you can
include it using the --add flag: makeupdates --add <path_to_the_rpm>/new_blivet.rpm
- you can also just copy the the pykickstart/blivet git clone to the
updates folder and it will be included in the updates image once it is next generated
example:
- blivet Git clone is in ~/devel/blivet/blivet
- Anaconda Git clone is in ~/devel/anaconda
cp -r ~/devel/blivet/blivet ~/devel/anaconda/updates/run/install/updates/
IMAGE_COMMIT=anaconda-20.21-1
cd ~/devel/anaconda scripts/makeupdates -k -t ${IMAGE_COMMIT}
The -k flag is important, because it makes makeupdates keep the updates folder around, so you can add additional stuff like pykickstart/blivet to it and it will be included.
Alternatively, you can also use the -f flag, that makes Anaconda automatically fetch from Koji any dependencies added since the $IMAGE_COMMIT corresponding to your compose:
scripts/makeupdates -k -t ${IMAGE_COMMIT} -f x86_64
Let me know if you have any issues with this - we use it all the time when working on changes spanning Anaconda-pykickstart-blivet
PS.: Could be that at least nr. 2 is not really documented anywhere ?
Best wishes Martin
I will give these a try. One other thought occurs to me ... Create two updates images.: one for anaconda and one for pykickstart. I belive that may work also ... or not.
Gene
On Thu, Oct 31, 2013 at 10:24:43AM -0400, Gene Czarcinski wrote:
I will give these a try. One other thought occurs to me ... Create two updates images.: one for anaconda and one for pykickstart. I belive that may work also ... or not.
No, you only get one updates.img, but like martin said, as long as you remember to run with -k it will keep any files copied into it. It can actually replace any file on the initrd's filesystem, including binaries so it should be able to meet your needs.
On 10/31/2013 11:38 AM, Brian C. Lane wrote:
On Thu, Oct 31, 2013 at 10:24:43AM -0400, Gene Czarcinski wrote:
I will give these a try. One other thought occurs to me ... Create two updates images.: one for anaconda and one for pykickstart. I belive that may work also ... or not.
No, you only get one updates.img, but like martin said, as long as you remember to run with -k it will keep any files copied into it. It can actually replace any file on the initrd's filesystem, including binaries so it should be able to meet your needs.
Well, I used ./scrips/makeupdates --add=pykickstart... and that created a good updates image
Unfortunately, it proved that my patch was not quite as good as I thought it was.
Gene
anaconda-devel@lists.fedoraproject.org
-
Brian C. Lane -
Chris Lumens -
Chris Murphy -
Gene Czarcinski -
Martin Kolman -
Matthew Miller