After updating to 5.5.7, booting doesn't work

1. offizieller Beitrag

    I was running v5.5.6 without problems and updated to v5.5.7, along with 2-3 other updates which got offered in the interface.

    Right after that I restarted the box, but booting didn't work any longer.


    Attaching a monitor revealed some interesting messages:

    Code
    [ TIME ] Timed out waiting for device /dev/disk/by-uuid/XXX.
[DEPEND] Dependency failed for /boot/efi.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Statistics collection and monitoring deamon.


    After some more [ OK ] messages the console shows this and hangs:

    Code
    You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.


    I think default didn't work, and rebooting brougt me back to the same.


    As I'm no linux expert, the logs are not helpful for me, but I spottet this which fits the other:

    Code
    The unit systemd-fsckd.service has successfully entered the 'dead' state.
...
A start job for unit dev-disk-by\XXX\XXX.device has finished with a failure.



    Is that related to the new UDEV rules introduced there?


    I currently can't look at the box, but wanted to post this already.

    • Offizieller Beitrag

    The problem seems to be that you've mounted the filesystem before the UDEV rules have been introduced. Because of that the configuration database contains the old devicefile, but the UDEV rules create new devicefiles for JMicron based controllers. You can delete the file but you need to delete it after every update manually. Another problem occurs if you attach more than one harddisk to such a crappy JMicron based USB controller. Every harddisk will become the same devicefile which normally should be unique. OMV is using predictable devicefiles because of that reason, they are unique across reboots. JMicron will break that and thus the system gets confused which will finally result in data loss.


    If possible you should backup your data and recreate the system from scratch, at least starting to reconfigure everything with mounting the filesystems, recreate the shared folders, .... This way the database will contain the correct devicefiles.


    The best will be to use a non JMicron based USB device, this hardware is totally crappy. I don't know what the developers smoke when they developed this microcontroller. Returning the same fake serial number for every attached harddisk instead of the real one is the worst idea ever.

    I'm using the Sabrent USB to single SATA. Which is a VIA controller regarding to your comment in the UDEV rules file.


    I guess I have to recreate the filesystem and all shares as well then to get the right devicefile into the configuration database... :/

    Can't access the box quite yet to test if moving the file works temporary.

    Update:

    I renamed the udev rules file and could boot without issues right after.

    I then applied the most recent update (5.5.7 to 5.5.9) and it still worked without problems - even after multiple reboots.


    So it looks like this is not the case?


    Zitat

    You can delete the file but you need to delete it after every update manually.


    Renaming the rules file to the original file name breaks booting again as expected.


    The only long term solution seems to be to delete and recreate the file system from scratch as votdev said already.



    How did you proceed, vah48? Did you try redoing the file system already?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden