Script lefuttatása boot alatt

Debian GNU/Linux

Hogyan kell lefuttatni boot alatt egy scriptet?Több módszert is ajánlottak a neten:

1. Tegyem be cronba @reboot-tal meghívva, full eléréssel, esetleg delay-jel. (@reboot sleep 10 && /path/to/my/script) Nem működött.

2. Tegyem be /etc/rc.local-ba, full eléréssel. Ez sem működött.

3. Tegyem be .bashrc-be vagy .bash_profile-ba. Ez ugyan működött, de csak akkor, ha már bejött a grafikus felület és kinyitottam egy terminált. Nekem pedig még a boot alatt kell.

4. Tegyem be initscriptbe, rakjak bele LSB header-t és hívjam rá az update-rc.d-t. Nem működött. Egy hasonszőrű topicban még mondták, hogy symlinkeljem be a scriptet az /etc/rc.d-be, de ez a könyvtár nem létezik.

A rendszer Devuan 2-es. (Debian 9 alapú.)

Valakinek ötlet?

  • 2272 megtekintés

( gee v | 2019. 03. 04., h – 12:12 )

Ha jól emlékszem, devuan az System V inittel megy.

Olvasd el az inittab man oldalát, de ha jól emlékszem, bootkor a /etc/rc.d/ könyvtárban lévő scripteket végrehajtja. Lehet, hogy S99scriptnév formára keres rá, és csak az így kezdődőeket.

Most látom csak, hogy nincs rc.d könyvtárad.

Akkor nézd meg, hogy milyen runlevelen indul el, és mondjuk ha 3-as, akkor a /etc/rc3.d/ könyvtárba linkeld be. Ott viszont már mindenképp csak a S99 kezdetű nevűt fogja végrehajtani.

Egyébként az, hogy nem működött, az elég kevés információ. Lehet, hogy te rontottál el valamit, vagy valamit nem tudtál és ezért nem csináltad meg. Logban megnézted a hibaüzeneteket pl?

( iattilagy | 2019. 03. 04., h – 12:15 )

Systemd-hez csinálsz egy service fájl oneshot type-al. Ami külön jó, hogy erre más service-ek simán dependálhatnak. Pl.:

[Unit]
Description=Init script

[Service]
Type=oneshot
ExecStart= script path
RemainAfterExit=true
StandardOutput=journal

[Install]
WantedBy=multi-user.target

> sysvinittel meg óriási szívás.

Kifejtenéd, hogy az eddig elhangzott lehetőségek (inittab, crontab, rc.local, /etc/rcX.d/Sxxsajatscriptem) közül melyik az óriási szívás és főleg miért? Ebből a crontab ugye init-től független (kivéve gondolom systemdland-ban), a másik három mind a SysVInit használatából és általánosan elterjedt konfigjából adódó lehetőség. Persze használni kell tudni őket ugyanúgy, mint ahogy a systemd-s konfigot is össze kell tudni precízen hegeszteni. Lásd még: systemd alatt is ugyanúgy fontos, hogy jól add meg a függőségeket, mint ahogy pl. az Sxxsajatscriptem használatakor az xx rossz kiválasztása sem segít a megoldásban.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ha nem egyetlen adott gépen, adott disztrón kell megoldani, ezek mindegyike szívás nézzük sorban:

- crontab: A cron nem igazán erre való, azt, hogy mikor fut le nehéz belőni
- rc.local: ez régen nem volt minden disztróban
- inittab: simán felülírja valami
- rcX.d: Ez a legértelmesebb megoldás, de boot után elég nehéz lesz kihámozni, hogy tényleg lefutott-e a script és mit logolt.

> - crontab: A cron nem igazán erre való, azt, hogy mikor fut le nehéz belőni

Hogy mi? A cron pont arra való, hogy pontosan akkor fusson le a parancsod amikor akarod.

> - rc.local: ez régen nem volt minden disztróban

