> So, after all, I think the initial bug report is related, as mountall should fail/not hang with invalid UUIDs, but my problem goes one
> step further: the cryptsetup devices are not being setup properly anymore.
Daniel, please open a separate bug report on cryptsetup for your issue.
Unfortunately, I think mountall itself is behaving correctly in your case - you have this cryptsetup device bind-mounted to /opt, and /opt is a FHS filesystem which, if absent at boot, could causes services to fail to start (since packages in /opt may have init scripts in /etc/rc2.d that expect the files to be available). So in the general case, *not* waiting for this filesystem to be present before proceeding with the boot could cause serious boot-time instabilities. (This is distinct from bug #448267, where I argue that we should not be waiting for /srv before entering runlevel 2 because nothing in /srv should be a dependency of the system boot.)
So your underlying problem is that cryptsetup isn't correctly setting up your devices, but that it should be doing so. There's no evidence that this is related to the problem ooops is reporting here.
> So, after all, I think the initial bug report is related, as mountall should fail/not hang with invalid UUIDs, but my problem goes one
> step further: the cryptsetup devices are not being setup properly anymore.
Daniel, please open a separate bug report on cryptsetup for your issue.
Unfortunately, I think mountall itself is behaving correctly in your case - you have this cryptsetup device bind-mounted to /opt, and /opt is a FHS filesystem which, if absent at boot, could causes services to fail to start (since packages in /opt may have init scripts in /etc/rc2.d that expect the files to be available). So in the general case, *not* waiting for this filesystem to be present before proceeding with the boot could cause serious boot-time instabilities. (This is distinct from bug #448267, where I argue that we should not be waiting for /srv before entering runlevel 2 because nothing in /srv should be a dependency of the system boot.)
So your underlying problem is that cryptsetup isn't correctly setting up your devices, but that it should be doing so. There's no evidence that this is related to the problem ooops is reporting here.