I have rebased a patch Dennis Gilmore submitted in August,
https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000337...
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.
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)?
Thank you,
d.marlin
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...
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.
David Lehman wrote:
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...
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.
I have tested using these settings and they do work as expected.
Also, yes -- you should verify that autopart yields a bootable system.
If I just use autopart, what will make /boot/uboot the first partition? Do I need to set a flag in platform.py to ensure 'asprimary' is used? We also need to ensure that '/' (root) is the last partition, currently accomplished by adding '--asprimary' to swap. Will we need to add something to make that happen as well?
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.
We would prefer not to have a separate /boot partition on OMAP, so I'll look at the options you provided.
Thank you,
d.marlin ==========
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
On Mon, Sep 24, 2012 at 11:04:13PM -0500, David A. Marlin wrote:
diff --git a/pyanaconda/platform.py b/pyanaconda/platform.py index ea5b92f..a1e03b0 100644 --- a/pyanaconda/platform.py +++ b/pyanaconda/platform.py @@ -350,6 +350,32 @@ class ARM(Platform): self._armMachine = iutil.getARMMachine() return self._armMachine
+class omapARM(ARM):
- _boot_stage1_format_types = ["vfat"]
- _boot_stage1_device_types = ["partition"]
- _boot_stage1_mountpoints = ["/boot/uboot"]
- _boot_uboot_description = N_("U-Boot Partition")
- _boot_descriptions = {"partition": _boot_uboot_description}
- bootloader.GRUB2.stage2_bootable = False
I think this belongs inside a class __init__, we shouldn't be modifying things outside the class during the class setup.
+class omapARM(ARM):
- _boot_stage1_format_types = ["vfat"]
- _boot_stage1_device_types = ["partition"]
- _boot_stage1_mountpoints = ["/boot/uboot"]
- _boot_uboot_description = N_("U-Boot Partition")
- _boot_descriptions = {"partition": _boot_uboot_description}
- bootloader.GRUB2.stage2_bootable = False
I didn't notice this dirty trick until bcl pointed it out. Luckily you won't need it once you've done your uboot class.
David Lehman wrote:
+class omapARM(ARM):
- _boot_stage1_format_types = ["vfat"]
- _boot_stage1_device_types = ["partition"]
- _boot_stage1_mountpoints = ["/boot/uboot"]
- _boot_uboot_description = N_("U-Boot Partition")
- _boot_descriptions = {"partition": _boot_uboot_description}
- bootloader.GRUB2.stage2_bootable = False
I didn't notice this dirty trick until bcl pointed it out. Luckily you won't need it once you've done your uboot class.
Right, this was just to test that it would do what we need, before we actually had a U-Boot class to set it in.
For testing with autopart, I feel I'm digging myself into a bigger hole. I added the following to omapARM.weight:
elif mountpoint == "/": return -100
and I received the error:
Could not allocate requested partitions: not enough space for LVM requests.
I didn't really want LVM, so I thought I might override the '/' partition by adding to omapARM.setDefaultPartitioning:
ret.append(PartSpec(mountpoint="/", fstype="ext4", size=2000, maxSize=3000, weight=self.weight(mountpoint="/")))
to which I received:
Could not allocate requested partitions: not enough free space on disks.
Apparently, we are no longer getting enough space in the image:
2012-09-25 15:02:36,509: disk_size = 1GB
where before it was 3GB (as defined by the partitions in kickstart). I think livemedia-creator does this based on the kickstart definition. Is there any way to override the disk image size so autopart may work? Or is there a much better way to approach this? (maybe just define the partitions?) :-/
d.marlin
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
On Tue, Sep 25, 2012 at 03:33:56PM -0500, David Marlin wrote:
Apparently, we are no longer getting enough space in the image:
2012-09-25 15:02:36,509: disk_size = 1GB
where before it was 3GB (as defined by the partitions in kickstart). I think livemedia-creator does this based on the kickstart definition. Is there any way to override the disk image size so autopart may work? Or is there a much better way to approach this? (maybe just define the partitions?) :-/
LMC adds up the sizes of all the partitions in the kickstart, it sounds like something in your ks changed.
Brian C. Lane wrote:
On Tue, Sep 25, 2012 at 03:33:56PM -0500, David Marlin wrote:
Apparently, we are no longer getting enough space in the image:
2012-09-25 15:02:36,509: disk_size = 1GB
where before it was 3GB (as defined by the partitions in kickstart). I think livemedia-creator does this based on the kickstart definition. Is there any way to override the disk image size so autopart may work? Or is there a much better way to approach this? (maybe just define the partitions?) :-/
LMC adds up the sizes of all the partitions in the kickstart, it sounds like something in your ks changed.
Right. I was testing 'autopart', which does not specify any partitions (IIUC), so we're just getting a default.
Maybe autopart is not expected to work with livemedia-creator?
d.marlin ==========
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
On Tue, Sep 25, 2012 at 04:33:09PM -0500, David Marlin wrote:
Brian C. Lane wrote:
On Tue, Sep 25, 2012 at 03:33:56PM -0500, David Marlin wrote:
Apparently, we are no longer getting enough space in the image:
2012-09-25 15:02:36,509: disk_size = 1GB
where before it was 3GB (as defined by the partitions in kickstart). I think livemedia-creator does this based on the kickstart definition. Is there any way to override the disk image size so autopart may work? Or is there a much better way to approach this? (maybe just define the partitions?) :-/
LMC adds up the sizes of all the partitions in the kickstart, it sounds like something in your ks changed.
Right. I was testing 'autopart', which does not specify any partitions (IIUC), so we're just getting a default.
Maybe autopart is not expected to work with livemedia-creator?
Correct. Since it is installing to an image file it really needs to know what the size should be. I suppose I could add a default or a way to specify the size via the cmdline instead of ks.
Brian C. Lane wrote:
On Tue, Sep 25, 2012 at 04:33:09PM -0500, David Marlin wrote:
Brian C. Lane wrote:
On Tue, Sep 25, 2012 at 03:33:56PM -0500, David Marlin wrote:
Apparently, we are no longer getting enough space in the image:
2012-09-25 15:02:36,509: disk_size = 1GB
where before it was 3GB (as defined by the partitions in kickstart). I think livemedia-creator does this based on the kickstart definition. Is there any way to override the disk image size so autopart may work? Or is there a much better way to approach this? (maybe just define the partitions?) :-/
LMC adds up the sizes of all the partitions in the kickstart, it sounds like something in your ks changed.
Right. I was testing 'autopart', which does not specify any partitions (IIUC), so we're just getting a default.
Maybe autopart is not expected to work with livemedia-creator?
Correct. Since it is installing to an image file it really needs to know what the size should be. I suppose I could add a default or a way to specify the size via the cmdline instead of ks.
If this is the way it's expected to work, then it is ok for me. I have been specifying the partitions in the kickstart, but thought I should test autopart with my patch. If it works as expect, test successful. :-)
Thank you,
d.marlin ========
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
David Lehman wrote:
+class omapARM(ARM):
- _boot_stage1_format_types = ["vfat"]
- _boot_stage1_device_types = ["partition"]
- _boot_stage1_mountpoints = ["/boot/uboot"]
- _boot_uboot_description = N_("U-Boot Partition")
- _boot_descriptions = {"partition": _boot_uboot_description}
- bootloader.GRUB2.stage2_bootable = False
I didn't notice this dirty trick until bcl pointed it out. Luckily you won't need it once you've done your uboot class.
I've updated the patch based on comments and suggestions, and I'm resubmitting it for review (separate email). I have not yet implemented the uboot class, but have removed the bootloader "stage2_bootable = False" hack used for testing.
Please let me know if this version is acceptable.
Thank you,
d.marlin ========
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
anaconda-patches@lists.fedorahosted.org
-
Brian C. Lane -
d.marlin -
David Lehman