Hi Colin, I thought the visual.d scripts present, *and manipulate* an in memory view of partitions, which are later checked by check.d, and then written to disk by commit.d. If it isn't visual.d, then what manipulates the partitions? The problem seems to be that ubiquity is running init.d -> visual.d ( which manipulates the in memory partition tables ), then runs init.d *again* and they aren't designed to be run a second time.
Hi Colin, I thought the visual.d scripts present, *and manipulate* an in memory view of partitions, which are later checked by check.d, and then written to disk by commit.d. If it isn't visual.d, then what manipulates the partitions? The problem seems to be that ubiquity is running init.d -> visual.d ( which manipulates the in memory partition tables ), then runs init.d *again* and they aren't designed to be run a second time.