I'm writing an Upstart task which runs at runlevel 1.

This is for an ecrypted system, and the task's job is to verify the integrity of the MBR & /boot. As such, it is important that this task runs as early as possible during system boot (so I've chosen runlevel 1).

99% of the time this task will just exit silently, but if it detects any problem, it needs a way of letting the user know, and ideally pausing the system boot until the user confirms.

I've tried the following as a test, but I cannot interrupt the system boot. Any suggestions?

start on runlevel [1] exec echo -n "Warning: MBR and/or /boot changed. Press any key to continue." exec read console output

Thanks in advance!

  • Also I've tried using the "task" option – vonbraun May 14 '11 at 12:04
  • You could edit all the runlevel 2 stuff to have it as a dependency. – RobotHumans May 14 '11 at 12:51
  • Hi, thanks for replying. My only concern is that editing all those files could be a bit error prone... is there any key task I can edit which everything else depends on? – vonbraun May 14 '11 at 13:24

vonbraun, runlevels mean something very different than they used to, so I don't believe runlevel 1 is actually where you want to be.

Sine you want to run ASAP, there are two options.

If you can work without writing to the root filesystem, and your data is guaranteed to be on the root filesystem, you can use the mounting event.

start on mounting MOUNTPOINT=/

The mounting event is a "hook", so mountall will wait for anything that uses it to unblock. You definitely must use the 'task' keyword so that your checks can run fully before mountall is unblocked.

At this point in the boot, the root filesystem is still readonly, but should be available. Other filesystems may not be available, so be aware (/var/run, in particular, can be tricky in this way). Do not use "AND" with another mounting event as that will lock up boot.

If you need to write to the root FS, you can use

start on mounted MOUNTPOINT=/

This will block mountall again, but after / is remounted read-write. This should prevent the resulting signals that kick off other parts of the boot from happening.

There are no guarantees here though, some other things will be going on in parallel. However, most of the boot will be delayed waiting for access to the filesystem, and in the stated scenario, that seems like the desired result.

Note that there are a lot of good related ideas in the Upstart cookbook


Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.