packages missing on new 4200
-
@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? -
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
-
@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
-
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.
-
@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.
-
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.
-
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.
-
-
@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.)
-
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 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.