De te jelen időben mondtad, hogy most szívás. (Egyébként meg #define régen, legjobb tudomásom szerint az /etc/rc.local az UNIX 7 (1979) óta létezik...)

> - inittab: simán felülírja valami

Hogy mi? Mi írja felül, mikor, hol?

> - rcX.d: Ez a legértelmesebb megoldás, de boot után elég nehéz lesz kihámozni, hogy tényleg lefutott-e a script és mit logolt.

Miért lenne? /var/log/ nem vész el.

( BognarB v | 2019. 03. 04., h – 12:14 )

Ez engem is érdekelne, de init 0 és init 6 -nál.
Triviálisnak gondoltam, de eddig nem sikerült vele sokat haladni. (sysvinit)

-----------------------------------------
Linux parancsok, kezdőknek

Egy ideje minden gépemen systemd van, úgyhogy csak emlékezetből írom:

Szerintem nem kellett semmi különös fejléc. Vagy nem tudom, mire gondolsz. Esetleg leírnád, hogy mi az, amit fejlécnek beírtál?

Mi az update-rc.d?

Nem tudom, Debiant használsz-e, nekem systemd előtti Debian rendszeren annyi volt, hogy a symlinket odatettem, a megfelelő elnevezési konvencióra (SXXfoo, KXXbar) figyelve, és onnantól a rendszer használta. Persze lehet, hogy azóta valamit változtattak.

Azt írod, hogy fejléc nélkül lett egy valami hiba, fejléccel egy valami más. Tehát akkor a scriptedet megpróbálta a rendszer futtatni, csak valami a tartalmával nem volt jó, gondolom.
Ha a hibaüzeneteket beírod, hátha valaki meg tudja mondani, hogy mi volt a gond.

( asch v | 2019. 03. 04., h – 13:06 )

Troll on: systemd-vel gyerekjáték volna

( zrubi v | 2019. 03. 04., h – 13:32 )

mit értesz pontosan a "boot alatt" kifejezésen??

a példákat amiker írsz, azok mind boot UTÁN futnak.

Ha pl az 1. módszer nem működik, akkor ~99% hogy a scriptedben van a hiba.

ha a 3. működik, akkor igen valószínű, hogy valami user session/environment főggősége van a scriptednek, azért nem megy máshogy.

De ha a script nem titkos, és megmutatod értelmesebb javaslatokat is kaphatsz ;)

--
zrubi.hu

Boot alatt azt értem, hogy mielőtt az X11 felkelne és az XDM feldobná a login formot.

Nem, végülis nem titkos a script. Lényegében arról van szó, hogy vannak a PIPO X8 és PIPO X8 Pro nevű minipécék, amikhez van egy live Linuxunk, amiről telepítjük a gépre. Az egyiken a cdc_ether driver kell, hogy vigye a netet, a másikon pedig a dm9601. Namármost, ez eddig egy dolog, de a sima PIPO-n, ha a dm9601 előbb betöltődik, mint a másik, akkor elszáll a net és csak reboottal lehet megjavítani; nem, sem unload, sem semmi nem segít. Ezt csak blacklisttel lehet orvosolni, viszont a másikon meg pont az a driver kell, amit itt blacklistelni kell. A probléma, hogy hol ezen, hol meg azon a fajta gépen kell felbootolni a telepítőknek a kulcsot, ezért írtam egy scriptet, ami annyit csinál, hogy megnézi, hogy ez melyik fajta PIPO, meg, hogy blacklistelve van e a dm9601 és a gép típusától függően tiltja vagy engedélyezi a drivert. Aztán rebootol, mert különben nem működik...

Ennyi a történet dióhéjban és itt vannak a scriptek:

detect_pipo: Ez ismeri fel a gépet.
detect_pipo_blacklist: Ez dönti el, hogy épp tiltva van-e az ominózus driver, vagy sem.
config_pipo_net: És ez az a script, amit meg akarok hívni, ami intézi az egészet.

Mind a három script az /usr/local/bin-ben lakik és mindegyik futtatható.

