Egy Arch Linux es egy OSMC (Debian) is csinalja nalam, hogy nem csatolja fel bootkor az fstabban megadott, amugy hazi FreeBSD szerverrol futo NFS-t hostnev alapjan:
Jun 19 21:50:57 apu systemd-networkd[256]: Enumeration completed
Jun 19 21:50:57 apu systemd[1]: Started Network Service.
Jun 19 21:50:57 apu systemd[1]: Reached target Network.
Jun 19 21:50:57 apu systemd-networkd[256]: enp4s0: Renamed to eth0
Jun 19 21:50:57 apu kernel: [drm] UVD initialized successfully.
Jun 19 21:50:57 apu systemd-networkd[256]: eth0: Renamed to enp4s0
Jun 19 21:50:57 apu systemd[1]: Starting Docker Application Container Engine...
Jun 19 21:50:57 apu systemd[1]: Reached target Network is Online.
Jun 19 21:50:57 apu systemd-networkd[256]: enp4s0: IPv6 enabled for interface: Success
Jun 19 21:50:57 apu systemd[1]: Mounting /mnt/media...
Jun 19 21:50:57 apu systemd[1]: Starting Network Name Resolution...
Jun 19 21:50:57 apu kernel: [drm] ib test on ring 0 succeeded in 0 usecs
Jun 19 21:50:57 apu kernel: [drm] ib test on ring 3 succeeded in 0 usecs
Jun 19 21:50:57 apu systemd-resolved[259]: Positive Trust Anchors:
Jun 19 21:50:57 apu systemd-resolved[259]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Jun 19 21:50:57 apu systemd-resolved[259]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172
Jun 19 21:50:57 apu systemd-resolved[259]: Using system hostname 'apu'.
Jun 19 21:50:57 apu mount[258]: mount.nfs: Failed to resolve server gos.lan: Name or service not known
Jun 19 21:50:57 apu systemd[1]: mnt-media.mount: Mount process exited, code=exited status=32
Jun 19 21:50:57 apu systemd[1]: Failed to mount /mnt/media.
Jun 19 21:50:57 apu systemd[1]: Dependency failed for Remote File Systems.
Jun 19 21:50:57 apu systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
Jun 19 21:50:57 apu systemd[1]: mnt-media.mount: Unit entered failed state.
Jun 19 21:50:57 apu systemd[1]: Starting Permit User Sessions...
Jun 19 21:50:57 apu systemd[1]: Started Permit User Sessions.
Jun 19 21:50:57 apu systemd[1]: Starting X-Window Display Manager...
Jun 19 21:50:57 apu systemd[1]: Started Getty on tty1.
Jun 19 21:50:57 apu systemd[1]: Reached target Login Prompts.
Jun 19 21:50:57 apu kernel: r8169 0000:04:00.0 enp4s0: link down
Jun 19 21:50:57 apu kernel: IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
Jun 19 21:50:57 apu systemd-resolved[259]: Switching to system DNS server 192.168.117.1.
Jun 19 21:50:57 apu systemd[1]: Started Network Name Resolution.
A journalctl kimenetbol az latszik, hogy hiaba el a network-online.target, meg nincs nevfeloldas es nem tudom hogy lehetne a systemd-t ravenni, hogy a generalt mnt-media.mount valahogy a nevfeloldas beindulasa utanra essen. Valakinek volt ilyen gondja illetve megoldotta-e mar helyettem?:)
NetworkManager nincs, automounttal meg IP cim hasznalataval fel tudom csatolni, de nem ez a jo valasz.
- 2775 megtekintés
Hozzászólások
A "_netdev" nem megoldás mint mount opció?
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).
- A hozzászóláshoz be kell jelentkezni
A doksit olvasgatva az nfs filerendszer-tipus implicit modon fugg a network-online.targettol, de ez nem megy az explicit _netdev-vel sem.
Azert ideztem be a journalt, mert abbol latszik, hogy eleri a targetet a mount elott, de nevfeloldas akkor meg nincs, lasd utolso par sor.
- A hozzászóláshoz be kell jelentkezni
most arra gondolok, hogy a halokartya atnevezese lehet az ok. ilyenkor a systemd nem tudja visszaszivni a kipipalt targeteket?
- A hozzászóláshoz be kell jelentkezni
en meg :)
ha 220-asnal ujabb systemd-d van, akkor megadhato az fstabban mountparameterkent a
x-systemd.requires=
parameter, itt megadnam a nevfeloldast mint függöseget. ha 220-asnal regebbi a systemd, akkor csak a mount unit override-jaban tudsz require-t allitani, de ez nyüg.
amugy /etc/hosts nem jatszik?
- A hozzászóláshoz be kell jelentkezni
koszi a tippet. sajnos az 'x-systemd.requires=systemd-resolved.service' megadasaval ele rakja ugyan, de a mount ugyanugy elhasal a nevfeloldason.
mas mar nem nagyon van, ugyhogy megprobaltam a multi-user.target-et is, akkor meg nem tul meglepoen kozli, hogy a rendszer meg indul es csak roottal lehet belepni.
mint irtam fent, meg tudom oldani az IP cim ilyen-olyan megadasaval, de azert van a DNS, hogy ne kelljen bedrotoznom gepenkent a cimeket.
- A hozzászóláshoz be kell jelentkezni
persze, a drotozas rossz, de egyebkent nfs-nel talan meg bocsanatos bün. ugyis a puppet vagy egyeb tool kezeli a hosts-t ;)
megmutatod a
systemctl cat systemd-resolved.service
kimenetét?
- A hozzászóláshoz be kell jelentkezni
megmutatom, de csak este, most nem ferek hozza a gephez.
nem azt mondom, hogy ha munkara kellene, ne tudnek 3 megoldast, amivel 2 perc alatt el van intezve az ugy. itt az elvekrol van szo. amugy pont emiatt inkabb irnam az IP cimet a mounthoz mint hosts-ba, mert ugy legalabb megmarad a DNS, mint kizarolagos igazsagforras.
- A hozzászóláshoz be kell jelentkezni
ime a systemctl cat systemd-resolved.service kimenete az arch gepen:
# /usr/lib/systemd/system/systemd-resolved.service
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Network Name Resolution
Documentation=man:systemd-resolved.service(8)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/resolved
Documentation=http://www.freedesktop.org/wiki/Software/systemd/writing-network-config…
Documentation=http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clien…
After=systemd-networkd.service network.target
# On kdbus systems we pull in the busname explicitly, because it
# carries policy that allows the daemon to acquire its name.
Wants=org.freedesktop.resolve1.busname
After=org.freedesktop.resolve1.busname
[Service]
Type=notify
Restart=always
RestartSec=0
ExecStart=/usr/lib/systemd/systemd-resolved
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN CAP_DAC_OVERRIDE CAP_FOWNER
ProtectSystem=full
ProtectHome=yes
WatchdogSec=3min
[Install]
WantedBy=multi-user.target
valamint az osmc-n:
# /lib/systemd/system/systemd-resolved.service
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Network Name Resolution
Documentation=man:systemd-resolved.service(8)
After=systemd-networkd.service network.service
[Service]
Type=notify
Restart=always
RestartSec=0
ExecStart=/lib/systemd/systemd-resolved
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN CAP_DAC_OVERRIDE CAP_FOWNER
ProtectSystem=full
ProtectHome=yes
[Install]
WantedBy=multi-user.target
az osmc-n nincs is engedelyezve, az archon tegnap engedelyeztem, de se vele, se nelkule
- A hozzászóláshoz be kell jelentkezni
a Type ertekere voltam kivancsi, notifyn van ami helyes, mast nem tudnek atallitani. müködnie kene.
ha override-olnad a nevfeloldas unitot, egy before= a mount unit ele kene bele, de ezt nagyobb hakolasnak erzem az ip alapjan törtenö mountnal.
a mount unitba tenyleg belerakta a nevfeloldas függöseget?
- A hozzászóláshoz be kell jelentkezni
bele:
# /run/systemd/generator/mnt-media.mount
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=remote-fs.target
After=systemd-resolved.service
Requires=systemd-resolved.service
[Mount]
What=gos.lan:/srv/media
Where=/mnt/media
Type=nfs
Options=defaults,rsize=65536,wsize=65536,timeo=10,x-systemd.requires=systemd-resolved.service
- A hozzászóláshoz be kell jelentkezni
FreeBSD-féle fstab-ban van olyan opció, hogy late, ami ilyen esetekre teljesen jó megoldás. Nézegettem a linuxos fstab-manuált, de nem láttam benne ilyet.
Elkezdtem nézegetni a systemd-mount leírását, és ez alapján egy nofail vagy/és egy x-systemd.device-timeout=10 (vagy 10-től különböző, nyilván) opció talán ígéretesnek tűnik.
- A hozzászóláshoz be kell jelentkezni
koszonom, megnezem megegyszer, de ugy tudom, a device-timeout a tenyleges mount lefutasanak idokorlatja, ami a nevfeloldas hibaja miatt itt azonnal visszater egy hibakoddal, a nofail pedig hibatol fuggetlenul engedi lefutni a fuggo unitokat, amik itt nincsenek.
- A hozzászóláshoz be kell jelentkezni
Lehetséges, nincs szoros kapcsolatom a systemd-vel. Viszont ha már annyira menő ez a systemd, esetleg a Restart= is megérhetne egy pillantást, talán egy on-failure beállítással.
- A hozzászóláshoz be kell jelentkezni
a Restart=on-failure szorosabb kovetelmeny, mint a Restart=always, nem ernek el vele semmit, amit az utobbi nem csinal
- A hozzászóláshoz be kell jelentkezni
A Restart=always van beállítva? A doksi azt mondja, hogy az alapértelmezett beállítás a no, azaz nincs újraindítás. Az always mindig újraindít (amikor a folyamat kilép), míg az on-failure csak akkor, ha az exit code nem nulla ("unclean exit code"), ami elvileg teljesül, hisz írtad: Jun 19 21:50:57 apu systemd[1]: mnt-media.mount: Mount process exited, code=exited status=32
- A hozzászóláshoz be kell jelentkezni
nyaahm, eltevedtem, azt hittem, a systemd-resolved.service-rol beszelunk, bocsi.
az mnt-media.mount-nak tudtommal nem lehet Restart-ot megadni, de a file-t nem is en csinalom, hanem a boot korai szakaszaban a systemd-fstab-generator
- A hozzászóláshoz be kell jelentkezni
Hm, lehet, hogy tényleg nem lehet.
- A hozzászóláshoz be kell jelentkezni
Szerintem jó lesz az a nofail:
man systemd.mount
The NFS mount option bg for NFS background mounts as documented in nfs(5) is not supported in /etc/fstab entries. The systemd mount option nofail provides similar functionality and should be used instead.
If the bg option is specified, a timeout or failure causes the mount(8) command to fork a child which continues to attempt to mount the export. The parent immediately returns with a zero exit code. This is known as a "background" mount.
- A hozzászóláshoz be kell jelentkezni
kiprobaltam, a problema ugyanugy fennall. a systemd doksija csak annyit mond a nofailrol, hogy hiba eseten nem akasztja meg a bootfolyamatot.
- A hozzászóláshoz be kell jelentkezni
Akkor nem nyert...
- A hozzászóláshoz be kell jelentkezni
Volt nekem is hasonló gondom (jobb ötlet hiányában az rc.local-t használtam csatoláshoz), de neked az egyszerű megoldás nem jó válasz.
- A hozzászóláshoz be kell jelentkezni
Gondolom, nem akar kerülő utakat, hanem az indítási/mount rendszeren belül, szabványosan akarja megoldani.
- A hozzászóláshoz be kell jelentkezni
Hát akkor marad a végső megoldás: bug report.
Aztán majd Mr Poetsch megmagyarázza, hogy ennek nem is kell működnie, a júzer menjen a fenébe.
- A hozzászóláshoz be kell jelentkezni
meg nem volt idom a systemd-networkd-vel letesztelni. ha azzal is csinalja, nem csak netctl-lal, bejelentem.
- A hozzászóláshoz be kell jelentkezni
az egyszeru megoldast (igazabol harmat is) ismerem, ezert azok nem erdekesek. ha ennek mennie kell (ahogy szerintem kellene), akkor lesz belole egy bugreport a systemd-nek, ha meg nem, akkor atertekelem az eletemet es felcsatolom IP alapjan:)
van olyan, hogy egy szakmai forumon valaki nem megoldast keres, hanem tudast.
- A hozzászóláshoz be kell jelentkezni
https://github.com/systemd/systemd/issues/3688
ugy latom, nincs altalanos megoldas, ha a systemd-networkd.service-t hasznalod, akkor systemctl enable systemd-networkd-wait-online.service, ugyanez NetworkManagerrel systemctl enable NetworkManager-wait-online.service.
- A hozzászóláshoz be kell jelentkezni