Probably because ubifs gets removed by the updating script could that be it
I'm happy to test this. Do you want to test using bootargs instead of bootargs-append?
Whoops! Sorry, that was a typo! bootargs-append
Another one to try might be bootargs-append = " ubi.block=0,rootfs root=/dev/ubiblock0_1".
Essentially, I'm wondering if we're just trying to mount the incorrect partition within the UBI device. If the understanding that I've mustered from nothing in the last day or two is roughly right that sentence will at least make sense to someone who knows what they're talking about.
Figured as much 
Gave it a whirl, unfortunately not difference with this.
Will try the second and edit this.
You need Todo that reboot thing
I can never get it to work? And it's not really clear if I'm doing it correctly.
After 5 seconds just unplug and then plug back in, and if it doesn't boot it means it switched and if it boots suprise suprise it worked just capture a log
Welp, I have no clue. Fairly certain I'm doing it correctly, as I can get it to switch between the non booting state/booting state. But the logs all look the same?
The one I just sent previously, to this one.
And they show Kernel command line: init=/sbin/init rootfstype=squashfs ubi.mtd=24,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro ubi.block=0,1 root=/dev/ubiblock0_1 so I assume that testing bootargs-append = " ubi.block=0,1 root=/dev/ubiblock0_1 has "worked".
But I've been trying to flash a build with bootargs-append = " ubi.block=0,rootfs root=/dev/ubiblock0_1" and I've gotten nowhere. Tried various delays from 3-7 seconds before unplugging, to getting it to the non bootable state to getting it back, and no luck, the kernel command line is the same. 
1 Like
I'll try in a few hours probably
I see you updated the PR with the ubi.block=0,1 is that change working for you?
Testing it, was lazy Todo it from cli just did it from GitHub gui
1 Like
one annoying error being spammed
[ 1198.887356] hsl_phy_phydev_get[798]:ERROR:phy_addr 5 phydev is NULL
You got any clue on fixing that
panics on MTD 22
Is this a router that's possibly going to be supported in the near future? Is there anything people can do to help?
It's 95% ready, just need someone to figure out the sysupgrade issue and I'm sure @judahrand is working on it
1 Like
Wow that's great news. Thank you so much for your ongoing development
1 Like
Hi @SpectreDev, how did you manage to solve this if I may ask?
I’ve created an image based on IPQ5018 target for Linksys MX2000 but I’ve been unable to boot the kernel.
I’ve tried different load addresses already.
It’s stuck at:
Jumping to AARCH64 kernel via monitor
Stock boot log can be found here:
@robimarko can ya help with my issue
Not really, I just dont have any experience with whatever Linksys intended to do