kernel fordítások 2022

Üdvözlök mindenkit!
Biztos mindenki ismeri a mondást, hogy addig jár a forrás a kútra míg le nem fordul, - természetesen a forrás szó helyére a kernel forrást írhatjuk jelen esetben. Az eredeti szólás-mondástól pedig eltekintek, mert ami törik maximum a kernelt konfigurálók kedve lehet, de mindenképp érdemes kísérletezni mert tanulni sosem szégyen!

Tovább olvasom

NosPup64

Fontosnak tartom elmondani, hogy a NosPup-ok nem saját céllal készültek, hanem olyan célkitűzést valósítanak meg, amik túlmutatnak a woof-ce nyersességén. Nem csak lefuttattuk a woof-ce-t és amit kaptunk felraktuk egyből a tárolóra, hanem feltérképeztük és optimalizálva javítani próbáltuk. Ki-ki a maga részét téve bele.

Tovább olvasom

UEFI alapismeretek és DpupBuster64 telepítés – videó

 

Bár a régi gépek BIOS -t tartalmaznak nagyrészt, egyre többet kerül elő az UEFI kérdés.

Aki esetleg teljesen járatlan a témában, annak javaslom az alábbi cikket, ami az alapvető tudnivalókat foglalja össze:
https://skamilinux.hu/a-nagy-boot-kaosz-efi-uefi-gpt-csm-bios-msdos-mbr-secure-boot/

Már viszonylag sok bejegyzés és fórumtéma született a rendszerindítás, betöltés és telepítés témakörében, ezek szinte mind kivétel nélkül a hagyományos BIOS – MBR sémát veszik alapul.
Ezek a rendszerbetöltés videók ebben a YouTube listában találhatóak meg:
https://www.youtube.com/watch?v=3As5IrHArb8&list=PLTwvqf_atuc1m-hdp_qOKpxtvxD52Nygt

Tehát éppen ideje volt egy új howto videónak, amiben átnézzük az alapvető tudnivalókat és megnézzük a gyakorlatban is egy DpupBuster64 rendszer UEFI only, azaz csak és kizárólag UEFI gépre történő telepítését, itt semmilyen más lehetőség nincs, a gépen nem lehet hagyományos, legacy rendszert telepíteni.

A videóban használt EFI firmware:
https://sourceforge.net/projects/puppyszoftver/files/UEFI/

---

Tovább olvasom

A teljes puppy rendszer áthelyezése másik partícióra – videó

 

Időnként előfordul, hogy elfogy a tárhely. 

 

Bizonyára megesett már mással is. Ilyen esetekben át kell szervezni a merevlemezünket, vagy ha több van, akkor a merevlemezeinket.

Előfordul, hogy pont a rendszerpartíciónk a problémás és a komplett telepített  és már ezer éve beállított Puppy linuxhoz kellene hozzá nyúlni.

Ez az az eset, amivel senki sem foglalkozik szívesen és a legtöbben inkább más megoldás után néznek.

No, arra gondoltam, hogy erről készítek egy kis összefoglaló videót, hogy hogyan lehet egy másik partícióra áthelyezni a már meglévő rendszerünket.

Fogadjátok nagy szeretettel:

Tovább olvasom

puppyszoftver tárolónk saját weboldala

Talán kevesen tudnak róla, de létezik - van egy weboldal is ami a puppyszoftver tárolónkhoz tartozik.

Ez a cikk ezt próbálja körül járni.

Tovább olvasom

Init rendszerek és szolgáltatás menedzsment

 

Amikor unix és linux alapú rendszerekről beszélünk, szinte minden esetben a disztrókra, programokra, driverekre és játékokra gondolunk, pedig az init és a rendszerfolyamatok kezelése a rendszerek alapvető építőkövei.

Ehhez viszont nem árt kicsit átnézni a linuxos rendszerindulás folyamatát egy hagyományos – BIOS -os gépen:

