packages missing on new 4200

SteveITS

@wgstarks in eMMC storage a simple reboot should be fast. An update might easily take 10m.

stephenw10

Check the console output whilst rebooting. You may need to change the boot order so it tries the eMMC first.

Steve

wgstarks

@stephenw10
I don't have an easy way to connect to console. Is there some other way? SSH would be much easier. This box only has the base eMMC storage installed.
If I do need to connect to console what am I looking for?

stephenw10

It could be trying to PXE boot from connected NICs and waiting to timeout.

The only way to know for sure it watch at the console but you can check the boot order from the pfSense command line using: efibootmgr

wgstarks

@stephenw10
Here is the output (its all greek to me )

[23.09.1-RELEASE][admin@heimdall.dahoney.me]/root: efibootmgr
Boot to FW : false
BootCurrent: 0014
Timeout    : 3 seconds
BootOrder  : 0009, 0000, 000C, 000D, 000E, 000F, 0010, 0011, 0012, 0013, 0014, 000A
 Boot0009* Fedora
 Boot0000* Fedora
 Boot000C* UEFI: PXE IPv4 Intel(R) Ethernet Controller I226-V
 Boot000D* UEFI: PXE IPv6 Intel(R) Ethernet Controller I226-V
 Boot000E* UEFI: PXE IPv4 Intel(R) Ethernet Controller I226-V
 Boot000F* UEFI: PXE IPv6 Intel(R) Ethernet Controller I226-V
 Boot0010* UEFI: PXE IPv4 Intel(R) Ethernet Controller I226-V
 Boot0011* UEFI: PXE IPv6 Intel(R) Ethernet Controller I226-V
 Boot0012* UEFI: PXE IPv4 Intel(R) Ethernet Controller I226-V
 Boot0013* UEFI: PXE IPv6 Intel(R) Ethernet Controller I226-V
+Boot0014* UEFI: Generic Ultra HS-COMBO, Partition 1
 Boot000A* UEFI: Built-in EFI Shell

stephenw10

Yup OK it's probably waiting at boot for PXE to timeout making it seem like it takes an age to boot.

You can change the boot order from the command line there. For example running: efibootmgr -o 0014 will set it to only boot the eMMC.

However if there's some problem you may need to access the console to set it manually so I wouldn't recommend doing that until you have console access.

wgstarks

@stephenw10 said in packages missing on new 4200:

making it seem like it takes an age to boot

Thanks. I'll see if I can find a longer console cable than what came with the 4200. Or maybe a USB extender will be ok???

I put a stopwatch on the boot. 8 minutes 32 seconds. Hopefully this change will fix it.

stephenw10

Yup a USB extender should work.

If you're local to the device such that you can move a console cable to it if needed then I would just try setting the boot order from the CLI. I have done that a few times and it's always worked.

wgstarks

I’m going to make sure I know how to get a console connection first. Seems like it’s always a pain on a Mac and I don’t do it often enough to remember the process.

tgl

@wgstarks said in packages missing on new 4200:

I put a stopwatch on the boot. 8 minutes 32 seconds. Hopefully this change will fix it.

I was seeing 2m 15s from power applied to system ready with my new 4200. I disabled UEFI network stack in the BIOS settings, and that took it down to 2m even. The remaining big delays are

Starting DNS resolver: a tad under 15s
Bootstrapping clock: a full 30s

This is from watching console output with the system pretty fully configured but no WAN connection attached. I hope that those steps are slow just because they are timing out waiting for a WAN connection; if so, the total boot time in production should be a reasonable-ish 1m 20s or thereabouts. I'm considering disabling the local DNS resolver anyway, since I see no great need for it, but I don't know what "bootstrapping clock" is unless it's trying to run ntpdate. (The BIOS knows the time and date at poweron, so hardware clock seems to be working fine.)

stephenw10

It checks the system clock against a few things to allow for devices with no RTC clock battery: https://redmine.pfsense.org/issues/12769

tgl

@tgl said in packages missing on new 4200:

... I don't know what "bootstrapping clock" is unless it's trying to run ntpdate.

Digging in the rc scripts shows that it's doing this:

/usr/bin/timeout -k 45 30 /usr/local/sbin/ntpd -g -q -c /dev/null {$ntp_boot_time_servers}

I didn't research that ntpd call in detail, but I suppose it's morally equivalent to ntpdate, and would probably complete pretty quickly if it had connectivity to the mentioned servers. So that mystery is explained.