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.

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.

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 withbothBootloaders

• Using the v6 and v7 NetInstall Command on Manjaro:
  Code:Select all

  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:
  Code:Select all

  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:
  Code:Select all

  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²

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)

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…

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 Sectionand 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.
• 串行连接的设备
  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)" underX86from 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.
  • Code:Select all

    netctl stop-all

  • Code:Select all

    ip link set [DEVICES] down

    Only your Loopback should be left up.
    All other Interfaces should be down. (Docker e.g.)
  • Code:Select all

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

    Setting the Device up for the IP Range.
  • Code:Select all

    ip link set [DEVICE to MikroTik] up

    Activate the Interface.
  • For me "ip addr show" looks something like this:

    1: lo: <环回,,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: UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether [MAC-ADRESS] brd ff:ff:ff:ff:ff:ff
    inet192.168.88.2/24scope global enp0s25

• Start the CLI Tool with your downloaded Firmware File.
  Code:Select all

  ./netinstall -a 192.168.88.3 [ROUTEROS FILE].npk

• Connect to the MikroTik Device via Serial.
  • For Example:
    Code:Select all

    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:

  Code:Select all

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

  When it's found it continues like this:

  Code:Select all

  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.

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.

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

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

Very funny Anav
OT:
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.

一个πe 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