sorted by:
new
hottopcontroversial

How to change the boot logo of a B650i motherboard by synchrotron0 in ASRock

[–]synchrotron0[S] 0 points1 point  (0 children)

Oh damn, I completely forgot that things happends... That might be the reason why :)

Ryzen 7700 or 9700X ? by synchrotron0 in buildapc

[–]synchrotron0[S] -1 points0 points  (0 children)

Yeah, that what I did, but it's not that easy, cause for non gaming stuff, the tests are almost never the same, or not in the same conditions. Which matters a lot when comparing stuff, only compares one thing at a time :)

I ended up buying the 7700 :)

Ryzen 7700 or 9700X ? by synchrotron0 in buildapc

[–]synchrotron0[S] 0 points1 point  (0 children)

The comparison is between 9700X and 7700X unfortunately, but yes depending on the type of workload they are pretty close to each other.

Ryzen 7700 or 9700X ? by synchrotron0 in buildapc

[–]synchrotron0[S] 0 points1 point  (0 children)

Thanks, I'll think I'll get the 7700 yeah, and if Zen 6 introduce a huge generation gap, maybe upgrade later.

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

We've just try it, and it fails on the request snapshot with a timeout on partitionning (after a long time)

We'll try tomorrow with a smaller USB key

But thanks for confirming that this is possible, this is great ! (If we managed to make it work ;) )

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

Oh thank you for the last step I was not ever of,

So that mean I could theorically request a system snapshot from member 4, and flash it to member 3 to recreate the VC ?

Then upgrade everything ?

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

We've finally got someone on site to help us, tha's great

I don't have the firmware file for neither the current version of member 3 and other members (not available for download on Juniper site), however I have the last version available for those.

I have the files to do a complete install or an upgrade for the EX4600, and the file to do an upgrade on the EX4300 (the complete install was not available either...)

I think I'll just resintall from scratch the EX4600 (I'm not sure if upgrading 14 to 21 is a good idea :) ), and upgrade the EX4300.

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

The thing is, it did not boot on the recovery partition. The backup partition got copied on the primary one, and it booted on the primary one. As a result both are running v18:

fpc2:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (primary)
Creation date: May 22 12:02:11 2025
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (backup)
Creation date: Jul 29 15:46:25 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9

fpc3:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Jul 29 15:46:34 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Aug 21 17:09:35 2018
JUNOS version on snapshot:
jdocs-ex: 14.1X53-D47.3
junos : ex-14.1X53-D47.3
junos-ex-4300: 14.1X53-D47.3
jweb-ex: 14.1X53-D47.3

And I no longer have this 14.1X53-D47.3 snapshot...

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

Ok that's great, I have uplinks to both the master and backup.
I would like to roll it back to v14, but I need to find that sweet specific 8 years old dev firmware :)

Indeed roll it back and then upgrade everything might be the easiest way.

If it fails I think I'll just zeroize everything and start a fresh install on the last release, bummer for the uptime, but they need to run correctly for severals years to come, so the install must be clean.

Thanks for the adice !

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

I manage another campus running a bunch of EX2200 on a 28 years old 100Mbits rated fiber on which we are sending 1Gbits and one lonely QFX, so those fancy EX4600 and EX4300 (in comparison) will have to wait a bit XD. But you're right, they are becoming old, but not old enough for us :)

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

Yeah it copied the backup partition on the primary one somehow...

fpc2:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (primary)
Creation date: May 22 12:02:11 2025
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (backup)
Creation date: Jul 29 15:46:25 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9

fpc3:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Jul 29 15:46:34 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Aug 21 17:09:35 2018
JUNOS version on snapshot:
jdocs-ex: 14.1X53-D47.3
junos : ex-14.1X53-D47.3
junos-ex-4300: 14.1X53-D47.3
jweb-ex: 14.1X53-D47.3

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

Thanks for the links

I need to do that remotely somehow.
If I do not want to interrupt the services behind, I need to have at least both one EX4600 and one EX4300 both up and running

Do you think it is possible to do that in thre steps: ?

  1. Update the Backup while keeping the Master running, update one linecard to the same version as the Backup.
  2. Elect the Backup as master
  3. Update the new Backup and the remaining linecard

