Mmm, I don't think that is the same issue. Your device is rebooting but fails to find a boot device. That bug refers to a failure mode where it never tries to reboot after shuting down. Though it's clearly similar.

Booting to single user mode: pcib0: <Marvell Armada 3700 PCIe Bus Controller> mem 0xd0070000-0xd008ffff irq 5 on simplebus0 pcib0: link never came up pci0: <OFW PCI bus> on pcib0 pci0: domain=0, physical bus=0 pcib0: a37x0_pcie_check_pio_status: Posted PIO Response Status: CA, 0xe00 @ 0 pcib0: a37x0_pcie_check_pio_status: Posted PIO Response Status: CA, 0xe00 @ 0 pcib0: a37x0_pcie_check_pio_status: Posted PIO Response Status: CA, 0xe00 @ 0xc ofw_firmware0: <armada-3700-rwtm> compat marvell,armada-3700-rwtm-firmware (no driver attached) gpioled0: <GPIO LEDs> on ofwbus0 crypto: assign cryptosoft0 driver id 0, flags 0x6000000 armv8crypto0: <AES-CBC,AES-XTS,AES-GCM> crypto: assign armv8crypto0 driver id 1, flags 0xe000000 Device configuration finished. procfs registered Timecounters tick every 1.000 msec enc0: bpf attached lo0: bpf attached vlan: initialized, using hash tables with chaining mvneta0: link state changed to UP usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 IPsec: Initialized Security Association Processing. tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 ugen0.1: <Generic XHCI root HUB> at usbus0 uhub0 on usbus0 uhub0: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: <Marvell EHCI root HUB> at usbus1 uhub1 on usbus1 uhub1: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1 pflog0: bpf attached pfsync0: bpf attached spibus0: <OFW SPI bus> on spi0 mx25l0: <M25Pxx Flash Family> at cs 0 mode 0 on spibus0 mx25l0: device type mx25u3235f, size 4096K in 64 sectors of 64K, erase size 4K sdhci_xenon1: Powering up sd/mmc sdhci_xenon1-slot0: Divider 500 for freq 400000 (base 400000000) **mmc0: Probing bus GEOM: new disk flash/spi0 mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 1501004d384731474303f49149fc7000) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e404000) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC M8G1GC 0.3 SN F49149FC MFG 07/2013 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 4bit, 200MHz (HS200 timing) mmc0: memory: 15269888 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 52.000MHz (high speed timing) sdhci_xenon1-slot0: Divider 4 for freq 50000000 (base 400000000) mmc0: setting bus width to 4 bits high speed timing mmc0: Failed to set VCCQ for card at relative address 2 mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 8GB <MMCHC M8G1GC 0.3 SN F49149FC MFG 07/2013 by 21 0x0000> at mmc0 50.0MHz/4bit/65535-block uhub0: 2 ports with 2 removable, self powered mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 524kB partition 3 at mmcsd0** pci0: driver added CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 = <CRC32,SHA2,SHA1,AES+PMULL> Instruction Set Attributes 1 = <> Instruction Set Attributes 2 = <> Processor Features 0 = <GIC,AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32> Processor Features 1 = <> Processor Features 2 = <> Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,1TB PA> Memory Model Features 1 = <8bit VMID> Memory Model Features 2 = <32bit CCIDX,48bit VA> Memory Model Features 3 = <> Memory Model Features 4 = <> Debug Features 0 = <DoubleLock,2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8> Debug Features 1 = <> Auxiliary Features 0 = <> Trying to mount root from ufs:/dev/ufs/pfSense_Install [ro,noatime]... Auxiliary Features 1 = <> AArch32 Instruction Set Attributes 5 = <CRC32,SHA2,SHA1,AES+VMULL,SEVL> AArch32 Media and VFP Features 0 = <FPRound,FPSqrt,FPDivide,DP VFPv3+v4,SP VFPv3+v4,AdvSIMD> AArch32 Media and VFP Features 1 = <SIMDFMAC,FPHP DP Conv,SIMDHP SP Conv,SIMDSP,SIMDInt,SIMDLS,FPDNaN,FPFtZ> L1 cache: 32KB (instruction), 32KB (data) L2 cache: 256KB (unified) TCP_ratelimit: Is now initialized regulator: shutting down unused regulators regulator: shutting down vcc_sd1... ok GEOM: new disk mmcsd0 GEOM: new disk mmcsd0boot0 GEOM: new disk mmcsd0boot1 uhub1: 1 port with 1 removable, self powered e6000sw0port1: link state changed to DOWN e6000sw0port2: link state changed to DOWN e6000sw0port3: link state changed to UP Root mount waiting for: usbus0 ugen0.2: <SanDisk Cruzer Blade> at usbus0 umass0 on uhub0 umass0: <SanDisk Cruzer Blade, class 0/0, rev 2.00/1.26, addr 1> on usbus0 umass0:0:0: Attached to scbus0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: <SanDisk Cruzer Blade 1.26> Removable Direct Access SPC-3 SCSI device pass0: Serial Number 200443230002CF812081 pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: <SanDisk Cruzer Blade 1.26> Removable Direct Access SPC-3 SCSI device da0: Serial Number 200443230002CF812081 da0: 40.000MB/s transfers da0: 7633MB (15633408 512 byte sectors) da0: quirks=0x2<NO_6_BYTE> da0: Delete methods: <NONE(*),ZERO> GEOM: new disk da0 Warning: no time-of-day clock registered, system time will not be set accurately Dual Console: Video Primary, Serial Secondary start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: random: unblocking device. Which appears to show the MMC there, but I'm not sure what to do.

