- Redmi Note 12 Pro - nem tolták túl
- Honor Magic5 Pro - kamerák bűvöletében
- Fotók, videók mobillal
- Samsung Galaxy S10 és S10+ duplateszt
- Realme GT 2 - aláírjuk
- Vodafone mobilszolgáltatások
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy A52s 5G - jó S-tehetség
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
Hirdetés
-
A hajlíthatók kedvence lehet a Dimensity 7300X 5G
ma Átcímkézés helyett csíkszélességet váltott a MediaTek, népszerű Motorolában debütálhat.
-
Összemoshatja a Google és a Magic Leap a valódi és a digitális világokat
it Együttműködésbe kezdett a Google és a Magic Leap nevű AR-startup.
-
Friss GPU IP-ikkel is készült az ARM
ph Az új Immortalis dizájn elég jól skálázhatónak tűnik.
Új hozzászólás Aktív témák
-
Sipi
addikt
Tanács: NAGYON fontold meg, milyen USE flageket kapcsolsz be. Totál felesleges mindig mindent, így csak nagyméretű binárisokat kapsz, melyeknek kiskmillió "dll"-je lesz. Lassú, nehézkes lesz a géped. Ráadásul rengeteg dolgot kell fordítanod.
Főleg az elején érdemes a -X kapcsolót berakni, mert az alaprendszerhez nem kell grafikus felület, ezzel is időt nyersz. Utána pedig ötször átgondolod, kell-e pl. openexr- vagy musepack-támogatás. Ha nem tudod, mi az, inkább ne.
Hasonló módon felesleges az adatbázis-támogatás (odbc, mysql, postgresql). Otthoni gépen maximum 1-2 program lehet, aminek tényleg kell ilyen, de akkor meg már sqlite, ha választható.Egyébként a legtöbb időt a USE flagek beállítása fogja jelenteni. Nekem ma már, hogy tudom, hogyan kell csinálni, az alaprendszerem egy minimális grafikus felülettel egy nap alatt megvan. Az X is hamar települ. A Gnome, KDE, gcc és glibc az, ami sok idő.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Miért ne lenne? Olvass csak bele jobban a kézikönyvbe!
A telepítés első lépései pl. a merevlemez előkészítése, illetve a rendszer letöltése. Bármilyen futó Linux alatt tudsz partícionálni... Utána chroot-tal átváltasz az előkészített Gentoo-ba. Ez is megy másik Linux alatt: az egyik terminálon a telepítés alatt lévő Gentoo fut, a többin az eredeti Linux. Csak akkor kell majd rebootolni, amikor az új kerneled is elkészült, és már a kész Gentoo-t akarod izzítani.Egyébként a telepítési kézikönyv a telepítő cédén is fent szokott lenni, másik terminálban én is azt kukkolom links2 vagy lynx karakteres böngészővel.
Nyugi, nekem is csak a kb. harmadik rendszerem lett épkézláb, előtte minden szart beletettem... Egyébként semmi gond. Egy Gentoo-t tényleg nem tudom elképzelni, mikor kellene nulláról újratenni. Ha rájössz, nem kell egy rakás USE flag, akkor kikapcsolod, és az emerge parancs --newuse kapcsolójával újrahúzod azokat a csomagokat, amelyeknél megváltoztak a beállítások. És onnantól olyan, mintha eredetileg így tetted volna fel. (Azt leszámítva, hogy esetleg fenn lesz a gépen pár program, könyvtár, amire nincs szükség többé. De mindegy, max. a helyet fogja.)
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
emerge gentoolkit
Ezután lesz egy euse parancsod:euse -i flag
kiírja, mire való az adott flag, valamint hogy globális (make.conf-ban kell állítani) vagy lokális (pár csomagra érvényes, a /etc/portage/package.use fájlban kell állítani).
Az XFCE-nek nincs külön flagje. A kde, gnome flag nem igazán azt adja meg, hogy neked kde kell, hanem hogy egy adott programhoz készítsen-e kde-támogatást. Ehhez persze a kde nagy részét fel kell rakni.
Telepítés elején a links azért akart annyit emergélni, mert megadtad, hogy X támogatással forduljon. Ha nem kell, akkor a /etc/portage/package.use fájlban kapcsold ki a links-re az X támogatást, vagyis írd be ezt a sort:
www-client/links -X
Mivel a make.confban be van kapcsolva az X, azon programok, melyeknek van X-támogatsa (pl. egyszerűbb grafikus felülete, vagy kihasznál valamit az Xorgból), ezzel fordulnak. A links-nél viszont kézzel kikapcsoltad, tehát jelenleg ennél az egynél nem veszi figyelembe, a lefordított links nem támogatja az X-et.
Az xfce-hez elég az xfce4 metacsomagot emergélni. Ez nem igazi csomag, csak az van benne, hogy egy működő XFCE-felülethez milyen csomagokat telepítsen.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Net: ellenőrizd, hogy tényleg jó parancsokat írtál bele, s azt is, hogy a megfelelő interfészhez! Létezik az adott ethX interfész? Megcsináltad a szimbolikus linket a net.lo-ra? DHCP kliens két esetben kellhet: direkt azt adtad meg, vagy nem adtál meg semmit az adott interfészhez. Ilyenkor a Gentoo automatikusan úgy veszi, hogy DHCP-t használsz.
A links-et előbb írtam. Ha a pretenddel meg is nézted, láthattad: be van kapcsolva az X flag, vagyis X-támogatást kérsz. Ehhez fel kell raknia.
Desktop: igen, ilyen sorrendben.
Nvidia: nem emlékszem, hogy különösebben piszkálni kellene. Pár opció kell a drivernek, de olyan alapdolgok, amelyek szerintem a genkernellel is beállítódnak.
A genkernel simán futtatva felülírja a .configot, hiszen előre beállított dolgokat készít. Viszont meghívhatod a parancsot a --menuconfig kapcsolóval is, ekkor elkezd molyolni, majd ő maga meghívja a menuconfigot, kézzel bekapcsolhatod, ami kell, kilépsz, és ez alapján folytatja a kernel-generálást.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
"avahi Add avahi/Zeroconf support
bash-completion Enable bash-completion support"Mivel ilyenkor azt írja, valami supportot tesz fel, keres rá az adott csomag nevére! Pl. az avahi is egy csomag, a bash-completion is.
links: éppen ezt nem ismerem, de igen, kikapcsolhatod. Egyébként szerintem meg tud képeket is jeleníteni - Linuxon a grafika megjelenítése karakteres konzolon is lehetséges.
A pretend és verbose kapcsolóval az emerge kiírja, az adott csomagot mikkel akarja telepíteni:
emerge -pv csomag
.
net: akkor oké. Annyi és olyan link kell, amennyi és amilyen hálózati csatolód van. Ha csak eth0, akkor net.eth0.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Blokkolás: akkor fordul elő, ha X csomagnak pl. 1.1-es verzió kell valamiből, Y-nak pedig 1.2-es.
Gentoo-nál a stabil ágban leginkább akkor fordul elő, amikor egyes csomagok úgy fejlődnek, hogy átveszik más csomagok feladatát. Ilyen volt pl. a shadow, illetve az udev is. Régebben a hotplug/coldplug külön csomag volt, majd egy újabb udev átvette ezt a feladatot. Ha fenn van a hotplug/coldplug, és frissíteni akarod az udevet, ütközni fognak, hiszen az új udev egyben coldplug is.Most biztosan van fent olyan csomagod, aminek a régi udev kell. A teljes frissítés viszont látja, hogy van újabb udev is, azt akarja feltenni. Az equery d udev kiírja, milyen csomagok függnek az udevtől, estleg azt is, milyen verzió kell neki.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Elméletben lehetséges, csúnya hackeléssel. Ahogy dr_strange írta: átírod az ebuildet, hogy más helyre telepítse.
Az Opera összes fontos cucca alapban a /opt/opera alá megy. Ebben van egy bin könyvtár, ahol a wrapper script van. A lib alatt verziónként eltérő könyvtárak - innen sejthető, hogy fent lehet több verzió is. (Pixmapek, ikonok, kis vackok a szoksásos /usr/share alá mennek, ez nem nagy baj, ha felülíródik más versióval.)De nem hiszem, hogy minden tökéletesen működne. Az Opera egy közös konfigot használ, a /etc/opera6rc-t, ha ez verziónként eltér, gáz.
Az ebuildet alaposan nézd át, mert nagyon sok helyen hivatkozik a végleges telepítési útvonalra, sok helyen kell átírni. Ezen kívül a kész telepítésben a bin könyvtárban lévő opera scriptet is át kell írni, mert az is hivatkozik. És a /usr/bin/opera linket is nézd meg, melyikre mutat.
Szerintem nem ér ennyit a dolog.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Van valaki, aki megpróbálkozott a következő, új generációs, nagysebességű cuccokkal?
- Paludis - a Portage package manager kiváltására
- einit - újfajta init system, xml alapú konfig
- initng - ez is, csak rc-config alapúNincs bátorságom feltenni, de érdekelne, mik a tapasztalatok, mekkora a sebesség-növekedés, stb, stb.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
De igen.
Eddig még csak szenvedek vele... Millió kapcsoló, ha nem használom, be akar húzni minden szemetet, a kimenete is elég olvashatatlan. Használni meg nem fogom, mert a manual utolsó 5 oldala csak ezekkel van tele.
I/O: a Portage baja nem az, hogy a telepítés esetleg lassú, hanem hogy egyre lassabb benne minden. A tervezése rossz. A Paludis valóban gyorsabb a csomagkezelési műveletekben, a --sync is egyszerűbb, a különféle cache-eket hamar generálja. Csak hozzá kéne szokni a kezeléséhez...
Sabayon: ugyanúgy, mint a Gentoo-t. A rendes működéséhez kell neki a Portage fa, emellé a Sabayon overlay. Innentől fogva én csak szívtam vele.
Karambol okés, pár hétig segítséggel öltöztem, de azzal már semmi gond. Csak nem merek autóba ülni.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz Proci85 #3278 üzenetére
Nekem Hauppauge és 2.6.24, de szinte minden kernel megcsinálja.
Esetleg előfordul, hogy /dev=lircx helytett /dev/lirc/x eszköz jön létre, de ez inkább a kernel- és lirc-fejlesztők ellentéte miatt, csak korábban volt jellemző.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz Proci85 #3281 üzenetére
Közvetlen lirc modul nincs. Nem ismerem a te tunered, de valszeg arra is integrálva van a vevő. Nálam csak a lirc_i2c és lirc_dev modul töltődik be, az i2c_* modulok mellett.
Viszont a v4l-modulok (bttv, conexant, ...) tartalmaznak kódrészeket, amivel az infrát kezelni lehet. Én mindig modulba teszem az összes v4l-drivert, és azt vettem észre, hogy az újabb kernelek olat is betöltenek, amit régen nem, és szerintem nincs is rá szükség.
A gpio modulra sosem volt szükségem - szerencsére, mert nekem régebben sem fordult le. Lehet, hogy neked is modulba kellene tenned a v4l-drivereket, hátha van köztük olyan, ami kell a lirc-hez.
Ja, a kernel IR moduljai máshoz kellenek, beépített infra-egységekhez, nem távirányítóhoz.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3301 üzenetére
Eddig úgy vettem észre, hogy ha a gcc nem ad internal gcc error, contact the developers hibát, akkor az adott programmal van gond.
Az, hogy csak adott revtől jön elő, megerősít ebben. (Csak egy tipp: esetleg a forrás olyan dolgokat használna, amit a 4-es gcc-ben vezettek be.)Egyik gépemen 4.1.2, másikon 4.2-es gcc van, semmi gondom nem volt még egyikkel sem. A 4.1.2 stabil, használhatod. Szerintem érdemes áttérni a 4-es gcc-re, a plusz tudása miatt.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3303 üzenetére
Ezt a hibát többnyire akkor dobja, ha kevés, és ezért elfogy a memória és swap, szerintem figyelmen kívül hagyhatod. Debugot miért kapcsolod be? Az is növeli a c++ programok fordításának memória-éhségét (ami egyébként is nagy).
Sorry, hardenedet elfelejtettem. Olyat nem használok. A /usr/profiles/hardened mappában tényleg hardmaszkolva van a teljes 4-es gcc sorozat... Pech.
Itt van pár infó arról, hogy mi vár rád, ha kézzel unmaszkolod a 4-es sorozatot, és hardeneddel akarod használni. (A 4-es még nincs felkészítve erre, ettől még működő kódot készít, csak az új funkciók nélkül.) Az utána következő válaszlevelek is érdekesek lehetnek.
Szerintem nem gcc hiba, a kmail is olyan, hogy a 800 mega memóriám eltűnik a fordítása közben. Evvan, én az rtorrentre gyanakszom. Nem hiba, inkább csak rosszul megírt kód lehet.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3305 üzenetére
Tudom, írtad, csak azért írtam le megint, hogy jelezzem, ez a c++ internal error nem az az internal error, amikor a gcc fejlesztőknek sürgős bugreportot kell írni.
Memory leak csak a gcc-ben lehetne, de ennél a régi verziónál ezt kizárom. Leak lehetne még valamelyik külső lib meghívása miatt, akár a debugolás, akár a 4-es sorozat egzotikusabb dolgainak kihasználásánál. Ez megint kizárt. LD-nél sem lehet gond, mert itt a linkelésig el sem jut.
Én alapból kikapcsolom a make.conf-ban a debugot, totál felesleges... Van még az ipv6 kapcsoló, próbáld meg annak ki- és bekapcsolásával is (meg egy xmlrpc is, azt is), hátha... ipv6-tal más jellegű problémáim már adódtak (ruby, ha jól rémlik), a hibának látszólag semmi közük nem volt az ipv6-hoz.
Szerintem rtorrent-hiba, ez a cc-fájl nem is nagy (a 0.8.0-ás verzióban), lazán vinne kellene a gcc-nek.
Jut eszembe, anno a kmailnél volt olyan kiadás, amit ugyanígy nem tudtam lefordítani. Ott valamelyik -r revvel patkolták. Ma is zabál, de legalább lefordul. Ilyenkor várni szoktam, majd csak kijavítják.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3307 üzenetére
Jááááá, vagy nem mondtad, vagy nem értettem!
Csinálj hozzá ebuildet! Alap: egy létező rtorrent ebuild, átnevezed rtorrent-9999.ebuild-re. Az elejére beteszed egy másik -9999 ebuildből azt a részt, ahogy az svn-ből cincálja a dolgokat. Szépen megírod.
Vagy ha nem akarsz tökölni: innen letöltöd, beteszed a lokális Portage-fába (alapesetben /usr/local/portage szokott lenni). Aztán unmaszk meg emerge.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3316 üzenetére
99%-ban mehetsz bugreportolni a gcc-teamnek.
Ha biztos akarsz lenni, próbáld ki (ugyanígy kézzel), hogyg++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -g -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT dht_manager.o -MD -MP -MF .deps/dht_manager.Tpo -c -o dht_manager.o dht_manager.cc
Illetve egyre kevesebb parancssori kapcsolóval. (A -M-esekre gondolok, az include maradhat. )
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3321 üzenetére
Jajj, de kár, hogy csak most olvasom, így nem írhattam be ugyanezt.
A 3.4.6 nem ancient. A 3-as és a 4-es két külön állatfaj, nem fognak elhajtani emiatt.
Én a bugs.gentoo.org-ot jobban csípem, mert az ottani fejlesztők nagyon szoros kapcsolatban szoktak állni a programfejlesztőkkel. A gentoo-t sok progrsmíró használja amolyan homokozóládának, mert a forráskód proglémái itt tutira előjönnek. Ha a Gentoo-soknak írsz, úgyis eljut a gcc-sekhez is.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Ez furcsa. A kdm KDE-s program, mikor betöltődik, a qt-t, a kdebase libet be kell töltenie, valamint a kdeinit, dcopserver is elindul, nem?
A local.start-ba tegyél be valami kis hülye KDE-s programot, az a kdm után indul el, amikor már van Xorg. A kimenetét irányítsd a /dev/null-ba. Következő sorban vársz pl. 10 másodpercet, majd kinyírod.A prelink nem ehhez kell, az a programok, könyvtárak szerkezetét alakítja át, hogy ami libeket meghívnak, egy helyen legyen, a loader könnyen, a program indításakor egyből megtalálja, mikre lesz szükség, és be tudja tölteni. Így nem kell az egész kódot átnéznie, miket kell hívni.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Persze, tapasztaltam. Az ablakkezelő cuccait, kwin, session manager, be kell tölteni - a kdm azt még nem húzza be. Ja, meg elkészül a személyre szabott sycoca adatbázis... Ezt tényleg csak akkor lehet előre tölteni, ha elindítasz valamit.
Tipp: van egy LD_PRELOAD nevű változó. Ezzel indítva rogramokat megadható, hogy a mögé írt libek előre töltődjenek be, minden más előtt. Azt nem tudom, mire vonatkozik, lehet, hogy csak a tényleg betöltődőkre, de egy próbát megér.
A kdm hívását pl.
LD_PRELOAD="azok a kde libek, melyek login után töltődnek" kdm
alakra írod át. Ha mákod van, ez behúz mindent, amit felsorolsz.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz tierbatyo #3337 üzenetére
Nézd meg a létrejött config.logot is, az bőbeszédűbb szokott lenni.
Van olyan, hogy az xy lib ellenőrzése azért hiúsul meg, mert az a lib ugyan megvan, de valami más, ami ennek kell, rossz, hiányzik. Lehet, hogy nem is a pitonnal van a huba.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3343 üzenetére
Nem hagysz ki semmit. A kernel üzenetében az van, hogy force use of acpi=ht. Valami miatt bekapcsolja az ACPI-s HyperThreadinget, ami olyan procin, ami nem támogatja, egyenértékű azzal, mintha kikapcsolnád az acpi-támogatást.
Talán a kernelnek meg kellene adni az acpi=noht kapcsolót, vagy kísérletezni a különféle acpi= kapcsolókkal, hátha valamelyiknél nem akar HT-t.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3352 üzenetére
A bind-tools része az nslookup és a host is.
Az első haosnló a Wineshez, ha nem adsz, a default DNS servert használja, ha kötőjelet teszel utána, az utána álló nevet/címet.A fejlettebb host parancs pedig olyan, hogy ha egy nevet adsz meg neki, azt keresi, ha még egyet, azt a DNS szervernek veszi.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Ha ezeket bekapcsolod, mi történik?
[ ] USB announce new devices
[ ] USB device class-devices (DEPRECATED)
[ ] Dynamic USB minor allocation (EXPERIMENTAL)Úgy nézem, ez nagyon új kernel lehet, úgyhogy ne tévesszen meg a deprecated kifejezés. Egy 2.6.26-os kernel eléggé eltér a 2.6.21-től is, de ez utóbbi sem nevezhető réginek.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Ha a dmesg ki sem írja, hogy megtalálta, nem ez a gond. A haldaemon csoport a hal-nak kell, nem kell, hogy tagja legyél.
Tuti, hogy hiányzik valami a kernelből, ami a dinamikus felismeréshez szükséges. Bootnál felismeri, mert akkor direktben végigszkenneli az összes eszközt.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3389 üzenetére
Szerintem a fő rsync szerverrel van valami gond - pár napja időnként "file size not match" hibát kapok sync után. Random ebuildek más méretűek lesznek, mint ami a manifestben van.
Egyszer volt ilyen, amikor a fő rsync merevlemezei teljesen bekepáltak, későn kapcsolták le, és majd az összes alszerver átszinkronizált róla. Akkor azt hittem, szétment a vinyóm, de kiderült, csak a Portage fa volt rossz.
A websync vagy a daily snapshot megoldás ilyenkor.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Szia!
Az OOo-t nem érdemes forrásaból feltenni, gyorsabb nem lesz tapasztalatom szerint. Ellenben _nagyon_ sokáig tart, és mivel nagyon érzékeny a beállításokra, verziókra, valószínűleg az első pár fordítás hibával le fog állni.
A KDE-t a mobil Pentium3-as laptopomon kb. egy nap alatt cakompakk újrafordítani. Böngészőből Operázok, azt nem lehet fordítani, csak binárisan feltenni. Mozillából i svan bináris csomag, szerintem azt sem érdemes (zgyanaz, mint OOo-nál.)
Szerintem ne aggódj, ha bekapcsolva tudod hagyni a gépet, kb. egy nap alatt meglesz egy újrafordítási ciklus KDE-ből. A többi pedig nem vészes, nem frissül minden naponta. Ha nem engedélyezed a "béta" programokat (make.conf-ban az ACCEP_KEYWORDS nem ~x86), viszonylag ritkán lesznek frissítések. KDE-ből érdemes minden csomagra egyesével bekapcsolni, meg pár függőséghez, de abból meg havonta egyszer van teljes verziófrissítés.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz klayton#1 #3402 üzenetére
Szia!
Ha PONTOSAN azt írtad, amit a kézikünyv, az is lehet baj.
Valszeg rossz eszközneveket adtál meg a grub konfigjában. Mi a pontos hibajelzés? Mit ír ki?A Gentoo telepítőcédéjéről be tudsz bootolni, majd a leírás szerint csatold a partíciókat, amire telepítettél, meg a devet, procot, stbt. Vagyis kövesd a telepítési útmutatót (partícionálás és formázás nélkül ) addi, amíg chrootolsz az új környezetbe! Ekkor belemész a telepített Gentoo-ba, és újra konfigolni tudod a grubot.
Ha az első vinyóra tetted, akkor hd0 a vinyó neve, a a másodikra, hd1. Az első partíció is 0, vagyis ha pont olyan a vinyókiosztásod, mint a telepítésnél, akkor hd0,0 lesz a root helye.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz klayton#1 #3404 üzenetére
Hm, kicsit furcsa, hogy KÉT darab bootolható partíciód van. Nekem dualbootos gépen csak egy, a Windows-é, mert az máshogy nem indul. Szerintem szedd le az sda2-ről a boot csillagot.
Az utolsó sorok meg hogyafenébe ne lennének fontosak! Abból derül ki, meddig jutott és hol hal le.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz klayton#1 #3406 üzenetére
Ez vagy azt jelenti, hogy nem jó a root= paraméter, nem jól adtad meg a root partíció helyét, vagy esetleg nincs a kernelben az IDE-vezérlőd beleforgatva. (Modulként nem jó.) Ha sda2 a root, akkor az jó, a kerneleddel lesz gond.
Ha kézzel csináltad, akkor a chipsetnek megfelelő drivereket bele kell tenni, de első próbálkozásnak csináld inkább genkernellel, az mindent beletesz modulként és megoldja, hogy jó legyen. (Kell a vezérlőd drivere, meg vinyótámogatás, meg nem emlékszemmég mik.)
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz klayton#1 #3408 üzenetére
Maradhat, mert a grub install csak annyit csinál, hogy (ha kell) a bootszektorba beleírja magát, meg kiteszi a megfelelő helyekre a saját fájljait.
Később legfeljebb a grub konfigban kell a sokadig kernelt hozzáadni, vagy a kernel paramétereket megadni.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz klayton#1 #3410 üzenetére
Asszem ez attól van, hogy genkernellel csináltad, ami RAMdrive-os indítást készít. De ehhez a leírásban kövesd az utasításokat, hogyan kell a grubot beállítani, mert teljesen más! genkernel esetén szinte mindent modulba pakol, még a merevlemez-kezelést is. Emiatt a bootnál betölti a kernel moduljait memóriába, onnan dolgozik, és csak utána csatolja a root fájlrendszert.
A block a blokkeszközt jelöli, nem ismeri fel, mi az az egyes vinyó első partíciója.
S
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Új hozzászólás Aktív témák
- Politika
- Hobby elektronika
- Elkészült Oroszország első litográfiai berendezése
- Redmi Note 12 Pro - nem tolták túl
- Kerékpárosok, bringások ide!
- Honor Magic5 Pro - kamerák bűvöletében
- Luck Dragon: Asszociációs játék. :)
- Eredeti játékok OFF topik
- Motoros topic
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs