Page MenuHomeSolus

Solus Installer does not align partitions to 4KiB boundaries for best practices
Closed, ResolvedPublic


I was just playing around with Solus in a VM to see how it defaulted it partition setup (using the Plasma Testing ISO). What I noticed is that the installer doesn't follow modern best practices, and it will result in a partition layout that will hurt SSD performance and lifetimes. SSD partitions and modern 4K HDD should always have their sectors 4KiB aligned.

GParted, KDE Partition Manager, and Windows utilities default to aligning partitions to 2048 sectors (512 B/sec = 1 MiB boundaries). 1 MiB alignment will always be 4KiB aligned as well as for any potential issues with flash erase block sizes (which are higher than 4K).

I did an install from UEFI with ext4, and let it pick swap space, it resulted in this EFI partition

PartitionStart SectorEnd SectorSizeSize (MiB)4KiB Aligned1 MiB Aligned

The EFI partition is 4KiB aligned, but it doesn't match the default used for other programs. For some reason, the installer is leaving a 32 sector gap between the partitions, which then leaves all subsequent partitions misaligned. It would probably be better to just align all partitions to the 2048 sector/1MiB boundary.

Related Objects

Event Timeline

jon.grossart renamed this task from Solus Installer does not align partitions to best practices boundaries to Solus Installer does not align partitions to 4KiB boundaries for best practices.Dec 5 2018, 2:18 AM
jon.grossart edited projects, added Installation; removed Lacks Project.
jon.grossart added a comment.EditedDec 5 2018, 7:08 AM

I just checked what happens if you have the installer resize a windows partition, and it does the same behavior. It leaves 32 sectors between the partitions, which causes the alignment to be off.

I don't know python at all or what that code would fix, but it seems like that installer is still trying to calculate stuff off the older geometry idea which isn't used for modern storage devices anymore.

I should also note if wasn't clear, this was tested with UEFI. I didn't test with MBR booting.

Edit: I just tested with MBR and the results are worse. It defaults to just a swap partition that started at sector 93 and then had the same 32 sector spacing between partitions. This would mean that no partition is 4k aligned.

Lorien added a subscriber: Lorien.Dec 5 2018, 10:26 AM

I was making a note for myself on how to fix it. You don't need to do anything :)

JoshStrobl triaged this task as High priority.Dec 6 2018, 2:45 AM
JoshStrobl moved this task from Backlog to Bugs / Unexpected Behaviors on the Installation board.
crom5 added a subscriber: crom5.Dec 6 2018, 2:36 PM

Asus and Lenovo SSD equipped laptops here. Important question: whatever fix arrives, will it require a new Solus installation or not? Thanks...

You can always fix partition errors yourself by moving partitions around (assuming the filesystems contained in them support it). But that's also going to copy everything in the partition around.

If you manually did the partitioning, you can set it up to avoid this as well if you're careful. I didn't test what alignment that provides. Or make sure you use a tool like fdisk/gdisk/GParted/KDE Partition Manager and will do the alignment for you.

Bugs like this might be a good reason to look at something like Calamares for the next version of the installer rather than maintaining all this logic in-house.

We have zero interest in using someone else's installer. Ours is overdue for an overhaul, but I have higher priority projects in my queue.

axaxs added a subscriber: axaxs.EditedJul 24 2019, 1:16 AM


I was intending to email the team, but didn't find a place to do so. By way of very brief introduction, I was on the Antergos team early on and wrote the advanced partitioner, as well as porting pyparted to python3. Not that this makes me an expert by any means, just offering to help where I can as I quite like this distro. I want to say you've done very nice work on this distro and the installer. My time is limited these days, but I'd like to offer my support/knowledge/code how I can.

This issue was bothering me so I fixed it locally. I tested with both lvm/luks and without, fresh installs. The patch was two parts, one part to align to 2048 boundaries on offsets, the other to expand partitions to fill those offsets - and, respectively. I have yet to test more exotic or existing setups, so the patch may need tuning.

Here is an fdisk of a fresh LUKS install with the patch. I didn't capture the output sans LUKS, but it aligned as well, as verified with parted align-check optimal.

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1003519 1001472 489M EFI System
/dev/nvme0n1p2 1003520 1000213262 999209743 476.5G Linux LVM

In any event, feel free to email me to say hi, or drop me your email. I was thinking of playing with eopkg at some point also, it's a bit slow.

All that out of the way, where/how may I submit the aforementioned PR?


ermo added a subscriber: ermo.EditedJul 24 2019, 10:45 AM


All that out of the way, where/how may I submit the aforementioned PR?

Maybe try ?

In terms of eopkg, it's being deprecated -- see to get an idea of the plan going forward.

Thank you Ermo.

In that case, I will not proceed to work with eopkg for the time being.

g66925 added a subscriber: g66925.Sep 28 2019, 4:21 PM

On clean or new disk, a way to align properly is to install on manually prepared partitions - root /, swap. Tested with MBR and GPT. This trick doesn't work if one want enable LUKS encryption.

crom5 added a comment.Sep 28 2019, 4:44 PM

I hope this long-standing problem will be fixed before the releasing of new Solus ISO

Is this a sure way to check for correct alignment? :
parted /dev/sda align-check opt 1
parted /dev/nvme0n1p1 align-check opt 1
parted /dev/nvme0n1p2 align-check opt 1
parted /dev/nvme0n1p3 align-check opt 1
parted /dev/nvme0n1p4 align-check opt 1

The output is:
1 aligned
1 aligned
1 aligned
1 aligned
1 aligned

Like the solution g66925 posted, i made a manual partitioning of root, swap & home.

axaxs added a comment.Oct 16 2019, 2:42 PM

I just wanted to remind that I submitted a PR against for this issue in July, for your review/testing.

livingsilver94 added a comment.EditedOct 16 2019, 4:40 PM

This issue has been hitting Solus for a lot of time and it weakens newcomers' will to try the distro. It's OK if Core Team doesn't have the time to fix the issue, but what's exactly the blocker when a user kindly provided a PR?

@livingsilver94, we aren't in testing mode for a new ISO, so patching the installer isn't a high priority right now.

@tuxayo we know.

crom5 added a comment.EditedDec 7 2019, 1:11 PM

@DataDrake wrote on 18.11.2019: "we aren't in testing mode for a new ISO, so patching the installer isn't a high priority right now".

06.12.2019: Josh Strobl: "we're well aware that our ISOs are a bit long in the tooth and could use a refresh. There's some AMD related fixes (for new hardware) in the Mesa 19.3 development series that we're wanting to wait for (otherwise we'd be shipping a new ISO with only half-working support for newer AMD hardware, largely that support coming from the kernel and LLVM 9). Once Mesa 19.3 stable is released and validated by our community we'll be putting out a new ISO."

According to newest available information, most probably Mesa 19.3 is coming in the next few days - quite soon after that, we will receive Mesa 19.3 stable release.
So let's hope :)

DataDrake closed this task as Resolved.Feb 5 2020, 6:25 AM
DataDrake claimed this task.