Closed scottlamb closed 2 years ago
Scott, I built the server from the new-schema branch and installed it. It would not run until I did nvr upgrade
but then I was getting no data from ws streams (same in my UI and yours, recorded streams played ok.) Replaced the docker image with the distribution version but it fails because the database schema is too new, and nvr upgrade
won't downgrade :-( I did not take a backup of the db. Do I have to start from scratch?
Hmm, starting from scratch isn't so easy. I moved the db, did nvr init
, now in nvr config
trying to add a sample directory it claims ENOENT
Even though that dir does exist:
root@nvr:~# ls -ld /ssd/nvr/sample/
drwx------ 2 moonfire-nvr moonfire-nvr 7569408 Sep 28 10:01 /ssd/nvr/sample/
Same result with any other path on that drive.
Shoot. I wasn't ready for anyone to upgrade their main installation to schema v7. I haven't fully tested it or even finalized the schema, and as you've noticed there's no downgrade code. Starting from scratch is probably best.
Hmm, starting from scratch isn't so easy. I moved the db, did
nvr init
, now innvr config
trying to add a sample directory it claims ENOENT
I could give that error message better context, but it was probably on the mkdir
syscall. The manpage says:
ENOENT A directory component in pathname does not exist or is a dangling symbolic link.
so possibly /ssd/nvr
doesn't exist inside the docker container, even though it does on the host. Is there a --mount
for that in your wrapper script?
Is there a --mount for that in your wrapper script?
Well, yes and no :-) I had added a mount line, but it was using a symbolic link that I must have created for reasons that I now have absolutely no recollection of. Since I'd lost the database I didn't realise I'd used the symbolic link instead of the actual mount point for the drive.
In my defence, I did re-read the installation instructions, but overlooked the note about the mount point. I assumed of course that since my script was already working it needed no changes :-(
Anyway, this has prompted me to reconfigure the hardware to swap out the SSD for a bigger high-endurance disk I'd since acquired.
I'm sure that nobody else will be stupid enough to make the same mistake - but just in case - perhaps the config ui could list the mount points available. From inside the container it would seem you can list these with mount |grep \^/dev | grep -v /etc
- or maybe there is a cleaner way.
Oh, and I wanted to use the new user preferences schema for testing the UI. I guess I need a disposable test server for that.
I'm sure that nobody else will be stupid enough to make the same mistake
Ha! No, very easy mistake to make, and I'm sure you won't be the last if we don't address it in some way.
- but just in case - perhaps the config ui could list the mount points available. From inside the container it would seem you can list these with mount |grep \^/dev | grep -v /etc - or maybe there is a cleaner way.
That's a good idea, but I think I can do even better by #160. Then there'd be no Docker mapping to worry about at all.
[edit: although, come to think of it, displaying the mount points in the UI is probably a good idea even without Docker's extra mapping layer involved...]
Oh, and I wanted to use the new user preferences schema for testing the UI. I guess I need a disposable test server for that.
That's what I do when messing with schema changes. I have a few installations:
Ok, all back up and running with new drive. This install is literally built on a breadboard.
Some easy stuff I definitely want to include:
label column inOh, I already added auser_session
, so they can give the name of the device or client agent or whateverdescription
and forgot about it.open
boot id and monotonic time;likely a separate table with time steps observed while running.punted the latter.Stretch goals (as in things I want but am unsure I want to hold version 7 up for their design and implementation), all punted:
My typical procedure is to start a branch, add everything in over several commits and tweak the upgrade script, and give it some more testing than usual. I want it to be pretty reliable given that the upgrade procedure can be intimidating for users and there's no downgrade procedure.