1) Egyébként az miért nem jó, hogy alapból blacklisteled mindkettőt, és simán modprobe-al húzod be a megfelelő modult (és megúszod a reboottal mókolást?). [ill. ha init scripből reboot-ot hívsz, tök jó reboot ciklusokat lehet csinálni]
2) Természetesen továbbra is a megfelelő LSB fejléc + update-rc.d lenne a korrekt megoldás, ha össze is sűríted egy scripbe
3) És természetesen: * laughs in systemd *

(egyébként pedig az _igazi_ megoldás: blacklist mindkettőre és egy-két jól irányzott udev szabály, hogy melyik modult töltse be)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

1) Nekem jó volna, de úgy nem működött. Nem tudom, hogy miért. Esik kel a Linux ezeken a gépeken.
2) Leírtam a nyitó posztban, hogy azt megpróbáltam és nem működött.
3) Csak nyugodtan. Én majd akkor fogok röhögni, amikor a systemd megint a levesbe küldi valakinek a gépét, mint a múltkor. (BTW, felesleges a trollkodás, nem a SysVInit nem működik, hanem én nem tudom, hogy hogy kéne ezt megoldani.)

Az udevnek lehet egyáltalán olyat mondani, hogy ha ez a CPU van, akkor ezt töltse be, ha meg az, akkor meg azt?

Az udevnek lehet egyáltalán olyat mondani, hogy ha ez a CPU van, akkor ezt töltse be, ha meg az, akkor meg azt?

Nem lennék meglepve, ha lehetne (ha más nem, a udev tud scriptet indítani, amivel kikeresheted), de itt nem tudom, hogy kell-e...

Jól látom, hogy ez valami USB-s kütyü? Nincs valami device attrib, amivel különbséget tudsz tenni köztük? Ha igen, onnantól két szabály, szűrsz arra az attribra, egyiknél modprobe cdc_ether, a másiknál dm9601...

Szerk.:

2) Leírtam a nyitó posztban, hogy azt megpróbáltam és nem működött.

Azt viszont nem, hogy _miért_ nem működött (meg _hogyan_ nem működött)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Jól látom, hogy ez valami USB-s kütyü? Nincs valami device attrib, amivel különbséget tudsz tenni köztük? Ha igen, onnantól két szabály, szűrsz arra az attribra, egyiknél modprobe cdc_ether, a másiknál dm9601...

A második fele jól hangzik, csak nem értem az első felében a kérdéseket. Mi az USB-s kütyü? Maga a minipc? Van rajta USB, de az miért fontos? Vagy úgy érted, hogy maga a hálókártya belül az USB porton ül-e? A CDC az lshw szerint a PCI expressen, a másikat nem tudom, de valószínűsítem, hogy az is.

> Azt viszont nem, hogy _miért_ nem működött (meg _hogyan_ nem működött)

Ez tény, de az elsőt nem is tudom leírni, mert én sem tudom, hogy miért nem működött (ha tudnám, akkor megoldottam volna. :/ ), a másikon meg nem nagyon van mit részletezni: egyszerűen nem történt semmi.

Ez alapján elvileg tudnál matchelni (jobb híjján) a USB Bus / Device id-ra:

Fejből, közvetlenül a komment szövegmezőbe gépelve: 


# PIPO
SUBSYSTEMS=="usb",ATTR{busnum}=="1",ATTR{devnum}=="2",RUN="modprobe cdc_ether"
# PIPOPRO
SUBSYSTEMS=="usb",ATTR{busnum}=="1",ATTR{devnum}=="3",RUN="modprobe dm9601"