A Linux rendszerindítási folyamata

1. BIOS.  A számítógép bekapcsolása után a BIOS inicializálja a képernyőt és billentyűzetet, majd teszteli a fő memóriát. Eddig a pontig a gép még semmilyen tömegtároló eszközhöz nem fért hozzá. Ezután az aktuális dátum és idő, illetve a legfontosabb perifériákra vonatkozó adatok betöltődnek a CMOS-ból. Az első merevlemez és annak geometriájának felismerése után a BIOS átadja a rendszervezérlést a rendszertöltőnek.
2. Rendszertöltő.  Az első merevlemez első 512 bájtos fizikai adatszektora betöltésre kerül a fő memóriába és a szektor elején található rendszertöltő átveszi az irányítást. A rendszertöltő által végrehajtott parancsok határozzák meg az indítási folyamat további részét. Az első merevlemez első 512  bájtját éppen ezért Master Boot Record-nak (fő rendszertöltő rekord, MBR) hívjuk. A rendszertöltő ezután átadja az irányítást az aktuális operációs rendszernek, ebben az esetben a Linux-kernelnek.
3. Kernel és initrd.  A rendszervezérlés átadásához a rendszertöltő betölti a memóriába a kernelt és egy kezdeti, RAM alapú fájlrendszert (initramfs). Az initramfs tartalmát a kernel közvetlenül képes használni. Az initramfs része egy kisméretű, init nevű végrehajtható fájlt, amelyik a valódi root fájlrendszer felcsatolását végzi. Ha speciális hardverillesztő programokra van szükség még a fő tárolóeszköz elérése előtt, akkor annak szerepelnie kell az initramfs -ben.
4. init az initramfs -ben.  Ez a program végzi el a megfelelő root fájlrendszer felcsatolásához szükséges összes műveletet: pl. megfelelő kernelfunkciók biztosítása a használni kívánt fájlrendszerhez, illetve eszközillesztőprogramok biztosítása a tárolóvezérlőkhöz az eszközvezérlő segítségével, ez lehet edev, mdev, udev, eudev, bármelyik általunk választott device manager. Ha sikerült megtalálni, a root fájlrendszeren hibaellenőrzés történik, majd felcsatolja a rendszer. Ha ez is sikerült, akkor az initramfs törlődik és elindul a root fájlrendszeren lévő init program.
5. init.  Az init kezeli a rendszer tényleges indítását és lehetővé teszi különböző funkcionalitást biztosító szintek használatát.

A démonok

Mindenkinek megvannak a maga démonai, ahogy a mondás tartja, jelen esetben viszont a szó  egy háttérben futó programot jelent, egy szolgáltatást végző alkalmazást, amit a rendszer újraindítása nélkül is le tudunk állítani, elindítani, konfigurálni. Ilyen démonok feladata a nyomtatás, a naplózás vagy akár a hálózati kapcsolat.

Az init folyamat

Amikor a kernel elindítja az init programot és az egyes számmal látja el a folyamatot ( PID:1 ) lényegében ezt hívjuk a rendszerünk valódi inicializációjának (initialization), innen a folyamat neve, egy rövidítés: init. Ez a folyamat a számítógép kikapcsolásáig jelen van és meghatározza a különféle  alkalmazások és szolgáltatások betöltési módját,  szokás szuperdémonnak is hívni, ami igen csak furcsa és mókás lehet kezdő linuxosok számára, de a fentiek ismeretében immáron teljesen érthető, hiszen minden folyamat, processz felett áll, így a démonok felett is.

Fontos, amennyiben a kernel nem találja az initet, akkor kernel pánikkal elszáll, mint a győzelmi zászló !

"Kernel panic - not syncing - attempted to kill init!"

Ezzel el is érkeztünk írásunk lényegi részéhez, hogy milyen init rendszerek és folyamatvezérlők vannak.

