Alongside Option

[mmstick]

Based on the refresh-option PR, with the alongside option re-enabled.

In a VM with Windows installed:

Resizing Windows:

[brs17]

While I have yet to look at this specific pr, the following are notes from having looked at #157 yesterday:

• Extra space on the external drive being used to boot the live disk and install the operating system is suggested as a place to install the OS. Is this desired? I would think more often than not it is not.

[mmstick]

@brs17 I've been thinking about how to handle this. The live disk can also be the recovery partition, which does want to be able to install to itself. I think it just needs a check for the recovery.conf file, and hiding it if not found.

[brs17]

Another thing I noticed is the visibility of "Alongside OS" in the recovery partition. It doesn't seem to really make sense to have that as a visible option. So potentially you only need to look for recovery.conf to not show the functionality at all.

[mmstick]

New changes:

• Alongside OS will no longer appear in recovery mode
• Alongside OS options will no longer appear for partitions on the install device
• Erase options will no longer appear for partitions on the install device
• However, erase options will still appear if in recovery mode.

Requires distinst d1f3d9. Automated builds will fail until it is merged.

[mmstick]

Still looking into Windows 10 resizing issues. Resizing with GParted works, but resizing with distinst does not. I've been comparing what GParted and distinst are doing differently, and I am running out of ideas on the cause.

Things which distinst and gparted are doing the same:

• The Windows' OS partition starts with a mebibyte alignment, and shrinks also align to the nearest mebibyte.
  • IE: calc $(cat /sys/class/block/$partition/size) / 2 / 1024 returns a whole number, and not a decimal.
• Before resizing, the file system is checked for errors (ntfsresize -i -f -v $partition).
• The --no-action argument is supplied to the resize command to simulate the resize.
• If no errors are found, the partition is resized to the new partition size, with the sectors length in bytes (ntfsresize -f -f --size $bytes $partition).
• The partition is then recreated with the same sector count that was supplied to ntfsresize.
• ntfsresize apparently shrinks the file system to be 7 sectors shorter than the specified size.
• The start sector remains the same after the shrink, as expected, and therefore the UUID also remains the same.
• The partition has the msftdata partition flag after recreating it

As far as I can tell, distinst and gparted are doing the exact same actions, even in the way that the partition is recreated with an exact() Constraint.

Some notes:

I can verify that the boot sector (first sector of the NTFS partition) remains valid after the resize. The "Hidden Sectors" count is the same value before and after the resize, which is the first four bytes starting from 0x1C. This value identifies that start sector of the partition, and must be updated when the partition is moved.

ntfsresize also reports that the partition is fine, so there doesn't seem to be a partitioning problem. All of the files are accessible when mounting the partition in Linux or in the recovery mode. So, there must be some extra step in the gparted code that's not easily found by grepping for references to ntfs.

[cassidyjames]

You should be able to use the GTK-standard "dim-label" style constant here now.