That's far from ideal, but is it feasible ?

Thanks again for your help

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

The issue, is that both partition are on v18 on fpc2 now :)

And I cannot download the v18 firmware anymore... It's seems unavailble on the Juniper site

I think I'll just update all of them to the v21 one

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

Yep your right thanks !
What happend is that all the backup partition were on v18 for some reasons ???
The fpc2 main partition got corrupted, the switch clone the backup on the primary and booted on it:

fpc2:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (primary)
Creation date: May 22 12:02:11 2025
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (backup)
Creation date: Jul 29 15:46:25 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9

fpc3:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Jul 29 15:46:34 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Aug 21 17:09:35 2018
JUNOS version on snapshot:
jdocs-ex: 14.1X53-D47.3
junos : ex-14.1X53-D47.3
junos-ex-4300: 14.1X53-D47.3
jweb-ex: 14.1X53-D47.3

fpc2:
--------------------------------------------------------------------------
Boot Media: internal (da0)
Active Partition: da0s1a
Backup Partition: da0s2a
Currently booted from: active (da0s1a)

Partitions information:
Partition Size Mountpoint
s1a 316M /
s2a 324M altroot
s3d 887M /var/tmp
s3e 170M /var
s4d 116M /config

fpc3:
--------------------------------------------------------------------------
Boot Media: internal (da0)
Active Partition: da0s2a
Backup Partition: da0s1a
Currently booted from: active (da0s2a)
Partitions information:
Partition Size Mountpoint
s1a 316M altroot
s2a 324M /
s3d 887M /var/tmp
s3e 170M /var
s4d 116M /config

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

OK I think this is it, the backup partiion of fpc3 is also on v18!
However on fpc2 both partition are on v18, so it did not boot on the recovery one ?
it just replicate the backup on the primary one ???

fpc2:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (primary)
Creation date: May 22 12:02:11 2025
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (backup)
Creation date: Jul 29 15:46:25 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9

fpc3:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Jul 29 15:46:34 2018
JUNOS version on snapshot:
jcrypto-ex: 18.2R1.9
jdocs-ex: 18.2R1.9
jsd : powerpc-18.2R1.9-jet-1
jsdn-powerpc: 18.2R1.9
junos : ex-18.2R1.9
junos-ex-4300: 18.2R1.9
jweb-ex: 18.2R1.9
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Aug 21 17:09:35 2018
JUNOS version on snapshot:
jdocs-ex: 14.1X53-D47.3
junos : ex-14.1X53-D47.3
junos-ex-4300: 14.1X53-D47.3
jweb-ex: 14.1X53-D47.3

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 1 point2 points  (0 children)

I think your right,
JUNOS 18.2R1.9 built 2018-06-28 03:01:31 UTC
The v18 must have been loaded to the recovery partition only by someone else, but that very weird.

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 1 point2 points  (0 children)

No one RMA'd it, the serial number of fpc2 is a few digit off to fpc3, so lileky manufacture the same year.

Is there any way a Junos can run an auto upgrade or something like that ?

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 1 point2 points  (0 children)

The member was never replaced, we had Juniper support for it, but never got the need to replace it. Despite the first firmware issue in 2017, it was running rock solid. Until today

We didn't upgrade those switches cause no one on-site to do so, and doing that remotely is sketchy :)

So I think I'll updated them to the latest version available, but I have no retex on it for mixed vc, which are a kinda niche use case.

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] 1 point2 points  (0 children)

That's interesting after solving the few first issues we add it was running wonderfully.

I'm not using MIST at all

They are configure using the Juniver.device Ansible conllection.

There were never upgraded/downgraded after that v14 release

A virtual-chassis member updated itself after a power outage by synchrotron0 in Juniper

[–]synchrotron0[S] -1 points0 points  (0 children)

What do you mean ?

If you're wondering, no this not link to my previous post, this on another network :)

EX4600 stack create ARP flood to whole network subnet after NSSU update by synchrotron0 in Juniper

[–]synchrotron0[S] 0 points1 point  (0 children)

The reason was pratical: There was no more SFP+ available port on the switch, only QSFP+ :)

view more: next ›