@froussy said in Netgate 7100 with SFP+ module: server room at 17 degree celcius? My room is about 23c and mine was getting in the high 80's. With the fan it is in the mid 60's. So for you, a solid maybe, watch the temps.

Yes. But not that device because it's SATA. The 4200 only supports NVMe drives.

I would reinstall 25.07 clean and restore the config into it if you have any doubt. As long as you have the config file and a recovery image on a memstick you will be able to recover so I would probably try upgrading first. The Device Tree Blob (DTB) is a file that ARM devices use to define the hardware present to the OS. The DTB file is present in the EFI System Partion (ESP). It's loaded into from there memory and passed to the OS by uboot.

@marcosm @stephenw10 Yes, I tried a power brick with a similar power rating as an initial troubleshooting step.

The uboot commands sound somehow familiar to me, but actually I cant remember if I needed to do so. I cant even remember which version of pfSense was the curretn at this time when adding the m.2 SATA, 21.x or 22.x? Regards

@stephenw10 OK.Thanks

@andrew_cb Thanks Andrew, yes cross-posted to reddit as well.

@mmkkoo https://docs.netgate.com/pfsense/en/latest/troubleshooting/disk-lifetime.html

Yup it's a display issue if the system creates a log entry with no host name: https://redmine.pfsense.org/issues/15411 You can just wait for the offending entry to move off the displayed logs.

@stephenw10 Yes, both ends are 1000 auto by default and I have tried fixing them to 1000 FDX fixed with no luck. Also - If I limit the client uplink to 100Mbps so the speed cannot really put heavy pressure on the 2100, the problem still arises. So it's most definitively an issue with the stability of the link or some buffer bursting as seen from the builtin 5 port switch side.

@stbellcom said in 6100 Failed eMMC replaced with NVme but now no longer reboots: so we went the next drastic step and that is remove the eMMC from the board. Got any pictures of this process, that show the location of the eMMC chip(s) or tips for someone who wants to try it?

I can confirm the Netgate 1100 runs very well with dual WAN, and failover takes but a moment. In my case FTTP (300/50) + LTE (30/10 typical but an upcoming provider swap may improve that). No issues with throughput or performance. Given your intended deployment I see you might end up with double- (or even triple-) NAT. This may cause you issues with throughput because of fragmentation/retries due to the squeezing of the MTU size with adding so many headers. Also, one lesson learned from having a radio-based element in the WAN setup - in my case LTE, but probably applies to Starlink, too* - dial-up the latency numbers on the gateway monitoring. Ping times may grow to over 2000ms under load so we don't want the gateway monitor to think it's down just 'cause it's busy! (the only Starlink I have access to is in a production environment. I don't think my colleagues would be happy if I 'borrowed' it just to test a hunch)

@ddbnj Solved it. I removed an interface still pointing to the SFP. New environments are error free now.

Nice.