update is anymore possible
W: No sandbox user ‘_apt’ on the system, can not drop privileges
so i have to rewrite the image an sd
While that could have been overcome if you are back to your old image please upload logs from old system and then try to upgrade again.
the old image is a fresh and updated osmc install
image: http://ftp.fau.de/osmc/osmc/download/installers/diskimages/OSMC_TGT_rbp2_20171102.img.gz
do you really need the logs from this state?
No, thought you recovered your previous install from an image.
ok. i try the stretch upgrade again.
hello
rpi1 512 (overclock 1100)
after upgrade ,
i have 1 bug kernel (dvbcore) for dvb-s2 usb tevii s2 660 ,
( dvbcore copy … bla bla ) probably the clone
no bug for dvb-s2 usb technisat skystar usb hd
oscam (not replaced) + tvheadend + client pvr hts work well …
all encrypted channels
( french csat ,bitrate less hight than on german channels )
in h264 + dolby work very well without artifact
in my apt source list , I see something weird .
deb Index of /raspbian stretch main contrib non-free
deb http://apt.osmc.tv stretch main
what should I have?
Thank you
Debug logs would be good. These should show what you are getting from raspbian which is probably the problem. How to submit a useful support request
About my
Nov 03 18:16:43 osmc kernel: Linux version 4.9.29-13-osmc (root@vero3-db) (gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1) ) #1 PREEMPT Wed Nov 22 16:09:35 UTC $
ok, a new setup was working fine. osmc compiling works too.
I haven’t done the upgrade, but I have a question.
Does the Stretch (Debian 9) version of the NFS package include a default /etc/nfsmount.conf file? It doesn’t exist in Jessie, but the NFS client does use it (so I assume the Stretch version will, too), and it really helps keep /etc/fstab cleaner.
If it isn’t included, a version from OSMC would be nice. I grabbed one from a CentOS install I had handy, and here’s a line from /etc/fstab for mounting a Windows NFS server using NFS version 4.1:
media:/nfstest /net/media/nfstest nfs bg,noauto,soft 0 0
Everything else is done in /etc/nfsmount.conf:
[ Server "media" ]
Nfsvers=4
vers=4
minorversion=1
rsize=1048576
wsize=1048576
namlen=255We recommend using fstab at this time.
Sam
Because…? Let me guess:
You like reading 200 character long lines and making debugging an fstab entry harder?
Making it easier to make sure every connection to a server uses the same default settings isn’t something that you are interested in?
Yes, it’s easier to ask people to just post their fstab here for debugging, but if Stretch includes a default /etc/nfsmounts.conf, then you’ll need them to post that, too, anyway, just to make sure it hasn’t changed.
Also, although NFS mounts currently don’t have anything security-related in fstab, other file systems (like CIFS) can, but those can also be moved to a different config file. This allows fstab to stay world-readable (like it has to). Best practice is to always reduce the chance of information leakage of any kind, so that makes several good reasons to move the options to a different, officially supported config file.
You can use the other approach if you want to. We choose not to as it’s easier to have all mounts in a single file, and this is the defacto method for mounting filesystems and network resources on Linux.
fstab will work with pretty much every distribution and doesn’t rely on userland helpers in the same way that your approach does.
/etc/nfsmount.conf is read by mount.nfs, which is called by “mount” after reading fstab and determining which subsystem to call. I wouldn’t call mount.nfs part of “userland”, since even the man page says it isn’t intended to be directly run by a user. And, mount.nfs for any patched distribution has support for /etc/nfsmount.conf compiled in…at least as far back as nfs-utils 1.2.3, which is now nearly 7 years old.
In addition, the defaults for any option not listed in fstab are determined by what is compiled into mount.nfs, and can change with an update to nfs-utils, which can cause the mount to fail. If you use /etc/nfsmount.conf, you can make sure that the defaults you want are used, even if you don’t include them in fstab.
if and only if:
nfs entry is present in fstab
or mount -t nfs / mount.nfs is invoked
which makes the case that this isn’t the best solution.
The defaults can be overriden for both fstab and /etc/nfsmount.conf, so I don’t quite follow your point here.
You can use the file you’ve suggested, we’re not stopping you.
If you know how to use NFS, then you likely won’t need our support, and in turn, wouldn’t need to provide us with fstab or have any questions surrounding NFS.
I can’t see any benefit of your approach however. I can only see two beneficial scenarios:
- You want the same mounting settings for all shares. This isn’t really applicable; because configuring NFS as a kernel based mount is a manual process.
- There are default NFS settings that should be set. This doesn’t seem necessary at the time of writing; and things seem to be work fine currently. If we had a Samba like situation in the future, it would be worth considering packaging this as a conffile or using an include directive.
You are missing the point that a lot of people buying the Vero are new to Linux and don’t know how to do NFS. There are a lot of posts here that show this is true, and even people who understand it a bit sometimes make mistakes.
Having a file that guarantees that the best (for OSMC, at least) options are always used by default, even if the compiled-in options to mount.nfs are changed makes supporting this easier. This won’t prevent users from setting options manually in fstab, as those options override any matching ones in /etc/nfsmount.conf.
Next, having a file with a skeleton for the options in a more readable form than really long fstab lines makes it easier for users to change something globally for all their mounts (the most common use case, as most users have one NFS server), but also allow easy changing of defaults for a particular server. Setting options for individual mounts in /etc/nfsmount.conf is a bit silly, but that can be done also, for users that want just one file to edit.
It’s easy to forget some of the more obscure options when doing a quick add of a mount to fstab (like “minorversion=1” is required when mounting a Windows NFS 4 mount), and nfsmount.conf prevents that. It also allows you to put commented out “how to’s” right in the file (again, for special cases like Windows NFS, or if you know specific NAS implementations require special options), and users can be told just to enter their server name/IP address in the “Windows NFS” section and remove the comment hash marks.
This setup would allow you to give help to users like “replace ‘yourserver’ in the following line with the name or IP address of your server, and ‘yourshare’ with the name of the share”:
yourserver:/yourshare /mnt/myfiles nfs defaults 0 0
No long, confusing options to mistype or misread, and easier debugging when they post their fstab entry here (“Is that the right server/share name?” “Have you tried it by IP address?” “Did you create the mount directory?”).
So, no, for NFS, I don’t need any help, but a lot of other people might appreciate you making it easier for them, and you might like having less questions, or more questions that can be pointed to an FAQ.
The more pragmatic solution is to improve the performance of Kodi’s built in NFS implementation, which is being worked on. Hopefully in the not too distant future we won’t need to recommend kernel based mounting apart from a very small number of situations.
Your suggestion to use /etc/nfsmount.conf has merit if there are sane defaults that can be set. Are there? I suspect that the majority of users employing NFS are not using Windows; but I have no proof of this.
Does /etc/nfsmount.conf support includes / sourcing from external files? If we were to use this method to set sane defaults, it would make sense for us to maintain these defaults. As such, we’d have to take ownership of this file in the form of a package, and ideally add a comment to tell others to edit something like /etc/nfsmount.conf.d/foo to override any default settings. The file could alternatively be marked as a conffile, but this is certainly less ideal.
Sam
Updated just now on a RPi2 in 30min without any issues (160Mbit up/down)
[edit]Seems my Harmony Elite doesn’t reconnect with Bluetooth, after pairing again and a reboot, it won’t reconnect.
Going with the tv remote (CEC) and reconnect each time works.[/edit]
Try to connect via bluetoothctl and see if it helps