Asociace repair.org udělila anticeny těm nejhorším produktům představeným na veletrhu CES 2026. Oceněnými jsou například šmírující kamery Amazon Ring AI, chytrý běžecký pás od společnosti Merach, která otevřeně přiznává, že nedokáže zabezpečit osobní data uživatelů, případně jednorázové lízátko, které rozvibrovává čelisti uživatele a tak přehrává hudbu. Absolutním vítězem je lednička od Samsungu, která zobrazuje reklamy a kterou lze otevřít pouze hlasovým příkazem přes cloudovou službu.
Íránští protirežimní aktivisté si všímají 30% až 80% ztráty packetů při komunikaci se satelity služby Starlink. Mohlo by se jednat o vedlejší důsledek rušení GPS, kterou pozemní přijímače Starlinku používají k výpočtu polohy satelitů a kterou se režim rovněž snaží blokovat, podle bezpečnostního experta a iranisty Amira Rashidiho je ale pravděpodobnější příčinou terestrické rušení přímo satelitní komunikace Starlinku podobnou
… více »Evropská komise (EK) zvažuje, že zařadí komunikační službu WhatsApp americké společnosti Meta mezi velké internetové platformy, které podléhají přísnější regulaci podle unijního nařízení o digitálních službách (DSA). Firmy s více než 45 miliony uživatelů jsou podle DSA považovány za velmi velké on-line platformy (Very Large Online Platforms; VLOP) a podléhají přísnějším pravidlům EU pro internetový obsah. Pravidla po
… více »Tržní hodnota technologické společnosti Alphabet poprvé v historii přesáhla čtyři biliony dolarů (83 bilionů Kč). Stalo se tak poté, co Apple oznámil, že bude na poli umělé inteligence (AI) spolupracovat s dceřinou firmou Alphabetu, společností Google.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 161 (pdf).
Po delší době vývoje vyšla nativní linuxová verze virtuálního bubeníka MT-PowerDrumKit 2 ve formátu VST3. Mezi testovanými hosty jsou Reaper, Ardour, Bitwig a Carla.
Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Narazil jsem na zvláštnost, kterou se mi nedaří zatím lépe diagnostikovat. Po výpadku napájení na jednom z domácích serverů (nepříjemné, nutno řešit, ale nikoli fatálně kritické) přestalo být možné namountovat exportovaný NFS svazek - čímkoli.
Na serveru je nyní Gentoo, jádro 4.19.50, nebo 4.9.63 (zkoušel jsem obě verze) a bude 4.9.79, net-fs/nfs-utils-2.4.1-r1, jádro má zapnutou podporu verzí NFS 3 i 4.
Připojovat jsem se zkoušel jiným Gentoo s podobnými verzemi jádra i nfs-utils, Debianem 10 i serverem samotným - vše se stejným výsledkem, takže problém na klientech jsem vyloučil.
Dejme tomu, že exportuji složku __public, nijak nezáleží na tom, co vlastně exportuji a odkud, nebo s jakými volbami, ono to nakonec nefunguje stejně.
/home/__public 192.168.0.254(rw,async,all_squash,anonuid=65534,anongid=65533,no_subtree_check)
Připomínám, že v konfiguraci iptables změna nenastala a zkouším i přes localhost, kde není omezení žádné.
Pokus o mount dopadá takto:
mount -t nfs -o nfsvers=3 jmenoserveru:/home/__public /mnt/hdd/ mount.nfs: Stale file handle
umount /mnt/hdd umount: /mnt/hdd: nepřipojeno.
mount -t nfs -o nfsvers=4 jmenoserveru:/home/__public /mnt/hdd/
Mount bez explicitně zadané verze NFS se pokusí použít verzi 4.
Pokud by sožka nebyla exportována, tak pokus o mount selže se správnou chybou. Taktéž i pokud nejsou dostatečná práva atd...
Zkusil jsem exportovat složku z BTRFS a při pokusu o připojení to skončí vždy chybou mount.nfs: Stale file handle bez ohledu na verzi NFS.
ls /mnt/hdd ls: adresář '/mnt/hdd' nelze otevřít: Zastaralý ukazatel na soubor cd /mnt/hdd bash: cd: /mnt/hdd: Zastaralý ukazatel na soubor mount ... jmenoserveru:/home/__public on /mnt/hdd type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.254,local_lock=none,addr=192.168.0.254)
V logu se nezdá být cokoli užitečného:
Oct 15 12:29:34 jmenoserveru start-stop-daemon[17414]: Will stop /usr/sbin/rpc.mountd Oct 15 12:29:34 jmenoserveru rpc.mountd[8523]: Caught signal 15, un-registering and exiting. Oct 15 12:29:35 jmenoserveru start-stop-daemon[17418]: Will stop nfsd Oct 15 12:29:35 jmenoserveru kernel: nfsd: last server has exited, flushing export cache Oct 15 12:29:35 jmenoserveru start-stop-daemon[17449]: Will stop /sbin/rpc.statd Oct 15 12:29:35 jmenoserveru start-stop-daemon[17477]: Will stop /usr/sbin/rpc.idmapd Oct 15 12:29:35 jmenoserveru start-stop-daemon[17504]: Will stop /sbin/rpcbind Oct 15 12:29:36 jmenoserveru rpc.idmapd[17586]: Setting log level to 0 Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Version 2.3.4 starting Oct 15 12:29:36 jmenoserveru rpcbind[17597]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Flags: TI-RPC Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Running as root. chown /var/lib/nfs to choose different user Oct 15 12:29:36 jmenoserveru rpc.mountd[17636]: Version 2.3.4 starting Oct 15 12:29:36 jmenoserveru kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Oct 15 12:29:53 jmenoserveru rpcbind[17663]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:29:53 jmenoserveru rpcbind[17664]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:29:53 jmenoserveru rpcbind[17665]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:29:53 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:800 for /home/__public (/home/__public) Oct 15 12:29:53 jmenoserveru rpcbind[17666]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:29:54 jmenoserveru rpcbind[17667]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:29:54 jmenoserveru rpcbind[17668]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:29:54 jmenoserveru rpcbind[17669]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:29:54 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:752 for /home/__public (/home/__public) Oct 15 12:29:54 jmenoserveru rpcbind[17670]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:29:56 jmenoserveru rpcbind[17671]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:29:56 jmenoserveru rpcbind[17672]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:29:56 jmenoserveru rpcbind[17673]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:29:56 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:885 for /home/__public (/home/__public) Oct 15 12:29:56 jmenoserveru rpcbind[17674]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:17 jmenoserveru rpcbind[17830]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:49:17 jmenoserveru rpcbind[17831]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:17 jmenoserveru rpcbind[17832]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:49:17 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:828 for /home/__public (/home/__public) Oct 15 12:49:17 jmenoserveru rpcbind[17833]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:18 jmenoserveru rpcbind[17834]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:49:18 jmenoserveru rpcbind[17835]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:18 jmenoserveru rpcbind[17836]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:49:18 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:960 for /home/__public (/home/__public) Oct 15 12:49:18 jmenoserveru rpcbind[17837]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:20 jmenoserveru rpcbind[17838]: connect from 127.0.0.1 to getport/addr(status) Oct 15 12:49:20 jmenoserveru rpcbind[17839]: connect from 192.168.0.254 to getport/addr(nfs) Oct 15 12:49:20 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:750 for /home/__public (/home/__public) Oct 15 12:49:20 jmenoserveru rpcbind[17840]: connect from 192.168.0.254 to getport/addr(mountd) Oct 15 12:49:20 jmenoserveru rpcbind[17841]: connect from 192.168.0.254 to getport/addr(nfs)
Kdesi jsem se dočetl, že chyba Stale file handle by snad mohla souviset s nějakým zámkem po špatně odmountovaném svazku, ale nenašel jsem žádný detail, jak zjistit jaký konkrétně, jediné doporučení tam byl reboot. To jsem udělal opakovaně při změně jádra za jinou verzi. Nemělo to vliv.
Úplně původně jsem ani verzi NFS 4.x neměl povolenou, pro interní síť a dvě klientská PC mi v pohodě stačila verze 3.
HDD, ze kterého exportuji NFS má ReiserFS na dvou oddílech. Zkusil jsem exportovat jinou složku z jiného oddílu - žádný rozdíl.
Zkusil jsem promazat /var/lib/nfs/rmtab, žádný vliv. Pouze se přimountováním v rmtab vytvoří nový záznam. Další soubory v /var/lib/nfs jsou většinou prázné (0 bytů), kromě etab, obsahuje seznam exportovaných svazků a state, obsahuje nějaké 4 byty. Význam neznám.
Zkusil jsem HDD otestovat pomocí readonly badblocks -sv /dev/sda, vše ok. SMART ok, žádné chyby ve výpisu.
Ze zoufalství jsem zkusil přes noc i emerge -ave world, pro případ, že by výpadkem napájení došlo k poškození nějaké s NFS související knihovny. Nepomohlo. Všechny soubory jsou čerstvě zkompilované, včetně jádra, kontrolní součty balíčků ověřené, vše ok. Jen NFS nefunguje.
V conf.d jsou konfiguráky nfs a rpcbind, nfs je defaultní neprováděl jsem v něm změny.
# /etc/conf.d/nfs # If you wish to set the port numbers for lockd, # please see /etc/sysctl.conf # Optional services to include in default `/etc/init.d/nfs start` # For NFSv4 users, you'll want to add "rpc.idmapd" here. NFS_NEEDED_SERVICES="rpc.idmapd" # Options to pass to rpc.nfsd OPTS_RPC_NFSD="8" # Options to pass to rpc.mountd # ex. OPTS_RPC_MOUNTD="-p 32767" OPTS_RPC_MOUNTD="" # Options to pass to rpc.statd # ex. OPTS_RPC_STATD="-p 32765 -o 32766" OPTS_RPC_STATD="" # Options to pass to rpc.idmapd OPTS_RPC_IDMAPD="" # Options to pass to rpc.gssd OPTS_RPC_GSSD="" # Options to pass to rpc.svcgssd OPTS_RPC_SVCGSSD="" # Options to pass to rpc.rquotad (requires sys-fs/quota) OPTS_RPC_RQUOTAD="" # Timeout (in seconds) for exportfs EXPORTFS_TIMEOUT=30 # Options to set in the nfsd filesystem (/proc/fs/nfsd/). # Format is <option&rt;=<value&rt;. Multiple options are allowed. #OPTS_NFSD="nfsv4leasetime=30 max_block_size=4096"
Do rpcbind jsem zkusil přidat volbu -d jako debug.
# /etc/conf.d/rpcbind . # Options for `rpcbind`. #RPCBIND_OPTS="-l" RPCBIND_OPTS="-l -d"
Výsledkem -d je alespoň to málo ve /var/log/messages, co jsem přiložil, jinak by nebylo ani to.
V dmesg nic.
Nějaký další nápad?
Řešení dotazu:
Replaying journal: Done.
Reiserfs journal '/dev/sda3' in blocks [18..8211]: 0 transactions replayed
Checking internal tree.. finished
Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
Leaves 101963
Internal nodes 648
Directories 4032
Other files 204770
Data block pointers 54142197 (0 of them are zero)
Safe links 0
exportfs -ua exportfs -a # nebo exportfs -fZdar Max
cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2
Ad use flagy:
[ebuild R ] net-fs/nfs-utils-2.4.1-r1::gentoo USE="caps ipv6 libmount nfsidmap nfsv4 nfsv41 tcpd uuid -junction -kerberos -ldap -nfsdcld (-selinux)" 0 KiB
A konfigurace jádra:
CONFIG_KERNFS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m CONFIG_NFS_V3=m # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=m # CONFIG_NFS_SWAP is not set CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_PNFS_FILE_LAYOUT=m CONFIG_PNFS_BLOCK=m CONFIG_PNFS_FLEXFILE_LAYOUT=m CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org" CONFIG_NFS_V4_1_MIGRATION=y CONFIG_NFS_FSCACHE=y CONFIG_NFS_USE_LEGACY_DNS=y CONFIG_NFS_DEBUG=y CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4=y CONFIG_NFSD_PNFS=y CONFIG_NFSD_BLOCKLAYOUT=y CONFIG_NFSD_SCSILAYOUT=y CONFIG_NFSD_FLEXFILELAYOUT=y CONFIG_NFS_COMMON=y
Další pokus, aktualizoval jsem jádro na verzi 5.3.0 a problém je stále stejný.
showmount -a vypíše zapamatované klienty s mountpointy, ale i když je prázdný a nenastane hláška mount.nfs: Stale file handle, tak to nefunguje.
Nejukecanější mount je k ničemu
mount.nfs: timeout set for Tue Oct 15 22:52:14 2019 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.254,clientaddr=192.168.0.1'
NFS (4.2) se přimountuje bez stížností, ale nelze s ní pracovat, jakýkoli pokus končí nelze přistoupit k '/mnt/nfs': Zastaralý ukazatel na soubor.
A opět, nezáleží na tom, jestli je klient Gentoo, nebo Debian... čímž chci říct, že to není vada jednoho klienta. Ani to není omezení firewallu, do vnitřní sítě omezení iptables není.
Ukecaný pokus o přimountování NFS verzí 3 skončí vždy takto.
mount.nfs: timeout set for Tue Oct 15 23:01:48 2019 mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259 mount.nfs: mount(2): Stale file handle mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259 mount.nfs: mount(2): Stale file handle mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259 mount.nfs: mount(2): Stale file handle mount.nfs: Stale file handle
Proč?
I když koukám na komunikaci tcpdumpem a vidím, že oba stroje spolu komunikují, tak z toho nedovedu vykoukat víc, než že komunikace mezi nimi končí tímto:
NFS reply xid 3824853766 reply ok 88 getattr ERROR: Stale NFS file handle
Jak to donutit k nějakému ukecanějšímu výstupu ... kdekoli, ze kterého se dá něco dalšího poznat? Jediné, co jsem dokázal vypátrat, že se v minulých letech (jako např. 2008, 2012, 2014) různé bugy různým lidem s různými verzemi nfs-utils staly. Nic, co by pomohlo.
Zkusím prozatím updatnout to Gentoo, už to je asi 14 dnů od poslední aktualizace, třeba bude jiná verze nfs-utils.
Tiskni
Sdílej: