Hass venv-Upgrade from 0.93.1 to 0.93.2 failed

Installation
1

Just ran an upgrade of the above which failed with the following output. I searched previous posts for similar error messages. I ended up re-imaging the SD card and ran the upgrade again. This time everything went fine. I’m just curious to know what problem is at play here

Installing collected packages: homeassistant
Found existing installation: homeassistant 0.93.1
ERROR: Exception:
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/cli/base_command.py”, line 178, in main
status = self.run(options, args)
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/commands/install.py”, line 414, in run
use_user_site=options.use_user_site,
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/req/init.py”, line 51, in install_given_reqs
auto_confirm=True
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/req/req_install.py”, line 822, in uninstall
uninstalled_pathset = UninstallPathSet.from_dist(dist)
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/req/req_uninstall.py”, line 529, in from_dist
for path in uninstallation_paths(dist):
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/req/req_uninstall.py”, line 60, in unique
for item in fn(*args, **kw):
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_internal/req/req_uninstall.py”, line 78, in uninstallation_paths
r = csv.reader(FakeFile(dist.get_metadata_lines(‘RECORD’)))
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_vendor/pkg_resources/init.py”, line 1423, in get_metadata_lines
return yield_lines(self.get_metadata(name))
File “/srv/homeassistant/lib/python3.5/site-packages/pip/_vendor/pkg_resources/init.py”, line 1420, in get_metadata
return value.decode(‘utf-8’) if six.PY3 else value
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xda in position 32782: invalid continuation byte

2

Was this a HASS venv install or Hassbian? That command did you run to upgrade? You can use pip from the venv with either one but the Hassbian scripts add other things.

3

Hass venv.

I ran the upgrade from pip as I usually do. Hadn’t come across this error before.

As I mentioned reimaging the SD card with an image I took before attempting the update and running the upgrade again resolved the issue.

I was just curious to know what caused the errors in the first place.

4

Did you run it from the venv with sudo ?
If you did not use sudo, does the user have write permissions to /srv/homeassistant?

5

Permissions are fine and this is what I use for the update

sudo su -s /bin/bash homeassistant
source /srv/homeassistant/bin/activate
pip3 install --upgrade homeassistant
exit
sudo reboot now

6

i believe the Hassbian script stops home assistant before upgrading. Perhaps a process had a file open that pip was trying to replace.

In fact, here are their official instructions if you do not use their script.

https://www.home-assistant.io/docs/installation/hassbian/upgrading/

7

Thanks @anon34565116

I’ll try this method on the next update and let you know how it works.

1 Like
8

I am currently running in a venv without the Hassbian scripts but I have chosen to remain on the older version, 0.90.2 until the bugs & brokenness settle down. On newer versions, the config pieces under Integration were missing for me, even with a clean install.

9

I have a venv install on ubuntu. I just updated using the same commands as @ConcordGE (except the unnecessary reboot) and it worked fine. I don’t stop home-assistant when I do this, I restart it afterwards. Never failed.

This isn’t windows. A file being open won’t prevent it being deleted.

10

I always shutdown running process before an update. How many times have you seen the following in Ubuntu

E: Could not get lock /var/lib/apt/lists/lock – open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not get lock /var/lib/dpkg/lock – open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

11

That is because you left an apt process running somewhere.

12

You are only half right. This isn’t Windows, it is a Unix-like filesystem that uses inodes.

An OS package manager, when it updates files does not have issues because it renames the old file first. Any processes with the file open still use that old inode to access it. New processes will use the new file. The OS has a process that runs at startup looking for these old renamed files and deleting them.

Python is not tightly integrated with the OS so it cannot delete open files.

For reference,

13

Exactly. So closing everything before updating avoids any side issues.

1 Like
14

That’s why I prefer Debian over Ubuntu. It insists on auto updates by default and hounds you if you turn them off.