Új hozzászólás Aktív témák

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3449 üzenetére

    Rászántam magam erre: [link]
    genkernel --zfs --callback="module-rebuild rebuild" --no-compress-initramfs initramfs
    Bár a callback-et ki kellett hagynom (csak anélkül ment végig). Lehet, hogy ez volt a baj, de azt hittem, hogy csak azért nem tudott mit kezdeni magával, mert nincs modulom, amit újraépítsen (minden beépített).

    * Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
    * Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..
    *
    * ERROR: --callback failed!

    Annyiból működött, hogy az initramfs töltődött be, és futtathatók voltak a shell-ben a zpool és zfs parancsok, viszont nem csak automatikusan nem tudta importálni a pool-t, de kézileg is hiába mutogattam neki a /dev/disk/by-id/ mappát is (ahol ott voltak a HDD-k), nem találta a pool-t. :(
    Csak libgcc pthread hibákat dobált, mikor próbálkoztam. :U

    Egyszer próbáltam magamnak összerakni egy egyedi Live-USB rendszert, ahol a genkernel felelt volna a teljes kernel konfigért, alapbeállításokkal (auto-modulosan), így initramfs-el együtt, de ott is nagyjából ugyan ez volt a probléma, hogy bár elérhető volt a btrfs parancs az initramfs shell-ben, de egyszerűen meg sem lehetett találni, nem még mount-olni a btrfs root-ot az initramfs-ből (hiába adtam oda a genkernel-nek a btrfs kapcsolót kézileg és próbáltam a genkernel-next verziót is több kernel verzióval, sohasem jöttem rá mit rontok el, bár hamar feladtam).

    Nem véletlenül ódzkodom tőle (initramfs), hanem nem értek hozzá. Noha inkább azért, mert nem is akarok, de épp azért nem akarok, mert eddig megvoltam nélküle... :))

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • F34R

    nagyúr

    válasz janos666 #3451 üzenetére

    Pont a Genkernel-next-et akartam ajanlani, nekem Archon volt meg inintramfs, meg az elso hasznalatkor Gentoo-n amikor meg nem tudtam kernelt forgatni mukodo modulokkal. Most ahogy igy le van faragva nincs szukseg ra, amugy is lassabb maga a forgatas. Ennek ellenere eszrevetem, hogy vannak olyan teruletek ahol igenis szukseg van ra.

    Dracut-al megjatszanek meg egy probat.
    Csak sajat felelosegre : "At the time of writing, dracut is not marked stable yet, so it may need unmasked before continuing."

    meg egy kis segitseg : [link]

    Egyebkent ajanlott nem Systemd-t hasznalni ebben az esetben, mert 220-as verziotol mar maskepp generalja le.

    "So, after looking into the dracut modules it seems that evolarium is right that zfs-dracut with systemd 220 or newer is broken and a generator script for the sysmount is required to make root on zfs work with dracut and systemd >=220."

    Remelem sikerulni fog :DDD

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3452 üzenetére

    Szerintem már nem fog kiderülni, hogy sikerülne-e, mert mégis visszavágyom inkább Btrfs-re. :DDD (Most az a terv, hogy szétszedem a HDD-ket RAID5-ből külön RAID1-be és single-be, aztán átvariálom a mappáimat és azok helyhasználatát is ennek megfelelően, később pedig vagy újra visszatérek RAID5-re, ha kijavítják a hibáit, vagy RAID10 lesz belőle, ha találok még egy ugyan ilyen HDD-t olcsón -> ez az egyik előnye, hogy Btrfs-nél lehet oda-vissza mozogni, míg a ZFS statikus profilú).

    Mivel nagy munkának tűnt az initramfs, így inkább arra szántam időt, hogy nagyjából felmérjem a töredezettséget pár hónap használat után. A tapasztalatom pedig az, hogy bár kevéssé tördelődött szét, mint a Btrfs, és ami fontosabb, ez még kevéssé látszik meg a teljesítményén (főleg a metadata műveletek sebességén, ami egy idő után nevetségesen lassúvá vált Btrfs-el, de itt ilyen nem érzékelhető), de azért mégis csak töredezik (ami nem meglepő, csak a mértéke/hatása a kérdés), csak Btrfs-el erre legalább "drága" gyógyír volt (rendszeres recursive online defrag és metadata balance felváltva -- azért drága, mert sokáig tart és közben lassít, plusz nyúzza a lemezeket), itt gyakorlatilag nem igazán van (lehet próbálkozni a filerendszeren belül, vagy átmenetileg másik filerendszerbe és vissza mozgatással, de ilyenkor semmi garancia nincs a töredezettségre nézve, és idővel egyre csak nő, mintsem csökkenne a szabad terület töredezettsége akkor is, ha mindig ~25% szabad területet hagyok és egy ilyen mozgatás próba előtt felszabadítok némi extra helyet -> konkrétan csak ártottam vele, mikor kipróbáltam).

    Mivel ZFS-nél a metadata művelek nem lassultak látványosan, így egy L2ARC matadata cache sem jelent semmi számottevő gyakorlati hasznot (próbaképp adtam neki egy 80Gb-os SSD-t és noszogattam, hogy töltse fel minél jobban, de csak metaadatokkal), a szekvenciális műveleteken viszont látni a töredezettség hatását (ezen pedig nem segít számottevően sem az L1, sem L2 ARC, mert itt nem a metaadat töredezettség lassítja az adatműveleteket is, hanem maga az adattöredezettség látszik meg és "minden" nem fér be a cache-be, amit szekvenciálisan kéne elérni --- kivéve persze az írást, azt szépen cache-eli a RAM-ban,de olyat minden filerendszer tud, ha mást nem a kernel csinálja helyette :D).

    Szóval ja... :))
    A konklúzióm az, hogy alapjaiban jobb a ZFS, de nem tökéletes. Hiányzik belőle pár dolog, ami a Btrfs-nél elérhető. Az pedig önmagában véve probléma, hogy a Btrfs-nél a defrag nem csak elérhető, hanem kvázi kötelező, míg a ZFS szépen eldöcög nélküle, de a "drágán" karbantartott Btrfs összességében jobban fog teljesíteni a nap végén, mint a "magára hagyott" ZFS.

    Közben találtam egy érdekes bejegyzést arról, miként lehet lecserélni a FAT filerendszer modult bármi másra az UEFI firmware-ben: [link], amivel elvben lehet boot-olni szoftveres bootloader és FAT partíciók nélkül is (ha nem szignó-védett az alaplapi firmware). :)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • F34R

    nagyúr

    válasz janos666 #3453 üzenetére

    Normal XFS-es vagy EXT4-s raid-et nem probaltal meg, vagy esetleg mar a hagyomanyos megoldasok nem jottek be?
    Egyebkent nekem singe disken volt BTRFS es hiaba kapcsoltam ki cow-t nem sokkal lett gyorsabb, sima szekvencialis felhasznalasra is lassabb volt mint az XFS, torrentnel jobban is toredezett.

    Egyebkent lehet jo hir neked, de van egy masik fajlrendszer ami a BTRFS kis hibait probalja kikuszobolni.
    egyenlore eleg early statusban : [link]

    Azthiszem meg is valaszoltam magamnak a kerdest.

    " I lost terrabytes of data with btrfs on a backup server again and again and again.
    In the end I use ext4 as trustworthy frontend, and btrfs as a unreliable backup. Because ext4 can't beat btrfs when it comes to snapshot/delete. It takes a second to snapshot, and deletes of a snapshotted tree what takes ext4 26 hours is a few minutes on btrfs.
    Another point against btrfs is the insane amount of memory it uses.
    But in the end I hope btrfs will be as trustworthy as ext4 or even as much as reiserfs in the 2.4 kernel series, because btrfs has this insane amount of checking that I really want. Especially in a SOHO environment where my photographs are going on my personal cloud.
    Actually, btrfs should become cloud based... My current attempts will be using an fcoe exported physical volume from another server, together with a local disk. But what if btrfs was running locally *and* remotely, working together for raid 1 storage on non raid disk configurations. The current btrfs implementation should allow something like that with not too much work. I mean: currently raid one is implemented by taking 2 "lower level" individual btree storages and make sure they have the same higher level data in that storage."

    :DDD :DDD

    Probaltal amugy mas disztrot is?

    [ Szerkesztve ]

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3454 üzenetére

    Szerintem semmi köze a disztróhoz, a mainline kernelben, illetve zfs git repóban van a lényeg, amibe a gentoo-source patchset csak minimálisan nyúl bele (sőt, alapvetően csak extra opciókat ad a menuconfig-ba, nem kényszereket teremt, vagy módosít) és ez is csak javasolt, de nem kötelező (használható a vanilla-source is). A ZFS kód azt hiszem közel 1:1 GIT-ről jött gentoo patch-ek nélkül (kivéve az extra useflag-eket), ahogy a Btrfs userland-hez sincs tudtommal érdemi patch a gentoo ebuild-ban.

    Ez szerintem kifejezetten jó is a gentoo-nál, hogy egyszerűen át tudom tekinteni, mi az, ami esetleg disztró-specifikus és mi nem, de általában jó tipp, hogy alapjáraton semmi sem az (mármint, ami "kintről jön", nem kimondottan a gentoo-hoz készül), és ha mégis, akkor sem megkerülhetetlen / kibogozhatatlan.
    Más disztróknál is utána lehet járni ennek, de általában az a kerülőút, hogy fogasd újra magadnak a disztróspecifikus patch-ek nélkül, ilyenkor pedig kényelmes, ha eleve forráskód alapú a disztró és a csomagkezelő.

    Amit a disztró tehet az esetleg az, hogy automatikusan átállítja az IO és/vagy CPU ütemezők paramétereit, esetleg beidőzít cron-al egy defrag-ot, netán btrfs balance-ot, stb.

    Vagy, ha messzebbre gondolkozunk, a Solaris megfordult a fejemben, de tudtommal oda, a zárt verzióhoz sem készült el soha ZFS-hez a Block Pointer Rewrite (és aki dolgozott rajta azt mondja örül is neki, hogy nem fejezte be és reméli más sem fogja helyette, mert "az lenne az utolsó feature", túlkomplikálná a jövőbeni változtatásokat), ami lehetővé tenné az online defrag-ot és a profilok közti online váltást (amiket a Btrfs már tud). Szóval ilyen szempontból ez most irreleváns. Linux-on relatívan zabálta a CPU-t a ZFS, de nem bántam, mert nem hiányzott másra (és talán jobban feküdt volna egy kicsi, de friss Intel CPU-nak, mint az öreg AMD csodának, amitől amúgy is épp szabadulni tervezek).

    A töredezettség pedig talán más mértékben alakul ki és/vagy érződik a megléte, de igazából nem a filerendszer, hanem a HDD "hibája". FAT32-t is használhatnék, azon is töredezetté válhatnak előbb-utóbb a file-ok, ha folyamatosan cserélődik egy részük, ez pedig mindig meglátszik az elvileg szekvenciális műveleteken, ha igazából mégsem azok, mert csattognak a HDD fejek a töredékekért. Ezért lehet hasznos a defrag (ez van EXT4-hez és Btrfs-hez is, ZFS-hez viszont nincs).

    Láttam a bcachefs-t. Az első benyomásom szerint semmi értelme, és többet ért volna valami olyasmit összerakni, mint a ZFS féle L2ARC. Csak nem is kell ARC, lehet sima "utolsó olvasat" cache, csak legyen olyan módja, ahol csak metadata megy rá, és ideális esetben kérésre automatikusan próbálja meg teletömni a metadata block-ok tartalmával hidegindítás után (reboot után melegen indulni biztos bonyolult, de ez nem tűnik annak).

    A legnagyobb balszerencsém a Btrfs-el csak az volt, hogy nekem pont a RAID-5 profil tűnik ideálisnak, míg a fejlesztők általában olyan szélsőségesen állnak a kérdéshez, hogy kétféle adat van, az egyiket minimum RAID1 (vagy 1+0) profillal tárolod és van róla off-site, off-line backup, 2+ példányban (a tenger alatti titkos bunkerben ólomszéfben, és a nagyi pincéjében is a dunsztosüveg mögött, a patkányfogó alatt alufóliában), vagy "szarsz rá" és olyan, mint ha egy sem lenne, szóval tök mindegy, akár a /dev/null-ra is küldhetné a filerendszer, szóval nem igazán támogatott a RAID-5/6. Már viszonylag rég volt viszonylag stabilnak tűnő állapotban (volt, aki állítólag legalább 1 éve használta), mikor használni próbáltam, de aztán kiderült, hogy tele van végzetes hibákkal, amikbe én bele is futottam (azóta is léteznek, nem prioritás a javításuk, de legalább már dokumentálták).

    Az extra hajlam és érzékenység a töredezettségre inkább csak olyan dolog, amit "tájékoztató és építő jelleggel" próbálok hangoztatni, nem olyan, ami miatt ne lehetne használni, hisz legalább működik a defrag és metadata balance (elvileg hibátlanul), amiket lehet automatizálni és az IO ütemezéssel csökkenthető az esetleges negatív mellékhatása is (bár gyakorlati szempontból ez lehetne alapszolgáltatás [mint pl. a zfs-nél a scrub-nak dedikált IO ütemező queue], de ez már részletkérdés, morogni lehet rajta, nem vizet választani vele).

    Amúgy igen. nem biztos, hogy ha szétszedem őket, akkor a szóló HDD-re is Btrfs megy, az talán EXT4 lesz (akár journal nélkül). Bár ezt már fejtegettem fentebb, hogy lényegében majdnem mindegy ilyen szempontból (csak a hibás RAID profilokra nincs gyógyír, minden másra igen és egyik filerendszer sem tökéletes más szempontból sem).

    Tudtommal nincs most ingyen semmi, ami olyan jellegű garanciákat kínál a konzisztenciára, mint a Btrfs és ZFS. Minden más vagy hagyományos RAID checksum-ok nélkül, vagy gyakorlatilag egy hagyományos, vagy checksum-olással kiegészített, esetleg paritásra épülő "okos backup" (pl. paritás nélkül ír fel először mindent, aztán kiegészíti a háttérben paritással vagy redundanciával és akár checksum-al is, de ez nem egy tranzakción belül történik, hanem későbbre tolva...). Ezektől ilyen szempontból szerintem minden visszalépés, vagy esetleg ugyan ez, csak más formában, de akkor olyanban, ami számomra nem tetszik, bonyolultabb, és/vagy elérhetetlen is (mint néhány speciális szerverekbe szánt megoldás, amit legfeljebb említésből ismerek, a működése "titkos" is vagy legalább is irreleváns, mert én úgysem fogom használni, főleg nem itthon).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • F34R

    nagyúr

    válasz janos666 #3455 üzenetére

    Igen, kimondottan zfs patchsettel elatott kernel nincs, egyik disztro oldalarol sem. Volt hir rola hogy az Ubuntu-ba telepiteskor valaszthato lesz a zfs de csak nem kerult bele mert o szerintuk sem ugy mukodik egyutt a disztrojukkal ahogy ok ezt megalmodtak.
    Gentoo egyebkent mindentol elter, mert eleve mas az osszetetele mint a binaris tarsainak.
    Legtobb initramfs-re epul es systemd az alapertelmezett init rendszer is (80%-ban).
    Solarison kivul meg volna egy tippem, FreeBSD. Meg van meg egy de annak a neve most hirtelen nem jut eszembe.
    Talan ezek meg egy probat megernenek. Ebbe viszont az a hatrany hogy nem tudsz valtani, mert ket fajlrendszer van az UFS meg a ZFS.

    E350 ha jol gondolom? regebben en is olvastam rola hogy a zfs jaratja szepen a cpu-t, de hogy most ez a rossz portolasnak vagy egy bugnak koszonheto, vagy esetleg azert mert tobb layeren megy at es ez feladatigenyes azzal nem torodtem.
    Most akkor jol gondolom azt hogy esetleg SSD-n nem volna olyan tordeles mint egy merevlemezen? Van egy felhasznalo Gentoo forumon aki BTRFS SSD-s Raid-et hasznal egy 850-s EVO-n :P Es azt allitja neki nincs vele semmi gondja.
    Igen ahogy te is mondod Raid5/6 olyan allapotban van hogy nem lehet hasznalni, ezt a hivatalos statusz oldalukon is feltuntetik.

    https://btrfs.wiki.kernel.org/index.php/Status

    Single Disk-re akar SSD-re egyebkent a legjobb meg mindig az Ext4 es az XFS. Tobb lemezen nem probaltam egyiket sem, foleg nem RAID-ben mivel nem rendelkezek egyforma diszkekkel.
    Egyebkent itt ha meglatogatod a nagy linux topikot ott is a "hagyomanyos" modszert fogjak ajanlani.
    Az ingyenes dologra (softraid) es a fizetos (hwraid)-re celoztal, az utobbinak is vannak buktatoi rendesen, igy meg mindig jobb az olcsobb modszert hasznalni, mert azt te is ki tudod kuszobolni.
    Egyebkent ugy veszem eszre hogy a te igenyeidnek inkabb a BTRFS tesz eleget, erdemes mindig upstream tartani, bar ha jol gondolom abbol is a git verzio erkezik hozzad...

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3456 üzenetére

    Nem, most egy AMD 5600K (most cserélem majd Intel G4400-ra), és még ezen is számottevő a CPU igény, az E350 szerintem kevés lenne, hogy kiszolgálja a 3 lemezes RAID-Z módot 7200RPM HDD-kkel, főleg Samba-n keresztül, ami szintén éhes tud lenni.
    A ZOL oldalán is kiemelten közlik, hogy nincs teljesítményre optimalizálva, ami szerintem leginkább ebben merül ki, hogy tekeri a CPU-t, mert egyébként gyors (szóval csak relatívan lassú, hogy egységnyi munkához viszonylag sok CPU idő kell neki, de ha megkapja a CPU-t, akkor hasít, viszont gondolom minimum egyenes arányban nőne a CPU igény a HDD-k számával egy profilon belül, így simán lehet skálázódási gond, ha valaki egy gyenge kis CPU-ra [kevés mag, alacsony ipc/c] szeretne alapozni egy sok lemezes, vagy több szimultán terhelt pool-t).

    Az SSD nyilván egy más világ. Ha nem lenne probléma a költséghatékonyság, akkor nekem is kizárólag viszonylag lassú SSD-im lennének HDD-k helyett (a HDD szintű szekvenciális sebesség, de alacsony elérési idő megérne nekem mondjuk 1/2 felárat, de ma ez még sokkal több attól) és sohasem kéne foglalkozni a töredezéssel.
    Van, aki SSD-n is szokta defrag-olni a Btrfs-t (ez szerintem egyéni megítélés kérdése, van aki szerint őrült hülyeség, szerintem van benne némi ráció is, mert nem csak LBA terület értelemben, hanem maga a filerendszer is töredezik, miközben nem kopik olyan gyorsan az a NAND, hogy egyedül ez nyírja ki, ha néha átfuttatják - én ezt szerintem kihagynám, mint puszta hobbi, hacsak nem bizonyosodna be, hogy mégis érzékelhető, de elhinném, ha igen).

    Nem, rendszerszinten ~amd64 minden csomag (nem stable, de nem is GIT/9999) és gentoo-source (nem vanilla, mert szerintem itt minden gentoo patch hasznos, az experimental is, és legalább ennyi "késés" azért kell). Egyedül a ZFS jött GIT-ről, mint 9999-es csomagverzió, mert a ZFS számozott kiadásai lassabban jönnek gentoo-ra, mint a gentoo-source, így néha nem lenne kompatibilis a frissen lerántott kernellel (maszkolni kéne a kerneleket, de elvileg minden ZFS GIT commit tesztelve van, így elfogadható kompromisszumnak tűnik ez is).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • F34R

    nagyúr

    válasz janos666 #3457 üzenetére

    Eleve megbizhatatlan az SSD hosszabb tavra, foleg adattarolasra. Johetnek az SSD guruk hogy tobbszor volt mar nekik HDD failure mint Flash alapu, de szamomra meg mindig jobb. Mivel koltseghatekonysag celjabol csokkentik a csikszelesseget ataltak TLC-er is hogy kisebb die size-al nagyobb tarhelyet erhessenek el, ez viszont a minoseg rovasara megy. Arrol nem is beszelve hogy egyaltalan nem koltseghatekony.

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3458 üzenetére

    Redundáns tömbben és hosszú garanciaidővel viszont ez majdnem mindegy, csak a várható / addig tapasztalt elhullási rátának megfelelően kell megválasztanod a redundancia szintjét és a hotspare-ek esetleges számát. Mivel általában szinkron módon írható/olvasható egy jobb féle SSD (nem csak a cache, hanem maga a NAND is), így nem is lohasztja le a tömböt egy-egy re-balance/build/silvering (ki hogy nevezi).

    Régen arról álmodtam, hogy mára legfeljebb kétszer annyiba kerül majd az olcsó NAND (akkor nem tudhattam, hogy a 3D TLC NAND lesz a nyerő) és akkor fogcsikorgatva meg lehet ejteni a majdnem teljes átállást, de ez lassabb folyamatnak bizonyult.

    ---

    Lenne viszont egy tényleg Gentoo-s kérdésem is. :D

    Van valami hatékony módszer a rendszer "tisztítására" azon kívül, hogy felhúzok egy szűz rendszert egy átmeneti új filerendszerben (vagyis inkább subvolume/dataset-ben, stb), kézileg válogatva átviszem a hasznos beállításokat/file-okat a régiből, aztán cserélek, majd törlöm a régi root mappastruktúrát (/subvoleme-ot)?

    Olyasmikre gondolok, hogy bizonyos csomagok beránthatnak sok másikat (pl. mikor nem néz szét az ember a useflag-ek közt előre és egy apró diagnosztikai kütyü még MySQL-t, Apache-ot és levelezőszervert is telepít, de van hogy szimplán csak változnak a függőségek), és a portage ezeket el tudja távolítani, ha már nincs rájuk szükség, ugyanakkor hátrahagyhatnak különböző konfigurációs/átmeneti file-okat, amiket érthető módon nem pucol le a csomaggal együtt. (Mármint valami más megoldás, mint kézileg átnézni minden kis almappát, vagy figyelmen kívül hagyni ezeket, mert valószínűleg úgyis csak néhány Mb az egész, vagy annyi se).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • F34R

    nagyúr

    válasz janos666 #3459 üzenetére

    Dist fajlokat szoktam kitorolni, meg a nem kello csomagokat kiszelektalni a world-bol
    eclean-dist --deep
    vim /var/lib/portage/world

    jah es termeszetesen a tmp

    rm * /var/tmp/protage/
    A regi kernel-source-t meg szoktam hagyni.

    rsync vagy tar, en utobbit jobban szeretem.

  • F34R

    nagyúr

    Meanwhile......

    4 ev utan erzesem szerint tonkrement az ssd-m. Ma egyszercsak fogta magat es egy folyamat kozben megadta magat, reboot de mar a be sem bootolt, bios nem latja, kabeleket neztem es erzekeny bucsut mondtam neki.

    ocz vertex 30gb-s, az utobbi ket evben kapta a sarat rendesen, de halalanak okat nem ismerem.

    Olvsatam nehany threadet, es nem feltetlenul a folyamatos forgatas miatt hullhatott el, hiszen masok is hasznalkan ssd-t ilyen rendszer alatt.

    Kar erte, ameddig nem nezek ki valami jo SSD-t addig hanyagolom.

  • F34R

    nagyúr

    Probalkozott mostanaban valaki mukodo distcc-vel?
    Valamiert nem akar a szerverre csatlakozni es csak local tudok forgatni :F

  • válasz F34R #3462 üzenetére

    Aha, működik, de szerintem már késő... :D

    Nem túl aktív ez a topik. :U Rajtam kívül gentoozik még valaki?

    [ Szerkesztve ]

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • válasz DrojDtroll #3464 üzenetére

    Pedig csak 6-8 óra összehozni egy alap rendszert kezdőnként. ;]

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • válasz DrojDtroll #3466 üzenetére

    Jó neked, hogy órákban tudod mérni. :)

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • Rimuru

    veterán

    válasz lezso6 #3465 üzenetére

    Ennyi ido egy chromiumnak kell es meg nincs rendszered. :P

    Vigyázat, csalok!

  • Domonkos

    Ármester

    Gepcsere miatt egyik asztali gentoo-s gepemet at kell koltoztessem egy laptopra. Kedresem az lenne, hogy hogyan tudnam ezt a legegyszerubben, legkevesebb felugyeletet igenylo modon megtenni.
    Ahogy csinalnam:
    -felhuznam a rendszert egeszen a login shellig
    -atmasolnam a /etc/portage mappat az uj gepre (megejtenem a szukseges modositasokat benne)
    -egy emerge hivassal telepitenem a regi @world elemeit (kiszedve a hw specifikusakat)
    -turelmesen varnek a befejezteig
    -telepitenem a hw specifikus dolgokat
    -atmasolnam a /home /root stb. tartalmat

    Gondoltam arra is, hogy siman, mint egy teljes backupot csak athuzok a masik lemezekre, de aztan elment tole a kedvem, mert az elso loginig amugy is kb. mindent ujra kellene csinalni, raadasul ahogy magamat ismerem tuti hogy felulvagnek valami letfontossagu elemet; emergelgetni meg amugy is elemergelgethet a hetvegen - csak hetfon lenne ra szuksegem, addig kellene munkara kesz allapotra hozni.
    Mukodne a fenti otlet? Van aki okosabban csinalna?
    Elore is kosz! :R

    Gender of electrical connectors is defined by the pins.

  • Domonkos

    Ármester

    válasz Domonkos #3469 üzenetére

    Vegul igy csinaltam es azt leszamitva, hogy meg mindig nem tudok elsore jo grub configot irni, minden siman ment. Emerge sem akadt el es a modulokat is sikerult mind elsore beforgatni. Igy kb fel oraval kesobb vegeztem, mint ahogy kalkulaltam az optimalis esetet.
    Ha valaki hasonlo dolog ele nez, akkor ez egy jarhato ut. :K

    Gender of electrical connectors is defined by the pins.

  • Bici

    félisten

    Sziasztok!

    Általában mi a szokás Gentoo esetén, milyen gyakran szokás frissíteni?
    Nem okoz gondot a fordítási idő, ami miatt ritkábbal frissítitek a rendszert?
    pl. egy Blender, KDE, stb. újrafordítása nem halálos?

    Egy játékfejlesztői gépen terveztem kipróbálni a Gentoo-t, de a tartok attól, hogy munka helyett a rendszer masszírozására menne el az időm. Ugyanakkor általában nem riadok vissza a részletes konfigurálástól, amíg nem akadályoz a munkában.

    Felhasználás: fejlesztés, és 2D/3D grafikai munka, videovágás, fotó feldolgozás - egyszerre általában 6-7 progi fut legalább.

    Sokáig Arch volt a gépen, most Fedora, de utóbbi esetén majdnem annyi buggal találkoztam, mint Arch-on (azért nem vészes), és ha ilyenek a friss csomagokkal működő disztrók, akkor nem veszítek semmit (pl. stabilitás), ha kipróbálom a Gentoo-t (vagy de?).

    Ebben kérném a segítségeteket, hogy van-e értelme kipróbálni, illetve ilyen felhasználásra számíthatok-e bármilyen előnyre.

    Volt egy korábbi próbálkozásom e téren, de azt végül feladtam, időhiány miatt.

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Istju

    senior tag

    válasz Bici #3471 üzenetére

    Szia.
    Sokat nem gentooztam, arch linuxot használok. Szerintem a telepítésnél a nagyobb nyűg a Gentoo. Frissíteni, én kb hetente szoktam, de amennyiben minden flottul műkszik, elég ritkábban is. Kivételt képeznek, azok a csomagok, ahol esetleg valami biztonsági kockázat áll fenn. Javaslom, ha Gentoot telepítesz, akkor iratkozz fel a fejlesztők levelezési listájára, így nyomon követheted, mit muszáj frissíteni. A többit, szerintem pár havonta is elég, ha korrektül megy minden eszközöd.

    A bonyolultság elrejtése még bonyolultabb rendszert eredményez, és ezért kerülendő. KISS

  • Domonkos

    Ármester

    válasz Bici #3471 üzenetére

    Epp alattad reszleteztem, hogy hogyan vandoroltam at egyik geprol a masikra.
    En nem ajanlom, ha nincs semmi tapasztalatod a gentooval, hogy egybol azon a gepen tesztelgesd, amivel dolgozni szeretnel. Rendkivul sok idot el lehet arra pazarolni, ha nem allitasz be elore minden USE-t es haverjait jol.
    En inkabb fognek mondjuk egy otthoni gepet amin eloszor jol bejaratnam, majd a szukseges file-ok atmenekitesevel egy nap alatt athuznek a masik gepre.
    Ha egy kicsit turelmes vagy, akkor sok kellemetlensegtol tudod magad megkimelni; csak ne ugy allj neki, hogy minden elsore fog sikerulni.

    Frissiteni mindig azelott szoktam, mikor egy uj csomagot tervezek folrakni - meg termeszetesen akkor is, ha egyikrol-masikrol kiderul hogy bibis. A munka befejeztevel aztan fellovok egy sshd-t, elinditom a frissitest es hazamegyek. Amikor epp eszembe jut, akkor ranezek hogy mi a helyzet. Altalaban nem szokott gond lenni.

    Gender of electrical connectors is defined by the pins.

  • Bici

    félisten

    válasz Domonkos #3473 üzenetére

    Istju, Domonkos: Koszi a tippeket!

    Tehat mondjuk egy virtualis gepen probaljam ki a gentoo vilagat, es ha mar megy, akkor koltoztessem at a munka gepet? Ez logikusan hangzik.
    Az esti frissites is megoldas lehet, amikor epe nem hagyom ott a gepet renderelni. :D

    A kerdes, hogy megeri-e. Azert gondoltam gentoo-ra, mert rolling es mert forrasbol fordulnak a dolgok, ami azert jo, mert CPU erobol sosem eleg egy grafikai gepen.
    Viszont, pl. 5% koruli / alatti eredmenyert elgondolkodom, hogy megeri-e. :U

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Domonkos

    Ármester

    válasz Bici #3474 üzenetére

    A sebesseg miatt szerintem nem eri meg, viszont a stabilitas es szemelyreszabhatosag miatt igen. Na meg azert is hogy nem kell a systemd-t elviselni :D
    "Jelentosebb" sebessegnovekedest amugy is csak olyan flagek beallitasaval fogsz kapni, amik miatt utana keptelenseg lesz az egyik gepen forditott binarist a masik gepre atvinni (-march=native es tarsai...)

    Gender of electrical connectors is defined by the pins.

  • Bici

    félisten

    válasz Domonkos #3475 üzenetére

    Értem.

    Most lehet, hogy nagyon hülyeségeket fogok kérdezni, de vállalom. :D
    - a stabilitás miböl fakad a gentoo-nál? A rolling mivolta miatt pont hogy arra számítottam, hogy a frissesség érdekében kicsit több a bug.
    - ha beüzemelek egy külön gépet fordításra, akkor nem fogom tudni az ott fordítottakat átvinni a fö gépre ha ilyen spéci flageket használok?

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Domonkos

    Ármester

    válasz Bici #3476 üzenetére

    Stabilitas onnan jon, hogy akik karbantartjak az egyes csomagokat kellokepp megbizonyosodnak rola, hogy azt a csomagot stabilnak lehet jelolni; nem ugy mint egyes bleeding-edge disztroknal, ahol ha mar fordul, akkor kuldik is be a repokba :DDD
    A binarisok atvihetoseget meg az tudja keresztulhuzni, pl. ha a forditonak megengeded, hogy minden olyan utasitast hasznalhasson a processzorod, amit csak tud. Es ebbol meg nem is feltetlen kovetkezik az, hogy a regebbi procira forditott programok az ujon is invalid instruction nelkul fognak menni. Persze fordithatsz ilyen flag-ek nelkul is, de akkor a sebessegen aligha nyerni fogsz valamit. Elkepzelheto hogy mukodne az is hogy egyik geprol a masik -march-ara forditasz, de az macera; en nem probaltam.

    Gender of electrical connectors is defined by the pins.

  • Bici

    félisten

    válasz Domonkos #3477 üzenetére

    Ha lenne egy a fö géppel azonos családba tartozó, de magszámban, és frekiben eltérö buildgép, akkor garantált lenne az átvihetöség, vagy akkor sem feltétlenül?

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Rimuru

    veterán

    válasz Bici #3476 üzenetére

    Azert stabil amiert mondjuk egy arch is az (egyszer BoB valahol szepen leirta), aztan persze lehetne finomabban is belemenni a reszletekbe...
    Amugy meg sok csomag vissza van tartva a stabilkent (testingben persze ott van a friss tehat rollingolhatsz ugy ahogy megszoktad pl arch alatt).

    Attol fug milyen flagekre gondolsz, (normalis esetben) azt tudni fogod ha valami hardver specifikus (pl nvenc), de amit beleforditasz az benne lesz.

    [ Szerkesztve ]

    Vigyázat, csalok!

  • F34R

    nagyúr

    Valasz: szerintem nem eri meg, foleg ha full rollingkent hasznalod. Nekem volt generic x86_64 es native is, szamottevo sebesseget nem lehet eszrevenni.
    Amit viszont erdemes forgatni az a kernel. Nyilvan videovago, render programoknal ki lehet cflag-el es nativ forditassal 2-5% csikarni ha eppen erre van szukseged. Viszont ahogy az elottem szolo kollega irta nagy erv mellette a testreszabhatosag,a tobbfele csomagverzio, a sajat overlayek hasznalata es a systemd mentesseg.
    Annyit azert tudni kell hogy az Openrc sincs mar olyan stabil mint kellene, regebbi verziok kevesebb featurel sokkal jobban szikla stabil volt.
    Nekem egy nagyon regi gentoo motoros azt is mondta ne mixeld a brancheket es legalabb kethavonta frissits!
    Nem egy, nem ketto felhasznalo regi ezer eves gepen, maszkolja a csomagokat, hogy pl ne frissuljon (olyanokat is amik mar epp benne sincsenek a portage faban:P)
    Szoval el kell dontened, hogy es mire szeretned hasznali, mert csak utanna tudunk jobban segiteni.

  • F34R

    nagyúr

    válasz Bici #3478 üzenetére

    Attol fugg ha pl van egy 4590-ed es 4690-ed es nyilvan megadtad az osszes cflaget amit eppen tud a processzorod akkor igen. Nyilvan generaciovaltasnal,megint celszeru ujraforgatni par csomagot.

  • Rimuru

    veterán

    válasz F34R #3480 üzenetére

    Nem egy, nem ketto felhasznalo regi ezer eves gepen, maszkolja a csomagokat, hogy pl ne frissuljon (olyanokat is amik mar epp benne sincsenek a portage faban:P) - mar nekem is van ilyenem. Vagyis meg benne van a faban, de mar nem sokaig. :DDD

    Vigyázat, csalok!

  • Bici

    félisten

    válasz Rimuru #3479 üzenetére

    Kössz!

    Igazából még én sem tudom hogy milyen flag-ekre gondolok. :D
    Az lenne a fö cél, hogy a Ryzen 7 prociból kihozzam a maximumot.
    Viszont, belegondolva lehet, hogy felesleges emiatt külön gép, mert ilyen célra úgyis olcsóbbat szereznék be, az meg gondolom, lassabban fordít. Akkor egyszerübb az fögépet pörgetni éjjel. Azért hetente egy napot találok, amikor nem renderelni hagyom ott a gépet.

    Azt hiszem, kipróbálom otthon, és majd meglátjuk.

    Köszi mindenkinek a fejtágítást!

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • F34R

    nagyúr

    válasz Bici #3483 üzenetére

    Arra azert keszulj fel hogy Ryzen-nel is fog egy ejszakat forditani (szoftverkornyezettol fugg).
    Es ugye mivel kezdo vagy nem biztos hogy egyszer fogod leforgatni a csomagokat.

  • Bici

    félisten

    válasz F34R #3484 üzenetére

    Ertem, koszi!

    Heti egy ejszaka forditas nem gond, sot ketto is belefer, csak olyat nem szeretnek, hogy rendszeresen arra menjek be reggel, hogy 60%-nal tart. :D

    De gondolom, nem kell minden heten a teljes rendszert ujraforditani.

    Mindenesetre kiprobalom otthon a gyengebb gepen, es ha azt mar kezelhetoen tudom tartani, akkor jo lesz munkaba is.

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Rimuru

    veterán

    válasz Bici #3485 üzenetére

    Nyugi annyira nem durva. A legnagyobb melo a telepites lesz.

    Vigyázat, csalok!

  • Bici

    félisten

    válasz Rimuru #3486 üzenetére

    Kössz! :D

    Noss, újra nekiállok hamarosan Gentoo-zásnak, egyelőre virtuális gépben, mert még mindig nagyon kevés időm van.

    Addig is egy kérdés; amikor a Gentoo pl. frissítéseket telepít, akkor nem csak a C-ben írt progikat fordítja forrásból, hanem a C++-ban írtakat is, ugye? pl. QT, KDE is teljesen forrásból megy?

    [ Szerkesztve ]

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Rimuru

    veterán

    válasz Bici #3487 üzenetére

    Röviden, ami mögött nincs ott a -bin suffix az forrásból megy mindig (persze változhat bizonyos körülmények között)

    Vigyázat, csalok!

  • Bici

    félisten

    válasz Rimuru #3488 üzenetére

    Oksi, kössz!
    És tudsz példát mondani azokra a bizonyos körülményekre?
    Illetve van olyan csomag, ami alapból nyílt forráskódú, mégis csak binárisban érhető el?

    Kössz!
    Sorry, ha furcsa kérdéseim vannak, csak általában sajátos szögből kezdem az ismerkedést minden újonnan megtanulandó dologgal. :D

    Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

  • Domonkos

    Ármester

    válasz Bici #3489 üzenetére

    Korulmeny? A legegyszerubb eset, amikor az adott szoftver nem nyilt forraskodu, vagy a nyilt forraskodu szoftver binaris blob-okat tartalmaz.
    Masik: elofordulhat, de nem tudok ra peldat mondani. Ha lenne is ilyen, akkor arra mar biztos keszitett valaki egy jo kis overlay-t, szoval kikuszobolheto. De nem dol ossze a vilag, ha egy-ket csomag nem csomagkezelobel lett felrakva. Meg kulonben is van par ebuild ami meg mindig nem tamogatja, hogy a sajat patcheidet felrakd rajuk...

    [ Szerkesztve ]

    Gender of electrical connectors is defined by the pins.

  • csixy

    addikt

    A Gentoo linuxot nem merészeltem direktben megközelíteni, de egy Sabayon minden szívfájdalom nélkül felment. Szóval meglehetősen valószínű, hogy Gentoo tanácsokra fogok majdan szorulni. Máris itt egy érdekes megfigyelés. Legacy körülmények között telepítettem, mert a telepítője UEFI-ben nem tudott elindulni. Most mégis tud UEFI-ül is. A történet annyi, hogy már eleve fel volt telepítve egy MBR-es partíciós táblás eszközre egy Linux Mint Legacy és UEFI módra is. Most a Sabayont betelepítettem a logikai /dev/sdb5 partícióra Legacy módra. A rendszerbetöltő természetesen a /dev/sdb-re került. Ahogy illik, a Grub menüjébe felvette a Linux Mintet is. Ebből ezután a Linux Mintet bootoltam Legacyban, majd lefuttattam benne egy sudo update-grub parancsot, így ő is felvette a Grub menüjébe a Sabayon linuxot. Ezután újra indítván a gépet a Linux Mint UEFI bootját indítottam és a Grub menüjéből a Sabayon linuxot választottam. Most itt fut a Sabayon UEFI-ben. GPT a környéken se nincsen. :)

    [ Szerkesztve ]

    Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.

  • cigam

    félisten

    Létezik, hogy 3 éves a live media? Miért nem frissítik legalább évente?

    Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

  • Rimuru

    veterán

    válasz cigam #3492 üzenetére

    Ne azt a hibrid izet hasznald, boven eleg a minimal iso (legfrissebb: 2019-08-21). Meg ha van mar barmilyen linuxod akkor live se feltetlenul kell, ott a stage3.

    Vigyázat, csalok!

  • cigam

    félisten

    válasz Rimuru #3493 üzenetére

    A honlapon azt írják, hogy Step 1: Boot a live environment. Még a manuel elején járok, és elég ködös mijaza stage3. Olvasok tovább...

    [ Szerkesztve ]

    Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

  • Rimuru

    veterán

    válasz cigam #3494 üzenetére

    Nem azzal kezdodik az "igazi". :D Gondolom amd64-et akarsz, [link].

    [ Szerkesztve ]

    Vigyázat, csalok!

  • cigam

    félisten

    válasz Rimuru #3495 üzenetére

    Igen, már vannak partíciók fájlrendszerrel, amibe kicsomagoltam a stage3 no multilib verzióját (kicsit bizonytalan vagyok, de nem tudom mire kellene a 32 bites könyvtár, vagy nem csak az difi?) A legtöbb parancsot csak copy-pste módon írom, ahogy az Arch telepítésekor is.
    Most fordítom a kernelt, de izzad szegény C2D proci, és nem vagyok meggyőzve, hogy ez az egész jó lesz nekem. Ha KDE desktopot választottam akkor azt is forrásból fogja lefordítani? Mert akkor megvan a jövőheti programja...

    Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

  • cigam

    félisten

    válasz cigam #3496 üzenetére

    A genkernel-nél meg is akadtam (not found). Szóval köszi, de nem.

    [ Szerkesztve ]

    Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

  • Rimuru

    veterán

    válasz cigam #3497 üzenetére

    A legtöbb parancsot csak copy-pste módon írom, ahogy az Arch telepítésekor is. - Ahogy archnal is mondtam tobbszor (de amugy minden parancs elott ervenyes), ertelmezni kell mi van leirva, nem esz nelkul mindent vegrehajtani.

    Most fordítom a kernelt vs genkernel-nél meg is akadtam (not found). :D
    A genkernel csak egy kenyelmi eszkoz kernel forditashoz, nem resze az alap rendszernek. Akinek kell az felrakja, akinek nem az kihagyja. Egyebkent ha wikit figyelmesen kovetted volna akkor tudnod kellene.

    Now it is time to configure and compile the kernel sources. There are two approaches for this:
    - The kernel is manually configured and built.
    - A tool called genkernel is used to automatically build and install the Linux kernel.

    Masreszrol ugyan ezen az oldalon ahol elojon a genkernel ott van folotte hogy kell telepiteni:
    To install an initramfs, install sys-kernel/genkernel first, then have it generate an initramfs:
    root # emerge --ask sys-kernel/genkernel
    vagy ez
    Now, let's see how to use genkernel. First, emerge the sys-kernel/genkernel ebuild:
    root # emerge --ask sys-kernel/genkernel

    forras

    Ha tippelnem kellene forditottal kezzel, utana jott volna az initramfs ahol megakadtal. "Pro" tipp ilyen esetben erdemes lehet rakeresni adott wikin hogy mirol is van szo, pl initramfs, lathatod hogy nem csak 1 ut van. Lehet azt is megtudnad hogy mondjuk nincs is szukseged ra. :D
    Ha KDE desktopot választottam akkor azt is forrásból fogja lefordítani? - Igen, [link]

    Vigyázat, csalok!

  • cigam

    félisten

    válasz Rimuru #3498 üzenetére

    Ennek az lehet az oka, hogy angolul sem tudok... Nekifutottam még1x, és a
    emerge --ask --verbose --update --deep --newuse @world
    parancs után látni véltem a mátrixot ;]

    Majd meg is akadtam, mert

    +Miért erölteti partícionáláskor a 2MB-os (BIOS boot) partíciót? (Lehet ha odaérek majd rájövök, de nem bánom ha spoiler-ezel :) )

    Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

  • Rimuru

    veterán

    válasz cigam #3499 üzenetére

    Van 3 csomag aminek olyan pythonra van szuksege ami tamogatja az sqlite-ot, kb ezt jelenti amit ott latsz.
    USE flagekkel tudod allitani a modulokat. Python eseteben az sqlite alapbol ki van kapcsolva, ezert szol a csomagkezelo hogy kellene.
    1 lehetseges megoldas:
    # echo '>=dev-lang/python-2.7.15:2.7 sqlite' >> /etc/portage/package.use/python

    Miért erölteti partícionáláskor a 2MB-os (BIOS boot) partíciót? - mindig fdisk(/gdisk)-et hasznalok, az nem eroltet ram semmit. Az hogy amit te hasznalsz program mit miert csinal neked kell tudni.

    Vigyázat, csalok!

Új hozzászólás Aktív témák