Init rendszerek és folyamatvezérlők, szolgáltatás menedzserek

• SysV-init: Talán érdemes az egyik legősibb inittel kezdeni, ez pedig az AT&T System V operációs rendszerének inicializációs megoldása, ahol különböző futási szinteket lehetett definiálni, tehát nem egyesével indítgattunk a terminálból dolgokat, hanem a telinit parancsot használva meg lehetett adni, hogy milyen módon működjön a rendszer és mi induljon el.
  A rendszer futása közben a futási szint a telinit vagy az init paranccsal módosítható, a kívánt szint számát paraméterként megadva:
  telinit 1 vagy shutdown now A rendszer egyfelhasználós módba vált. Ez a mód rendszerkarbantartásra és -adminisztrációra használható.
  telinit 3 Elindul az összes lényeges program (a hálózat is), a normál felhasználók bejelentkezhetnek és X grafikus környezet nélkül használhatják a rendszert.
  telinit 5 A grafikus környezet is bekapcsolódik. Általában elindul egy képernyőkezelő, mint az XDM, GDM vagy KDM. Az automatikus bejelentkezés engedélyezése esetén a helyi felhasználó automatikusan bejelentkezik az előre kiválasztott ablakkezelőbe (GNOME, KDE, vagy bármely másik ablakkezelő).
  telinit 0 vagy shutdown -h now A rendszer leáll.
  telinit 6 vagy shutdown -r now A rendszer leáll, majd újraindul.
  A default értékek az alapértelmezett konfig fájlban találhatók meg: /etc/inittab
  A SYSTEM V a wikipédián:https://en.wikipedia.org/wiki/UNIX_System_V
• BootScripts – A GoboLinux saját scriptekkel vezérli a rendszerindítást, példák a hivatalos dokumentációban: https://wiki.gobolinux.org/Documentation/Boot-script-tasks/
• busybox-init – főként beágyazott rendszerekhez használják előszeretettel, kicsi, gyors és viszonylag egyszerű is
• procd – az OpenWrt által használt megoldás, Wikipédia oldal: OpenWrt, hivatalos init scriptek: https://openwrt.org/docs/techref/initscripts
• Dinit – szolgáltatás kezelő és init system. A Chimera Linux initje és  Artix Linux -ban boot opció.
• Epoch – egy kicsi és gyors init és folyamatkezelő, GitHub: https://github.com/Subsentient/epoch
• Initng – a következő generációs initként definiálják, aszinkron folyamatindítást tesz lehetővé többek között, GitHub: https://github.com/initng/initng
• launchd – a meglévő Darwin/macOS/iOS/tvOS rendszerindítás cseréjének szánták a Mac OS X v10.4 -től kezdve, a hagyományos stílusú ‘rc.local’ scripteket futtat és a SystemStarter folyatmatot
• OpenRC – Az Alpine Linux, Gentoo linuxokban használt folyamatvezérlő és init rendszer, a Devuan és Artix Linux -ban pedig boot opció, ami izolált folyamatokat és párhuzamos futtatást is lehetővé tesz, nekem személy szerint is nagy kedvencem
• runit– egy olyan keresztplatformos, teljesértékű init rendszer, ami párhuzamos folyamatok kezelését is lehetővé teszi, a Void Linux alapértelmezett initje
• Sun Service Management Facility (SMF) egy teljesen újraírt és újratervezett rendszer illumos/Solaris -hoz a Solaris 10 -től kezdődően, ugyanakkor a régi System V-init mintájára egyedüli service -ként fut
• Shepherd – A GNU egy szolgáltatás- és démonkezelő, amely aszinkron, függőség-alapú inicializálást biztosít. Guile Scheme nyelven íródott, a projekt weboldala: https://www.gnu.org/software/shepherd/
• s6 – Egy komplett szoftver csomag, amely init szolgáltatást is nyújt többek között, a projekt weboldala: https://skarnet.org/software/s6/
• SystemStarter – A Mac OS X korábbi init rendszere a Mac OS X v10.4 verzióig
• Upstart – A korábbi init rendszer teljesértékű cseréjének szánták az Ubuntu kezdeményezésére és használták is egészen 2014 -ig. A Fedora 9, Red Hat Enterprise Linux 6 és a Google’s Chrome OS is szintén használta.
• finit – Az init a SysV init és a systemd alternatívája, eredetileg Claudio Matsuoka által az EeePC fastinitből visszafejtve: weboldal
• Hummingbird -A hummingbird egy sebességre tervezett init rendszer. Alapértelmezés szerint nem csinál mást, mint elindítja a rendszert és leállítja a rendszert: repo
• 31init  – 31 sorból álló, C nyelven írt init program: repo
• uselessd – egy olyan projekt, amely a systemd-t egy alap initd-re és process supervisorra redukálja, miközben minimalizálja a tolakodást és az izolációt. Alapvetően ez a systemd a felesleges dolgok kivágásával, repo
• cinit – A cinit egy gyors init rendszer függőségi funkciókkal és profil támogatással. weboldal
• minit – egy nagyon minimális, de teljesértékű init weboldal

