-
IT café
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz inf3rno #28977 üzenetére
Attól függ, hogy kinek, mire kell. Desktop vagy server, milyen adatintegritási szint kell. Rendszeres biztonsági mentéseket készítő mezei desktop felhasználónak elég egy ext4 is. Esetleg egy btrfs snapshotozással. ZFS átlag desktop felhasználásra overkill, de szerverre meg teljesen jó. Kipróbálhatod most már mind a kettőt, a ZFS is támogatott a kernelben. Én azt még nem próbáltam, csak a btrfs-t, úgy 2 éve, akkor sem volt gondom vele.
Annyit persze még tudnod kell, hogy minél többet tud egy fájlrendszer, annál inkább jobb vas kell alá, meg több memória. Ilyen szempontból az ext4 még lájtos, a btrfs már combosabb, de azon is attól függ, hogy milyen feature-öket kapcsolsz be, a legerőforrásigényesebb a ZFS.
-
Frawly
veterán
válasz vargalex #28988 üzenetére
Az ilyen dolgain ki tudok akadni én is. Látszik, hogy sok mindent windowsos szemmel közelít meg. Azt sem értem, hogy egy shared memory szegmens hogy lehet gyanús.
Én első körben a problémáját érintve, megnézném hányas Firefox, megpróbálnám a Firefoxot safe mode-ban indítani, csinálnék egy pinget belső és külső cím felé is, lefuttatnék egy iw dev eszköznév station dump parancsot.
Hasonlót még az is tud okozni, ha névütközés van a hálózaton, pl. két gépnek azonos a host neve. De őt ismerve, hogy össze-vissza berheli a rendszerét mindenféle saját root-os megoldással, lehet bármi a probléma. Így a legbiztosabb az lenne, hogy egy új, Live Ubuntu-ról is kipróbálni, hogy ott csinálja-e.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #28998 üzenetére
Abban egyetértek, hogy az rkhunternek utánanézhettem volna. De ha ettől boldog vagy, most megtettem. Egy rootkit elemző. Na már most két eset lehetséges. Vagy csak tévesen riasztott be valami heurisztika miatt, vagy a böngészőben futott valami olyan oldal, ami tartalmazott valami rosszindulatúnak minősített ad/miner scriptet. Emiatt én baromira nem aggódnék, hogy Ubuntun rootkitet szedtél volna össze.
Vagy ha mégis sikerült, akkor kitüntetünk, mert te lennél az első, akiről hallottam, hogy összeszedett támogatott desktop Linuxon valami csúnyaságot. Olyanról olvastam, hogy valaki hosszú évek óta nem frissített szerveren szopott be openssl heartbleedet, vagy valami ransomware-t, azt is valahol Kínában, de hogy még jelenleg támogatott desktop disztrón szedje össze valaki, olyanról nem hallottam még.
Ha viszont a GUI lefagy, akkor nem a böngészőben meg a hálózatban kéne a hibát keresni. Először a dmesg logban, journalctl-ben nézném meg, meg a X.org logban.
-
Frawly
veterán
Én jelenleg a QEMU-t használom KVM-mel, ahhoz ha telepíted a ovmf csomagot, és megmutatot a proginak az OVMF_CODE.df binárist, akkor UEFI-t használ, és ahogy a menüjében matattam, Secure Bootot is tud. Viszont én nem ajánlom, hogy Secure Bootot használj, sok előnye nincs, de az OS telepítéseket rendkívül megnehezíti.
-
Frawly
veterán
válasz inf3rno #29067 üzenetére
Nem sarkítás, igazuk van. A RAID a backupot nem váltja ki. Mert hiába a rendelkezésre állás, meg a fájlrendszer checksumja, az ellen nem véd, ha pl. emberi hibából, vagy szoftveres bugból adódóan felülírsz adatot, törölsz, vagy pl. ransomware darálja be. Vagy pl. a RAID és a fs checksum hibakorrekciós képessége is korlátos, ha túl sok lemez esik ki, vagy túl nagy blokknyi adat sérül, arra védelmet nem nyújtanak. Backupnak mindig lennie kell, hiába a redundáns RAID megoldás, utóbbi tényleg arra jó, hogy ha a lemez hibájából esik ki valamennyi, akkor legalább a rendelkezésre állás meglegyen.
Sokan tévesen hiszik, hogy jujj, RAID, akkor teljesen védve vannak, és nem kell backup. De, kell.
[ Szerkesztve ]
-
Frawly
veterán
válasz Dißnäëß #29082 üzenetére
Pont azért egyesítették a két ZFS projektet, hogy ne legyen eltérés a kódok között. ZFS esetén valóban nem szükséges a softraid.
inf3rno: azért az ritka, ha valahol olyan sok tera gyorsan változó adat van, ami már a mentés készítése alatt megváltozik. Eleve a háttértárak korlátozott sávszélessége is korlátozza ennek az előfordulását. Attól is függ milyen adatot akarsz menteni, meg milyen fájlrendszerről.
-
Frawly
veterán
válasz inf3rno #29086 üzenetére
A snapshot sérült biztosan nem lesz. Legfeljebb egy időállapotot nem konzisztensen mutat. Ja, ez a megoldás sem mindenható, ha az lenne, akkor kihaltak volna a backup szoftverek és mindenki snapshotokat készítene kizárólag.
De mondom, ennek a gyakorlati jelentősége kicsi, mert olyan rendszerről, aminek a tartalma már a backup készítése alatt megváltozhat. Nyilván, ha tudod, hogy neked ilyened van, akkor más megoldás után kell nézni, vagy le kell csatolni a kötetet, és úgy backupolni.
-
Frawly
veterán
válasz Dißnäëß #29094 üzenetére
Nem a guest-ben kell a discard-ot beállítani, hanem a host OS fájlrendszerében, amin a qcow2 képfájl van. Kivéve, ha az SSD-t fizikai egészében adod át a virtuális gépnek, mert akkor a guest-en kell állítani, a host pedig nem használja.
(#29097) bambano: robokuty nagyon eltűnt mostanában.
-
Frawly
veterán
válasz samujózsi #29099 üzenetére
Most hogy újra végiggondolom, igazad van. Mégis csak át kéne engedni, különben a fizikai host gépen hiába van TRIM, ha úgy látja, hogy az egész qcow2 fájl foglalja a saját lemezterületét, hiába lett valami törölve belőle, nem szabadul fel a már nem használt blokk belőle.
Ezen a linken az első válaszban adnak meg működő példát.
De a legtisztább az lenne, ha az SSD oda lenne dedikálva fizikailag a virtuális gépnek, mert akkor semmit nem kell átengedni, a guest-en elég simán beállítani a TRIM-et.
Illetve NVMe-n nem tudom hogy lehet megoldani. Mert a TRIM parancs csak PATA/SATA/AHCI SSD-khez van, az UNMAP csak SCSI/SAS/UASP interface-esekhez. NVMe-n viszont a TRIM-et végző parancs bele van integrálva más lemezműveletekbe, ezért külön nem lehet meghívni, meg semmin keresztül átengedni. Na már most nem tudom, hogy a discard átengedése ezen mit segít.
-
Frawly
veterán
válasz MasterMark #29104 üzenetére
NVMe-n elvileg kikapcsolhatod, nem kell külön TRIM-et futtatni, sem fstrim, sem discard mount opció formájában. A TRIM-elést végző parancs be van építve az NVMe protokollba. Ezt tesztelni is lehet, kikapcsolt TRIM mellett létrehozol egy tesztfájlt, majd letörlöd, és megpróbálod helyreállítani. Ha helyre lehet, akkor nem lett trimelve, ha nem, akkor a trimelésről gondoskodott az NVMe driver.
-
Frawly
veterán
válasz Papooo #29111 üzenetére
Az ciki, ha ennyire nem lehet életre kelteni rajta semmit. BIOS resetet próbáltál rajta vagy load defaults-ot? Sok laptop tud olyan, hogy vagy már közvetlenül UEFI BIOS-ból tud frissíteni, ha kap címet Ethernet kábelen át DHCP-ről, vagy tudnak olyan módot, hogy bootoláskor ha benyomsz a szájába egy FAT32-re formázott pendrive-on egy új BIOS lemezképet, és nyomsz valami spéci billentyűt, akkor felfrissíti onnan magát. Ezt a konkrét gépet nem ismerem, de meg lehetne próbálni.
Emulátorból és virtuális gépből sose fogsz tudni BIOS-t frissíteni. Esetleg Linux alól, de nem tudom, hogy Lenovo-nál ez megoldható-e, sok esélyt ennek a vonalnak nem adok.
-
Frawly
veterán
válasz Frawly #29139 üzenetére
A net szerint az az oka, hogy nem találja az init-et. A root partíció meg van neki adva, a szokásos módon, root=/dev/sda2, ez működött is az 5.5-RC1 kernelnél, ami viszont Gentoo tárolóban volt. Az persze logikus lenne, hogy az initet nem találja, mert alapból az init=/sbin/init fájlt keresné, de Gentoo-n olyan nincs, /sbin/openrc-init van helyette. De az sem segít, ha megadom bootkor kernelparaméterben, hogy init=/sbin/openrc-init, épp ugyanezt a hibát dobja.
-
Frawly
veterán
válasz samujózsi #29141 üzenetére
Nem maradt ki, a root fs ext4, és próbálkoztam már a rootfstype=ext4 kernelparaméterrel bootoláskor, az sem segít. Most a virtio támogatást fordítom bele, mert QEMU virtuális gépen fut.
Megnehezíti a hibakeresést, hogy nem tudok visszagörgetni, így nem látszik a kernelpanic legelső sora.
-
Frawly
veterán
válasz samujózsi #29143 üzenetére
Látod, ez jó kérdés. Szerintem max modulként van benne. Hogy fordítsam bele jobban?
Ahogy nézem, ez a baj. Most el sikerült olvasnom a kernel panic elejét (virtuális gép UEFI firmware-jében vettem fel a felbontást, így több sor marad meg). A RAID detektálás után fullad le. Nem a RAID a baja, mert olyat nem használok, meg letiltottam a raid=noautodetect paraméterrel.
Ami az md RAID betöltése után következne az a root filesystem (egy bootoló kernelnél megnéztem), ezt már nem írja, ehelyett van:
BUG: kernel NULL pointer dereference, address: 0000000000000Tehát az a baja, hogy a root filesystem-et nem tudja csatolni. Igazoltam ezt úgy, hogy megadtam neki kernelparaméterben egy szándékosan kamu rootot: root=/dev/sdb1. Akkor is ugyanilyen kernel panic kíséretében száll el.
Pedig sima GPT partíciókat használok, semmi spéci titkosítás, RAID, LVM vagy hasonló bonyolítás. UEFI EFI stub boot, de a Secure Boot is ki van kapcsolva.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #29145 üzenetére
Initramfs sincs, nem is kell, anélkül is bootol ugyanezen a virtuális gépen Gentoo rendszeren a 4.9.86 és 5.5-RC1 kernel is. A modulnál már értem mit mondasz. A menconfig - Filesystems - Ext4 mind a négy opciója [*]-gal van (statikusan) belefordítva, nem modulként (ami M lenne).
De valami miatt mégse tudja felcsatolni a root partíciót, pedig biztosan /dev/sda2, a többi kernel, amiket említettem, azok fel is tudják épp így csatolni EFI stub bootban, initramfs nélkül. Csak ez a kernel.org-ról származó 5.5-RC2 nem tudja. Próbáltam úgy is, hogy root=PARTUUID=b14b1a-b1a-b14-b1ab1a formában adom meg, az sem segít. Így most vagy nem találja meg a root-ot, vagy megtalálja, de nem tudja felcsatolni.
Az is biztos, hogy a root partíció sima ext4, és fájlrendszerhibák sincsenek rajta, a működő kernelek is le fsck-zzák és mindent rendben találnak.
Egyébként a müködő kerneleknél ez látszik az md sorok mögött, ennek kéne történnie kernel panic helyett:
[ Szerkesztve ]
-
Frawly
veterán
A gentoo-s kernelek is bootolnak épp úgy, ext4-ről, initramfs nélkül. Initramfs akkor kell, ha van RAID vagy LVM vagy titkosítás, esetleg a /var, stb. másik partíción lenne a roothoz képest. De ezen speciális esetek EGYIKE SEM áll fenn. Pont azért írom, hogy sima ext4 partíció, semmi extra konfig, semmi extra mount paraméter nem kell. Tehát nem ez a gond. RAID-et sem használok, csak azért lett említve, hogy nem ez a gond, hiába az md-s sorok után hal be. Egy későbbi screenshoton becsatoltam a kernel panic elejét is.
Ezt a tty konzolos mókát ki fogom próbálni. Egyébként nekem nem az a bajom, hogy nem működik, hanem hogy nem írja ki normálisan, hogy mi a baja. Lehet valami kernelfordításkor maradt ki, mert make defconfig-ot használok, de utána végigszaladok rajta egy make menuconfiggal, hogy még beletegyek 1-2 dolgot, de lényegben defconfig az egész.
[ Szerkesztve ]
-
Frawly
veterán
válasz Papooo #29117 üzenetére
Egy ötletem van a problémád megoldására. OFF topik, de azért ideírom. Szóval fogsz egy akármilyen OS-t, lehet akármilyen Linux is, Ubuntu vagy Mint vagy ami tetszik. Feltelepítesz rá egy QEMU virtuális gépet, meg hozzá virt-managert. Letöltöd a Win10 legújabb iso-ját a MS oldaláról. A virtuális gépet úgy indítod, hogy odaadsz neki kompletten egy min. 32 gigás pendrive-ot vagy külső HDD-t, vagy külső SSD-t. Feltelepíted erre virtuális gépen a Windows 10-et. Mikor feltelepült, leállítod. Kilépsz a virtuális gépből, a pendrive-ot leválasztod. Újraindítod a gépet, és bootolsz a külső meghajtóról. A Win10 Win to Go módban fog indulni. Ez alól tudsz BIOS-t frissíteni.
A másik még egyszerűbb módszer, hogy szerzel a gépbe egy belső meghajtót. Erre meg pendrive-ról feldobod ugyanezt a Win10 lemezképet. Nem kell termékkulcs sem, mikor kérdezi, akkor arra nyomsz, hogy majd később adod meg. A Windows lehet aktiváció nélkül valami 90 napig vagy meddig használni. Neked elég lesz az az egy nap, amíg BIOS-t frissítesz alóla.
-
Frawly
veterán
válasz Jester01 #29157 üzenetére
Megnéztem közben ezeket. Ezek be vannak kapcsolva. De egyéb oldalról is kizártam a konfighibát. Az 5.5-RC1 Gentoo git kernel ebuild konfigját használtam, amivel bootolt az RC1. Ez az RC2 ezzel sem bootol. Szóval nem a konfig a gond. Szerintem ez egy RC2 specifikus bug. Túl új még az RC2-es kernel, 2 napja sincs, hogy kijött.
Esetleg nem bug, hanem a Gentoo-n van úgy valami megoldva, hogy valami speciális patch-t igényel, amit a kernel.org-os git kernel nem tartalmaz. Bár ezt kevésbé tartom elképzelhetőnek, de azért nem zárható ki.
-
Frawly
veterán
válasz Papooo #29160 üzenetére
Akkor ez bukta. Hacsak szerviz nem tud neked frissíteni. Linux alól nem fogsz tudni frissíteni, a gyártó csak olyan BIOS-t adott ki, ami kizárólag Windows alól frissíthető. A virtuális gép és emulátor meg azért nem jön szóba, mert azoknak meg pont az a lényege, hogy ne férj hozzá a host géphez, ne tudjon a virtualizált vagy emulált szoftver belebarmolni. Tehát nem éred el a gép hardverét.
Bár eolyan ötletem van, hogy a Windows telepítő által tartalmazott .wim lemezképet kézileg felhúzni a merevlemezre. Ugyanis a modern Windows telepítők (Vista és későbbi verziók) nem telepítik már a rendszert, nem építik ki, hanem egy általános, készre telepített lemezképet klónoznak rá a meghajtóra, majd ezt átméretezik akkora méretre, ami a telepítési célpartíciónak megfelel. Ezt viszont te kézzel is meg tudod csinálni, láttam erről egy YouTube videót, ahol a fószer P2-es gépre akart modern Windows húzni, persze nem sikerült neki működőre, de azt mutatta, hogy ilyen .wim lemezképet kézileg is fel lehet húzni. Nem biztos, hogy neked segít, mert ha sikerül is, semmi garancia nincs rá, hogy a Win logó után nem indul az is újra.
-
Frawly
veterán
válasz Papooo #29162 üzenetére
Kissrácnak ne laptopot vegyetek gamer-kedni, laptopon gamerkedni luxus. Ilyen ócska E1 procis meg U-s procis laptop nem való amúgy sem játszani, még akkor se, ha diszkrét GPU van benne, a proci thermal vagy power throttling miatt az sem tudja kifutni, amit tudna, és általában az ilyen gépeket ócska TN-es kijelzővel látják el. Az igazi gamer laptopok meg ultra drágák, baromi hangosak, stb..
Vegyetek neki egy jó ár/értékarányú, olcsó Ryzen 1600-2600-os gépet, olcsó B350, B450-es lappal, min. 8 GB RAM-mal, egy használt, piszok olcsó RX570-es GPU-val, meg egy 30k-s FullHD Freesync IPS monitorral. Egy ilyen gépen lehet rendesen játszani, a legtöbb játék 1080p High Graf, 60 fps-sel elfutkároz. Még a legújabb, legbrutálabb játékcímek is. Meg egy ilyen gépet később is könnyű bővíteni, ilyen-olyan upgrade-ekkel használható vagy 10 évig, sokkal gazdaságosabb és jobb egy ilyenen játszani.
[ Szerkesztve ]
-
Frawly
veterán
válasz Papooo #29168 üzenetére
Ja, hát 35k-ból ne akarjon semmit játszani szegény gyerek. Max. pasziánszt, Super Mario-t, esetleg Half Life 1, GTA 3-VC. Ilyen Half Life 2, Far Cry 1, Doom 3 szintű gamma már necces egy 35k-s cuccon. Ha annyira szűkösek az anyagiak, akkor a legolcsóbb játékra venni egy használt PS4-et vagy Xbox-ot, de olyat, aminek tiszta az előélete, nincs bannolva. Esetleg venni valami refurb helyről egy kiselejtezett céges Optiplexet, i5-i7-es proci, 2-3. genes, min. 8 GB RAM, meg mellé venni egy legalább GTX 750 vagy R7-R9 AMD kártyát, ez talán összesen kicsit kevesebből áll meg, de azért jóval több lesz ez is, mint 35k.
A T530-as laptop már egy fokkal jobb próbálkozás, de az is min. i5-ös legyen, és én még kötnék rá eGPU-ként egy szintén GTX 750-1050 szintű használt kártyát, valami olcsót, ami 20k körül vagy azalatt megáll. 35k-ból ez sem fog kijönni, talán a laptop, ha refurb vagy leharcolt, de az eGPU-s megoldás efölé benne fog fájni egy másik ~30k-ba.
A WoT meg egy olyan játék, aminek folyton változik a hardverigénye. A régi verzióknak nem volt nagy, anno, mikor kijött, de fokozatosan fejlesztik a motorját, grafikáját, így egyre combosabb gép kell alá.
-
Frawly
veterán
válasz Frawly #29159 üzenetére
Beigazolódott, hogy az 5.5-RC2 kernel.org vanilla kernel bootképtelensége egy kernelbug, nem csesztem el semmit, nincs baj sem az ext4-gyel, sem az init-tel, és nem is a Gentoo hibája. A kernel.org-os 5.5-RC1 simán bootol defconfig-os fordítás után, szintén mindenféle initramfs nélkül. Majd vasárnap vagy hétfő hajnalban megnézem az RC3-mal.
Szerintem a kernelbe bekerült egy regresszió, ami miatt megfekszik QEMU alatt. Natív telepítésben ez a bug lehet elő sem jön, nem is jelentette még senki.
-
Frawly
veterán
-
Frawly
veterán
Feltettem pár hozzászólással később a hibaüzenet első felét is. Lényegében a legelső sor volt a lényeg, NULL pointer dereference. Magyarán csak olyan memóriaterületre nyúlt, amihez nem kellett volna, szimpla bug miatt totálisan összefosta magát. Ez még oké is, de akkor a kernel panic végére ne ilyen attempted to kill init baromságot írjon, félrevezetve az embert, hanem írjon akkor unknown error, vagy erre a NULL pointer reference dologra mutató dokumentációs linket.
Az amatőr ügyfélszolgálatok szoktak ilyen baromságokat javasolni, hogy egyszerű netkimaradásnál vagy energiagazdálkodási beállítás miatti gikszernél is újratelepíttetik a Windowst, csak hogy ki legyen zárva a hiba, kényelemből félrevezetik a laikust.
Mondom, nem az a baj, hogy nem ment, mert arra számítani lehetett, hogy a legfrissebb RC nem épp a legstabilabb dolog a világon. Csak akkor ne vezessen félre a hibaüzenet, jól megvezetett, mert még nincs a témában nagy tapasztalatom, és emiatt magamban kerestem a hibát, vergődtem mindenféle konfiggal, partíciócsatolással, init problémával, közben a hibának 0 köze volt ezekhez.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #29200 üzenetére
Igazatok van, egy működő kernel kimenetét csatoltam, de elfelejtettem a hibaüzenet elejét becsatolni. Íme:
Az 1.904...től érdekes:
BUG: kernel NULL pointer dereference, address: 0000000000000Azt a tty-os trükköt még nem próbáltam, amit írtál. A QEMU konzolját viszont néztem, nem látszik benne a kernelkimenet, csak az UEFI BIOS kimenete. De könnyen lehet, hogy ez az én hibám, mert a QEMU-nak még be kéne adagolni valami paramétert, hogy látszódjon.
-
Frawly
veterán
válasz samujózsi #29211 üzenetére
Nem működik ez a tty. Próbáltam ezeket console=/dev/ttyS0 console=ttyS0 console=tty. Külön-külön persze, nem egyszerre.
Kernelparaméter nincs, se quiet, se semmi. Vagyis root=/dev/sda2 mitigations=off logo.nologo, de ezek kernelfordításkor lettek a kernelbe beleforgatva.
(#29212) Jester01: örömmel olvasom. De nem vagyok benne biztos, hogy ez az a bug. Ugyanis próbáltam rw paraméterrel is root partíciót felcsatolni, és nem működött, de lehet rossz helyen adtam meg. Meglátjuk, két nap van hátra az RC3-ig.
-
Frawly
veterán
válasz samujózsi #29215 üzenetére
Még egyszer hangsúlyozom: ez minimalista, openrc-s Gentoo base rendszeren kézzel forgatott, defconfigos vanilla kernel, EFI stub bootal, GPT-s meghajtóról, FAT32 EFI partícióról indulva, ext4-es root partíciót használva. Se kernel patch-ek, se GRUB, se initramfs, se systemd, se Gnome, se dbus, semmi, se quiet, se spash screen, se semmi sallang. Nem csak a tanulás miatt szenvedek ilyesmivel, hanem nem akarok mainstream disztrót, mint az Ubuntu, ami tele van vágva 99%-ban számomra teljesen nélkülözhető dologgal. Ha csak az lenne a cél, hogy valami Linux működjön, 2 perc alatt felhúznék egy Ubuntut, Mintet, Manjaro-t, vagy 15-20 perc alatt egy Arch Linuxot. Itt most az a cél, hogy saját magam részére a legminimalistább, de még használható saját disztrót dobjak össze, amiben egy deka sallang nincs.
Egyébként valószínű, hogy ehhez, amit írsz, a kernelbe kéne forgatni valami plusz opciót, hogy működjön, a defconfig nem tartalmazza a szükséges dolgokat. Legalábbis én erre tudok gondolni, mert elhiszem, hogy Ubuntu-n ez simán megy, az ő foltozott, full extrásan fordított kernelükkel.
Kernelparamétereket persze meg tudok adni, az UEFI BIOS-ba belépek Esc-kel, ott a Boot Options-ben el tudom indítani az UEFI vészkonzolt, azzal kapok egy shell-t, ott el tudok navigálni az EFI partíció adott bzImage kernelfájljára, ami egyben egy EFI bináris is, és ott kézzel be tudom adagolni a paramétereket, úgy tudom indítani. Tehát csak az EFI shellben beverem ezt:
fs0:\EFI\Gentoo\bzImage console=/dev/ttyS0 console=ttyA "console=/dev/ttyS0 console=tty" paramétereket próbáltam egyszerre is. A kernel rendben bootol, de átváltva a QEMU serial console-jára, abban csak az UEFI shell látszik, a kernel kimenete nem.
-
Frawly
veterán
válasz bambano #29219 üzenetére
Az elvileg bele van fordítva. Legalábbis vonatkozót csak a menuconfig - Device Drivers ---> Character devices ---> Serial Drivers részben találok, de itt minden be van kapcsolva:
* 8250/16550 and compatible serial support
* Console on 8250/16550 and compatible serial port
* 8250/16550 PCI device support
* Extended 8250/16550 serial driver options
és még egy csomó ilyen 8250/16550-es dolog: sharing interrupts, autodetect IRQ, RSA serial ports support, Intel LPSS/MID support.Egyedül csak speciális, konkrét UART eszközöknél nincs csak *, mint pl. Altera UART support, ARC UART driver, stb..
Elhiszem pedig, hogy működnie kéne, pl. Ubuntu kernellel. A QEMU verziója sem baj, a legújabb 4.2.0-ás stabil QEMU-t használom, tehát nem elavult, meg nem dev/béta verzió.
-
Frawly
veterán
válasz inf3rno #29218 üzenetére
Neked külön válaszolok: szerintem az lesz, amit írsz, erre én is gyanakodtam már. Ti GRUB-bal próbáljátok, én meg EFI stub boottal, utóbbinál nincs semmilyen külön boot manager. Ez simán lehet oka, hogy esetleg a soros porti konzol nem irányítódik át megfelelően a soros port kimenetére.
-
Frawly
veterán
válasz Frawly #29216 üzenetére
Még annyit, hogy úgy tűnhet, hogy az Ubuntut, Mintet, Manjaro-t ekézem, de nem állt szándékomban. Teljesen megértem, hogy miért használnak ezek a disztrók bloatabb, de általánosabb megoldásokat. Pl. GRUB, initramfs, systemd, full extrás DE. Ezek sokfélébb használathoz passzolnak, és sokkal problémamentesebben lehet belőlük hülyebiztosabb megoldásokat gyártani. Hiszen ezen disztrók célközönsége sokkal szélesebb, a mainstreamebb, laikusabb emberkéket szolgálják ki, inkább a kezdőket, és nekik jobb egy olyan általános megoldás, ami teljes körű szolgáltatást nyújt, lefedve mindenféle felhasználási kört, kevesebbféle szituban mond csődöt, cserébe bloat lesz. Ezen disztróknál ez kényszerpálya, nem hibáztatom a disztrókészítőket ezen döntéseikért, teljesen logikus lépés tőlük. Sokkal hülyebiztosabbnak kell lenniük, sokkal univerzálisabbnak. Ha ezt nem teszik, akkor a laikus azonnal úgy érzékeli, hogy xaralinux, meg esse-asse-megyen rajta, és pattintják is vissza a Nyílászárókat. Tehát ezen kezdőbarát disztrók felelőssége sokkal nagyobb, hogy ne taszítsák el a kezdőt, ne szolgáltassanak kudarcélményt, hanem hatékonyan népszerűsítsék a Linuxot.
De van egy olyan pont, amikor ez a túlzott univerzalitás, meg bloatság már egy tudásszint felett felesleges, mint a segédkerekek a biciklire, ergó el kell őket hagyni. Így ha az ember tudja konkrétan, hogy mire van szüksége, akkor csak kizárólag azokból jobb egy egyéni személyre szabott sovány, minimalista rendszert csinálni, sokkal pattogósabb, erőforrás-kímélőbb, sallangmentesebb lesz. Meg szakmailag is nagyobb sikerélmény, és tanulási lehetőség. Mert mennyivel jobb az a rendszer, aminek minden elemében az ember saját maga dönt, nem döntik el helyette, a rendszer minden eleméről pontosan tudja, hogy micsoda, mihez kell, és azt is, hogy tényleg kell, nem váltható ki.
-
Frawly
veterán
válasz samujózsi #29229 üzenetére
Pedig a QEMU hálókártyáját nekem simán kezeli a defconfigos kernel. Szerintem a soros konzol hiányáról sem ő tehet, ez valami QEMU-s vagy OVMF UEFI firmware-es probléma lesz.
Az efibootmgr -v leközli, hogy milyen paraméterekkel lett felvéve indításra az adott kernel. Ha viszont a jelenleg beboolt rendszeren valami egyszeri, speciális paramétert alkalmaztál, pl. EFI shellből, akkor ezt ezzel a paranccsal tudod lekérdezni:
cat /proc/cmdline
Az efibootmgr mindenféle kamu bejegyzéssel lefut. Az, hogy ez bootkor törlődik-e, azt UEFI BIOS-a válogatja. A legtöbb UEFI törölni szokta azokat a bootbejegyzéseket, amikhez a meghajtó vagy EFI partíció, EFI bináris nem érhető el. De nem mindegyik, egyes UEFI-k meghagyhajták.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #29232 üzenetére
Nálam eddig minden paramétert kiírt az efibootmgr -v (vagy ---verbose a megfelelője a hosszú paramtérnévnél), minden gépen, fizikain és virtuálison is.
Pl. ThinkPad-emen Arch alatt, ebből az első 3 sor, és a legutolsó számít:
[csaba@Piglet ~]$ efibootmgr -v
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 0019,000A,001A,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004 ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E* ATAPI CD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F* ATAPI CD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010 Other CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011* ATA HDD3 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012* ATA HDD4 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013 Other HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0015* IDER BOOT Floppy PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0016* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0018* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot0019* Arch HD(1,GPT,068aec4c-eb24-443b-8ae1-ba5782bc6364,0x800,0x32000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.2. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.Közben ezt megerősítve a /proc/cmdline tartalma:
mitigations=off random.trust_cpu=on initrd=intel-ucode.img initrd=initramfs-linux.img root=PARTUUID=a826f815-4fed-b440-907a-bca1e2633e6e rw
A /proc/cmdline is teljesen jó, hiszen az UEFI átadja az összes paramétert, amit te megadtál. Ezzel direkt kisérleteztem, hogy az efibootmgr-es bejegyzéssel nem egyező, illetve ellentétes paramétereket adtam át az EFI shellben a kernelnek és a cat /proc/cmdline helyesen írta ki, hogy milyen paraméterek lettek TÉNYLEGESEN átadva.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #29248 üzenetére
Biztos, hogy ide van felcastolva, ilyen mtp:host néven? Próbálj meg valami egész mást rámásolni.
Két lehetőség van: egy hosszabb másolás közben x idő után szétdobja a kapcsolatot a teló (pl. bekapcsolódó képernyővédő okoz neki gondot), és ez mindig annál a fájlnál mutatkozik meg.
Vagy abban a DCIM mappában az a fájl sérült a fájlrendszeren. Meg kéne próbálni csak ezt átmásolni. Szigorúan terminálban, cp vagy rsync paranccsal, hogy lehessen látni a folyamat közben, hogy mit ír ki hibaüzenetben. Grafikus alkalmazásnál alapból nem látni, hacsak nincs megint csak terminálból indítva.
[ Szerkesztve ]
-
Frawly
veterán
válasz samujózsi #29257 üzenetére
Szerintem az Android nem kezeli le a fájlnevekben a karakterkódolást, vagyis nem tudja MTP-n rendesen átadni. A Linuxnak tuti nem kell gondot okozzon, ott be lehet állítani a kódolást UTF-8-ra. De majdnem biztos, hogy Android-bug, mert Windowson sem ment, azt írtad.
Egyébként nekem is van néhány számnál zárójel fájlnevekben, és nekem nem volt gondom MTP-n sem, de majd kipróbálom még egyszer, kifejezetten ilyen (0) ... (1) ... (2) fájlokkal.
-
Frawly
veterán
válasz haddent #29260 üzenetére
Érdekes tanulságösszegzés. Irigylem a problémádat. Szívesen cserélnék veled, hogy az 1 gigás netem nem futja ki magát virtuális gépben. Ehelyett ilyen csóresz 15 mbites neten van, amihez még kaka Wi-Fi jelerősség is társul az albérletben De legalább qemu-kvm-ben nem lassul, igaz nincs is hova neki, mert akkor átmenne negatívba a sebessége
-
Frawly
veterán
válasz CPT.Pirk #29263 üzenetére
Ez nem a HDD-n múlik, hanem azon az USB házon, adapteren, amin keresztül a gépre van lógatva. A smartctl sokszor nem tudja kiolvasni a SMART-tot USB-n keresztül. Főleg USB BOT módban nem, UASP módban néha lehetséges, de nem minden ilyen USB-s adaptert támogat. A Windows sokkal esélyesebben ki tudja olvasni a SMART-ot ilyenkor is.
-
Frawly
veterán
válasz CPT.Pirk #29275 üzenetére
Nagyon helyes. Erre én is törekedni szoktam, hogy Windows csak akkor legyen használva, ha nincs rá linuxos alternatíva egyáltalán, vagy van, de nagyon rossz hatékonyságú. Sajnos ilyen UASP meg SMART kezelése terén el van maradva a Linux, nem is maga az OS, hanem a driverek, meg ezek a userspace toolok, ezeknek a fejlesztői mind Windows onlyságra gyúrnak rá sajnos.
(#29276) samujózsi: erősen chipsetfüggő. Meg lehet adni a smartctl-nek partíciót is, a hozzá tartozó lemezt nézi. Az viszont jó tanács, hogy ha nem megy az alapértelmezett futtatása a smartctl-nek, nem tudna kiolvasni semmit, akkor ingyen van próbálkozni a -d scsi megadásával.
-
Frawly
veterán
válasz samujózsi #29296 üzenetére
Szerintem nem lesz névütközés, főleg, ha LUKS is van, mert akkor ilyen /dev/mapper/titkosításnév-lvmgroupnév vagy mi alapján jön létre a dev eszköz a LUKS titkosítás feloldása után. De nem vagyok biztos benne, próbáld ki. El nem tudod rontani, legfeljebb kiírja, hogy nem tudta felcsatolni. Szóval kárt nem okozhat, ingyen van kipróbálni.
-
Frawly
veterán
válasz samujózsi #29301 üzenetére
Igen. Használtam már több disztrón is, a szóban forgó Ubuntun és Archon is, évekig, ráadásul LUKS titkosítással. Ütközéses helyzetem még nem volt vele. Azt nem állítom, hogy garantáltan nincs ütközés, de ezek szerint van, mert kipróbáltad. Egyébként ha felcsatolod egy Live rendszer alatt, akkor át tudod nevezni az LVM csoportokat és köteteket, nem lesz ütközés. Adatvesztés nélkül átnevezhetők.
Read only médiára úgyse tárolnál le LVM köteteket, az ilyenekre fájl/mappaszinten érdemes menteni, nem low level szinten.
-
Frawly
veterán
válasz samujózsi #29303 üzenetére
Nem azt írtam, hogy garantáltan nem lesz ütközés, hanem hogy „szerintem” nem lesz, és próbáltam megindokolni. Ezek szerint van, tévedtem, beismerem. Próbáltam reagálni a problémádra, mert nem látszott, hogy már kipróbáltad.
Az RO-ként felcsatolt meghajtók mindig szopófaktor, LUKS, LVM, névütközés nélkül is. Általában nem javasolt így csatolni semmit, kivéve, ha nagyon indokolt, hibás fájlrendszer, vagy a célmeghajtón valami kiritikus fontosságú adat van, ami a csatolás nem tehet tönkre, stb.. Először azt hittem, hogy RO alatt itt most ilyen DVD-t vagy hasonlót értesz.
-
Frawly
veterán
válasz Dißnäëß #29308 üzenetére
Azt nem tudom, hogy a Debian telepítő ezt mennyire tudja, de kézzel biztosan meg tudod csinálni ezt Debian minimal netinstall CD-ről kézzel. Kb. úgy, ahogy írtad, titkosítást létrehozod, meg a boot partíciót USB-n, felcsatolod, és onnan indítod a text mode telepítőt.
Én ennek egyébként Arch-csal mennék neki, azzal tuti megcsinálható. De mint tudjuk, az nem lehet olyan stabi, az csak hobbista debileknek van.
Abban igaza van a másik kollégának, hogy attól, hogy titkosított a meghajtó, még nem feltétlen kell a bootot a USB-re tenni, lehet egy titkosítatlan boot partíció a titkosított lemezen is, egy titkosítatlan részen.
USB hamarabb akkor kell, ha azt akarod megvalósítani, amit írtál, hogy az egész meghajtó partíciók nélkül egy nagy LUKS konténer, és titkosítási headert nem akarsz rá, hanem azt is USB-n tárolod. Nem sok értelmét látom az ilyen trükközésnek, mert aki ért hozzá, úgyis levágja, hogy egész lemezes titkosítás van rajta.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen