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

Installation Home Assistant OS
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

45

Hello there, I tried you doing this procedure, but is it normal that I’ve been pushing enter now for over literally 30 minutes… and still not done…

46

Nevermind after 40 minutes holding ENTER everything is working fine!

Thanks again!

47

Press “A” for All next time

48

So what does fsck report?

Also if this is a problem in haos, it won’t even be looked at by a dev unless a github issue is posted.

49

As a last resort I replaced my NVMe drive with a new Samsung M2 drive. I cloned the NVMe and then ran fsck to be sure. It is showing exactly the same problem with Home Assistant. Interestingly their is a new error message which relates to the PCI driver for the M2 bus. I used a fix I saw on the internet by using

  1. cp /etc/default/grub ~/Desktop
  2. Edit grub. Add pci=noaer at the end of GRUB_CMDLINE_LINUX_DEFAULT. Line will be like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer"
  1. sudo cp ~/Desktop/grub /etc/default/
  2. sudo update-grub
  3. Reboot now

This got rid of the pciport error. Maybe it is still the issue?

50

Heaven knows why you copy the file to the desktop before editing it, but whatever :slight_smile:

More importantly, pci=noaer just suppresses error messages, it doesn’t fix what is causing the errors.