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