anaconda-arm-uboot-partition.patch
David Marlin
dmarlin at redhat.com
Tue Sep 25 20:33:56 UTC 2012
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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
More information about the anaconda-patches
mailing list