I had to restart router few times to get rid of that error:
usb_serial_generic_write_bulk_callback - nonzero urb status: -71
It is about z-wave usb controller (generic usb-serial driver).
Everything else went smooth.
After the update, when calling the schnappi.sh I get
Warning, could not drop caches
Warning, could not drop caches
Warning, could not drop caches
Everything seems to work. Shall I be worried about the warning? What can I do to make it go away?
I use Turris 1.1 upgraded, BTRFS, 32 GB SD card with lots of free space
root@turris:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p2 29.8G 867.7M 28.6G 3% /
tmpfs 1011.5M 11.2M 1000.3M 1% /tmp
tmpfs 512.0K 0 512.0K 0% /dev
-------------------------------------------------------------------------------
| ID | Size | Type | Date | Comment |
-------------------------------------------------------------------------------
| 60 | 34.19MiB | pre | 2018-09-20 16:31 | Automatic pre-update snapshot |
| 61 | 10.02MiB | post | 2018-09-20 16:37 | Automatic post-update snapshot |
| 63 | 9.98MiB | pre | 2018-09-26 17:39 | Automatic pre-update snapshot |
| 64 | 10.08MiB | post | 2018-09-26 17:40 | Automatic post-update snapshot |
| 68 | 11.12MiB | pre | 2018-10-15 21:51 | Automatic pre-update snapshot |
| 69 | 11.23MiB | post | 2018-10-15 21:54 | Automatic post-update snapshot |
| 6 | 183.21MiB | single | 2018-03-06 22:54 | User created snapshot |
| 73 | 10.34MiB | time | 2018-11-11 01:05 | Snapshot created by cron |
| 74 | 10.16MiB | time | 2018-11-18 01:05 | Snapshot created by cron |
| 75 | 10.09MiB | time | 2018-11-25 01:05 | Snapshot created by cron |
| 76 | 10.09MiB | time | 2018-12-02 01:05 | Snapshot created by cron |
| 77 | 10.08MiB | pre | 2018-12-03 17:16 | Automatic pre-update snapshot |
| 78 | 10.08MiB | post | 2018-12-03 17:18 | Automatic post-update snapshot |
| 79 | 10.09MiB | time | 2018-12-09 01:05 | Snapshot created by cron |
| 80 | 6.64MiB | pre | 2018-12-10 16:43 | Automatic pre-update snapshot |
| 81 | 1.39MiB | post | 2018-12-10 16:52 | Automatic post-update snapshot |
-------------------------------------------------------------------------------I have the same issue on both of my Turris 1.1 boxes. They were without errors before upgrade to 3.11. Now, when I do âschnapps listâ, it starts with
Warning, could not drop caches
Warning, could not drop caches
parent transid verify failed on 194887680 wanted 8597 found 8546
parent transid verify failed on 194887680 wanted 8597 found 8546
Ignoring transid failure
Warning, could not drop caches
followed by correct list of snapshosts.
I believe I have enough free space on SD card. One is
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p2 7.1G 750.7M 6.1G 11% /
And second is very similar
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p2 7.3G 705.9M 6.6G 10% /
Any idea? Should I worry? Or plan to export snapshot, factory reset, migrate to BTRFS again, import snapshot? It emerged on two boxes at the same time. If that is corrupted BTRFS, then it was corrupted by upgrade to 3.11. Please, investigate it, because if upgrade to 3.11 corrupts BTRFS, then there is the risk it will corrupt it again after recovery process and my effort would have been unnecessary.
Just filed two more bugs:
Canât reliably get to Luci from turris webapps page
Turris OS 3.11: miniupnpd no longer starts at router boot
@Pepe please check these out.
@sammy_cda I suspect my bug above is the true reason UPnP is not working out of the box on 3.11. When I fixed that issue, I didnât have to have any other package installed but miniupnpd for UPnP to work. minidlna is only needed if youâre using the router as a media server, and miniupnpc is the UPnP client, it doesnât need to be on the router.
1 Like
I expect that Turris kernel is still missing CONFIG_ADVISE_SYSCALLS and consequently weâre hitting [v2] btrfs-progs: report I/O errors when closing the filesystem - Patchwork Some people here used to miss madvise, too.
EDIT: I believe the warning from btrfs is harmless, given the semantics of POSIX_FADV_DONTNEED. (No guarantees though.)
Another crappy release breaking things which worked before.
- Removed youtube-dl package prevented upgrade:
##### Error notifications #####
Updater selhal:
inconsistent: Requested package youtube-dl that is not available.
- mpd package is broken:
# /usr/bin/mpd
Error loading shared library libavformat.so.57: No such file or directory (needed by /usr/bin/mpd)
Error loading shared library libavcodec.so.57: No such file or directory (needed by /usr/bin/mpd)
Error loading shared library libavutil.so.55: No such file or directory (needed by /usr/bin/mpd)
Youâre the first, who reported issues with those two packages. Thank you for reporting them as nobody reports it even this release was for a month in RC version.
-
Unfortunately, I donât know right now, why youtube-dl wasnât compiled.
-
We know, whatâs went wrong with mpd.
This will be fixed in Turris OS 3.11.1 as weâd like to release to RC very soon. What should work for you is to force reinstall the package, which you can do with the following command.
opkg update && opkg install mpd-full --force-reinstall
Not sure how many of TO user are familiar with the schnapps concept, which though requires ssh access and that might be the first stumbling block. Access to schnapps via Foris might improve the situation.
The issue with schnapps is however that it creates 2 snaps and the second one is from after the update and if the update botches the router, as in not accessible, the hardware rollback would revert to the snaps from after the update and thus create a loop. Hence one would have to be aware and delete the second snap prior rebooting. Perhaps this should be thought over in order to provide a failsafe since access with the UART console is even more challenging.
Configuration backup does covers just bare bone (etc\config\ | \etc\updater\ | firewall user) and thus restoring from there in worst case will leave the user still with some work. Perhaps it could be more comprehensive like medkit.
Long story short - if switching between stable and rc is easy and recovery would more convenient for the less advanced user TO might gain a broader user spectrum willing to participate in RC testing. In the end a good stable release would benefit each user.
1 Like
I think doing a 2 LED Reset twice should bring to back to the snapshot before the update.
Maybe split this topic? I totally agree with what you wroteâŚ
Thanks, the mpd reinstallation did indeed help.
As for RC testing, you canât expect everybody to run RC. For me itâs enough to get breakages which appear in the releases, I donât want to see more of thatâŚ
Some basic sanity tests could be done automatically - AFAIK missing packages did happen in the past and that should be easy to detect automatically. Missing libraries (if thatâs really the problem cause) would be also easy to spot automatically.
2 Likes
The mpd thing is also a missing package, I believe. I expect you were left with the old version when it disappeared, and by accident the sonames of ffmpeg libraries got bumped at the same timeâŚ
I had mpd-full already, there is Install("mpd-full") in /etc/updater/conf.d/opkg-auto.lua.
1 Like
Vzhledem k tomu, co jsem si pĹeÄetl výťe jsem vyuĹžil moĹžnosti oddĂĄlenĂ aktualizace o 72 hodin, kterou mĂĄm dlouhodobÄ nastavenou a ve Forisu dĂĄle jsem vybral volbu âOdmĂtnoutâ. JiĹž v tento moment mÄ pĹekvapilo, Ĺže datum aktualizace nebylo za tĹi dny, ale tĹi mÄsĂce (Ăşnor 2019).
O to vĂce jsem pĹekvapen, Ĺže mi dnes (po ÄtyĹech a ne tĹech dnech) pĹiĹĄla zprĂĄva s tĂm, Ĺže k instalaci prĂĄvÄ doĹĄlo spoleÄnÄ s pĹehledem dalĹĄĂch balĂÄkĹŻ, co ÄekajĂ na schvĂĄlenĂ. Za dalĹĄĂch tĹi a vĂce dnĹŻ tak zĹejmÄ mohu Äekat nezĂĄvisle na nastavenĂ Turris OS 3.11 a rozbitĂ˝ router.
⢠NainstalovanĂĄ verze 20180409-2 balĂku ca-bundle
⢠NainstalovanĂĄ verze 7.62.0-2 balĂku libcurl
⢠NainstalovanĂĄ verze 60.4.6-3.6-2 balĂku updater-ng
Hi Sammy_cda,
I saw your post and followed your advice. Alltough it had no effect at first, it now seems to work.
Thanks
But Luci is still as slow as it gets. Every page takes some 6 sec⌠to open.
1 Like
See my bug here https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/268 I think thatâs the real reason UPnP didnât work. I didnât have to install miniupnpc or minidlna once I fixed that (I have no need for the functions of those packages)
inconsistent: Requested package youtube-dl that is not available.
Should be fixed in Turris OS 3.11.1., weâll release the RC version, really soon.
We have updated it to version 2018.12.09 and also we sent the PR to OpenWRT as well.
This does not look good. For me, it might seem like a corrupted file system, right now, you just have 2 transactions, if they appear more, then itâs for sure something bad and I do not even want to tell you that you should ignore them, because, in the end, itâs your data. Not mine and you would have to know if you have any backups, and if not, itâs a good time to have some backups.
Anyway, letâs take a look at those 2 transactions. According to BTRFS kernel documentation:
Under normal circumstances the generation numbers must match.
Would you please try the following command and send me the output from it? It will show you if they are any I/O errors.
btrfs dev stat /dev/mmcblk0p2Then, I would start with command btrfs scrub, which would verify the block checksums for data and metadata blocks. If it somehow succeeds, Iâd suggest you change the microSD card for a new one or try to format the current microSD card and after you do it, you can try to use something like H2testw to check your microSD card.
And finally, the last interesting question, did you have a power outage?
We have enabled it for Turris 1.x in Turris OS 3.11.1.
1 Like
INFO:Running post-install and post-rm scripts
Output from resolver-conf.postinst:
chown: unknown user/group kresd:kresd
uci: Entry not found
Should be fixed in Turris OS 3.11.1 by this commit from @paja
https://gitlab.labs.nic.cz/turris/turris-os-packages/commit/675b3be3cbeac0dcb375453f44b7e7665dbb7341
1 Like
I seem to be unable to find any news from @paja on this, hence this reply.
After the upgrade to 3.11 my TO does not resolve anymore, despite that kresd was up and running (seemingly). After killing kresd, I tried restarting it, which still gives the already reported error:
root@jib-router:~# ps | grep kres
1974 root 104m S /usr/bin/kresd -c /tmp/kresd.config -f 1 /tmp/kresd -a 127.0.0.1 53 -a 192.168.99.1 53 -a 192.168.66.1 53 -a 192.168.55.1
25436 root 1108 S grep kres
root@jib-router:~# kill 1974
root@jib-router:~# /etc/init.d/kresd start
chown: unknown user/group kresd:kresd