3

I installed debian 11 on dell 5505 SE and installed UFW. But when I start my pc it shows "a start job is running for Uncomplicated firewall (xxx min / nolimit)". And goes on.. I restarted and booted into debian recovery mode and uninstalled UFW, there is no boot issue How can I fix the UFW issue boot splash

4
  • Debian 11 has persistent systemd journals by default. Does journalctl _SYSTEMD_UNIT=ufw.service tell you of any errors UFW might have encountered while it was installed?
    – telcoM
    Aug 18, 2021 at 9:49
  • It did not show them on the console, that's true... but it might have logged them in the systemd journal, and the log messages might be still there even after you've removed UFW. So please run the command I suggested, and if the output includes anything that looks like an error message, please edit your question to add the error messages.
    – telcoM
    Aug 18, 2021 at 9:55
  • @telcoM I reinstalled the entire debian 11 and installed UFW again, same problems exist. I checked the journalctl ,but it shows no entries
    – HRC
    Aug 18, 2021 at 10:20
  • You could also install UFW but disable it (systemctl disable ufw). Then reboot (hopefully without delays). Then start UFW manually (systemctl start ufw) and see if the start completes in a reasonable time. If not, it might be an unexpected dependency with something else you have installed; if you can identify what it is, a bug report would be appreciated. Also, make sure your system can resolve internet hostnames; DNS resolution problems can often cause large delays.
    – telcoM
    Aug 18, 2021 at 11:24

6 Answers 6

5

People experiencing this problem can adjust /lib/systemd/system/ufw.service to have:

[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
#DefaultDependencies=no
#Before=network.target
Before=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

Then run:

$ sudo systemctl daemon-reload

then reboot. This change should be uploaded to Debian unstable soon. Assuming that goes ok, an update to bullseye can be pursued.

Note: I pasted the whole unit for people to be sure it is the way it should be, but this is the only part that changed:

#DefaultDependencies=no
#Before=network.target
Before=network-pre.target
Wants=network-pre.target

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834#32 has more discussion and describes the fix that is now in Debian unstable (0.36.1-3).

3
  • The 'quiet' option is unchanged from the existing unit. I pasted the whole unit for people to be sure it is the way it should be, but this is the only changed part: #DefaultDependencies=no #Before=network.target Before=network-pre.target Wants=network-pre.target bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 has more discussion and describes the fix that is now in Debian unstable (0.36.1-3).
    – jdstrand
    Nov 3, 2021 at 13:53
  • Ok, I adjusted the original post.
    – jdstrand
    Nov 3, 2021 at 13:59
  • Ok, I understand now. Thank you for the clarification!
    – AdminBee
    Nov 3, 2021 at 13:59
1

I had the same problem, with no possible fix.

In the end, I replaced ufw with "firewalld" and the problem disappeared.

1

Note, from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986493

ufw uses the iptables compat packages and does not use nftables. This line:

Starting firewall: ufw...
iptables-restore v1.8.7 (nf_tables):

simply means that the iptables-restore command is using the nf_tables backend.

0

There is a bug report on ufw about a missing dependency on nftables. It might be the reason why it fails: since systemd has not been told about the dependency, it might try to start ufw before nftables, which will probably fail.

There's also another bug report about setting the timeout limit for this service, in case it fails for any reason. Of course, if the ufw service fails to start up and the boot is allowed to proceed, the system will start up without a firewall configuration, which might be a security issue.

So, try adding the missing dependency first: run systemctl edit ufw.service and type in the following lines:

[Unit]
Requires=nftables.service
After=nftables.service

Since nftables.service is set to run before the network-pre.target by default and ufw.service definition includes Before=network.target, this should enforce the ordering as nftables.service -> ufw.service -> network.target, which seems like a sensible ordering. This might fix the root cause of the problem.

If this does not fix it, please submit a bug report of your own to let the package maintainers know about this issue. If this turn out to be a good fix for you, you might also want to comment on the above-mentioned bug report to give this issue a bit more visibility.

Since Debian 11 has a /lib/systemd/system/ufw.service file, editing the Required-Start: special comment line in the /etc/init.d/ufw script (as suggested in the bug report linked above) will have no effect unless you're running Debian 11 without systemd... and in that case, nftables has no corresponding SysVinit start-up script provided, so without further tinkering the dependency would be doomed to fail in the non-systemd case anyway.


If and only if you can accept the system starting up without a firewall in place, you might also add the following lines while running systemctl edit ufw.service:

[Service]
TimeoutStartSec=20
TimeoutStartFailureMode=kill
TimeoutStopSec=10

These will add a timeout to the ufw.service start and stop procedures. You can adjust the timeout values to suit your needs.

0

My system (bullseye 5.10.0-9) does this whenever I unplug my network cable. This did the same thing on my old install(buster upgraded to bullseye). Current install is very fresh with only qemu/libvirt/ffmpeg/vlc/basic kde stuff. Also, I always remove all my avahi and cups packages, except lib dependencies. And also removed kdeconnect.

The issue definitely has to do with some aspect of host resolution or network link (non) initialization.

There should be some logic added to background the start sequence, add a listener for when dhcp initializes, and then resume. Although this too could introduce a security risk between the time DHCP assigns ip address and ufw is initialized. Maybe if all packets were looped into lo and dropped until ufw could load the rules.

Seems like it could turn into a complex solution. Honestly I don't know much about the kernel, just my observations.

1
  • Welcome to the site. Your post looks like a comment rather than an attempt to propose a comprehensive solution. Please use the comment function below the original question for that purpose; the answer section is only meant for posts that contain a proposed solution.
    – AdminBee
    Nov 3, 2021 at 8:02
0

For those of you finding your machine unbootable due to this issue:

  • Reboot; choose the menu option at boot for "Recovery Console"

  • Recovery console will prompt you for the root password; enter it

You can now go about editing the ufw service file as suggested from a bash shell; for those who would like to edit it using tools they normally have when booting as usual, some additional steps:

  • enter "ufw disable"

  • temporarily disconnect the network cable or shutdown your wifi (there's no firewall active now; right?)

  • reboot; hopefully your machine boots OK now (including its desktop, if you are running one...)

  • edit the service file however you choose per the spot-on answer above

  • do a ufw enable; reconnect your cable or activate your wifi

  • reboot

If it is ufw but not the problem above, at least you will now be able to fix it more easily.

Now excuse me while I edit the ufw service files of all my debian 11 instances hosted at remote hosting providers! (before they get a reboot...) If your machine is at a remote hosting provider and presently unbootable (have the hosting staff confirm it's a ufw error as described above...), you will have to either get access to recovery console through a web service they provide, or give instructions to their staff to disable the firewall on boot.

If it's an Amazon EC2 instance and you didn't set up console access tools, you can detach the system disk from that instance and attach it as a slave to a new temporary install intended for such purposes (I call my instance for that "forensics"...) You can check boot logs on the system disk to confirm that the boot failure was due to this. After you edit the service file, you can reattach the drive to your original server and reboot it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .