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