Egy HW upgrade utolsó szösszenetén szeretnék túljutni. Adott egy pár éves, karbantartott gentoo ami jól működik, de tartalmaz(hat) már nem használt/rendszerszinten megváltoztatott dolgokat. Mindenből van bináris is egy hagyományos HDD-n. Eljött az idő, hogy egy sokkal gyorsabb NVMe tárolóra költöztethetem a rendszert és bár biztos vagyok benne, hogy ha simán másolnám, konfigurálnám, működne tovább, mint eddig, mégis kíváncsi lennék, hogy mások mit tesznek/tennének ebben az esetben. Friss install vagy másolás? Ha friss, akkor a meglévő binárisokat felhasználva vagy teljesen az elejéről, helyben forgatva vagy esetleg ezek keveréke? Amit változtatni szeretnék az egyedül a boot, amit uefi-stub-al fogok megoldani, de ez nem jelentős változtatás. Minden egyéb marad (make.conf, profile, stb...).
Fórumok
Hozzászólások
Simán fájlmásolással mennie kéne. Létrehozod az NVMe-n ugyanazokat a partíciókat, ugyanazon PARTUUID-vel, és rajta ugyanazokat a fájlrendszereket azonos UUID-vel. Persze az UUID-ket csak fájlmásolás UTÁN igazítsd ki. Ha nem volt speciális LUKS, LVM, RAID, ZFS, stb. móka, simán mennie kell így. Sima klónozás/dd is működik.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Megy is másolással, ez inkább gentoo specifikus kérdés és leginkább arra keresetem volna a választ, hogy más gentoosok mit gondolnak, hogyan csinálják/nák egy lényegesebb váltásnál. Sosem volt baj a klónozással vagy másolással. Mindig így csináltam eddig és azt hiszem most is így lesz :)
dzsolt
Nem, ez egyáltalán nem Gentoo specifikus. A Gentoo telepítése rugalmas, akármilyen módszerrel lehet telepíteni és bootoltatni, pont ezért nincs hozzá telepítő sem. Nálam pl. amikor volt Gentoo, systemd nélkül teleptettem, OpenRC-vel, GRUB sem volt fent, hanem UEFI EFI stub boottal bootolt a kernel közvetlenül, semmi extra boot manager, se initramfs nem volt. De Kisguczy Illésnek meg Gipsz Jakabnak meg megint máshogy fog kinézni a Gentoo telepítése, lehet ők runit-tal telepítik, vagy systemd boottal, GRUB-bal, initramfs-t használva, vagy ZFS-re, vagy akármire.
Azt írtad is, hogy EFI stub bootra állsz rá, ehhez nem is kell semmi extra, legyen egy FAT32-es partíciód, oda menjen a kernel, és az EFI bootos támogatás legyen benne beleforgatva a kernelbe Gentoo Wiki alapján, és efibootmgr-rel add hozzá az UEFI NVRAM-ba bootolási opcióként az EFI partíción lévő kernelt, megadva, hogy melyik lemez, melyik partícióját van, és meg kell adni a rootpartíciót valamelyik UUID-jét is. Nem egy nagy szám utólag sem megcsinálni. Ha ehhez a megoldáshoz folyamodsz, akkor már az sem fontos, hogy az UUID-k egyezzenek, csak akkor a bootopcióknál meg kell adni az új root UUID-t vagy PARTUUID-t, és a /etc/fstab fájlban is át kell igazítani a csatolásokat. Ez csakis a bootoláshoz kell, a többi rendszerkomponenst, init, make.conf, profile, stb. nem fogja érdekelni, hogy már másik lemezről fut, nem HDD-ről, hanem SSD-ről.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Tehát mégis gentoo specifikus! Idézem magam:
„...és bár biztos vagyok benne, hogy ha simán másolnám, konfigurálnám, működne tovább, mint eddig, mégis kíváncsi lennék, hogy mások mit tesznek/tennének ebben az esetben. Friss install vagy másolás? Ha friss, akkor a meglévő binárisokat felhasználva vagy teljesen az elejéről, helyben forgatva vagy esetleg ezek keveréke?...”
Ráadásul direkt a gentoo topicba tettem, mert ez a kérdés! Nem a boot, vagy a particionálás és semmi UUID kérdésem nem volt, az efi stub-ot már használom a laptopomon, teljesen zökkenőmentes azért nem volt (kb. 5-6 éve itt is érdeklődtem felőle) és a HDD->SSD migrálás után ez sem lesz másabb. A kérdés az lett volna az (egyébként alig létező) itteni gentoo-s fórumozóktól, hogy melyiket választanák a feltett kérdésben szereplő lehetőségek közül. A gentoo sem tökéletes, a profilok előre haladtával bizonyára akad a rendszeremen olyasmi ami visszamaradt és nincs rá szükség, használaton kívüli, esetleg csak hulladékként helyet foglal és elkerüli figyelmem. Ez egy tiszta telepítésnél ez nem kerülne az új meghajtóra. A rendszeremen egy ideje (kb. 2 éve) készülnek bináris csomagok, hogy a laptopon ne kelljen fordítani, tehát többé-kevésbé aktuális binárisok, talán ezekből is használhatnék és végül a másolásos (rsync-el amihez scriptet írtam és amikor kell mindig átnézem/aktualizálom) eljárás most is működne, mint eddig mindig. Tehát mégis gentoo specifikus, mert a kérdés maga az! A válaszod természetesen értékes és helyénvaló, de általános, nem ebbe az alfórumba illő és nem erre a kérdésre ad választ, mert a kérdés mégis gentoo specifikus!
dzsolt
Én ezt továbbra sem érzem Gentoo specifikusnak. Pont azért mondom, hogy a Gentoo pont azért Gentoo, mert nincs specifikuma. Mindenki más felállásban telepíti, más csomagokat telepít, egyes komponensekbe más USE flag-ek mentén más funkciókat fordít bele. Hiszen pont az a Gentoo egyik lényege, hogy a saját gépedhez fordul, ami Gipsz Jakabéra nem lesz jó, cserébe nem kell tartalmazza azokat a sallangokat, amik Gipsz Jakabnak kellenek, és pl. egy Ubuntu leszállítja, és mindenkire rátolja.
Én egyébként újratelepíteném. Nem azért, mert rendszerköltöztetéssel ne menne úgy, ahogy fentebb írtam, hanem ha tényleg ilyen 2 éves sallangok vannak a rendszeren, akkor simán nem árt tiszta lappal indítani. Meg mindenből frisset fordítani. Néha jót tesz a rendszernek, ha sallangmentes. Én jelenleg Arch és Artix vonalon vagyok, de használtam már Gentoo-t, sőt, mi több, pár nap múlva én is telepíteni fogom. Természetesen szín tiszta új telepítés, semmi 2 éves lom, meg régi csomag. Már csak azért is javaslom, hogy telepítsd újra, mert kernelt így is kell forgatnod, ha nem lenne benne EFI és NVMe támogatás. Másik gépen forgatással sem foglalkoznék, a Gentoo-nak az is a lényege, hogy full rolling, érdemes rendszeresen frissíteni. Igazából csak néhány csomag fordítása nagy idő, a legtöbbnek simán pár percen belül van még egy gyengébb notin is. Ilyen böngészők, LibreOffice, LLVM, glibc, húzós (ezek többjéhez pont ezért van bináris csomag is), a kernel, X.org az nem annyira, legalábbis nem releváns hardveren (márpedig NVMe-s kérdésről van szó, ami releváns hardvert feltételez). Persze ez attól is függ, hogy mit használsz, egy full KDE fordítása nyilván hosszabb, mintha csak egy szög egyszerű WM-et kéne fordítani. Ezért mondom, hogy más Gentoo userekből nem tudsz kiindulni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Azta, Raynes... Majd te megmondod Arch vonalról, egyszeri sikertelen Gentoo próbálkozással egy gyakorló Gentoosnak, hogy mifán terem a Gentoo :)
Nekem világos mi volt az op kérdése, hozzáértő tud is rá válaszolni, mert ez gentoo technikai kérdés, még érdekelne is így kívülről, hogy mik vannak arrafelé. Az is világos, hogy te nem a kérdésről beszélsz. Gentoos meg miért ne fordíthatna más gépen, ott nem kötelező, hanem lehetőség, hogy optimalizálj a célgépen fordítással 0,001 %-ot. Ne érezd már kötelességednek, hogy kívülről megmond, hogy kellene használnia a Gentoot...
Plusz simán fordítok olyan kernelt, ami a build gépen meg se nyekken, de a célgépen megy. Minek gyengébb/munka gépen szarakodni?
Köszönöm! Én is így gondolom :) Ez a gép pont a házi szerverem ami csomagokat készít a többinek (ezek vegyesek: arm, arm64(aarch64), amd64. Egy ideje már az x86-ot kivettem a listából, nincs hozzá gépem)
dzsolt
Nem, nem mondtam meg hogy használja. Ő kérdezte ki itt emberek véleményét. Én leírtam a sajátom, hogy miért telepíteném újra. Lehet nem értesz egyet vele, akkor cáfold szakmailag kérlek, ne személyeskedéssel.
Azt meg nem értem mit írjátok hogy Gentoo-s kérdés. Nincs olyan, hogy „A” Gentoo. Mindenki máshogy telepíti, és igen, pont erről szól a topik, hogy felesleges más gentoo-sokat kérdezni, mert nekik más a telepítésük. Már az Arch is erről szól, meg az összes haladó disztró, hogy nincs installer, nincs default, mindenki máshogy legózza össze a rendszerét, nem lesz két egyforma rendszer. Archon is csak annyi van eldöntve, hogy kötelező systemd init van, meg initramfs. Artix-on már ez sincs eldöntve, mert lehet OpenRC, runit, S6 init, meg initramfs nélkül is telepíteni. Emiatt két egyforma telepítés nincs, Kisguczy Illés systemd-vel és GRUB2-vel telepíti, meg KDE5-tel, ext4-gyel, Intel GPU-t használva laptopra, míg Gipsz Jakab OpenRC-vel, EFI stub boottal, GRUB nélkül, f2fs partíciókra, egy szál dwm-mel, AMD-s dedikált videókártyával használva, amire multimonitor setup van neki rákötve. Nem értem, hogy ezen mit nem értetek. Gentoo-nál már annyira egyedi, hogy még a kernel is az lesz, kidobálhat belőle az ember mindent, ami nem kell neki, és emiatt nem csak azért lesz gyorsabb, mert a procijára lesz az embernek ráforgatva a szükséges optimaliizációkkal és utasításkészletekkel, hanem mivel egy csomó feature nincs is belefordítva, már a kernelbináris mérete összemegy jelentősen. Lényegében mikor Gentoo-t teszel fel, akkor nem Gentoo-t használsz, hanem a saját egyedi igényre szabott és forgatott disztródat. Épp ezért van, hogy nektek nem tetszik, amit írok, mert az én igényeim, gépem, stb. mások, mint a tiétek, de a Gentoo pont erről szól, hogy minden igényre ráigazítható, nem Egyenbuntu, ahol ugyanazt a Gnome GRUB-systemd Snaphegyek szutykot kapja mindenki az arcába a Ubiqity installeren keresztül, ha kell neki, ha nem, mert a Canonical eldöntötte, hogy az mindenkinek kell.
Azt sehol nem írtam, hogy nem lehet célgépen fordítani, mert lehet. Inkább azt ragoztam, hogy érdemes-e. Mert az UEFI bootból és az NVMe-ből ítélve egy modernebb, relevánsabb gépről van szó, aminek feltételezhetően nem okoz gondot a Gentoo fordítása. És nem a 0,001% optimalizáció miatt nem érdemes, hanem a plusz idő alatt, míg leforgatod, meg utána még a bináris csomagokat eljuttatni a célgépre, külön feladat, főleg, minden egyes frissítéskor vergődni vele, újra és újra. Így build szerver ide, vagy oda, én nem szórakoznék ilyennel, legalábbis nem releváns hardveren. Mint írtam, pár napon belül újra fog felmenni a Gentoo nálam, most már 8 maggal gyorsabban tudok nekifutni, mint a régi gépen, ami egy 1000 éves szutyok üzleti noti volt, 2 mag 4 szál, gyertyaláng teljesítmény, órákat szüttyögött el a fordítgatással, igaz az én bénaságom is belejátszott anno, hogy többször is le kellett fordítani ugyanazt, USE flag mizéria miatt, de az is igaz, hogy magamnak nehezítettem meg a túlzott minimalizmussal, meg kezdőként azonnal nekiálltam v9999-git-es csomagokat forgatni frissességmániából. Ha egy fullos forgatást csináltam volna mindenből, akkor elsőre lefordult volna, de akkor meg a Gentoo értelme veszik szerintem oda, annyi erővel egy fullosra forgatott bináris disztrót is feltehet az ember helyette, ami igaz nem lesz 0,001%-os különbségre kioptimalizálva, de fent van 5-15 perc alatt. Azért kell az összképet nézni, meg hogy kinek mi éri meg munkában.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
...csak annyit tennék hozzá, hogy mutass még egy rendszert aminek itt van fóruma (ráadásul direkt a gentoo-ba tettem fel) és felmerül a kérdés, hogy a teljes rendszert fordítsam forrásból vagy ne, mert javarészt friss csomagokkal rendelkezik! Ez egy ubuntunál/debianál/egyéb rendszernél nem kérdéses és itt ez volt a kérdés! Illetve lehet, hogy vannak akik forrásból ubuntuznak/debiánoznak, nem tudhatom. Semmi más nem merült fel kérdésként! Csak ezért érzem ezt mégis gentoo specifikusnak. Ha szerinted ez mégis általános, hát legyen! Akkor nem gentoo specifikus :)
dzsolt
Én kipróbáltam devuant úgy. Olvasd el a blogomat. :)
Azt olvastam, soha eszembe se jutna kipróbálni :D
dzsolt
Igen, teljes rendszert forgass. Már ha engem kérdezel. Úgy értem, hogy Stage3-ból telepítve indulj ki, már csak az a hivatalosan támogatott. De nem baj, a Stage mindegy is, mert az első emerge --sync kiadásakor úgyis detektálni fogja, hogy vannak bizonyos „csomagok”-ból újabb verziók, és azokat úgyis újraforgatja, meg azok függőségét is, ha azok újrafordításra szorulnak. Legalábbis én így csinálnám, mert ha egyszer tiszta lappal kezdünk, akkor kezdjünk azzal rendesen, és ne ilyen régről maradt megoldásokkal, meg isten tudja mikor fordított binárisokkal.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Itt hirtelen beszórtál 3 hozzászólást, de csak erre az egyre reagálok, tedd be a megfelelő részeket a megfelelő helyre!
Sok fogalmad nem lehet a gentoo-ról, ami érthető ha nem ez a fő rendszered! Azok a binárisok nem régebbiek másfél hónapnál, a make.conf-ban fixen rögzített, hogy binárist is csinálnia kell! Ez az alap install valamikor 10-11 évvel ezelőtt volt friss install, de maga a rendszer friss, 17.1-es, október első hetében fordult újra 17.0-ról. Az emerge @world a teljes rendszert fordítja, pláne ha verziót is váltasz, így a csomagok frissességére nincs panasz. Lehetnek természetesen anomáliák a rendszerben, lehetnek felesleges python verziók, lehetnek nem használt, kihullott, blokkolt, maszkolt csomagok régről, de maga a rendszer aktuális és egy depclean után többnyire el lesznek távolítva a nem használatos csomagok is, kivéve a bináris csomagtárból, ahonnan a nem létező ebuild már soha nem fogja sem eltávolítani vagy telepíteni. Lehetnének korábban fordított, de azonos verziójú, azonos USE-val összeállított, viszont korábbi gcc-vel (akár csak r0-rn különbséggel) fordított csomagok is, de erre van megoldás és nálam ezek nincsenek az élő rendszeren. Ezek a fájlok egy másik háttértáron vannak, nem játszanak szerepet az installban/másolásban és bár a helyet foglalják, nem zavarnak (amíg még fér a hdd-re). Ez az „igen teljes rendszert forgass”, mondjuk úgy hogy melléütés, hiszen rendszeresen fordul a teljes rendszer, ezért rolling. Lehetnének különböző gcc-vel fordított programok, de nincsenek, ez 101% A korábban linkelt scriptet rendszeresen futtatom, minden nagyobb telepítéskor, frissítéskor, mondjuk úgy, hogy 1-3 havonta (ezért írtam, hogy 2 havonta, mert ez az átlaga) újrafordul a teljes rendszer (ez olyan 2900 csomag)! Többé-kevésbé tiszta is lehet a rendszer természetesen a fent említett anomáliákat tekintve talán mégsem teljesen az. Törött csomagok nincsenek nagy számban, ami van is leginkább a python 2.7 korlátai miatt vannak (és ami még megy arra vigyázok, hogy ne törölje a rendszer a hiányzó függőségei miatt), bár van amit néhány forráskódsor módosításával futtathatóvá tettem, írtam ebuildet az én verziómhoz és megy tovább minden. Ezeknek a régi verzióknak a használhatatlan maradványai valóban csak hulladékként van jelen feleslegesen, ezeket felesleges másolni, ezzel tisztában is voltam. Ugyanígy lehet bármi más felesleges a rendszeren, köszönhetően szintén a pythonnak, ami pip-en keresztül telepít valamit és „elfelejti” leszedni. Ezen még dolgozom, hogy a nem használt és a telepített programok listájában nem szereplő dolgokat felderítsem és kezeljem. Van még 10-20 gigányi forráskód is a rendszeren (ez pl. a kernel git és az abból származtatott verziók, fordítási maradványok javarészt), de ezek jelen esetben nem játszanak szerepet, mert ha nem cseréltem volna komplett gépet, akkor is kapott volna egy nagyobb hdd-t amire előbb utóbb át fognak változatlanul vándorolni és most épp jött a rendszerrel.
Ha az ACCEPT_KEYWORDS-ban ~ szerepel, akkor igen pörgős a rolling és eléggé (néha túlzottan) friss csomagokkal van belakva a rendszer és előfordulhat, hogy egy emerge @world után használhatatlan a rendszer, míg ennek mellőzése esetén a te szavaiddal élve, megmarad konzervatívnak. Én használom mind a kettőt, de a ~ csak egy-egy csomagnál van bekapcsolva (azt is óvatosan, -pv-vel futtatva az emerge-t), nem érvényes az egész rendszerre. Ez a gentoo nagysága, hogy lehetsz up-to-date fejlesztői csomagokkal is és stabilakkal is. A tiéd a döntés, kezedben a ~kulcs!
Tehát összefoglalva: A kérdés még mindig az volt, amit fenn látsz, nincsenek isten tudja mikor fordított binárisok, illetve vannak, de csak a binpkgs könyvtárban, ami pedig ugyan azt a szerepet tölti be, mint más rendszereken a repo csak itt helyben van. Ha olyan adódna, hogy egy 2 évvel ezelőtti stage3-ból kellene indulnom, nagy valószínűséggel a csomagok nagy részét nem kellene lefordítani, mert már(még) megvannak. Ezért is gentoo specifikus a kérdés és nem általános linux! A korábbi ismereteim alapján csak a kérdésben feltett két variáció látszott megoldásnak. Mindkét esetben ugyan az az eredmény nagyjából és most mégis egy harmadik megoldást választottam, mert olyan tippet kaptam itt amivel a jövőre nézve könnyítem meg a rendszer karbantartását. Ez az eljárás ebben a formában nem tudom, hogy más rendszeren hogyan működik, de innen nagyon is olyannak tűnik, hogy ez bármely distro esetén használható! Más distro esetén nem nagyon szokott felvetődni egy /-nak szánt ssd/hdd cserekor, hogy ugyan fordítsunk már egy *buntut/mintet/egyebet. Klónozod, másolod, letöltöd a megfelelő telepítőt és telepíted. 10-30 perc és kb. ugyanennyi darab klikkelgetés után ott ülsz a rendszered előtt és eszedbe sem jut, hogy van egy másik út. Ez volt az amire reagáltunk, hogy nem érted a kérdést, mert nem is erre válaszoltál és mivel nem erre válaszoltál arra a következtetésre jutottam(talán jutottunk), hogy nem érted a kérdést. Akkor a másolást javasoltad, most pedig a fordítást. Még mindig nem vagyok benne biztos, hogy ténylegesen érted. Semmi gond, én ugyan így lennék az összes többi rendszerrel, mert hosszan egyiket sem használtam, valahogy nem álltak kézre. Minden új lenne, bizonyára az egész koncepció is, hogy mi és miért úgy van.
dzsolt
Semmi baj nincs az igényeiddel, arra próbáltam rámutatni, hogy nem érted a kérdést. Még most sem, de elengedem, engem nem zavar, ha téged sem.
Igen, azért írtam, hogy magyarázd el mit nem értek. Mi a Gentoo-ban az a konkrét specifikum, ami miatt másik meghajtóra máshogy kell költöztetni, mint egy Archot, Artixot, Voidot, vagy akármit. Nyugodtan javítsd ki, hogy hol tévedek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Tényleg rolling, ez nem kérdés, és az, hogy 2 éves sallangok lennének? Nem valószínű, inkább 10 lesz az vagy picit több, mert rolling és nem a gentoo az a rendszer amit probléma esetén kétnaponta újrahúz az ember! Saját géphez fordulna? Persze ha valaki annyira optimalizálni akar, akkor igaz, de ez az ember nem én vagyok. Mindig mindent csak annyira amennyire muszáj, hogy hordozható maradjon!
UI: csak apróság, az első gentoo telepítésem egy VIA Epia M9000-esen volt valamikor a 2000-es évek elején, még az a rendszer is megvan valamelyik backup-ban, na az volt teljesen specifikus :) Tökéletes multimédia gép volt, egyetlen másik rendszer sem tudott annyiféle formátumot lejátszani, miközben teljes értékű desktopnak is lehetett használni! Soha egyetlen másik gépen nem indult el, még egy M10000-esen sem, annyira optimalizált volt! Akkor fogadtam meg, hogy soha többé nem fordítok csak egyetlen gépre!
dzsolt
Szerintem a régi gépek sem voltak mások. Igaz sokkal lassabbak voltak, 1 mag, RAM sem volt sok, viszont akkoriban a kódbázisok sem voltak több gigásak, meg több millió kódsorosak. Bár összességében lassabban fordult le egy komplett rendszer, de akkoriban frissíteni sem kellett annyira gyakran, mert nem rohantak annyira az új verziókkal, mint ma. VIA-s gépem nem volt, de láttam kódforgatást ilyen 486-os meg P2-es gépeken, hát az sem volt villám, valóban. Emlékszem, még 2005 táján voltam egy szegedi linuxos képzésen, ahol a csóka ilyen 2 giga RAM-os P4 Celeron gépeken tolta a gépteremben, és nekiállt az egész képzés OpenOffice-ot forgatni, na az tarkón lövés volt, voltak gépek, amik 3 óra múlva se végeztek vele.
Az, hogy mi a rolling és mi nem, azt nem a te minősítésed dönti el, hanem a csomagok frissülési mechanizmusa. A Gentoo igenis rolling, mert nincs a rendszernek főverziószáma, ugyan vannak eselect profilok, de még azoknál is, ha rendszeresen indítod az emerge syncet, akkor találni fog új csomagverziókat, a csomagok apránként újulnak meg, nem egy újabb főrendszer kiadásakor, ahogy Ubuntun, Debianon, meg a többi kiadás alapú disztrón. De ez jó dolog, már mint a rolling. Nyilván ésszel kell azt is csinálni, rolling és rolling között is vannak különbségek, hogy a frissességet milyen brutálisan tolja valaki. Vannak óvatosabb rollingok, ahol valamennyire visszafogják a verziókat kicsit konzervatívabbra, nem a legeslegújabbra frissül minden csomag.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
HA lvm -en van a teljes OS:
a /boot (sda2) es /boot/efi (sd1) particiokat hozd letre, masold at a dolgokat oda.
a maradek diszknek adj egy particiot, pvcreate <nvme particio>, vgextend <os_vg_neve> <nvme particio>
pvmove <forras diszk particoja (pv) > <nvme particio>
utana:
initrd újraépítése.
grub install az nvme -re
Soha többé lvm!!! Háztáji szerverecske ez, maradok az ext4-en... még... :) Majd a következő cserekor, vagy esetleg második nvme beépítésekor, de addig inkább csak vm-ben próbálgatok egyéb fájlrendszert.
dzsolt
Príma is az a cékettőspontbekszles alá fellapátolni mindent amúgy DOS-os módra :-P
?
dzsolt
A sohatöbbéelvéem-re írtam, mert onnan már csak egy ugrás az, hogy egy / ext4-en, esetleg egy swap partíció, aztán annyi... Ez ugyanolyan kényelmes, mint amikor LVM-re rakja az ember a dolgait, / /var /opt /var/tmp /home /srv vagy épp igény szerint szétrakva logikai kötetekre - induláskor nem kiosztva a teljes diszket(!), hogy később a szabad terültet ott tudja használni ahol kell. Igaz, ez utóbbi odafigyelést meg maszírozást igényel - viszont ha jól csinálja a gazdája, akkor nagyon kellemesen be tud állni a használatnak megfelelő kiosztás anélkül, hogy gondot okozna.
Ez a jelenlegi, de ez még változhat (illetve fog is a boot környéke)! Mondjuk ettől függetlenül csak arra tudtam gondolni az egysorosod után, hogy magadból indultál ki... és az lvm-re, igen! Soha többé! Inkább szemezgetek a btrfs-el rendszerszinten, de még nem ismerem eléggé, így előbb tanulom vm-ben! Az lvm csak kétszer szerepelt az életemben és az adatok visszanyerése egy esetben nem járt sikerrel, így köszönöm, kihagyom!
dzsolt
Mi a búbánat 51GiB a / alatt? Egyébként meg LVM-mel, illetve logikai kötetkezelést használó OS-ekkel igen.igen régóta van napi kapcsolatom - és nem a Linux-os lvm volt az első ilyen. Adatvesztés nekem kifejezetten az lvm miatt nem volt - és itt az évek alatt, ha összeszámolom, inkább ezerhez közelítő a mintaként szolgáló, közvetlenül vagy közvetve üzemeltetett Linuxos gépek száma. AMit láttam/hallottam, az vagy hardverhiba volt, vagy egyszerű pebkac. Ilyet egyébként btrfs-nél is látottmár a világ - ugyanígy pebkac/hardverhiba következtében.
Egyelőre még az üzleti világban ha Linux, akkor lvm a jellemző - btrfs-t lehet tanulni, de majd ha az lesz az alapértelmezett (nem úgy, hogy arra is telepíthető) tárhelykezelési megoldás, majd akkor beszéljünk róla.
A /usr/src 30GB. Ezt hirtelen nem tudtam hová tenni, itt nem zavar, majd egyelek belőle, mert már nem kell minden (kernel git, néhány ebuildelt kernel forrása, pár egyéb forrás). Ezek mennek vissza a sata ssd-re majd, de akartam egy reboot-ot.
dzsolt
Aminek egyébként semmi keresnivalója a / fájlrendszerben... :-P
...ha már keresnivaló: valamit a feltett kérdéshez is esetleg? Ez olyan tipikusan beszólok jellegű eddig amit eddig itt „hozzáadtál” így ha nincs a témához is, akkor nem értem mit keresel ebben a topicban...
(amúgy a /opt is 15 GB. És? Ez nem egy dataparkba szánt webszerver, ráadásul láttál egy pillanatképet miközben válogatom a maradékot. Ha csak kioktatni akarsz, fejet hajtok, megtetted, állj tovább, de itt erősen offtopic vagy!)
dzsolt
A triplafelkiáltójeles benyögések nagyon bántják a jobbérzésű emberek szemét, és igen, illendően a /opt is külön rakandó. Van "néhány" vm-em, amik darabonként ~20GB méretűek, alkalmazásszerverrel, alkalmazással, online elérhető logokkal, tok-vonó. A mindent egybe, illetve a "belefér a / alá, akkor odarakom" otthon bohóckodni talán elmegy, de -ne vedd zokon- szakmailag nem igazán jó megoldás: ha leveszed róla a /opt meg a /usr/src tartalmát, akkor döbbenetesen sok szabad hely lesz egy olyan fs-ben, ami egy full install esetén sem fogyasztana annyit.
Szóval lvm-mel pikk-pakk működne a migrálás fizikai eszközök (pv-k) között, sima partíciókra rakott telepítéssel meg azért... szóval kell mókolni némileg.
Már itt tudtam, hogy mire megy ki :)
„Príma is az a cékettőspontbekszles alá fellapátolni mindent amúgy DOS-os módra :-P”
Tudtam, hogy kár már egyetlen karakterért is egy ilyen beszólás után, de már mindegy. Szerintem itt hagyjuk abba :)
Még annyit: meghajlok előtted nagyuram, igen az LVM mindenek felett!
dzsolt
Ne hajolj meg! RedHat/Centos/Fedorabuzik megrögzött mániája ez az lvm fétis. Komolyan. Annyira tolja a pofájukba az említett disztrók mindegyike, hogy nem tudnak enélkül élni.
A RedHat/Fedora/RedHatbased/Fedorabased fanok a szakszerű szerverüzemeltetéshez nagyon értenek, kegyetlenül jogkövetőek, de a linuxhoz mélyebben fingjuk nincs.
Ha valaki előtt meg akarsz hajolni, akkor az vl, nagyurunk meg HaroldKing.
Ha meg annyira szereted zellert, mert én is szeretem, főzzünk belőle zellerkrémlevest és együk meg.
... mondjuk szarkazmusnak szántam :), leginkább azért, mert nem kívánok az illetővel ebben a témában több szót váltani, bár ahogy indított, tudtam mire számíthatok. Lekezelő, miközben a valódi kérdésről fogalma sincs, de tolja a talicskáját, mert miért ne. Van egy könyv, a gyermekek pszichológiai elidegenítéséről szól a szülők viselkedésmintáival, és ott ezt a fajta „hadviselést” a szavak terrorjának vagy lelki terrornak nevezik, és általában az alacsonyabb értelmű szülő követi el a saját gyermekén, mert a másik szülőre akar így nyomást gyakorolni. Ebben az esetben az LVM a gyerek, a többit tudod! Ez azért veszélyes, mert valójában nem rossz az infó, de olyan módszerrel akarja lenyomni a torkodon, hogy rosszul érezd magad tőle és felsőbbrendűként tekints rá, kifordulj a vitából (most és mindörökké), veszekedni kezdj, vagy fejet hajts, mindegy csak ne legyen igazad és neki igen! Sajnos az internet tele van ilyen emberekkel.
Ha valaki előtt hajlongok, akkor azt utoljára tettem, nincs vele többé dolgom!
A zellerkrémleves jöhet, finom grillezve is, de inkább megveszem és azt együk meg ;)
dzsolt
Hint: nem binugzban volt először LVM, és nem is ott kezdtem LVM-et használni (akkor Linux még nem is igazán létezett), de sebaj (sőt azt sem hozom elő, hogy van a linuxosnál szerintem jobb, átgondoltabb logikai kötetkezelő megoldás is). A gentobuzik meg mindenhova is komplett build környezetet akarnak rakni, mert nem lehet, hogy ne mindent forrásból egyedi beállításokkal csináljanak - igaz, alapvető biztonsági elvárás már elég régóta, hogy adott szerveren lehetőleg csak a feladatához szükséges komponensek legyenek - tehát egy komplett build környezet pont nem - kivéve, ha a szervernek az a célja, hogy forrásból binárist kreáljon.
Mit értesz komplett build környezeten? Azért érdekel, mert a forrásalapú disztribúcióknál gyakorlatilag a rendszer magja maga a build környezet. Tetszik vagy sem. Nem azt mondom, hogy nem lehet teljesen kioperálni, csak nem biztos, hogy az a többletmunka megéri.
Én ezt úgy értelmezem, pl egy fájlkiszolgáló és nyomtatószerver-re ne legyen téve ftp, vagy egy domain controllerre mondjuk samba.
Legyenek vagy fussanak? Tudtommal utóbbi elegendő, ha el van lehetetlenítve, hogy támadás esetén el lehessen indítani
Egy nem forrás alapú rendszernél ez nyilván való, de lfsnél vagy gentoonál már csak azért sem, mert ezek a disztribúciók nem szerverre lettek kitalálva, mint ahogy slackware sem, de mondhatnám MXLinuxot is, meg egy rakatot. Sőt, szerintem debian sem, mivel a felelősséget simán áthárítja, belépéskor a pofánk elé is tolja a magáét.
Máris odajutottunk, hogy csak a kereskedelmi linuxokat lehet csak szervernek használni. Tehát Red Hat, SLES meg uborka a canonical enterprise szolgáltatásaival kiegészítve. Az oraclet direkt hagytam ki.
"Mit értesz komplett build környezeten? Azért érdekel, mert a forrásalapú disztribúcióknál gyakorlatilag a rendszer magja maga a build környezet." - Egy SaMBa szerveren semmi keresenivalója devel libeknek, C-fordítónak, meg úgy általában komplett toolchain-nek.
"Legyenek vagy fussanak? Tudtommal utóbbi elegendő, ha el van lehetetlenítve, hogy támadás esetén el lehessen indítani" - Hogy lehetetleníted el? Ne legyen ott, az a biztos.
"Egy nem forrás alapú rendszernél ez nyilván való, de lfsnél vagy gentoonál már csak azért sem, mert ezek a disztribúciók nem szerverre lettek kitalálva"
Ott a pont: ezek játszósnak, tesztnek lettek kitalálva, semiképp nem éles üzemi környezetnek. lehet velül e-pélót lengetni, hogy bibibíííí, nekem 2 másodperccel gyorsabban lefut a foobarbaz teszt, mert emzéperix use flag helyett EmzéPerX2-vel fordítottam hajnalban, holdtöltekor, fekete kakas kukorákolása közben... :-D
Ezt pont egy redhatbuzi/szakértő kérdezi? Ott a legegyszerűbb példa az SELinux. Ha az nem elég, akkor semmi. De kár addig elmenni. Futtatásjog elvétele, tűzfal.
A nincs ott sem megoldás, mert ha már annyira meghackelik a rendszert, hogy jogokat változtat meg mi rá a garancia, hogy nem telepítik fel távolról a hiányzó szolgáltatásokat?
Egy dnf -y install vagy apt install picit egyszerűbb, mint egy emerge, sőt. Egy emergelés sokkal előbb hiúsul meg, mint egy apt vagy dnf, és nem azért, mert szar, hanem kellően fel kell paraméterezni és bármikor elakadhat egy függőségi kérdés/probléma miatt.
Én nem is mondtam soha, hogy szerverre felraknám munkahelyen. A desktop más példa. Maradjunk a nem munkahelyi környezetnél. Egy gentoo, de szinte bármelyik disztribúció nagyobb mozgásteret kínál egy centosnál. Mert RH/CentOS/Oracle meg nem desktoposnek lett kitalálva. Desktop os-en nem a guival ellátott munkaállomásokat értem.
A munkahelyement egy SL7 és egy CentOS8 szervert állítottam be két telephelyen, de eszembe nem jutna desktopra feltenni nemcsak magamnak, másnak sem. Oda inkább debian vagy Mintet (munkahely), otthon magamnak meg természetesen gentoo. Nem faszlengetés miatt, hanem a szabadságérzése miatt. Nekem ne mondja meg egy disztribúció mit használjak.
igaz, alapvető biztonsági elvárás már elég régóta, hogy adott szerveren lehetőleg csak a feladatához szükséges komponensek legyenek
Ez sajnos nagyon régóta már csak egy elméleti síkon működő biztonsági stratégia. Valójában ugyanis kb. bármilyen valós alkalmazáshoz olyan mennyiségű egyéb szart kell fent tartani, hogy nem igazán tud megvalósulni ez az elv. Oké, cc nem lesz a gépen, meg devel libek sem, de lesz egy komplett perl és/vagy python, vagy ha az valamiért éppen megúszható, akkor is lesz shell. És ezeken keresztül kb. bármit meg lehet csinálni (a pythonban konkrétan komplett szerveralkalmazást lehet röhögve írni). Ergó "baszhatod" a biztonságodat. A samba nagyon szép példa, mert az integrációi pythonban vannak írva, ergó nincs samba python nélkül. Shell nélkül meg eleve teljesen menedzselhetetlen (és full unsupportált) a géped.
Személy szerint ezen legacy üzemeltetési stratégiánál biztonsági szempontból több klasszissal jobbnak tartom a konténer-alapú koncepciót. Ott megtehetem, hogy annyira kiherélem a környezetet bent, hogy még az üzemeltetéshez szükséges dolgok sincsenek meg, mert hiszen azt meg tudom csinálni máshogy is (és mivel meg lehet tenni műszakilag, még akár a vendorból is ki lehet préselni, hogy ehhez közelítsen az általa előállított konténer image). Persze egy fos alkalmazáson ez sem segít, igazából ennek az előnyei is akkor jönnek elő igazán, ha az alkalmazás is tud alkalmazkodni egy üres környezethez (lásd pl. a go-féle "egy szál statikusan linkelt bináris" koncepció).
Ugyanezt persze chrootban is meg lehet csinálni klasszikus üzemeltetésnél, csak ott nagyjából zéró segítséget kapok ehhez, írhatom az összes toolt magamnak, plusz ugyanúgy unsupportált lesz a végeredmény, ergó csak magamra hagyatkozhatok.
Ami nem feltétlenül szükséges, az ne legyen ott. Ezt gondolom, te is "aláírod". Az, hogy csillió+1 vackot a pythondivatbuzgók eme rettenetben követtek el, az adottság, tehát sajnos a python-nak ott köll lennie a működő gépen, ha tetszik, ha nem.
"biztonsági szempontból több klasszissal jobbnak tartom a konténer-alapú koncepciót" - Én is, amennyiben a könténer megfelelően "kicsontozva" készül el. Például nincs benne gcc :-D
Az egy szál statikusan linkelt bináris az "attól függ" - lehet jó is, meg lehet nagyon rossz: elég, ha a statikusan belefordított lib lukas - amíg nincs új build, addig az adott hibát viszi magával, miközben lehet, hogy az OS-ben rendelkezésre álló dinamikus libed már javítva van. (Konténer dettó: ha 1024 éves komponensekből 1024 éve összerakott konténered van, akkor az adott szolgáltatás sérülékenységét _selődlegesen_ az fogja meghatározni, nem az, hogy az alatta lévő OS-ben mi, milyen hibát/sérülékenységet tartalmaz.
A chroot-ról egyezik a véleményünk: Zuzu, csevegés, sajtreszelő.
Desktopon is pont ugyanúgy szopás "az egész diszkem egy bazinagy / partíció" c. hozzáállás. Amikor végül sikerül megtölteni, és már egy interaktív login se megy, mert az is írni szeretne a fájlrendszerbe, akkor majd újragondolod a dolgot. A szétpartícionálás meg ugye rugalmatlan LVM nélkül...
Az elméletét ismerem az lvm-nek, de a rugalmassága ellenére sincs rá szükségem! Próbáltam, az elsővel megszenvedtem, mire úgy ahogy használni tudtam, a másodikon egy áramszünet után elvesztettem a teljes tartalmat, sosem tudtam többé felcsatolni semmit belőle. A hdd azóta is működik. Amúgy sose volt egy / rendszerem, igaz nem is daraboltam apróra. A /-en általában tudom, hogy mi és miért van. A /opt sosem volt külön, ez egy háztáji gép, nem érzem szükségét! Ez egy gentoo, sosem volt 10-20 perc alatt kész egy telepítés, nem éles szerverre megy.
dzsolt
"a másodikon egy áramszünet után elvesztettem a teljes tartalmat, sosem tudtam többé felcsatolni semmit belőle" - Ez azért érdekes... igaz, csak VM.ekre, de nem egyszer, nem kétszer volt szerencsém snapshot-ból indítani lvm-es VM-et, ami gyakorlatilag ugyanaz, mintha a konnektorból kirántottam volna a tápot, és egyszer sem volt adatvesztés. Ugyanígy fizikai gépek is kaptak a praxisomban áramszünetet lvm-mel, és azok is problémamentesen indultak el, adatvesztés nélkül. Szerintem erősen pebkac lehetett az az adatvesztés...
zellernek van igaza, csak Linuxon 12 éve használok LVM-et (én se itt találkoztam vele először), és még sehol nem láttam LVM-szintű adatvesztéses problémát (eltekinte persze a "letöröltem véletlenül az egészet - nincs undo?" c. esetektől). De még csak nem is hallottam első kézből ilyenről. Fájlrendszer szintűt láttam, többet is, és volt egy időszak a Linux életében, amikor az ext4 elterjedésekor a default beállításokkal gyakorlatilag orosz rulett volt az áramszünet (és képesek voltak megmagyarázni, hogy ez jó! "mert egy szerver alatt legyen szünetmentes" - tehát sosem fordulhat elő, hogy a szünetmentes beszarik/lemerül, hogy a táp elfüstöl, a laptopot lerúgják az ágyról, Beavis a gépteremben jár és kirúgja a tápkábelt, a kernel elcrashel, meg hasonlók, nem, ezek mind megoldhatók könnyedén...). Én anno elolvastam, hogy hogy működik, és azóta sem értem, hogy miért nem a journal_checksum,journal_async_commit,barrier=1,data=journal volt a 0. naptól kezdve a default beállítás. Nekem ilyen mount opciók mellett viszont soha nem volt ext4 problémám se.
Annak idején, talán 5 éve lehet, egyszer véletlenül került lvm a lányom laptopjára. Ahol gyorsan kellett rendszer a gépre, ott sabayont telepítettem és csak katt-katt módra lvm-be tette. Azzal ismerkedtem egy darabig, érdekelt, tetszett, aztán amikor Hamburgba kellett járnom, beszereztem egy utazós laptopot, arra már tudatosan tettem (a win virtualboxban futott, de az adatok a /home alá voltak mentve). Több hónapnyi powershell munkám veszett oda, mert ugyan céges programok voltak, a laptop nem mehetett fel a céges hálóra így csak ami éppen kellett, azt vittem át (ide-oda) usb-sticken külön engedéllyel. Egy reggelen nem bootolt többé. Az óra villogott, gondolom áramszünet volt az éjjel és hálózaton kiveszem az akkut. Még aznap kapott másik vinyót és hónapokig próbálkoztam mindenfélével (volt dd-s másolatom is, de 1000MB-t nem tárolok ha nincs értelme), de soha többé nem láttam az adatokat! Ennyi időt soha nem vesztegettem el az életemből fájlrendszer miatt!!! Amikor feladtam, tettem rá ntfs-t és ext4-et is, hogy hibát keressek, de semmi jele hibának. Most is használatban van. Értem én, hogy az LVM f@sz@ meg minden, de addig nincs baj, amíg nincs baj! ext2-3-4-ről aránylag simán lehet adatokat menteni még akár távolról is, partíciós tábla is visszanyerhető ha időben vagy, de ez ott volt 5 centire a géptől és minden elveszett ami rajta volt! És aki egyszer megégeti magát...
dzsolt
Tehát lvm, rajta virtualbox, abban futott egy windows, és oda fel volt húzva valahogy a Linuxos fs egy része, és így lett adatvesztésed, pontosabban nem tudtad a diszken lévő pv/vg/lv/fs dolgokat helyrekalapálni, és ebből neked az jött le, hogy az lvm rossz - de a jó ég tudja, hogy mi történt valójában... 2015-ben már bőven napi használatra alkalmas volt az lvm Linuxon is (ami eredetileg a HPUX-os lvm alapján íródott - ahhoz is volt szerencsém egyébként...), úgyhogy én máshol keresgélném a hiba valódi okát.
FYI: mindjárt 2021-et írunk, van btrfs meg van zfs. felejtsük már el a lvm-t...
Melyik mainstream disztribúciónál alapértelmezett fs/tárhelykezelés a btrfs vagy a zfs? Olyan jópofa, amikor itt ekézik sokan a systemd-t, hogy "mindent egybegyúrnak, fúj" - a másik meg tolja, hogy legyen egyben a storage kezelés és a fájlrendszer funkcionalitás... Ha majd ez az utóbbi összegyúrás lesz a mainstream disztróknál az alapértelmezett, akkor foglalkozok vele napi szinten, addig max. megnézem, kipróbálom, és hagyom még érlelődni.
nem alapértelmezett, de kiválaszthatod... mi a probléma? attól még production ready a zfs, amiért nem alapértelmezett...
"...hogy legyen egyben a storage kezelés és a fájlrendszer funkcionalitás"
biztos azért, mert úgy jobb... nagyon szép, hogy rétegeljük a funkcionalitásokat, csak nem biztos, hogy a legjobb megoldás
"production ready a zfs" - Igen, de nem véletlenül nem alapértelmezett.
"nagyon szép, hogy rétegeljük a funkcionalitásokat" - KISS. Minél több réteget, funkcionalitást gyúrunk egybe, annál kevésbé lesz rugalmas a dolog, és annál több lesz az a hiba/probléma, amit adott réteg/funkcionalitás lecserélhetetlensége miatt el kell viselni.
"Igen, de nem véletlenül nem alapértelmezett"
persze... főleg, hogy pl. Linus is csak szidja a zfs-t. (mondjuk mit is csinálhatna, mert ugye a zfs sosem lesz része a kernelnek)
de már régóta kínos, hogy linuxon nincs egy normális, használható filerendszer...
amúgy Fedorában btrfs a default, afaik...
#define "normális, használható filerendszer" - szerintem a legtöbb use-case mellé odarakható egy optimális fs+tárhelykezelés. Ami mindkettő akar lenni (fs+tárhelykezelés) az meg mint a svájci bicska, mindenre csak korlátozásokkal alkalmas.
Fedora... Testing/devel ágat köszi, de nem rakok production-be.
Egy csomó use-case van ahová nem jó se a zfs se a btrfs.
Nekem van zfs-em is (proxmoxon), btrfs (synology-n) és lvm-es ext4 (régebbi szerveren, rpi-n).
Nincsen semmi baj az lvm-el, teljesen jó cucc.
Gábriel Ákos
egy pár use case-t mondhatnál...
zfs over lvm... hogyismondjam... pl. elveszíted a self healing funkcióját? ami... gáz...
Mielőtt hozzáfogsz, ellenőrizd, hogy a kernelben az nvme támogatás benne legyen.
Utána, ha létrehoztad a megfelelő partíciókat, csak át kell másolni a fájlokat.
A grub.cfg-ben le kell cserélni a meghajtód uuid-jét az az új meghajtóéra. Csak akkor fog bebotolni.
Köszönöm, ez most jól jött! Várhattam volna, hogy bootoljon :) Csak modulban volt! A grub installt efi stubbal akarom, azt majd holnap.
dzsolt
helyben forgatva
Én régóta (>15 éve) használok Gentoot, és már kb. sehol semmit nem fordítok helyben. Néha, nagyritkán, ha egy-egy egyedi csomag kell, csak azon a gépen, csak ideiglenesen (mert mondjuk nincs hozzá konténer készen), akkor hajlandó vagyok ilyesmire. Egyébként minden mást az erre a célra szolgáló gépen az erre a célra szolgáló chrootban, előbb egy emerge -b, aztán disztributálást követően emerge -K a többi gépen.
Megjártam azt az utat, hogy mindent helyben, és nem, köszönöm, az már két gépnél is kezelhetetlen inkonzisztenciákat okozott (ugyanaz a csomag az egyik gépen lefordul, a másikon meg nem). Arról nem beszélve, amikor 42 csomag újrafordítása közben az egyik fordítási hibával megáll, megtalálom a releváns bug reportot, ami szerint ez most nem is fog menni, majd ha az upstream megfixálja, tehát álljunk vissza az előzőre - de az sem fordul már, mert az, ami a múlt héten még jó volt, most már nem az, egy másik random bug miatt, vagy esetleg már bent sincs a portage fában.
Köszönöm! Pont ilyen válaszra vártam! Ez egy jól működő i7 fordító szerver költöztetése ryzen7-re ami újabban állandó üzemű 0-24-ben fut egyéb okokból, de semmi kritikus service nincs rajta. Semmi nem indokolná a teljes újrafordítást, de már régen nem csináltam tiszta telepítést rajta és ugyan ez a rendszer költözött már párszor rsync-el i3-i5-i7 gépek között az évek folyamán, közben volt hdd->ssd költöztetés is. Nem „agyonoptimalizálokmindentmertazazigazigentoos” tipus vagyok, inkább arra törekszem, hogy minden gépen menjen, így most csak kivettem az ssd-t a régiből és beletettem ebbe, a boot rendbetétele után ment minden tovább. Az új háttértár vetette fel a kérdést :) Viszont! Nem chrootban szoktam fordítani, lévén minden gépemen használom az összes csomagot legalább egyszer :) Van is néha bajom belőle, de mindig megoldható és sosem okozott hosszabb kiesést, igyekszem stabilan tartani és csak egy-két ~ csomagom van. Ez érdekelne, hogy mit-hogyan ha direkt erre a célra szeretnék egy állandó chroot-ot, esetleg kettőt, egy stabil és egy ~amd64-et! Ez állandóan fut vagy csak ha szükség van rá, akkor indítod? Használok vm-eket az arm-hez, de az vm, nem chroot, ide ez praktikusabb lenne! Kérhetnék egy kis összefoglalót?
(közben az éjjel elkezdtem a friss installt, de fogok használni a már kész binárisokból, pláne a monstrumokból ahol lehet és nem túl régi)
UI: kb. 2 éve készítek binárisokat, azelőtt minden azon a gépen fordult amelyiken használni akartam és ez csak simán egy asztali gép volt ha gyenge lenne a laptop valamihez :). Káosz volt, azóta kicsit rendezettebb lett. Ha ezen túl leszek, akkor jön egy laptop csere még és akkor megszabadulok teljesen a két gép különbségeitől, akkor nem lesz kérdés, hogy az asztali (szerver, bár a hw nem kifejezetten szerverre vall, inkább gamer pc amit sosem használok játékra :) Ehhez már most ismerkedem a Catalyst-al, hogy egyszerűen készíthessek saját install rendszert a meglévőre alapozva.
dzsolt
Semmi nem indokolná a teljes újrafordítást
gcc upgrade indokolja. Kb. évente jön új stable gcc verzió (de max. 1.5 évente). És ott tartunk, hogy nem lehet nagyon sokáig kihúzni a régivel, mert jellemzően 1-2 év után kidobálják a régi gcc verziók támogatását a Gentooban. A binutils és a glibc is hasonló, vagy picit nagyobb intenzitással szokott frissülni (mondjuk évente kétszer).
Én azt szoktam csinálni, hogy 1-1.5 évente, pár hónap kivárással az új stable gcc megjelenése után (amikorra már minden fordul vele) nyomok egy tabula rasát.
Ez érdekelne, hogy mit-hogyan ha direkt erre a célra szeretnék egy állandó chroot-ot, esetleg kettőt, egy stabil és egy ~amd64-et! Ez állandóan fut vagy csak ha szükség van rá, akkor indítod?
A chroot egy könyvtár, amiben tudsz indítani mondjuk egy shellt, úgy, hogy a shell azt hiszi, az alkönyvtár a világ közepe (/). És amit ebből a shellből indítasz, az is ezt fogja hinni.
- mkdir dir
- cd dir
- mint egy normál telepítésnél, kibontod a latest stage3-at (ezt el is rakod, ebből fogod telepíteni ugyanis a többi gépet is)
- varázsolsz /usr/portage fát (latest portage tar, esetleg emerge --rsync, vagy máshonnan idemásolod - nálam naponta megy egy chrootban az emerge --sync, és azt snapshotolom szintén naponta ZFS-en)
- a /etc/portage beállításokat jól megcsinálod (hasznos gitben tárolni, hiszen ezt egy-az-egyben szeretnéd vinni célgépekre is)
- mountolsz mindenféle jókat
- chroot . /bin/bash
- emerge -b
Nálam ezek vannak a mount listán:
ez utóbbi azért van, hogy a letöltött binárisokon tudjon több környezet is osztozni (még sajnos van egy x86-os gépem is, ezért olyan build környezet is van), meg egy tabula rasánál ne kelljen mindent megint leszedni - dolgok el bírnak tűnni sajnos ezek közül a netről...
Ja, a /old.distfiles használatához env beállítás kell a make.conf-ba, különben ugye nem ott keresné.
Kb kéthavonta futtatom a check scriptemet ami nem az enyém csak módosítottam, direkt a gcc változások miatt írta annó (2006 környékén) a szerzője. Mondhatom, hogy a gcc és vonzatai nem indokolják az újratelepítést, egy-két óra múlva meg tudom mondani, hogy mi volt az utolsó gcc a rendszeren, de jelenleg az új telepítés fut :)
A chroot-ot köszönöm ;) Tudom mi a chroot, leginkább az érdekelt volna, hogy a rendszereddel együtt indítod vagy csak abban a pillanatban amikor szükséged van rá. Így olvasva azt gondolom, hogy állandóan fut nálad. Az emerge --sync nálam egy arm-es néhai tv okosítón fut és onnan kerül megosztásra a gépeim között. A fogyasztása kb 2-3W és még egyéb megosztásokat is tettem rá, erre tervezem a binárisok tárolását/megosztását is megoldani.
Köszönöm a infókat, van miből továbbgondolni a saját rendszerem ;)
dzsolt
Na nekem itt már nincs dolgom. :) Annyit kérdeznék a topicnyitótól, ha nem ragaszkodsz az agyonoptimalizáláshoz, akkor miért nem kész kernelt használsz? Gentoo augusztus óta szállítja.
ad1, nem is tudtam róla :D
ad2, megszoktam, hogy néha fordítok egyet... (na jól van, nem mindig sikerrel :P )
ad3, vissza az elsőhöz: miért ne lenne dolgod itt? Te vagy a legaktívabb gentoo-s itt :) Érdekel a véleményed!
dzsolt
Megelőztek.
Megválaszolták több részben. Továbbá ahova vl a gentoo doktora válaszol, ott senkinek nincs dolga. Ígaz ez az én véleményem, de szerintem a hupon ő a gentoo ásza. A másik talán dwokfur.
De nem gentoo témában. Nem akarlak lebeszélni róla, de ha nem okoz cseppet sem nehézséget az angol szövegértés és megfogalmazás, akkor a https://forums.gentoo.org/ a barátod. Én is szoktam oda írni, amikor fordítási bugba ütközök.
A hup tele van meleg ubuntussal, meg pár furcsa fedorással és persze nagyképű, önimádó Macfanatikussal.
Raynes azon megnyilvánulásán felcsuklottam, amikor a nem gentoo specifikus dologról írt. Most gondolkodtam el azon, hogy lehet nincs mindig igaza.
...hát ha itt követed a hozzászólásaim, akkor láthatod, hogy 2-3-4 évente jövök valamivel, mert csak :) Néha jól esik a magyar szó, de aztán évekre eltűnök. A gentoo fórumot olvasom, a német nyelvűre írni is szoktam alkalmanként, de ennek is van már pár éve. Itt még mindig hómofissz van, kissé unatkozom és újra felfedeztem a hupot. A válaszoknál pedig már megszoktam, hogy sokszor kapok válaszokat olyan kérdésekre, amit senki nem kérdezett és még magyarázatot is hozzá, hogy márpedig odavágó az és jó lesz nekem! Jókat derülök, nem bántódom meg csak néha értetlenül állok az eset előtt, mert ezek az emberek szentül hiszik, hogy igazuk van! Legyen nekik! Nem a gentooból élek, de az itthoni gépemen ezt használom, mert ezt szoktam meg.
Jah! A rendszerem frissen tartására aktívan használom ezt:
https://forums.gentoo.org/viewtopic-t-494331-start-0-postdays-0-postorder-asc-highlight-guenther.html
Jótékony hatása miatt soha egyetlen gcc upgrade sem okozott fejfájást és volt egy több éve nyugvó elmentett állapotú img-m, amit simán frissítettem vele.
dzsolt
Nem olvastad el (alaposan) a blogomat. 33. pont.
https://packages.gentoo.org/packages/sys-kernel/gentoo-kernel-bin
Ha ragaszkodsz saját kernelhez, akkor is okos dolog ennek a megléte. Sikerült nekem is olyan okosan kernelt fordítanom, hogy sunyin fagyogatott az xorg és a kernelt basztam el, persze míg rájöttem volt pár felesleges köröm.
Igaz, nem olvastam el :( Illetve most már igen. Nekem is megvannak a gyorsító eljárásaim, hasonlóak a tiédhez, ráadásul scriptekbe rendezve (egyúttal ez a check lista is). Viszont a kernel más tészta, azt szinkronban akarom tartani az arm vonallal, ezt már említettem talán. Azért ha másért nem, a konfig miatt ránézek :)
dzsolt
Mondhatom, hogy a gcc és vonzatai nem indokolják az újratelepítést
Persze, egészen addig, amíg meg nem tapasztalod, hogy ha egy program egyik részét az A) gcc verzióval fordítod, a másik részét meg a B) gcc verzióval, majd ezt egy program formájában szeretnéd futtatni, akkor az erősen kétesélyes, hogy lesz-e ebből egyetlen működőképes program. A leginkább látványos példája ennek, hogy a kernelbe modult betölteni nem triviális, ha nem ugyanaz a gcc verzió fordította őket (leginkább ugyanazokkal a flagekkel), de más binárisan pluginezhető programoknál is lehet lyukra futni így, a C++ kiemelten problémás.
hogy a rendszereddel együtt indítod
Nade mit indítanék ott? Egy shellt? A háttérben, csak hogy fusson ott valamit?
..olyasmi. Arra gondoltam, hogy előre (f)elkészített chroot amibe azonnal bejelentkezhetsz vagy mindig összeállítod amikor éppen kell. A telepítés chroot-ja stage3-al indul, amiből később lesz aktuális rendszer. Készíttetsz rendszeresen stage3(4)-at az aktuálisról, vagy akkor készül amikor épp használni akarod? Ilyesmikre gondoltam.
Amúgy Günther szkriptje amit feljebb linkeltem pont azért jó, mert nem lesz ezerféle lefordított bináris, mindent lefordít azonos környezetre, többnyire még azt is amin az emerge @world elhasal (nagyon néha előfordul, hogy elakad)
dzsolt
előre (f)elkészített chroot amibe azonnal bejelentkezhetsz vagy mindig összeállítod amikor éppen kell
Hát ugye ha szeretném tudni továbbfejleszteni a rendszeremet (értsd: az adott .tbz2 halmazból telepített gépeket updatelni per package), akkor azt a chroot környezetet, amiben ő fordult, igencsak praktikus megtartani. És ezt is szoktam vele csinálni. Plusz snapshotolva megvan pár régebbi állapot is, ha vissza kell állni, mert zsákutcába jut a frissítés (pl. glibc-t nem lehet downgradelni, ha utána valami nem fordul az új glibc-vel, akkor ugye vagy megvárod féllábon ugrálva, míg megfixálják, vagy visszamész egy olyan állapotra, amikor még nem volt a glibc upgradelve).
Készíttetsz rendszeresen stage3(4)-at az aktuálisról, vagy akkor készül amikor épp használni akarod? Ilyesmikre gondoltam.
Nem, ilyesmivel egyáltalán nem szórakozok. Az adott chrootból a hozzátartozó, eredeti stage3 lesz az, amivel egy új telepítés indul, amibe rögtön belemegy az aktuális portage tree + .tbz2 halmaz. Az aktuális stage3 is lehetne, csak ugye akkor kéne arra ügyelni, hogy semmiből ne legyen nálam régebbi - ami sokszor nem teljesül, mert jó pár package frissítése nálam kézzel van kimaszkolva (pl. python, php, boost).
Ja, még egy dolog, amikor teljes újrafordítás van: profilváltás. Én most őszig húztam a 17.0->17.1 váltást, ami igazából egy reinstall mindenképpen.
17.0->17.1 váltást októberben csináltam, ezért gondoltam, hogy elég friss a rendszer egy másolásra :)
Hogy miért is kérdeztem a stage előállítást és, hogy fut-e mindig. Most ismerkedem a catalyst-al, ugyan főként livecd/dvd-re, de készíthető vele aktuális stage és azt hittem, hogy ezzel vagy ilyesmivel az aktuális rendszeredből előállított működő chroot-ban fordítasz. Amúgy igen, pl. python2.7, van még pár alkalmazásom ami 2.7-et használ, most épp nem is tudom hirtelen, hogy mi lesz velük. Jó lenne mindtől megszabadulni, de van ami jó lenne ha megmaradhatna. Persze megoldom, mint általában csak ez most megint valami új lesz és öszvér megint.
dzsolt
Igen, azt hiszem, a workflow-m nem volt elég jó definiálva: a chrootban van "az" etalon rendszer, ebből készül mindegyik gép (az is, amin ez az egész fut - nyilván itt volt egy tojás-tyúk probléma, az első host még nem így készült). Ebben csinálom később a frissítéseket (folytatom onnan, ahol tartottam), amiket aztán terítek, és amikor néha nulláról újrakezdem (ez a tabula rasa), akkor az egy teljesen új chroot etalon rendszert fog jelenteni, új stage3-ból, amiből aztán emerge -Kve world útján tudnak frissülni a többiek (akiket nem törlök és nem telepítek újra az aktuális stage3-ból) - meg a host maga is.
A python2.7 egyértelműen eljutott a szopásfaktort jelentő állapotba, nálam 4 python csomagból már custom ebuild van, mert kell a 2.7-es megmaradt cuccokhoz...
Nos, ez egy teljesen más megközelítése a telepítésnek, mint ahogyan eddig csináltam és tetszik :) Megcsináltam a chroot-ot és nulláról kezdett a még működő korábbi rendszerem alatt (igen, másoltam, mert menet közben bontakozott ki, hogy ez a módszer célravezetőbb). Nem folyamatosan fut, az elején tartok, mert a gép még holnapig kell a home-office miatt (semmi komoly dolga nincsen csak azon vagyok bejelentkezve állandóan. Igazából a jelenlétet várják el, nincs semmi egetverő munkánk már idénre). Szóval chroot: a make.conf is az alap (kis kiegészítésekkel), mert ha az enyém beillesztem (ami az évek alatt szépen meghízott) akkor gyakorlatilag emerge @world @system futna le. A korábbi binárisokat most nem próbáltam meg újrahasznosítani még.
Egy pár kérdésem volna hirtelen:
Amikor tiszta lappal kezdesz, mikor illeszted be a szokásos make.conf-od? Mehet rögtön az elején vagy előbb készítesz egy tiszta alapot és arra engeded rá a teljeset? Sok USE van nálam beállítva a make.confban, de mivel lehetne ezt a package.use/mask/unmask alatt is kezelni, érdemesebb-e ott és a make.conf-ot amennyire lehet kigyomlálni? Jelenleg sok a tiltás/engedmény benne és a package.use/mask/unmask alatt bírálom felül illetve a megengedetteket is ott veszem el. Igazából láttam már annyiféle /etc/portage variációt, hogy eldönteni is nehéz, melyik a kézreállóbb. Legutóbb a Redcore-t néztem és az egész jól összeszedett :)
Melyik pythont használod single targetnek? Nálam még a 3.7, de látom, hogy időközben 3.9 is stabil lett. Ugyan le van fordítva, de legutóbb azért még voltak vele problémák amikor próbáltam.
Nagyon régen csináltam már nulláról mindent.
dzsolt
mikor illeszted be a szokásos make.conf-od?
Rögtön az elején. És emiatt van is egy kezdeti lépés, aminek keretében azokat a csomagokat újrafordítom (1 vagy több lépésben), amik részei a systemnek, de annyira eltekergettem a default beállításaikat, hogy az emerge -1be system nem futna le elsőre jól, vagy berántana minden szart (pl. samba, mysql). Ez 2-3 emerge parancs, jellemzően valami env változóval felülbírálva a use-flageket, és kb. 30-40 csomaghoz hozzá fog nyúlni.
Az egyik ilyen gond pl., hogy a libva környékén van valami körkörös dependencia, ami miatt több csomag közül egyet le kell fordítani a kívánt use-flagek nélkül (azóta se értem, hogy ezt hogyan gondolták). A másik gond, hogy mivel nálam +ldap flaggel fordul csomó minden, ezért a system része az openldap, amihez viszont kell a db csomag, de a db formátuma verziófüggő, ezért le van fixálva, hogy melyik verziót használja az openldap (ha hagynám a latest verziót, akkor minden upgrade-nél állandóan figyelnem kéne, hogy ne baszódjanak el a futó példányok, mivel db.so - és így db formátum - upgrade esetén előtte mentés - utána visszatöltés kéne) - ami nyilván régebbi, mint amit a stage3 hoz magával, hiszen nem szeretnék évente többször az ldapok alatt formátumot váltani. (ez majdnem akkora vicc, mint bármelyik microsoft termék, tiszta wtf életérzés...)
Sok USE van nálam beállítva a make.confban
Oda az ember a defaultokat rakja. Ha valami default on vagy off, akkor csak az eltéréseket kell a portage.use alá rakni. Ha valami feature-t csak egy-két programban akarsz használni, akkor nem kell default on-ra rakni.
Melyik pythont használod single targetnek?
Nálam általan egy 3-as python van használatban egyszerre, hát azt. Eddig volt még egy 2-es is, de ez lassan ugye ki fog halni. Akkor váltok pythont, ha már minden modul fordul hozzá. Ez általában 1-2 hónap minimum a stable jelzés plusz a profilban a default target flag átírása után.
A cirkuláris függőségi problémák nem újdonság, többek között ezek relatív gyors megoldására világít rá Günther (korábban linkeltem) topicja a gentoo fórumon, igaz a gcc frissítés kapcsán. A leírásai és a scriptjei sok munkát spórolnak meg nekem a mai napig. Az ő gcc frissítő scriptje generál egy másikat, ami a teljes rendszert újrafordítja --oneshot kapcsolóval a megfelelő sorrendben mindaddig amíg a teljes rendszer rendben nem lesz. Sokszor előfordult, hogy az emerge @world vagy @system elhasalt és ezzel fejeztem be (illetve mindig lefordítja az összes csomagot), bár a körkörös függőségeket ő sem tudta teljesen kiküszöbölni sajnos.
Én most elkezdtem egy „üres” make.conf-al, semmit nem vettem bele a fordítási kapcsolókon kívül és alapon python 3.8-al kezdett. Beleraktam a régiből amit feltétlenül muszáj és beállítottam a 3.8-at single_python_target-nek. Remélem nem lesz gond. A régi telepítést húzom-vonom vagy 10-11 éve, most itt az ideje, hogy átálljak a mostani divatos /etc/portage rendszerre, mert az utóbbi már eléggé misch-masch volt.
Szóval nem lesz azonnal kész, mint terveztem, de az llvm fordítása nem volt 10 perc sem, pedig a régi vason (egy elég régi i7, 16GB RAMmal) majdnem egy napig tartott, így azért ez kényelmesebb :) Ennek a chroot-os rendszerépítésnek örülök, eddig mindig az élő rendszeren frissítettem, ezennel ez megszűnt (az összes problémájával együtt), ezt nagyon köszönöm!!!
dzsolt
Én egy 4670-es Haswellen fordítok, 8GB-nál több memóriát még -j4-gyel sem használ a fordítás. Viszont van pár csomag, ami irreálisan sok idő alatt fordul (pl. a qt-webengine, vagymiaszar - nyilván lakik benne egy komplett webbrowser, értem én, csak a francért nem tudják valamelyik browser engine-t .so-ból használni).
Ha jól tévedek, az valami chromium származék. Én a QTWebFlix-nél kutattam utána kicsit,kellet volna valami hasonló YT-hoz ami winen is használható. Még nyitott a kérdés :)
dzsolt
Még egy kérdés: van valami módja, hogy a rendszer ne is keresse a gnome-keyringet? Jó lenne már telepítéskor elkaszálni, hogy ne minden alkalommal eltávolítani kelljen :) Értem én, hogy jelszó meg biztonság, de teljesen más megoldást használok a jelszavak kezelésére ezt pedig mindig -C-vel díjazom. A következő nagyobb emerge meg mindig visszateszi.
Még valami, vannak layman-al telepített repok a régi rendszeren, az új nulláról indított rendszeren ezeket te hogyan kezeled/néd?
dzsolt
Még egy kérdés: van valami módja, hogy a rendszer ne is keresse a gnome-keyringet?
Nem értem a kérdést. Még sosem használtam/láttam ezt a cuccot. A nevéből sejtem, hogy mire lehet jó, de kb. ennyit tudok róla.
Magam sem tudom, hogy mi volt ami „kívánta” magának, de ha a make.confban USE -gnome-keyring, akkor megáll a tudomány. A chrome, chromium aktívan használja. Eleinte csak egyszerűen letiltottam, hogy ne induljon el, de egy-egy frissítés után jelentkezett megint. Azóta emerge -C, de ez is csak a következő frissítésig jó, viszont így legalább addig nem jelentkezik. A desktopom Mate, nem is értem, hogy miért települ. Most ahogy áthoztam a /etc/portage/-t (pedig nem egy az egyben másoltam, igyekeztem válogatni), megint felütötte a fejét :(
Mindegy, majd kigyomlálom.
Más. Van egy régi installom (arm32). Csináltam róla egy listát, hogy mik a telepítettek. Van valami egyszerű módja, hogy összehasonlítsam az új portage-val (mármint, hogy mi minden tűnt el a portage-ból a telepítés óta) az cat package_list | emerge -pv-n kívül :) Csak statisztikai kérdés (kíváncsi vagyok, hogy mennyi minden és mi változott), nem lesz frissítve soha többé. Ha megáll, megy a kukába, nincs napi használatban amióta vannak 64 bites arm lapjaim (van másik 32-es is, de az folyamatosan karbantartott).
dzsolt
Bocsánat. Egyszer régen mégiscsak kellett, hogy találkozzak a problémával. Csak olyan régen volt, hogy már elfelejtettem.
Ő lesz az:
Van valami egyszerű módja, hogy összehasonlítsam az új portage-val
Persze: emerge -pve world
Amúgy az a tapasztalat, hogy 3-5 évente van olyan szintű változtatás, aminél törnek a dolgok. Ha ezt a változtatást "átalussza" a rendszered, akkor pár újabb év után már a váltáshoz szükséges támogatás is elmúlik a rendszerből, és akkor egyáltalán nem tudsz a régi állapotból az aktuálisba frissíteni, csak ha valahonnan szerzel egy évekkel korábbi portage fát, és csinálsz egy közbülső frissítést. Ezeket a váltásokat onnan lehet felismerni, hogy ilyenkor vannak részletes útmutatók, hogy hogyan kell a régiről frissíteni, milyen toolokkal milyen sorrendben milyen lépéseket megcsinálni.
Bakker, és tényleg! Nekem a gtk benn maradt :( No még egy rund :)
Arról a régi rendszerről csináltam egy listát és azt hazudtam az aktuálisnak, hogy ő a régi eix, így az eix-diff segített. Ez már nem fog frissülni, egy régi gyakorló arm sbc volt/van. Nyomtató szervernek használtam egy usb-s nyomtatóhoz, mert hiába van rajta hdmi, nincs az X-hez drivere. Mindenre jó volt, ahol elég volt az ssh vagy a tty csak azóta vannak már jobbak itthon.
Most már csak az nvidia van hátra, a többi szépen a helyére kerül apránként, de ez nagy menet lesz. A quadro 450s valami régi 3xx drivert kívánna, amit meg én nem, mert a fő kártyám meg azzal nem megy. Sosem volt ilyenem eddig. Mehet 2 X-szerver egyidőben úgy hogy az egyik a nouveau a másik az nvidia? Alapból blokkolni szokták az egyiket, hogy a modul be se töltődjön. Még nem próbálkozom, most fordítás folyik még csak infót gyűjtök.
dzsolt
Azért van árnyoldala is. Nem blogoltam róla, lehet nem is fogok. VL lehet nem olvastad azt a blogomat, azt kell tudni, hogy nagyon szépen szét vannak szedve a konfigurációs állományok. Tehát a make.conf...package.use...package.mask... etc nem fájlok, hanem könyvtárak, amikben egy egységes logikát követve gyönyörűen tagolva vannak a konfigurációs állományok. Ez a tagolás egy humanoid számára tök jó, átlátható, de itt jön a de. Ugyasnis a portage egy buta egyszerű jószág, neki nem sikerül átlátnia ezt a logikát és ha egy telepítést vagy frissítést szeretnél eszközölni, kérheti a függőségi problémák miatt az alábbi telepítendő/frissítendő csomagok use flagjainek megváltoztatását. Ha ráböksz az általa javasolt módosításokra, akkor az az állat nem az adott konfigurációs fájlba teszi bele, hanem valami általam érthetetlen logika alapján tök nemodaillő helyre teszi, és a csavar az egészben az, hogy az ezálltal két helyen két példányban van megadva egy egy csomag use flagje, de csak azt veszi figyelembe, amit ő írt bele és ahova. Én meg, ha nem nyálazom át alaposan és úgy állok neki use flageket változtatni nem értem, miért nem veszi figyelembe, mert azt a fájlt lesi, amelyikbe ő hányt bele egy kurvára nemodaillő helyre.
pl: /etc/portage/package.use/00-media-libs.package.use fájlban az alábbi bejegyzés van: media-libs/libsdl2 -gles
Közli a portage, hogy kell a gles2, nyomok egy etc-updatet azán beteszi a media-libs/libsdl2 gles sort,de a 00-sys-apps.package.use fájlba úgy, hogy ott maraf a media-libs fájlban is az ellenkezője. Na itt kezdődik a bonyodalom. Ha ennyire lüke a portage - nem azt várom el, hogy megfelelő fájlba tegye, de - hogy nem képes kivenni a nemtetsző változatot amiatt értetlenül állok.
Ha ráböksz az általa javasolt módosításokra, akkor az az állat
Nehéz ezt a labdát nem lecsapni: aki így tesz, az az állat... :D
Szóval nem, semmi szín alatt nem engedem meg egy programnak, hogy a beállításokat eltekerje. Azok azért vannak, mert van mögötte egy koncepció, ha pedig emiatt lyukrafutás van, akkor a koncepciót újra kell gondolni - és ezt egy ember tudja megcsinálni, a gép nem. Aki ezt az energiát nem akarja belerakni, annak jó lesz az Ubi is, várják sok szeretettel :D
Pl. tipikus, hogy egy programnak dependenciát jelentő libből ugyanolyan flag verzió kell, mint amilyen ő maga. Tehát ha randomappnak van egy samba flagje, és kell neki a librandom könyvtár, akkor nem jó neki, ha az -samba, ha a randomapp meg +samba. Na ez nálam akkor fordulhat elő, ha explicite beraktam egy tiltást: librandom -samba, és amúgy a default +samba. Viszont ennek ekkor oka van, és valószínűbb, hogy nem a librandomot változtatjuk meg, hanem vagy a defaultot (-samba az egész gépre, mert ráuntam, hogy mindenre külön -sambákat kell mondani), vagy pedig a randomapp lesz -samba.
Szóval nem feltételenül jó az, amit a tool javasol.
Tudom. De csak hogy tudd. Háromféle gentoos létezik.
1. Konfigmásoló robot
2. Agyatlan vagy igénytelen kocka, aki megelégszik egy ratyi ablakkezerlővel, akinél egy fluxbox/blackbox már bloatnak számít az afterstep meg a fapados asztali környezetek kde-je, továbbá nem használ a tömeg által hasnált összetevőkből semmit pl initramfs vagy másnéven initial ramdisk, ismerős kockaúr? :P
3. Ez egy új jelenség, egy új állatfaj, ami csak néhány éve ütötte fel a fejét. Én úgy hívom őket: Violetta gentoosok. A Violetta egy argentin filmsorozat. Abban különbözik a hagymányos fröcsögős brazil szerelmes szappanoperáktól, hogy ez nem épelméjű felnőtteknek, hanem 10-12 éves csitri csajoknak szól. Jó azért bevallom az összes rész nem láttam, szégyellem is magam miatta, de azért is nézek ilyen szarokat, mert bele akarok látni a kislányok fejébe, mert sok gonosz van köztük.
Egyszer egy kis tíz éves dagi „dög” egy kora esti bálban – ahol büfés szerepet vállaltam – leült mellém, amikor nem volt semmi, megkérte az anyja, hogy foglalkozzak kicsit vele és beszélgetés közben megfogta a combom. Rászóltam mit csinál, erre azt mondta, hogy ugye tudom, hogy bajba kerülhetek. Mondtam Neki ezért ne csináljon mókából ilyen hülyeségeket. Szóval Stalmant megértem, hogy védi a pedofilokat. Az a baj, hogy simán lehet egy felnőtt ilyen áldozat. Mert a szegény kislány, hisz csak egy ártatlan gyerek. Aha! Egyre több a sátán ivadéka. Fosok is a kislányoktól. Szörnyűek. Ezért próbálok a fejükbe látni és nézek idióta csajos meséket. Eddig nem jártam sikerrel. Szerintem Haroldking saját programnyelvén írt kódját is előbb megérteném.
Valószínű ezért hisztizek meg fröcsögök ennyit. Visszatérve Violettára van kötődése a Unixhoz. Beszarás. Így hívják a sorozatban a zenei kiadót.
Szóval én violettagentós vagyok. Hisztis királykisasszony. És Te beszóltál egy ilyennek. Nem félsz?:P
A violettagentósok szeretik a külsőségeket a csillivilli szarokat. Én Mate desktopot használok compizzal, emeralddal és cairo dockkal. Poénból van fent egy cinnamon windows 10 témával. Ezen felül bluetooth támogatás spotify meg multimédiás szarok. Remélem már belső vérzéseid vannak a kíntól mivel gyalázom gentoot, mert egy igazi gentoos a kiss elvet követi, mint a zakkan slackisek meg wannabeekiddie archosok. De én nem.
Nálam a kiss elv az, hogy szó szerinti angol→magyar fordításban értem. Tehát akinek nem tetszik az anti kiss elvem, annak nyelvét várja a seggem.
Ánuszrózsámra jöhet a KISS,
kinek nem tetszik, annak KUSS.
Most már érted mi az a violettagentoos. Olvasgasd a nem szakmai blogjaimat és megérted.
Csakhogy én is egy pöttyet visszaszóljak. Minden tiszteletem a 15+ év alatt megszerzett hatalmas tudásod miatt, de lehet van amit azért nem tudsz a genttoról, mert faék egyszerűen használod.
Upgradelj egy redcore linuxot vissza gentoora. Én megcsináltam. Aki ezt végig csinálja, az portageből csillagos ötöst érdemel, mert az azt jelenti, hogy kurvára megtanulta.
Amit írtál, meg dzsolt is a 17.0->17.1 profolváltást, hogy mekkora meló volt. Hmmm.
Én tavaly megcsináltam a szerveremen, az asztali gépemen és a laptopomon is. Csak mondom, hogy mindhárom gép teljesen más profilt használ. Mindegyik zökkenőmentesen sikerült és nem tartott olyan sokáig, mert nem forgattam újra az egész rendszert. Ezt a hivatalos útmutatót követtem. És azóta is tudom frissíteni a rendszert. Kisebb fennakadások voltak ugyan, de nem hinném, hogy emiatt. Az asztali gépemen ráadásul hardened profilt használok és valamiért fent volt akkor a kde is, és úgy váltottam profilt és úgy is sikerült. Na ez az amiben én lehet jobb vagyok Nálad, persze ez alatt nem azt értem, hogy az én tudásom megközelítheti a tiédet, mert biztos nem, viszont valamit én is tudok. Nagyon okosan NagyZ beszólt nekem egyszer, hogy ő szégyelli magát, hogy spotify meg bluetoot feltelepítést én linuxhoz értésnek nevezem. Hát kurvára, mert ezt ubuntusok fedorások soha nem fogják megérteni, hogy nem egy apt install / dnf installt aztán kész.
Látod mekkora foshalmazt zúdítottam Rád, mert beszóltál egy trollszerű képződménynek?
Máskor ne tedd! ;)
Bakker, te lemásoltad a desktopom :) Mate/Compiz/Cinnamonn W10 bőrben (fogalmam sincs mióta, de szerintem azóta, hogy van gnome3. A cinnamon pedig a Schülerlkonto-m, azaz az iskolai dolgok futnak rajta ha éppen kell. Így ha valakinek mutatnom kell valamit, nem érzi magát annyira elveszettnek még a különbségek ellenére sem)! Pont, mint nálam (illetve a laptopon a w10 bőr a mate-ra van húzva, de a mostani fordítás után ejtem, mert nem tökéletes :D
Amúgy nem írtam, hogy nagy meló volt a 17.0->17.1 váltás. Azért halogattam addig, mert mindenről készül bináris is és elviszi (vitte) a gépem teljesítményét ha hamar össze akarom rakni. Nekem a fordítógépem az egyetlen asztali gépem is egyúttal amit használnom kell munkára is! Ilyen váltásokat akkor szoktam megejteni, amikor van 4-5 nap pihi és akkor volt. Ez csak ezen múlott.
Viszont ilyen más rendszerekről vissza/előre lépni a gentoora, na arra nincs időm. Ha gyorsan kellett egy install, akkor Sabayon, de már az sincs pár éve, mert a lányom eladta a laptopot az asztalin meg W10 van nála.
Még annyit akarok tisztázni, hogy nem geekségből vagyok gentoo-s. Egyszerűen nem tudom, hogyan működik a többi! Valaha volt mindenféle a gépeimen, hol ez, hol az. Debian, RedHat, Suse, UHU. Live lemezről kipróbáltam másokat is, sőt virtualboxban a RedCore vagy mi, azt is. A laptopon első körben Sabayon futott, innen az ismeretségünk, de vannak korlátai. Ma már a kaputelefonon, NAS-on, routeren is gentoo fut, bár ez utóbbit szívesen cserélném Padavanra csak előbb legyen kész az asztali teljesen. Idő. Csak idő kérdése. Kb ennyi az én gentoos történetemnek.
Szerintem aki nem gentoozik, ugyan így van csak a saját kiismert rendszerével. Ez csak ennyi...
dzsolt
VL írta és nekem furcsa, hogy pont neki okozott ez nagy melót.
Én sem. De én veled ellentétben 15 év alatt az öszes nagy disztribúciót végigpróbáltam, és még számos kisebbet is. Igazából a debian vált be, de amióta eleget tesz bizonyos megfeleléseknek, azóta nem használom. Erre tavaly a szivárványozással és az idei linus utálattal megpecsételték sorsukat.
Röviden annyi, hogy ezt a szabadságot csak a forrásalapú disztribúciók adják. Az LFS mégjobban megadná, de az már életrabló, ha valaki minden használt összetevőjét folyamatosan frissen tartaná.
Elmúlt 15 év? Na ebben az elmúlt 15 évben nem nagyon nézegettem már őket, maximum egy-egy liveCD/DVD-t. Azért ne hidd, hogy lemaradtam teljesen, de nekem az összes többi sokkal nagyobb munka lenne, mint ez valaha volt!
dzsolt
Ha hiszed ha nem, amit itt ketten dzsolttal irogattatok, ha ezt elolvassa egy ubuntus, minket fognak hülyének nézni, hogy miért nem ubuntut használunk.
Miért is? Én sem nézem őket hülyének, hogy miért nem gentoot használnak! Ez nem egy verseny vagy meggyőzés topic, nem a gentoo áll mind felett vagy fordítva.
Akinek ez a fontos, hogy „rád erőszakolja”, hogy mit használj annak kb. mindegy, hogy mit használ. Mindenki legyen boldog azzal amije van, ismerje ki/meg és éljen annak a lehetőségeivel. Az ilyesmi hitvitákból kihúzom magam, nem nekem találták ki.
dzsolt
Ez szép. Nem is ezt írtam, hanem hogy Téged vlt meg engem néznek hülyének a nem gentoosok, hogy miért egy ilyen "időrabló" rendszert használunk.
Időrabló lenne? Nekem az lenne időrabló, ha azt ami nem megy *buntu/egyéb alatt, windowson kellene megoldanom! Ez alól kivétel a játék! Ha valaki játszik, ott legritkább esetben elegendő bármelyik linux. Egy ideje sajnos nekem is kell a windows is. Ha a googlenak megfelelt a ChromeOS-hez, vagy a CoreOS, FlatCar megfeleőnek találja a gentoo-t, mint bázist, akkor jó lesz ez nekem is. természetesen ezek a rendszerek az itteni közösségben nem sűrűn ismertek, talán fogalma is csak keveseknek van ezekről a rendszerekről és arról meg még kevesebb, hogy miként jöttek ezek létre. Ez csak a jéghegy csúcsa, vannak még itt szintén nem túl ismert disztrók amik a gentoo bázisra épülnek, de ki figyel itt minden apróságra ;) A RedHat kihúzta a CoreOS alól, érthető is ha van egy bejáratott builder környezeted amit egyébként kereskedelmi forgalomban tartasz, így ez egy logikus lépés volt részükről. Igaz az is, hogy évekbe telt nekik és a felhasználók jelentős része az inkompatibilitás miatt FlatCarra váltott! Amúgy ha valaha azon törtem volna a fejem, hogy csináljak belőle valami éles produkciós szervert, akkor megkapta volna a Nix-et vagy az equo-t csomagkezelőnek és kiszedném alóla a dev dolgait, mert megteheted! Nem kell mindennek benne maradnia, ha célirányosan egy terjesztést szeretnél belőle. Csak ugye én hobbista linuxos vagyok, nincsenek ilyen vágyaim és egyedül talán meg sem tudnám oldani (De! Sem a kaputelefonon, sem a routeren nincsenek dev csomagok, sőt semmi sem. A komplett rendszert kell frissíteni egyben, mint a CoreOS esetében ami amúgy nekem nagyon tetszik! Lehetne csomagkezelést belevinni, de ezek célgépek, nincs rá szükségük illetve a routeren néha jól jönne, így oda padavan-t szeretnék. Ami egy köztes lehetne az a Libre/CoreElec féle megoldás ami szintén felépíthető gentoo alapokon, szóval a lehetőségek határtalanok csak egyedül ugye nincs mindenre időm)... Ezt a legtöbb más linux terjesztést használó át sem látja, fel sem fogja, nem is tud róla csak azt veszi észre, hogy a gentoo macerás (nekik).
dzsolt
Arch májsztereket nem értem. Nekik kis lépés lenne a Gentoo és sokkal rugalmasabb rendszer.
Nem minden Arch-user advanced. Vannak, akik segédscripttel telepítenek, vagy Arco Linux, vagy Manjaro formájában használják. De egyetértek, a Gentoo rugalmasabb, nem kötelező benne a systemd. De akinek nincs baja a systemd-vel, vagy kifejezetten szereti/kell neki, azoknak viszont az Arch gyorsabb telepítésű, könnyebb fenntarthatóságú.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Úgy meg mi értelme? Hogy elmondhassák, archot használnak? Azon nekem is megakadt a szemem, amikor az fstab létrehozó scriptet olvastam.
... én nem a telepítés „öröméért” használok gentoo-t, sőt minden (is) scriptekbe van rendezve. Csak akkor váltok manuális módra, ha muszáj (fstab mindig kézi, particionálás mindig kézi, bár ez akár mehetne scriptbe). Amikor valaki azt állítja, hogy időrabló egy gentoo, akkor elgondolkodom, hogy látott-e már valaha gentoo-t közelről :) Pár éve volt itt valaki aki bizonyára azt hitte, hogy vicces vagy okos és beszórt egy ilyen hozzászólást: „Azonnal munkába kell fongom az új gépet. Mi lenne ha egy olyan rendszert választanék rá amit kurvasok idő feltenni és karban tartani? Zseni vagyok!” Életében nem látott gentoot :D Azt hitte a kis biboldója, hogy akkor fogok hozzá gentoot tanulni vagy ki tudja, mire gondolt a költő. Nekem van egy listám azokról az alkalmazásokról amiket használok és telepítettem. Ezt a listát adom az emerge-nek és kész. Néha persze eltörnek a dolgok, de általában pár perc javítani a függőségeket, flag-eket. A mostani telepítést másképp csinálom, ezt tanulnom kell, de maga a telepítés semmiben nem különbözik a korábbiaktól, maximum a chroot-ból átvinni a rendszerre másabb. Pluszként, hagytam a profilt úgy fordulni (majdnem) ahogy gentoo-ék megálmodták. Egyenlőre kíváncsian várom a python2.7 nélkül mi fog (nagyon) hiányozni (a zenmap nagyon).
Tehát mi értelme? Nagyon is sok, egy csomó emberi hiba lehetőségét kizárja, ha előre le van fixálva, mit is csinál a gép! Rengeteg időt nyerek vele! A fordítás idejét nem tudom megspórolni, az annyi amennyi...
dzsolt
Azért egy emerge-vel build+installt meg egy kickstart install-t összeeresztve kíváncsi lennék arra, hogy melyik eredményez hamarabb használható gépet. Pláne, ha az is elvárás, hogy a telepített csomagok köre a szolgáltatáshoz szükséges minimális legyen...
Hmmm! Ez olyan ismerős! Valahol már olvastam vl ;)