It is 2026, yet MikroTik is still using a 20-year-old DOS-era CHS partitioning format. Nowadays, 99% of storage devices are SSDs or NAND flash memory—who uses HDDs to run the OS anymore?
Does MikroTik not realize that lacking 4K alignment on SSDs causes a 50% reduction in read/write speeds and doubles flash wear? Furthermore, UEFI booting is still not supported by default.
I strongly recommend updating the disk partitioning scheme. Here is a recommended configuration that supports both BIOS and UEFI, remains compatible with 128MB NAND, and most importantly, ensures 4K alignment:
Now, X86 && CHR disk part
sfdisk -l /dev/loop0
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 * 34 65569 65536 32M 83 Linux
/dev/loop0p2 65570 258047 192478 94M 83 Linux
MikroTik's disk partitioning scheme is absolute dogshit! Lacks 4K Alignment.
34/8=4.25
65570/8=8196.25
Me, for example. You deserved the -1 (on subsequent post).
Just because YOU don't use them, do you assume everyone else foolishly does the same?
Ignoring devices that have NAND or XOR flash,
what do I care about using an SSD instead of a recycled disk?
I don't have to store files inside a x86 and/or CHR, so what do I care about speed or wear?
I've been using the same machines since 2007:
never a single HDD or SSD failure... and 19 years is a long time...
If you're a fan of alignment and other gaming crap... RouterOS is not a gaming peripheral...
(And by the way, the DOS era isn't "just" 20 years ago...)
I didn't give you one -1 either because the next comment to @znevna would require for you a forum ban.
Everyone has their own ideas and view, and in this case, if he didn't offend you, how dare you offend him?
While I don't really agree with the tone, OP has a point. Many people do use the CHR on various cloud/VPS platforms, and many of them have problems with booting the Mikrotik-provided image as-is.
When I read "I strongly recommend updating" followed by a wall of sfdisk commands and unhinged insults, the first thought is that you have to contact MikroTik directly, as we, mere mortal forum users, have no power to repartition RouterOS.
To invoke the ancient wisdom of our great leader BartoszP: dark days will come upon those who refuse to submit bug reports and feature requests via the official channels. MikroTik follows news on the forum more or less (!!!), but the only official way to get your SSDs aligned is to raise a ticket.
Coming in here with that attitude and AI-generated slop just proves you're begging for a troll topic.
Only for the record the 34 Is not in any way connected with DOS.
CHS is one of the two ways a partition Is addressed in MBR style disks.
The other Is LBA.
In practice CHS can only be used up to 1024x255x63 = 16450560 sectors, so with 512 bytes sectors after around 8 Gbytes It becomes "a suffusion of yellow".
DOS/Windows anyway respected the (real or virtual) number of sectors of the device, i.e. placing partitions on head boundary, mainly at sectors before 63, but also 32 or 16 depending on the geometry of the device.
No device ever existed with 34 sectors.
When LBA started becoming in use (circa 1997 or 1998) DOS/Windows continued using the head boundary for LBA too for several years, and only with Vista It shifted to Mbyte aligned.
In those years many (cannot say if most) Linux distros simply ignored these (artificial and arbitrary) conventions and allowed any number of sectors for partition alignment.
It Is from them that a "senseless" 34 may have come out.
While you say others may not dismiss your views just like that, the other way around is equally valid.
It might also help if you do not show the same behavior which you attribute to others as being a problem ?
I'm not sure the alignment matter as much as OP thinks, since RouterOS is not really disk bound. But OP is correct that the partition does limit UEFI support, since standard things like OVMF cannot deal with the ext2 partition.
RouterOS kernel is itself an EFI image‡... so it boots fine in UEFI. Further, RouterOS replaces BIOS services anyway once kernel boots. And in testing, booting UEFI (with my fat-chr repartitioned image) is about 25-35% faster. So that's where I agree with OP, since MikroTik should already just package one CHR image with FAT boot partition. I do have an ticket on it in SUP-144667, so MikroTik is aware of the request, although it been open 2 years.
‡ See https://github.com/tikoci/mikropkl/blob/main/Lab/x86-direct-kernel/NOTES.md which is part of the larger "Lab" notes in ./Lab in same mikropkl GH repo. Since the `fat-chr` is just the core repackaging, there is less research/testing in that repo, as `mikropkl` published it a UTM image (for Mac), as well as ZIP with the repackaged image along with `qemu.sh` to launch it on Linux.
The fat-chr UEFI image is available at by selecting "Apple" (which is historic naming, but is the UEFI FAT CHR repartitioned image):
Inside the downloaded ZIP, is a qemu.sh which can start the EUFI. Also in ZIP file from chr-images download page is a qemu.cfg which allows you adjust machine settings like RAM/CPU/etc. IDK OP use case, but the qemu.sh / tikoci/mikropkl Labs/**/*.md has more details than the fat-chr project on CHR and EUFI.
It on the "4K alignment", I just don't share is the "core issues". As others pointed out, RouterOS just is not disk intensive, and that "breaking upgrade" is always a risk MikroTik must protect against. So even if your 50% were right, it only on disk performance, and given the kernel/etc are loaded to RAM quickly likely nearly unmeasurable on any network-based operation (and given it's a router that kinda what's important).
And on CHR, it flows through some virtualization layer, so I'm not sure alignment even matter. The lack of FAT is why instructions like Vultr resort to using dd, and similar complexities on other VPS/"cloud providers" since EFI is kinda standard for a while.
Finally, if you are using a lot of disk operations... The solution is add another virtual disk partitioned however you like. And feature like /app container already requires a separate disk and cannot be homed on the boot partition anyway. And the whole "4K alignment" is solved with extra disk where you might care about disk performance (ROSE).
So you have me on EFI boot... so IMO that is the "core issue". EFI is demonstrably quicker to launch than BIOS on every QEMU platform I've tested. The "50% slower" you claim was proven how? Since even with "DOS" BIOS boot using QEMU SeaBIOS, even with emulation and lower power host, it still 30-40s to boot. And this path is well tested in quickchr (which does NOT use the EFI boot), e.g. Integration · tikoci/quickchr@5f0fac2 · GitHub.
But if you think the "core issue" if alignment is imporant, other than working OVMF support for EFI boot, you're off base.
Sure, but why would you be using the boot disk for ROSE? You can add an extra disk which will use a normal GPT (or MBR if you like) partition table, and the 4K alignment is fixed on those disks. The kernel operation all be done from RAM/paged that support ROSE, so the boot partition's alignment becomes meaningless after booted. And for extra disks that you might use in ROSE, those all would be aligned but format on them.
The only argument is on a pure/non-virtual X86, but even then you partition a SSD to avoid the alignment issue.
And once again the fact "DOS" BIOS has to go through all the device enumeration, that RouterOS is just going to toss out when kernel loads is the bigger cost in "boot time"... than any disk alignment issues on a 16MB disk.
Alignment is actually a thing, when we are talking of SSD's and similar, performance is better with aligned partitions[1].
On normal hard disks (the 512 bytes ones, not the new "native" 4kB ones) it is mostly a myth, born out of peculiar settings on Windows 2000 or 2003 (cannot remember) server.
[1] Though (only for the record) it depends on filesystems, NTFS is not a problem as it is inherently aligned (its boot sector is file $boot and starts at offset 0 in the partition/volume) and has by default cluster size of 4 Kb, as well ext2/3/4 should be fine, BUT what matters is filesystem alignnment, this is particularly noticeable with slowish devices (USB sticks or SD-Cards) with FAT32 (very common): https://rmprepusb.blogspot.com/2014/06/increase-speed-of-your-sd-card-or-flash.html
Original discussions on reboot .pro are lost in the mist of time, if interested something can still be recovered with the Wayback Machine.
A quick sumup:
There are three theories that are somehow interconnected in this thread (actually 4) !
With regards to the same "clearer English" three Regions in FAT32:
1– Reserved Region
2– FAT Region
3 – File and Directory Data Region
First theory, confirmed by n experiments, is that aligning Region #3 to a multiple of cluster size of the filesystem gives a speed improvement in read/write operation, this is INDEPENDENT from the kind of device and also applies to "conventional", rotating hard disks (though them being much faster than a USB device the difference is less noticeable).
Second theory by steve6375, and at the moment confirmed, is that on "solid state" devices this Region #3 should be aligned to a multiple of page size.
Third theory (actually an evolution of the second and also by by steve6375) is that to further better speed this Region #3 is aligned to a multiple of page size with offset of -1 cluster (as this will normally hold the drive Label and thus it is not accessed often). This improvement seems also confirmed though seemingly causing only a slighter improvement.
Fourth theory (by yours truly) is that maybe if BOTH Region #3 and Region #2 are aligned to BOTH a cluster multiple and to a page size multiple, then there might be another small improvement. At the moment this last theory has not been tested (and BTW also the previous two need further testing).
More saying if MikroTik did ever get around to support UEFI boot via some "stock" .img/.qcow2, I'd call it good without needing to realign the boot since it currently a delicate dance in how RouterOS is packaged/loaded. So if they changed the alignment, I suspect it be complex since RouterOS kernel makes certain assumptions on the layout... But RouterOS seemingly does not care if ext2 or fat as long it has same geometry, which is fat-chr (or any script to converted ext2->FAT) works. Basically IMO FAT-only is "simple" change, while re-aligning to 4K requires more invasive changes... thus later less likely to be implemented.
I stand by for nearly all functions of RouterOS merely EFI boot alone get you a 25%+ quicker time to login/"up". While I have not tested what effect "4K realignment" have on boot, the fact that if you were using heavy disk operations, you still like want that separated from the boot partition for a variety of reasons (e.g. recoverability), in which partitions could be aligned.
I don't think routerOS can have an issue at the time we checked the CHR image to fix it, the issue was not with the second (large) partition, it was only with the first one, and for THREE reasons, the first (that we corrected) was the filesystem (ext2FS instead of FAT) the second about the overlapping of the partitions (that we corrected) and the third the BIOS (BIOS only) bootloader that couldn't be moved because its structure has some addresses/offsets hardcoded (and I went through the remapping of the first partition to have a protected number of sectors for the BIOS booloader).
BUT I cannot see why it shouldnt' boot in UEFI (not in BIOS) with arbitrary alignment.