(egyébként a Debian Wikiben azt írják, hogy mindig a cdc_ether kell, de néha elhasal: https://wiki.debian.org/InstallingDebianOn/PIPO/PIPO%20X8)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Sry, a RUN-nak teljes elérési út kell (/sbin/modprobe). Ha van valami HW switch vagy valami az eszközön, amivel ki tudod rúgni a Wifi-t és vissza, akkor a udevadm monitor-ral tudod nézni, egyébként udevadm test /sys/bus/usb/devices/... -rel tudod tesztelni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ja, igen, mindkettő eszközön van valami mindkét eszköz úton... Keresd ki a /sys-ben az eszközt (/sys/bus/usb/devices/ alatt lesznek), aztán mindkettőre csinálj egy udevadm info -a /sys/... -t, kell, hogy legyen valami, amire tudod szűrni

Pl. még tudod a vendor és device id-ra is szűrni, valami ilyesmivel: 


SUBSYSTEMS=="usb",ATTR{busnum}=="1",ATTR{devnum}=="2",ATTR{idProduct}=="0a46",ATTR{idVendor}=="1269",RUN="/sbin/modprobe cdc_ether"
# másikra ugyanez az idProduct/idVendor pár

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Beleírtam ezt:

# PIPO
SUBSYSTEMS=="usb",ATTR{busnum}=="1",ATTR{devnum}=="2",ATTR{idProduct}=="0a46",ATTR{idVendor}=="1269",RUN="/sbin/modprobe cdc_ether"
# PIPO PRO
SUBSYSTEMS=="usb",ATTR{busnum}=="1",ATTR{devnum}=="3",ATTR{idProduct}=="0a46",ATTR{idVendor}=="1269",RUN="/sbin/modprobe dm9601"

De így meg egyiket sem tölti be. Egyik gépen sem.

Szerintem valamit nem írtál jól le, hogy mi történt, vagy félreérted amit SzBlackY mond.

blacklistelni azt jelenti, hogy tiltod a modul automatikus betöltését. Megtetted ezt _mindkét_ modullal, amik ütik egymást? Ha igen, akkor boot után próbáld meg _kézzel_ betölteni őket! Mi történik? Így sem működik a rendszer? Mi a hibajelenség?

* Mert ha így is hibázik, akkor nem egyik modul interferál a másikkal, hanem valami harmadik dologgal interferálnak.
* Ha viszont így működik, akkor már csak azt a szkriptet kell megcsinálni, ami helyetted "kézzel" behúzza a megfelelő modult. (Én sysV init szolgáltatásként csinálnám meg ennek a betöltését.) A lényegi különbség eközött és a te megoldásod között az, hogy így megoldva nem kellene reboot, hanem a sticket bootolva egyből jó lenne a rendszer.

A normál PIPO-n a kettős blacklist és a modprobe cdc_ether után működik a net, viszont a PIPO Pro-n hiába mondom neki, hogy modprobe dm9601, utána nem hajlandó működni. ifup/ifdown azt mondja, hogy nincs konfigurálva, /etc/init.d/networking stop/start kiírja, hogy configuring done, majd ugyanúgy nem megy, az ifconfig eth0 up/down meg kiírja, hogy ilyen eszköz nincsen. Reboot életre leheli, de akkor a blacklistet el kell távolítani.

Itt nem harmadik dologgal ütköznek, hanem ennek a szar PIPO-nak a Linux támogatottsága egy raklap alsógatya. Esik-kel, boot-ba néha belefagy, stb.

Diffeld meg a betöltött kernel-modulokat, és a dmesg-et úgy, hogy blacklistelve van a modul és úgy, hogy nincs. Hátha ráakadsz arra a másik lépésre, ami a netkártya felállásához kell. Elég fura volna, ha boot alatt be lehetne tölteni, később meg már nem. (Ha egy másik driver valami invalid állapotba hozza a hardvert, az érthető hogy bajt okoz, de ha ilyen nincs, akkor mindegy kellene legyen, hogy mikor tölti be a drivert.)

Közben kiderült, miért nem ment: az /etc/udev/rules.d-ben volt egy konfig, ami már bejegyezte az eth0-át egy adott mac addressre és az eth1-et egy másikra. Miután kitöröltem, rebootoltam és modprobe dm9601 && /etc/init.d/networking restart és működik. Valahogy lehet forceolni, hogy ne csináljon persistent rulesetet az eth0-ra?

Ez offtopic, ezért külön hozzászólás:

3) Csak nyugodtan. Én majd akkor fogok röhögni, amikor a systemd megint a levesbe küldi valakinek a gépét, mint a múltkor. (BTW, felesleges a trollkodás, nem a SysVInit nem működik, hanem én nem tudom, hogy hogy kéne ezt megoldani.)

