installation of system-7.18.2 failed: disk is too small

Hi,

I have an hAP ax2 that i manually upgraded the flash to 1GB. All was fine, i applied all the updates in the last two years up to 7.18.0. Once 7.18.1 was released i notice i cannot upgrade to it, probably there is a bug in the free space calculation that is working with 128MB but not with 1024MB. I wait for a new version and today i saw 7.18.2 was released, but the problem is still there.

In the resource page i have these values:

Free HDD Space: 976.4 MiB
Total HDD Size: 1024.0 MiB
Bad Blocks: 0.1%

Log:

2025-03-18 22:46:03
memory
system
error
installation of system-7.18.2 failed: disk is too small

Not sure if in this case you used a bad chip, that had it’s size artificially increased but only works until XX megabytes, but more importantly SUCH MODIFICATIONS ARE NOT SUPPORTED AND WILL NOT WORK ANYWAY

netinstall to the rescue if all other methods fail.

But if you try to write files to flash so that you fill the space, does it work?

very good point !

I uploaded a video file that has 65MB, no issue. I think i performed between 20-30 updates after the flash chip replacement, i don’t believe the issue is the flash, but how the free space is calculated.
Screenshot from 2025-03-19 13-05-06.png
Screenshot from 2025-03-19 13-04-43.png
Screenshot from 2025-03-19 13-04-33.png
Screenshot from 2025-03-19 13-05-32.png

You could be right, but also, MT has no real incentive to help try to troubleshoot this issue on that particular model with the modification you did, since it would set a precedent for accepting responsibility for things way outside of their control…they can’t reasonably be expected support after-market modifications made to their hardware by their users.

For closed-ish systems like RouterBOARDS, where the manufacturer only ever intended for it to be used one way & treated as a sealed appliance, they can only be expected to comprehensively test and support the exact parameters within which they originally designed it to be used. There are often tight hardware/software dependencies under-the-hood that users have no idea about, either, like whether support for specific NAND or NOR chips has even been compiled into the stock kernel. So it could be a silly free space computation bug in the upgrade routine like you imply..or it could be something deeper than that, something that can’t be fixed by just quickly changing a single line of code.

If I were you, I would pursue this in one (or both) of two other ways:

  • Get your hands on a different model of MT hardware that comes stock with 1GiB of flash storage. They are rare but do exist. RB5009 is one (current) example. CCR1036 is another (although discontinued). If you can reproduce the same bug on that hardware, then you have proof it is a more generic issue with doing ROS upgrades on large flash storage, and then perhaps they’ll actually look into it.
  • I would try to do a Netinstall anyway. This will force a re-format of the flash storage, which is inconvenient since you will have to re-copy all of your data back onto it afterward. But reformatting it might fix some subtle issue with the existing formatting that may be confusing the upgrade procedure when it goes to check for free space. If, for example, when you installed the new chip, you simply cloned the contents of the old bit-for-bit onto the new one without doing a Netinstall the first time, then I’m not surprised parts of the system are confused about free space.

If you did do a Netinstall the first time, it’s still worth a try giving it a shot anyway…a reformat and reinstall can often cure bizarre issues. And even if it doesn’t help avoid the problem with future ROS upgrades (you might find that, with your hardware mod, a Netinstall is going to be required each time you want to update ROS), it might at least allow you to get around the error this one time.

Hi,

I totally agree, i decided to cancel my warranty when i performed the flash upgrade, but if in the code was introduced a new condition that instead to check the real free space (like resource page is doing) vs the required space for update installation, then there is a bug, even if it don’t affect the production models. If i perform netinstall and it is working i think if the bug remain there i will not be able to perform any GUI update.

Hello,

there was some issue around that version where the kernel partition was too small (i don’t know - sometimes?), and some sort of repartitioning took place automatically. There may be some hardcoded values there. Anyhow, I’m willing to bet you a flash chip (ha-ha) that after a netinstall it will work.

I also understand Mikrotik - they are supporting the device only as sold…

Thanks for the advices. I did a netinstall to 7.18.2. Now i will wait for the next release to test this.

Probably free space more than 134217727 bit cause variable overflow.

On your spare time, can you try again the passage from 7.18 to 7.18.[1|2] leaving on purpose free space less of 134217727???

On that devices are expected only 128MiB…

Just for fun and curiosity…