New Netgate SG-1100 2.4.5-RELEASE-p1 Available Packages Empty

Jeremy11one

@rcoleman-netgate I just did another factory reset. Immediately after the setup wizard, pfSense checked for updates and did not find any. Here is the Update page:

rcoleman-netgate

@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.

Jeremy11one

@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?

rcoleman-netgate

@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.

stephenw10

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 like 216.239.35.0

Steve

Jeremy11one

@stephenw10 Yes, it can resolve and ping. And its date & time are correct.

stephenw10

Hmm, OK make sure it can resolve and ping ews.netgate.com

What 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 ms

Steve

Jeremy11one

@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.

Jeremy11one

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.

stephenw10

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

Jeremy11one

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)