Erre tudsz egy linket mondani? systemd "okozta" adatvesztésre egyedül az rémlik, amikor valaki azzal találkozott, hogy lehet a systemd-tempfiles-t rm /* -re paraméterezni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Erre tudsz egy linket mondani? systemd "okozta" adatvesztésre egyedül az rémlik, amikor valaki azzal találkozott, hogy lehet a systemd-tempfiles-t rm /* -re paraméterezni...

Adatvesztésest? Tudok mondani azt is (ez pont az amit te is említettél), noha én nem arról beszéltem, hogy az adatokat küldi a levesbe, hanem azt, hogy a gépet. (Link erre is: https://news.ycombinator.com/item?id=10999335)

De ez itt tényleg off és felesleges is. Felhívnám a figyelmedet, hogy ezt nem systemd fikatopicnak szántam, én meg sem említettem a systemd-t, asch és te triggerelődtetek a Devuan említésére és hoztátok be a topicba.

( Nyosigomboc v | 2019. 03. 04., h – 14:11 )

Tegyel bele egy ilyet az rc.local-odba:

set >/home/username/env.txt

Igy kiderul, hogy tenyleg nem fut le, illetve milyen env. var-ok vannak beallitva. Ugy vettem eszre, a legtobbszor lefut a script, csak valami nincs beallitva, amit varna a scripten beluli program, ezert nem az tortenik, amit vartal.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

config_pipo_net script full eléréssel van meghívva és már az sem fut le.
Ezt miből állapítod meg?

szinte biztosan az a baj, hogy a scripten belül nincs megfelelő $PATH, így ezek egyike sem találja meg a lefuttatandó állományokat:

PIPO=`detect_pipo`
PIPOBL=`detect_pipo_blacklist`

mivel ezek nélkül nem csinál semmit a scripted, így érthető, hogy nem működik.

(amikor interaktív terminálból hívod meg, akkor a login session-ben még szerepel a $PATH-ban a /ust/local/bin, és működik - ahogy írtad is.)

Szerintem.
--
zrubi.hu

( Zahy v | 2019. 03. 04., h – 22:10 )

Noha jól látszik, hogy az /etc/rc.local segítségével már közelítesz a megoldáshoz, azért megemlítem, hogy a SysVinit esetén létezik olyan is, hogy /etc/inittab, és ebben azok a sorok, amiknél az action kulcsszó (a 3. mező) a "sysinit" / "boot" / "bootwait", azok a fenti sorrendben, a fájlbeli sorrendnek megfelelően futnak le a boot meglehetősen korai szakaszában. Mondjuk pl. ha rossz helyre teszi az ember, akkor simán lehet, hogy még nincs is felcsatolva a /usr, vagy a /usr/local.

Illetve megteheted, hogy kikeresed, hogy mi az alapértelmezett futási szint (az a sor, amiben "initdefault" a kulcsszó, abban a sorban a második - runlevel - mezőben szereplő legmagasabb értékű szám), és a fájl elejére felveszel néhány olyan sort, amiben a futási szint (2. mező) megegyezik ezzel a számmal, a kulcsszó (3. mező) a "once" kulcsszó, a negyedik mezőben pedig teljes elérési úttal az általad futtatni akart script.

És í. t. (Mint mások is mondták, a kicsit részletesebb hibaleírás sokat tud segíteni.) Ha pedig azt kell egy SysVInit-es rendszer esetén kideríteni, hgy mi az alapértelmezett futási szint, akkor az inittab tanulmányozása helyett használható a "who -r" parancs boot után egy terminálban.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Noha jól látszik, hogy az /etc/rc.local segítségével már közelítesz a megoldáshoz, azért megemlítem, hogy a SysVinit esetén létezik olyan is, hogy /etc/inittab, és ebben azok a sorok, amiknél az action kulcsszó (a 3. mező) a "sysinit" / "boot" / "bootwait", azok a fenti sorrendben, a fájlbeli sorrendnek megfelelően futnak le a boot meglehetősen korai szakaszában.

Egy darab sysinit-est találtam: si::sysinit:/etc/init.d/rcS
A másik kettőből nincs.

> Mondjuk pl. ha rossz helyre teszi az ember, akkor simán lehet, hogy még nincs is felcsatolva a /usr, vagy a /usr/local.

Láma kérdés: felcsatolva? Mármint mountolva? Itt egy partíción van minden (kivéve a swap). Vagy úgy érted, hogy a $PATH-ben nincs még benne? Az már kiderült, hogy tényleg nincs akkor még benne.

> Illetve megteheted, hogy kikeresed, hogy mi az alapértelmezett futási szint (az a sor, amiben "initdefault" a kulcsszó, abban a sorban a második - runlevel - mezőben szereplő legmagasabb értékű szám), és a fájl elejére felveszel néhány olyan sort, amiben a futási szint (2. mező) megegyezik ezzel a számmal, a kulcsszó (3. mező) a "once" kulcsszó, a negyedik mezőben pedig teljes elérési úttal az általad futtatni akart script.

Ezt találtam: id:2:initdefault:
Tehát akkor be kéne elé szúrnom egy olyat, hogy piponet:2:once:/usr/local/bin/config_pipo_net ?

> És í. t. (Mint mások is mondták, a kicsit részletesebb hibaleírás sokat tud segíteni.) Ha pedig azt kell egy SysVInit-es rendszer esetén kideríteni, hgy mi az alapértelmezett futási szint, akkor az inittab tanulmányozása helyett használható a "who -r" parancs boot után egy terminálban.

Thx. Mondjuk ehhez valid service is kéne. Az LSB headert ugyan beleraktam, de ennek ellenére sem futott. Majd holnap retry.

No akkor sorban:

Az egy db. sysinit felhúzza a single-user módban szükséges dolgokat, az még korai. Az, hogy nincs boot/bootwait, az nem baj, opcionális.

Igen, felcsatolásként említettem a mountolást. Mondjuk ha nincsenek önálló fájlrendszerek, akkor ez nem érdekes.

A PATH-beli értéket akár te is változtathatod, ha mindenképp az a cél, hogy legyen benne a /usr/local/bin, akkor akár ezt is beteheted a scriptjeid elejére:
PATH=$PATH:/usr/local/bin
export PATH

Végül pedig igen, egy ilyen sor kell oda.

Azért ilyeneket még ellenőrizz:
- script futtatási joga
- script első sorában #! után álló shell létezzen (és szintén legyen futási joga)
- minden a scriptből hívott parancs vagy elérési útvonallal legyen, vagy olyan könyvtárban, ami benne van a PATH-ban
- eseleg script elejére (she-bang után) két ilyen sor:
exec 2> /tmp/stderr # stderr átirányítva ebbe a fájlba
set -x # ennek hatására minden parancs futtatása előtt kiíródik az stderr -re a parancs

innentől látszik, hogy milyen parancsnál lesz hiba, és mi az a hiba.
és a következő boot után megnézni, hogy mi van a /tmp/stderr nevű fájlban - és ez alapján javítani a scripten.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> A PATH-beli értéket akár te is változtathatod, ha mindenképp az a cél, hogy legyen benne a /usr/local/bin, akkor akár ezt is beteheted a scriptjeid elejére:
PATH=$PATH:/usr/local/bin
export PATH

De hülye vagyok, ez eszembe se jutott, hogy átállíthatom kézzel... :/

> - script futtatási joga
> - script első sorában #! után álló shell létezzen (és szintén legyen futási joga)

Ezek megvoltak.

> - minden a scriptből hívott parancs vagy elérési útvonallal legyen, vagy olyan könyvtárban, ami benne van a PATH-ban

Ez viszont nem, nem volt benne a PATH-ban...

> - eseleg script elejére (she-bang után) két ilyen sor:
> exec 2> /tmp/stderr # stderr átirányítva ebbe a fájlba
> set -x # ennek hatására minden parancs futtatása előtt kiíródik az stderr -re a parancs

Erre már nem kerül sor, mert azzal, hogy fel lett véve a hiányzó útvonal, a script életre kelt és megcsinálta, amit kellett, thx a rámutatást. Viszont sajnos csak azután teszi, hogy az X11 elindul és az XDM feljön. Bejelentkezni nem kell, de a telepítők ebbe bele fognak zavarodni, hogy most mikor kell várni, meg mikor nem, azonfelül a rebootba belehal a gép, kapok egy fehér képernyőt, rajta egy mozgatható pointerrel és kámpec. Ctrl + Alt + Fx sem segít, csak az eltáp. Hogyan lehetne az X11 előtt lerendezni ezt?

Nem tudom, hogy éppen most hogy működik a devuan alatt a systemvinit, amikor régen Debian alatt ment, akkor nem volt még párhuzamosítás és hasonló úri huncutságok, hanem sorban hajtotta végre a startup fájlokat.

Ha belenézel az rc2.d könyvtárba, az xdm valószínűleg az utolsó lehet, pl. S99xdm vagy hasonló néven.
Annyit kell tenned, hogy korábbra* teszed be a te parancsodat.

Már nem emlékszem hol (talán man inittab, vagy akár a /etc/inittab vagy /etc/rc2.d könyvtárban (vagy máshol valami doksiban)) le van írva, hogy melyik szám kb. mit jelent. Olyasmit képzelj el, hogy mondjuk 10-ig elindítja a core akármiket, logolást, eszközkezelést, modulokat. 20-ig valamivel molyol, 30-nál húzza fel a hálózatot, 40-nél mountolja fel a fájlrendszereket (amik ugye lehetnek elméletileg hálózaton is, pl. /usr és /home simán), 50-nél indítja azokat a dolgokat, amikhez kell a /usr 60 körül kész a karakteres alaprendszer, 99-nél elindítja az X-et.

A lényeg az, hogy meg kellene keresned azt, hogy hová illeszkedik logikailag a scripted. Pl. mivel a hálózat nem megy a scripted nélkül, gondolom arra a részre kellene rákeresni, ami a hálózati interfészek felhúzása előtt van (nézd meg, hogy hányas számnál indul a network, networking vagy mi a neve a linknek), és az elé érdemes beszúrni.

DE! Ha pl. a scriptednek kellenek olyan dolgok, amik nem a root fájlrendszeren vannak, akkor keresd meg azt a pontot, ahol a fájlrendszereket felmountolja, és a közé a pont és az xdm közé tedd valahová.

* arra, gondolom, rájöttél, hogy a számok sorrendjében hajtja végre a dolgokat az init által indított program (valami runner a neve, úgy rémlik). Szóval ha S42foo a scriptedre mutató link neve, akkor az S41bar után és az S50baz előtt fog lefutni.

Köszi a magyarázatot, mindenképpen bele fogom magam ásni, de úgy néz ki sikerült megoldani Zahy és SzBlackY javaslatainak összekombinálásával: Az eth0 rulesetet belinkeltem a /dev/null-ra, a két drivert blacklistre raktam és az rc.local-ban pedig meghívok egy scriptet, ami a korábbi módosult változata, nem blacklistel meg rebootol, csak loadol, aztán újrahúzza a network-öt: http://everlink.hu/init_pipo_net

Köszi mindenkinek!