Unattended Reboot Failing

arrmo

Hi,

I have been seeing this in recent v2.4 builds, or at least I don't recall seeing it before. When I reboot (or install an update), the boot process does not proceed fully to completion without manual intervention. It starts to boot, but then "stalls" at,

alc0: link state changed to up
^@

Pressing Enter allows this to proceed, then stalls again at,

Enter the WAN Interface ... (longer message)

Are others seeing this also? I'm thinking it's related to network configurations / drivers - given where it is in the boot, and the fact that the network configuration is needing to be refreshed (it seems).

FYI, my 2 network drivers are alc and cdce.

Thanks!

Hugovsky

Seems like you might have a disc problem. What's your hardware?

arrmo

Which HW are you referring to - NIC's?

Everything runs fine … except for the pfSense boot process (in recent updates).

Thanks!

arrmo

OK, a bit more on this - rebooted, had the issue again, but watched very carefully as items scrolled by. A couple interesting points - I see the message,

Warning: Configuration references interfaces that do not exist: ue0

Then,

Network interface mismatch - Running interface assignment option.

BTW, a power cycle is OK sometimes, but never reboot. But overall, it seems like the boot process is not waiting long enough for my (USB) Ethernet interface to come up. Is there a way to make it wait?

Thanks!

Hugovsky

@arrmo:

Which HW are you referring to - NIC's?

Everything runs fine … except for the pfSense boot process (in recent updates).

Thanks!

ALL hardware. Are you using ZFS?

Gertjan

@arrmo:

…. my (USB) Ethernet interface to come up ....

:o (do you really HAVE to use a NIC like that ?)

chrcoluk

@arrmo:

OK, a bit more on this - rebooted, had the issue again, but watched very carefully as items scrolled by. A couple interesting points - I see the message,
Warning: Configuration references interfaces that do not exist: ue0
Then,
Network interface mismatch - Running interface assignment option.
BTW, a power cycle is OK sometimes, but never reboot. But overall, it seems like the boot process is not waiting long enough for my (USB) Ethernet interface to come up. Is there a way to make it wait?

Thanks!

ue0 is usb ethernet, a device generated e.g. having a tethered phone connected.

You need to make sure ue0 interfaces are disabled prior to reboots else you will get a config mismatch, or make sure the usb ethernet is up before the check during the boot, so e.g. on reboot quickly enable tethering again on phone.

arrmo

Hi,

To the questions / comments above,

yes, need to use this interface (USB) … it's running on a laptop, so only one internal GE NIC
to the comment,

You need to make sure ue0 interfaces are disabled prior to reboots else you will get a config mismatch, or make sure the usb ethernet is up before the check during the boot, so e.g. on reboot quickly enable tethering again on phone.

Yes, agreed! It's not a phone, it's a GE network connection, but that doesn't matter. But … how to disable / fast enable the USB interface? I admit, not a real FreeBSD expert (not even close actually ... ;)).

Thanks!

chrcoluk

A feature request I think might be needed as I had the same issue myself only posted about a week or so ago hence I knew the answer, it would be nice if one can tick a box to mark an interface as dynamic which ommits it from the boot check.

To answer your question login to pfsense gui, then goto interfaces menu, select assign.

Either

hit delete next to the interface with ue0 assigned. In my experience this does not delete rules or gateways using the interface, but it will disable them.
or assign a non ue0 device to the interface such as a proper ethernet or some dummy device, this may be hard for you since you only have one ethernet port which is assigned to something else.

Then readd the interface after reboot, in my experience the gateway gets auto reenabled when this is done.

arrmo

That makes sense, thanks! But I'll have to do this every reboot, right? As you say - seems like a handy feature to have, as doing this every reboot would be painful … not to mention, I have had a couple random reboots lately (crashes with the latest v2.4), and when remote I can't get in to fix it ... :(.

BTW, this didn't seem to happen before, I'm guessing something has changed to make this occur now.

Thanks again.

arrmo

I think I have a fix! Or at least it works for me … :P

I added this script as an earlyshellcmd => reset the USB NIC, wait a few seconds, and then make sure to bring the network up for that interface. I ran it, and no hiccups, machine came right up! Try it on your machine as well, see if it works?

Here it is (of course logger is not needed, I just like it captured so I can check later, when debugging ... and I called my script usbNetReset),

#!/bin/sh
logger "usbNetReset: Starting ..."
usbconfig -d ugen1.2 reset
sleep 5
ifconfig ue0 up
logger "usbNetReset: Complete"

Thanks for the pointers!

chrcoluk

thanks but that likely wont do anything for me, the reason I lose the ue0 interface is that when my phone detects a usb disconnection (which occurs on a reboot) it will auto disable tethering, the usb connection is reestablished right at post, but tethering is not auto enabled again, and needs to be enabled for the ue0 interface to be activated.

Once my vdsl is properly fixed by my isp (currently street cabinet running on batteries as has no power feed, so goes down twice a day when they swap out batteries) then my phone wont be connected to pfsense.

cozkramer

@chrcoluk:

thanks but that likely wont do anything for me, the reason I lose the ue0 interface is that when my phone detects a usb disconnection (which occurs on a reboot) it will auto disable tethering, the usb connection is reestablished right at post, but tethering is not auto enabled again, and needs to be enabled for the ue0 interface to be activated.

Once my vdsl is properly fixed by my isp (currently street cabinet running on batteries as has no power feed, so goes down twice a day when they swap out batteries) then my phone wont be connected to pfsense.

I don't use usb tethering, tho it's nice to know that it works on pfSense.

For your phone issue though, if your on Android, you may want to have a look at an app called Tasker and Secure Settings. I believe they'll let you automate your tethering based on any criteria you want.

chrcoluk

yep, I will consider that in future, finally my vdsl cabinet has power again so my phone is not connected to my unit now, so just back to 1 wan again.

TauCeti

I have been seeing this in recent v2.4 builds, or at least I don't recall seeing it before. When I reboot (or install an update), the boot process does not proceed fully to completion without manual intervention.

I just had exactly this happen to me yesterday. Although it is only the first time I've observed the issue. I was upgrading from: 2.4.0.b.20170718.1715 to 2.4.0.b.20170721.0023 on SG-1000 via the console.

The upgrade script claimed it was rebooting but it didn't.
I then initialised a reboot from the console.
SG-1000 did not come back up (it was left for four hours).
Power cycle and the unit came up with zero issues.

arrmo

OK, I take it back … my script only works sometimes, not consistently it seems ... :(.

It is frustrating - every reboot I have to go and unplug and re-plug the USB adapter, then press enter. Any suggestions are welcome!

Thanks.