anaconda-arm-uboot-partition.patch

David Lehman dlehman at redhat.com
Tue Sep 25 14:07:35 UTC 2012


On Mon, 2012-09-24 at 23:04 -0500, David A. Marlin wrote:
> I have rebased a patch Dennis Gilmore submitted in August,
> 
>    
> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000337.html
> 
> and made some minor modifications.  This is just a 'draft' at this 
> point, but I would appreciate any feedback on the approach (if 
> acceptable) and suggestions for improvement.  I understand that we will 
> need to subclass Bootloader to add U-Boot support, but wanted to see if 
> I was on the right track with the platform changes.

This looks pretty reasonable to me so far.

> 
> Also, I have been testing this using livemedia-creator in F17 
> (backported the changes).  The storage definition in the kickstart file is:
> 
>    bootloader --location=none
>    zerombr
>    clearpart --all
>    part /boot/uboot --size 200 --fstype vfat --asprimary --label=boot
>    part swap --size 500 --asprimary --label=swap
>    part / --size 2000 --fstype ext4 --label=rootfs
> 
> 
> This appears to do what we want for the OMAP disk image.  Should I be 
> doing anything else here to test the changes in platform (possibly using 
> autopart)?

Passing asprimary for /boot/uboot is almost certainly enough to make it
the first partition even without your other changes given that you
aren't creating a separate /boot. You should verify that it ends up
being the first partition without asprimary. Also, yes -- you should
verify that autopart yields a bootable system. I suspect you'll end up
with a /boot when you run autopart. If that's not desirable, you'll have
to remove that from the return value of Platform.setDefaultPartitioning
before returning from omapARM.setDefaultPartitioning.




More information about the anaconda-patches mailing list