Running Handler: common : Reboot if required due to security updates

Hello!

I keep running into this error when running the securedrop install for 1.8

Both the app and mon server return the following message during install playbook:

fatal: [mon]: FAILED! => {“changed”: false, “elaspsed”: 634. “msg”: Timed out waiting for last boot time check (timeout=600)", “rebooted”: true}
fatal: [app]: FAILED! => {“changed”: false, “elaspsed”: 642. “msg”: Timed out waiting for last boot time check (timeout=600)", “rebooted”: true}

When I check the app&mon server they return a kernel error and aren’t bootable anymore.

Has anyone run into this issue?

I get a warning message on the task before this for [grcsecurity: check if reboot is required due to inactive grsecurity lock.

The message says : flush_handlers task does not support when conditional
included: /home/amnesia/Persistent/securedrop/install_files/ansible-base/tasks/reboot.yml for app,mon

Thanks for any help!

Are you ok to share the hardware make/model that you’re using for the servers? SecureDrop uses a custom kernel with security patches applied, and it sounds like it’s not working with the hardware in question.

(If you’d rather not post that information on the forum but would still like to share, GPG-encrypted email to securedrop@freedom.press is another option.)

Thanks for the prompt reply!

I’m using the recommended: NUC8i5BEK with latest bios

I’ve just attempted to run through it twice and it fails both times at the reboot, this is the message I see on the reboot:

error: /vmlinuz-5.4.97-grsec-securedrop has invalid signature
error: you may need to load the kernel first

But at this point its corrupted and I can’t boot into either app or mon.

Ah, that sounds like you’ve still got “secure boot” enabled in the BIOS, @mil. Enter the BIOS setup on both of the NUCs, disable secure boot, and try again.

We’re very interested in eventually supporting secure boot—see somewhat related discussion about the Workstation, rather than servers, in https://github.com/freedomofpress/securedrop-workstation/issues/602—but at present our hands are tied.

Let us know if that doesn’t straight you out, @mil!

Ahh gotcha! Okay trying that will update once I go through, thanks again!

You’ll find mention of the secure boot setting here:

Again, let us know if you run into trouble! We’ll look into alerting about the secure boot setting early in the install process, to save subsequent Admins the headache.

Yep that resolved the issue, thanks!

Ya I completely missed that when I was going through the docs.