CCR1009 BootLoop Update 7.1.1 | No NetInstall

RouterOS Beginner Basics
1

SOLUTION IN #p901265

Hello,

I just wanted to update my devices to 7.1.1 from 7.1 but this put my CCR1009-7 and all hAP ac2 in a BootLoop.

The hAP ac2 took the image from NetInstall but the CCR1009 just appears with the message:
“PXE client: $MyMacAdress$”
And then nothing happens. When I use the secondary BootLoader it starts after four Messages back into the Loop.

This exact same config could talk to the hAP ac2 I tried.

v7.2.1 [stable] is released!
2

Just an update if anyone cares:

One hAP ac2 and the CCR1009-7 still are still paperweights.

I contacted the MikroTik Support and after a few completely unhelpful replies (obviously they didn’t bother reading anything I sent) I was told I could send it in for an RMA or to my dealer if it’s still in warranty.

Obviously it’s not in warranty anymore, otherwise I hadn’t contacted them.

I’m pretty sure MikroTik is still liable (this is all in the EU), otherwise a lot of companies would love to brick old gear…

—

I guess going from U******i to MikroTik wasn’t such a good idea.
Let’s see how I can replace the stuff…

—

I wish you all more luck in this and the next year.

3

After installing a native Windows10 machine I could recover the hAP ac² with the v6 NetInstall.exe.
The CCR1009-7 doesn’t show up.

CCR1009-7 Attempts:
Each with both Bootloaders

  • Using the v6 and v7 NetInstall Command on Manjaro:
sudo ./netinstall -a 192.168.88.3 routeros.npk

Using server IP: 192.168.88.2
Starting PXE server
Waiting for RouterBOARD...
PXE client: XX:XY:YY:YZ:ZZ:A1
PXE client: XX:XY:YY:YZ:ZZ:A1
PXE client: XX:XY:YY:YZ:ZZ:A1
... (and so on)
  • NetInstall64.exe Wine:
bootp recv bytes: 300 mac=XX:XY:YY:YZ:ZZ:A1
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
bootp recv bytes: 300 mac=XX:XY:YY:YZ:ZZ:A1
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
bootp recv bytes: 300 mac=XX:XY:YY:YZ:ZZ:A1
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
... (and so on)
  • NetInstall.exe 6.49.2 Wine:
bootp recv bytes: 300
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
FAILED TO REPLY
bootp recv bytes: 300
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
FAILED TO REPLY
bootp recv bytes: 300
client: XX:XY:YY:YZ:ZZ:A1
bootp req received
FAILED TO REPLY
... (and so on)
  • NetInstall.exe 6.49.2 Win10:
    Doesn’t list the CCR1009-7
  • NetInstall64.exe Win10:
    Doesn’t list the CCR1009-7

So the NetInstall.exe 6.49.2 seems work slightly more than the Rest.
FAILED TO REPLY went away under Win10 when I recovered the hAP ac²

4

Remind me not to upgrade my CCR1009 until I see in the FIXES

  • fixed CCR1009 bricked when upgrading to Ver7 from Ver6.

Or even better.
MT announces a free upgrade for CCR1009 users to CCR2004 or RB5009 due to bricking issue…

( I wonder if Latvia believes in the Three Wise Men bearing gifts such as free replacement)
(Yes, I know my future lies in writing fiction novels)

5

I’m not only unhappy because they seem not to care but it happened with a DotDot-Release in the Stable Channel, so I didn’t think anything about it and tried deploying it before Christmas…

6

Working Steps for the next Victim



Hints:

  • MikroTiks Documentation for NetInstall is confusing/not especially good.
  • MiktoTiks Download Page is not sorted like you might expect.
    Take a look at the General Section and the X86 Section.
  • In the Commands you need to set Parts that are in [Brackets] to your individual ones.

Tools:

  • Linux
    Manjaro in my Case.
  • Serial Connection to the Device
    tio in my Case.

Steps:

  • Download the right Firmware from the Mikrotik Site.
    I first went back to the newest stable v6.
  • Download “Netinstall (CLI Linux)” under X86 from the Mikrotik Site.
    Depending on your situation you might want the one from the v6 or v7 Section.
  • Get your Network-Interfaces ready for the NetInstall:
    Should require sudo.

netctl stop-all


  * ```text
ip link set [DEVICES] down

Only your Loopback should be left up.
All other Interfaces should be down. (Docker e.g.)

ip addr add dev [DEVICE to MikroTik] local 192.168.88.2/24


Setting the Device up for the IP Range.
  * ```text
ip link set [DEVICE to MikroTik] up

Activate the Interface.

  • For me “ip addr show” looks something like this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,> UP> > mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether [MAC-ADRESS] brd ff:ff:ff:ff:ff:ff
inet > 192.168.88.2/24 > scope global enp0s25

  • Start the CLI Tool with your downloaded Firmware File.
./netinstall -a 192.168.88.3 [ROUTEROS FILE].npk
  • Connect to the MikroTik Device via Serial.
  • For Example:
tio -b 115200 [/dev/tty123, SERIAL to MikroTik]
  • Power the MikroTik on and enter the BootLoader Menu over Serial.
    I had a 2s Delay to press any Key.
  • Reset the Settings.
  • Change the Network Boot Mode to BootP instead of DHCP.
  • Setup booting from Ethernet.
  • Reboot.
  • Now the CLI should be able to find it, send the Firmware and reboot the Device.

After starting “./netinstall -a 192.168.88.3 [routeros-mipsbe-6.49.2].npk” for example you get this:

Using server IP: 192.168.88.2
Starting PXE server
Waiting for RouterBOARD…

>
> When it's found it continues like this:
>
> ```text
PXE client: [MIKROTIK-MAC]
Sending image: [mips]
Discovered RouterBOARD...
Formatting...
Sending package [routeros-mipsbe-6.49.2].npk ...
Ready for reboot...
Sent reboot command
  • Back in the BootLoader Menu over Serial set the Boot back to your preferred way.
  • Now you should be back to a working Device.

If somebody needs more Details please just ask.

7

Glad that you solved the issue on your CCR1009

I upgraded my CCR1009 from RoS v 6.49.2 to v 7.1 without issue … I also upgraded from v7.1 to 7.1.1 without issue … then I upgraded from 7.1.1 to 7.2rc1 and I had an issue not with the upgrade process but my CPU went nuts on a normal load … so I then reverted back to 7.1.1 without issue and so far everything is working properly for me.

I suspect that the boards used in the CCR have some components that are slightly different in each factory build so its very possible that is causing the issue insofar as the bootloop is concerned … from my experience in the manufacturing life … sometimes the QA/QC processes miss the mark. Happens to everyone in the mfg line of work.

8

Damn and I was ready to go to the bank to get that postage for you in the right currency. ;-

9

Very funny Anav :laughing:
OT: :open_mouth:
BTW, TailScale and your Raspberry Pie provide a Techie method to manage your Tik Remotely using Winbox … and performance is NICE … however, no need for TailScale or ZeroTier because with WireGuard its as simple as eating Apple Pie … However from an ease of use for non technical people I prefer TS over ZT and most who dare to try it out will agree. :laughing:

10

One Pie at a time LOL.
I tried raspberry pie for DNS services and ripped it out quickly after the family almost lynched me.
I am trying the ZT pie at the moment, because its baked into the router.
I will try the TS pie, after and probably in the docker setup, so first I would have to master docker cooking.
So really the TS is pie in the sky at the moment. ;-PPP