HASS OS 6.0 VDI => After Upgrade fails every boot: Failed to start grow file system on /mnt/data

Installation Home Assistant OS
22

same problem here… those steps solved the issue!
Tks!

23

Wondering if 6.1 solved the above issues. I’ve held off updating OS on my Pi4b so far…

24

So something is corrupting the filesystem. Hopefully not a dying ssd/sd.

25

after updating to 6.1 the haos keeps crashing… omg, have to reinstall again

26

Dying USV it was. Had some improper shutdowns the last few weeks.

27

haos 6.X is a disaster… installing 6.1 on a raspberry 4 from scratch doesn’t work too… reverting to 5.13, again…

28

Updated OS and severely broke HA.

How do you downgrade to 5.13?

29

installed 5.13 from scratch, restored a snapshot…

1 Like
30

THIS actually fixed the issue… thank you for the reference !!

Will Never update OS again until I realize it is stable.

4 Likes
32

I’m having the same issue. I plugged in a monitor and keyboard/mouse to the raspberry pi 4. The output is:

[Failed] Failed to start File System Check on /dev/disk/by-label/hassos-data.
See ‘systemctl status “systemd-fsck@dev-disk-by\x2dlabel-hassos\x2ddata.service”’

Followed by

You are in emergency mode. After logging in, type “journalctl -xb” to view system logs…

The solution from Tscherno didn’t work for me.

When I try:
umount -A /dev/disk/by-label/hassos-data

I get an error “target is busy”

I also tried umount -l /dev/disk/by-label/hassos-data (after remounting read-only, to ensure no files were in use). This succeeded, but then the fsck command failed with “unable to set superblock flags on hassos-data”

I’ve also tried df -h when in this emergency mode and see my usb partition filesystems succesfully mounted (and I can ls the contents). But when I leave emergency mode and finish booting Home Assistant, df -h no longer shows the usb partitions

33

Is something else then mounted at /mnt/data? Make sure that you only have one partition with the file system label hassos-data.

35

(I missed posting this as a reply, so retrying, but now getting an error “post is too similar to what you already wrote”)

I have an external usb drive mounted, set up according to:

Note that this does appear to mount the drive to /mnt/data/… see lines:

# Determine the mount point
ENV{mount_point}="/mnt/data/supervisor/media/%E{dir_name}"

# Mount the device on 'add' action (a.k.a. plug the USB drive)
ACTION=="add", RUN{program}+="/usr/bin/mkdir -p %E{mount_point}", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no --collect $devnode %E{mount_point}"

Is there a workaround for those of us who have usb drives auto mounted with udev?

36

In this case you need to unmount that USB drive first, e.g.

umount /mnt/data/supervisor/media/{fs-label}
37

Thanks @agners. I ended up unplugging the usb drive and booting without it. I’m now able to run the command umount -A /dev/disk/by-label/hassos-data.

Then when I run the command fsck.ext4 /dev/disk/by-label/hassos-data I get the error:

fsck.ext4: unable to set superblack flags on hassos-data

I’ve just noticed that my original error that causes it to go into emergency mode isn’t actually from growfs. The original error is:

[FAILED] Failed to start File System Check on /dev/disk/by-label/hassos-data.
See `systemctl status “systemd-fsck@dev-disk-by\x2dlabel-hassos\x2ddata.service” for details.

I googled this, which seems to suggest a potentially bad sd card? (it’s a relatively new good quality sandisk, so this would be surprising). If I just run exit, the system seems to boot up fine, but seemingly in a read-only state. When I change any config or delete the homeassistant_v2 db file (6gb), the same 6gb file appears after a reboot without the changed config.

Sorry - I’m not sure if I should create this as a separate issue, since it now looks different from what’s originally posted in this thread.

Any ideas about this error message? unable to set superblack flags on hassos-data

38

The source code has this comment:

				/*
				 * Whoops, we attempted to run the
				 * journal twice.  This should never
				 * happen, unless the hardware or
				 * device driver is being bogus.
				 */

(see e2fsprogs/e2fsck/unix.c at 67f2b54667e65cf5a478fcea8b85722be9ee6e8d · tytso/e2fsprogs · GitHub)

So I guess that means indeed broken hardware :frowning:

39

that did the trick.

41

This fixed mine. Thanks for sharing !

1 Like
42

I am having to run through this unmount an fsck every third day or so. Will this isuse get fixed? Is there a way to keep the hassos-data drive clean inside HA, some automation task maybe?

43

Your storage device is probably broken. Replace it.

44

Hi nickrout. The NVME drive checkes out fine in Ubuntu, never gives any problem. Its the virtual disk in the KVM VM that keeps failing with this error and it appears I am not alone. So very unlikely to be a SSD problem. Just to check I ran through an extensive battery of test on the NVME drive that took a few hours to run. It reported zero problems. I looked today at my cron job that restarts a crashed KVM VM and this has triggered four times in the last 4 hours. It only triggered once yesterday. Looks like there is a problem in HA somewhere