0

I was swapping disks in my Ubuntu Zesty and forgot to remove the /etc/fstab entry for the old disk.

The reboot process hung for a moment when trying to mount the missing disk, then resumed, went through the NICs configuration and halted when it was unable to raise a br0 bridge.

It asked to either go into maintenance mode (busybox) by giving the root password, or continue the boot process (which did not continue but hung indefinitely).

I did not make the link initially, but commenting out the missing disk in /etc/fstab fixed the issue. This is reproducible every time.

There is therefore a hard (stopping) dependency between the availability of a disk and the ability to start a network bridge.

  • what could there be a reason to have one?
  • how can I check where it is configured?
  • Where was the old filesystem mounted? – Kusalananda Sep 30 '17 at 19:50
  • @Kusalananda: it was mounted on /mnt/1TB1 – WoJ Sep 30 '17 at 20:10
  • This question presumes causation where there most likely is none, and as such is probably unanswerable. Subtract the part about a network bridge, and you have well-known standard behaviour for systemd bootstrap when there's a faulty non-nofail entry in /etc/fstab. The stuff about a network bridge is a red herring, and asking for an explanation of said red herring will likely not garner an answer. What makes you think that the red herring is relevant? Just that it happens to be the last message on the screen before the mount unit failure causes the activation of rescue mode? – JdeBP Oct 1 '17 at 11:44
  • @JdeBP: no, it was the fact that the last message before the activation of rescue mode was that the bridge cannot be raised, as mentioned in my question. – WoJ Oct 1 '17 at 19:04
  • That is of course "yes". – JdeBP Oct 2 '17 at 5:48

Your Answer

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

Browse other questions tagged or ask your own question.