New Netgate SG-1100 2.4.5-RELEASE-p1 Available Packages Empty
-
@jeremy11one Previously you said that you aren't local to the device but now you've done a factory reset. Does that mean you're on site?
If so I recommend requesting the 22.01 image from TAC and reimaging the system.
-
@rcoleman-netgate No, I'm still remote. There is a laptop onsite that is connected to the neighbor's Wi-Fi and also plugged into our LAN via ethernet. So I can remote into the laptop through the neighbor's Wi-Fi connection, then access the firewall through its LAN port since it's plugged into our network. That lets me do Factory Resets and anything else through the pfSense box's LAN port.
If there's no way to fix it via the LAN port, I can ship a USB cable to them so I can re-image it that way, but shipping will take a few days.
What is causing this "Bad Request" error? Is there some SSH command to tell pfSense to download and install a new image from another source?
-
@jeremy11one The issue I see is it is looking at a package repo that isn't providing all the necc. information.
I am afraid that I am not knowledgable enough to walk you around that specific issue but that doesn't mean that there is no other option to get to 2.4.5_1 and then to 22.01.
-
If that 1100 able to ping out to anything now?
Does it show the correct time and date?
If it doesn't try entering a known ntp server directly like216.239.35.0Steve
-
-
Hmm, OK make sure it can resolve and ping
ews.netgate.comWhat you're seeing there looks exactly like the issue the custom update branch was created to workaround.
[21.05.2-RELEASE][admin@1100.stevew.lan]/root: ping -c 1 ews.netgate.com PING ews.netgate.com (208.123.73.93): 56 data bytes 64 bytes from 208.123.73.93: icmp_seq=0 ttl=50 time=109.961 ms --- ews.netgate.com ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 109.961/109.961/109.961/0.000 msSteve
-
@stephenw10 Somehow, pfSense stopped responding completely. I guess some config change I was trying somehow broke it. So this morning, we finally did the usbrecovery method, and MORE problems. The usbrecovery appears to have run successfully, but the firewall won't boot.
Here's the console output starting from the end of the usbrecovery:
Done! The system will halt now, please power off and remove the firmware recovery storage device. Shutdown NOW! shutdown: [pid 818] Waiting for system shutdown. *** FINAL System shutdown message from root@pfSense-aarch64-recovery *** System going down IMMEDIATELY Feb 7 17:14:13 pfSense-aarch64-Stopping cron. Waiting for PIDS: 709. Stopping devd. Waiting for PIDS: 483. Writing entropy file: . Writing early boot entropy file: . . Terminated Feb 7 17:14:23 pfSense-aarch64-recovery syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done All buffers synced. Uptime: 3m8s The operating system has halted. Power cycle or reset to reboot. TIM-1.0 WTMI-armada-17.10.5-34ce216 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.248V Fill memory before self refresh...done Now in Self-refresh Mode Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! Vref read training =================== Final vdac_value 0x0000001F Vref write training =================== Final vref_value 0x0000001F DLL TUNING ============== DLL 0xc0001050[21:16]: [3,35,1c] DLL 0xc0001050[29:24]: [7,27,17] DLL 0xc0001054[21:16]: [5,36,1d] DLL 0xc0001054[29:24]: [6,30,1b] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL1: Built : 16:19:41, Nov 1 2NOTICE: BL2: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL2: Built : 16:19:45, Nov 1 20NOTICE: BL31: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL31: U-Boot 2017.03-armada-17.10.2-g6a6581a-dirty (Nov 01 2018 - 16:04:57 -0300) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1200 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 750 [MHz] DRAM: 1 GiB U-Boot DT blob at : 000000003f716298 Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 41 ** Bad device mmc 0 ** Card did not respond to voltage select! mmc_init: -95, time 23 ** Bad device mmc 0 ** libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! ## Starting EFI application at 05000000 ... WARNING: Invalid device tree, expect boot to fail efi_load_pe: Invalid DOS Signature ## Application terminated, r = -2 reading efi/boot/bootaa64.efi 2097152 bytes read in 60 ms (33.3 MiB/s) reading armada-3720-sg1100.dtb 12725 bytes read in 11 ms (1.1 MiB/s) ## Starting EFI application at 05000000 ... Card did not respond to voltage select! mmc_init: -95, time 23 Scanning disk sdhci@d8000.blk... Found 4 disks Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0x5000000 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) Console: efi (0x1000) Load Path: bootefi Load Device: bootefi ERROR: cannot open /boot/lua/loader.lua: invalid argument. Type '?' for a list of commands, 'help' for more detailed help. -
In case this helps anyone else, NetGate support said my SG-1100 needs a firmware update to fix this new error:
From NetGate:
Your 1100 needs a UBoot firmware upgrade to get the ZFS component support. You will need to install to a UFS partition first, then run this command from the Diagnostics->Command Prompt (after connecting the 1100 to the internet): /usr/local/share/u-boot/1100/u-boot-update.sh -f And then you can reinstall with the ZFS partition. Some 1100s had a UBoot version running that we did not find during our exhaustive testing and the above process should cover the error at the end of your log file: ERROR: cannot open /boot/lua/loader.lua: invalid argument. -
Hmm, uboot should normally be updated automatically during the install.
We have seen some cases where it failed to recognise the old version and the above work-around can solve it in that situation.
Most users should never have to do that though.Steve
-
My SG-1100 is now fixed and running the latest OS and U-Boot firmware. Thanks for everyone's help.
before forcing update: U-Boot 2017.03-armada-17.10.2-g6a6581a-dirty (Nov 01 2018 - 16:04:57 -0300) /usr/local/share/u-boot/1100/u-boot-update.sh -f after forcing update: U-Boot 2018.03-devel-18.12.3-gc9aa92c-dirty (Oct 07 2021 - 18:20:55 -0300)