Na és hol marad a systemd – a sokak által gyűlölt és szeretett megoldás?

Nos az a helyzet, hogy a systemd egy Red Hat alkalmazott Lennart Poettering és Kay Sievers munkássága nyomán jött létre és a projekt eredeti célja egy init rendszer lett volna.
A gond az, hogy mára már gyakorlatilag teljesen átvette a home könyvtárak kezelésétől, a rendszerloggolástól a felhasználók kezelésén át a hálózatkezelésig és a folyamatkezelésig szinte mindent. A dolgok jelenlegi állása szerint a projekt annyi mindent integrál magába, hogy gyakorlatilag a teljes alaprendszert átveszi, így egy kész systemd-core-os -t hozva létre, mint egy konténer image, ami mindenkinek ugyanaz lesz, ami szerintem nagyon rossz irány és ezek a fejlesztések nagyon károsan hatnak a linux rendszerekre.

Tehát már messze nem csupán egy init vagy egy szolgáltatás kezelő rendszer, ami már csak azért is problémás, mert végig a legmagasabb azonosítóval, a PID:1  -el fut, így bármilyen hiba vagy törés esetén a legmagasabb szintű jogosultsággal fut le az adott folyamat.
A másik probléma, hogy a systemd nem tartja magát a POSIX szabványhoz, ami számomra teljesen elfogadhatatlan 22 év linuxozás után, tehát számomra a systemd nem init rendszer és nem helyes a szemléletmód az ami mögötte van, így én ezt a projektet semmilyen formában nem vagyok hajlandó támogatni sem videók, sem cikkek formájában.

Köszönöm a figyelmet és remélem, hogy lesz majd aki hasznosnak találja, a végére pedig szeretnék ajánlani egy magyar cikket és egy külföldi oldalt, egy kis szakmai olvasnivaló.
Akár egyetértünk vele, akár nem, szerintem nagyon hasznos írások és mindenképpen szélesíti a látókörünket.

Kéretik elolvasni – egy igen alapos és körültekintő leírás:
https://lacyc3.eu/systemd

Végül egy olyan link, amivel én személy szerint tökéletesen egyetértek és csak támogatni tudom,
legyetek szívesek figyelmesen átolvasni az itt leírtakat: https://nosystemd.org/

Tovább olvasom

Szubjektív ajánló pupletekhez

Ez egy nocsak kolléga által készített és épp ezért szubjektív mindenkori kiinduló pont kezdőknek, akik a 0-ról kezdik az ismerkedést és nem annyira értik még a Puppy Chart -ot. A cikket elolvasva kiderül, hogy mely puppy kiadások mentén érdemes elindulni.

Tovább olvasom