- Computex 2024: monstrumhűtő a DeepCoolnál (videóval!)
- Computex 2024: szimpatikus Montech billentyűzetek a porondon
- Computex 2024: háznézőben a Montech asztalainál
- Computex 2024: kompakt AIO-k és tápegységek a Montech receptje alapján
- Computex 2024: a Ducky klaviatúrái sem restek felülni az analóg vonatra
Hirdetés
-
SGF24 - Befutott a Monster Hunter Wilds legújabb előzetese
gp Az új rész jövőre érkezik, ennél pontosabb dátumot nem kaptunk még sajnos.
-
Pénzt akar a WhatsAppból a Meta, az AI majd segít
it Új AI-eszközöket kapnak a cégnek, a Meta célja, hogy több bevételt szedjen ki a WhatsAppból.
-
Computex 2024: szimpatikus Montech billentyűzetek a porondon
ph A vállalat egy olcsóbb fajta, két színben választható, vezetékmentes modellel és két érdekesen festő koncepcióval jelentkezett.
-
PROHARDVER!
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
-
bambano
titán
válasz samujózsi #29199 üzenetére
"És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni.": miért? azok, akik most kernelt fejlesztenek, átlag felhasználóként kezdték és nulláról tanulták meg azt, a dump olvasást is.
a linux egy szabad világ, ne akarjuk előírni senkinek, hogy mit csináljon. azt mondhatod, hogy te nem tudsz átlag felhasználónak dump olvasásban segíteni. ha más tud, vagy megtanulja önállóan, akkor mindenki boldog.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
samujózsi
tag
válasz bambano #29204 üzenetére
Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?
Úgy a 0.99-1.0 környékén még volt rá példa, hogy a kernel dumpból kintudtam hámozni, minvolt a baj, mi több, a cdu31a driver részébe még bele is írtam pár sort a magam szórakoztatására (ha tudod még, mi volt az)
Ma már csak user vagyok, eszembe nem jutna ezekben turkálni -> nem várom el, hogy olyan helyről jöjjön úgymond értelmes hibaüzenet, amivel esélyem sincs érdemben kezdeni valamit.Vagy, ha mindenáron értelmes infóként akarok a kernel efféle hibaüzeneteire tekinteni, akkor nem morgok azon, hogy értelmetlen (nem az), hanem megtanulom értelmezni. Ami saccra pár hónap tanulás alsó hangon.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
inf3rno
nagyúr
válasz samujózsi #29205 üzenetére
Nekem hasznos igazából annyi lenne a napi dolgokban, hogy adjon valami tippet, hogy melyik hardver vagy driver vagy beállítás hibás. Az egész kb egy sor lenne. Ehelyett valami katyvaszt ad, amivel a fejlesztőkön kívül senki nem tud mit kezdeni. Weben is nem véletlenül írunk 500 internal server errort meg 404 not found-ot vagy ilyesmiket ahelyett, hogy a teljes trace-t odanyomnánk az end user pofájába. Egyrészt biztonsági kockázat, másrészt meg úgysem tudna mit kezdeni vele, mert nincs hatásköre hozzá és nagy valószínűséggel nem ért hozzá. Ugyanez a megközelítés lenne jó itt is. Aztán aki hozzáértő az megnézheti debug mode-ban a trace-t meg minden ilyen extra dolgot, aki meg nem, annak elég tudnia, hogy a videokártya adta be a kulcsot vagy annak a driverét kellene frissíteni. Na csak ennyi, gondolom még néhány száz év, mire ilyen OS is lesz.
[ Szerkesztve ]
Buliban hasznos! =]
-
samujózsi
tag
válasz inf3rno #29206 üzenetére
De ezt próbáld megérteni, hogy erről biztos infója nincs a kernelnek.
Ha van, akkor kiírja.
De honnan tudhatná egy PC-n futó OS kernele, hogy adott esetben a diszk, a vezérlő vagy a kábel a hibás? Csak annyit lát mndjuk, hogy valami nem stimmel az átvitelnél. Ha egyáltalán észreveszi és nem csak annyi történik, hogy hülyeség töltődik be, emiatt a futtatott kód lesz hibás.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
bambano
titán
válasz samujózsi #29205 üzenetére
"Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?": de itt az alapeszméről van szó.
nem mondtam, hogy hatékonyan fog belenyúlni, nem mondtam, hogy sikeres lesz, azt mondtam, hogy hagyni kell.az opensource és a linux alapeszméje, hogy mindenki buherálhatja. ezt az alapeszmét szerintem helytelen lenne megölni.
az egy másik tészta, hogy a hivatalos kernelbe mi hogyan kerül bele és az is, hogy a júzer saját energiáit vagy másokét hogyan pazarolja. ha be akar menni bekötött szemmel az erdőbe, hagyni kell, hagy menjen. ha koppan, koppan, ez téged ne zavarjon. de lehet, hogy felfedezünk egy új mingót.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
-
samujózsi
tag
válasz bambano #29208 üzenetére
Megtiltani senki sem akarja, hogy hozzányúljatok. Viszont azt senki se várja el a kernel fejlesztőitől, hogy olyasmire pazarolják az idejüket, mint pl a kernel hibáinak pontos meghatározása egy-egy ilyn crash esetén!
Mert ugye itt elsősorban azon megy a szófosás napok óta, hogy érthetetlen a kiírt hiba a felhasználónak.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz Frawly #29209 üzenetére
Mindkét console= parametert beleraktad a kernel parancssorába? A /dev/ttySn esetében n helyett biztosan jó sorszám áll? Ha egy Serial port van, akkor ttyS0, ha a meglévő mellé veszel fel újat, akkor inkább ttyS1 kell. A biztos módszer, hogy törlöd virt-managerben a meglévő Serial portot és felveszel helyette egy újat, textbe irányítva, úgy 0-s lesz biztosan.
Akkor a grub menübe kb ezt kell beletenni:
linux console=/dev/ttyS0 console=tty
Ha van más paraméter azt tartsd meg (esetleg a quiet törölhető)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Jester01
veterán
A kernel NULL pointer az olyan hiba amire a fejlesztők nem gondoltak, ezért BUG. Ha gondoltak volna, akkor le lenne kezelve és értelmesebb hibaüzenet lenne ott.
Egyébként ki lett javítva:Fix root mounting with no mount options
The "trivial conversion" in commit cccaa5e33525 ("init: use do_mount()
instead of ksys_mount()") was totally broken, since it didn't handle the
case of a NULL mount data pointer. And while I had "tested" it (and
presumably Dominik had too) that bug was hidden by me having options.Jester
-
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.
-
samujózsi
tag
válasz Frawly #29213 üzenetére
Akkor nem tudom. Ubuntu 18.04 gyári kernellel megy.
A grub menüben a megfelelő menüponton nyomsz egy e-t.
Elvileg a megjelenő sorok közt van egy linux szóval kezdődő.
Annak a végéhez hozzácsapod, hogy "console=/dev/ttyS0 console=tty" idézőjel nélkül.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.
-
samujózsi
tag
válasz Frawly #29216 üzenetére
Szerintem ennek bármilyen kernellel mennie kell.
A virt-managerben hány Serial eszközöd van?
Gentoot nem fogok feltenni, de majd megnézem valami mással, csak kicsit nagyobb diszkkel, mert amikor próbáltam, nem volt hely a fordításhoz.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz bambano #29219 üzenetére
De az nem default manapság?
Azért megjegyzem, a posztod alapján van bennünk némi közös: mazochista módon állunk az ilyen szarokhoz
Én most egy EFI-vel súlyosbított KVM virtuális gépre próbálok arch linuxot varázsolni a célból, hogy kipróbáljam ezt a kernelt a default configjával.
Épp csak... korábban szinte kizárólag virtualboxot használtam, az archlinuxból a nevén kívül semmit sem ismerek.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.
-
samujózsi
tag
válasz Frawly #29221 üzenetére
Ennek kevés köze van a szanaszét patch-elt kernelekhez. Annyira ősi dolog, hogy elvben minden kernelben benne kellene lennie, még a routerekre és más hasonló eszközökre készültekben is benne van amennyire tudom.
Mindenesetre ha nincs secure boot¹ bekapcsolva a gépeden vagy a fizikai vason (alias host) futó rendszered képes úgymond meghágni azt, akkor talán érdemes lenne felraknod egy virtualboxot, alá betolni a gentoo-d image-ének egy másolatát és azon kipróbálni. Egyre gyanúsabb a kvm efi ugyanis.
¹ A secure boot úgy jön ide, hogy a virtualbox aláíratlan kernel modult hoz magával. Lehet, hogy a disztro saját repojából települő aláírt válrozattal jön, én a virtualbox.org-ról hoztam el a telepítőt, az meg például ubuntun nem működött.
Ellentétben valamelyik ubi klónnal, ami valahogy engedélyezte mégis.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.
-
inf3rno
nagyúr
válasz Frawly #29222 üzenetére
Nem hiszem. Mármint nekem úgy tűnt, hogy a GRUB csak annyit tesz, hogy átadja a paramétereket a kernelnek. A lényegi munkát a kernel végzi ezzel kapcsolatban. Legalábbis ez jött le abból a pár sorból, amit elolvastam a témában, meg ha belegondolsz a soros portos driverek vagy mi a szösz is a kernelben van, nem a GRUB-ban... Nem is vagyok benne biztos, hogy beleférne a GRUB-ba, de mióta bejött a GPT meg az EFI már nehezen követem, hogy mi hány MB lehet. Valami olyasmi rémlik, hogy MBR-el és BIOS-al elég kötött volt a bootloader mérete és valahol a lemez elején kapott helyet valami olyan helyen, amit elvileg nem is erre találtak ki. Mióta bejött a GPT talán már nincs ilyen megkötés, passz.
[ Szerkesztve ]
Buliban hasznos! =]
-
samujózsi
tag
Van arra lehetőség, hogy az efibootmgr segítségével felvett kernelhez tartozó boot paramétereket, amiket a felvételkor adtam meg, lekérdezzem valahogy?
Az efibootmgr -v nem igazán ad erre vonatkozó infót.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Még egy kérdés: én rontok el valamit vagy az teljesen normális, ha a kvm guestben kiadott efibootmgr --create ... parancs által létrehozott bejegyzés boot után nyomtalanul felszívódik?Mocsok egy dolog: az
efibootmgr --create ... --loader <loader neve> ...
parancs szó nélkül lefut hibásan megadott loaderrel is, csak a boot után törlődik. Hibajelzést nem láttam.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz Frawly #29221 üzenetére
Mea culpa! Valóban tojik rá a defconf konfigurációval gyártott kernel, hogy ott a paraméterek közt a console... Hát legalábbis érdekes.
Viszont így még hálózatom sincs, csak egy sit0@NONE eszközöm van a lo mellett...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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 ]
-
haddent
addikt
Sziasztok KVM networkinges kérdéssel fordulnék hozzátok. A következő a setup:
vason 3 hálókártya, 2 bridgeben. Egyik egyedül, másik kettő összefogva. Kvm virt-tel, bridge módban hozzácsap mindkettőhöz 1-1 -et még, ezt kapja meg az opnsense. Megy a digi pppoe, és bármit dugok a fizikai bridgelt lanba, tök jól megy minden. Viszont a hoszt gép (és így a többi virtuál kvm gép) hiába kap ip -t, sőt pingeli a 8.8.8.8 -at, resolvolja a googlet, látszólag minden jó, minden ki van engedve, de pl "curl google.com" már kifagy, semmi
Biztos valami apró részlet, vagy óriási ,de elfáradtam, ötlet?köszi!
-
samujózsi
tag
válasz Frawly #29230 üzenetére
A /proc/cmdline ebben az esetben nem ér semmit, hiszen pont az lenne a lényeg, hogy az efi mit lát abból, amit én odaadtam neki.
Többé-kevésbé a /sys/firmware/efi/efivars (emlékezetből írom, de remélem, pontosan) alól ki lehet bányászni, de ez nem igazán korrekt, csak a normális megoldást nem találom.
Az efibootmgr -v nem ír ki minden paramétert, épp ezért kérdeztem.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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 ]
-
haddent
addikt
válasz bambano #29234 üzenetére
Rendbe bizony De már megy, hardware offloadot ki kellett kapcsolni.
Következő csoda: minden tökjól natolódik, kivéve szerencsétlen deluget. Bármit csinálok, nem tölt se föl se le lényegében. Deluge ui -ban zöld minden, de amúgy kb. 0 forgalom. Sense logban már zöld minden, NATolva van egy konkrét porton, reflekt (oda-vissza), egyszerűen nincs reject, mégis
Bár épp az előbb bugolt be, fogta magát és olyan rule alapján engedett valamit amit már töröltem. Aztán meg létrehoztam újat és arra meg nem futott rá .. Még 1-2 ilyen aztán köszönöm szépen megyek vissza iptables cli -hez -
unknownerror
tag
Sziasztok!
Nem pont linux-os kérdés. (illetve megfelelő topicot nem találtam)
Adott egy Windows Server HyperV-vel, és rajta 4 Linux VM. Az egyik VM raid5 ssd-n van, és durván 70millió i-node fogyott rajta el. Ez egy egyedi fájl alapú adatbázis szerűség, üzemeltetőként mi se értjük teljesen hogy működik, de életben kell tartani. (no update, no fejlesztők)
Az a problémám, hogy jelenleg 12-16 órán át fut a mentés úgy, hogy kívülről mentem a vm-et cache-lt raid5 hdd-s szerverre, gigabiten. Gyanítom itt az írással lesz gond, mert több mentés is megy rá éjszaka, de arra nem gondoltam, hogy ilyen sokáig fog ez menni. Persze ez egy éve még bőven végzett 5-6 óra alatt, reggelre mindig lefutott, aztán ez elkezdett felkúszni.
Előzőleg snapshot-tal oldották meg a mentést belülről, de egymásra futottak, ezért lett a hyper-v-re váltás több hypervisor kísérlet alapján.
Nos, az adatbázis növekszik, attól tartok, hogy a mentése hamarosan gondot fog okozni. Illetve, amíg ment a hyper-v, addig snapshotot készít, előfordult, hogy a mentés ideje alatt többszáz gb-ot megmozgat az adatbázis, ezt hozzá kell számolnom.
Ti hogy mentenétek / mentetek rengeteg apró fájlt tartalmazó lemezt / gépet? Jelenleg 800gb-os az adatbázis, pdf-ek, jpg, png és hasonlókból áll. Rsync kizárt, nem fut le.
Köszi előre is.
Üdv:
Miklós -
samujózsi
tag
válasz unknownerror #29236 üzenetére
Nem állítom, hogy pontosan értem, mi történik, a hyper-v meg nekem nem sokat mond.
Ha van elegendő háttértár, akkor az adatbázist LVM-re tenném, mellé LVM snapshot, azt dd-vel menteni, aztán a snapshotot lelőni. Ilyenkor ugye nem fájlonként ment, hanem azt a 800GB-1TB image-t.
Persze kérdés, hogy maga az adatbázis hogyan működik, sérülés esetén egy ilyen backupból vissza lehet-e állítani?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Hello,
USB-ről bootoló Debian (Bullseye), #sokadik rész.
Valakinek van ötlete arra, hogy miért nem bootol USB3-ról?
Amint USB3 port + USB3 eszközről akarom bootolni, nem indul. Ha USB2-n van, akkor igen.
Jelenleg a "Begin: Running /scripts/local-block ... done.
" üzenetnél döglik le, és kb. tudom is, miért : az USB-n lógó eszközt nem látja (initramfs shellből látszik). Na most, xhci driver modul megvan, initramfs updatelve, /etc/modules-b felvettem egy csomó usb modult, az xhci-t is, stb. Mi okozhatja ezt...?Köszi minden ötletet
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
samujózsi
tag
válasz unknownerror #29236 üzenetére
Egyébként itt: [link] esetleg többen tudnak segíteni.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
unknownerror
tag
válasz samujózsi #29239 üzenetére
Szia!
Köszi, (belül) ezt a csoportot kerestem.
A windows server belső backup-jával mentek, a linux-os vm pedig megkap egy 1,5T-os vhdx lemezt, ami egy hardware raid5 köteten van. Megnézem az lvm-et, ki lehet-e alakítani itt, szerintem működhet. köszi! Illetve lehet, hogy a raid vezérlő is szűk keresztmetszet a sebességben, ezt most tesztelem.
Miklós
-
samujózsi
tag
válasz unknownerror #29241 üzenetére
Az az igazság, hogy főleg, ha SSD-ről másolsz, akkor a HDD mindig szűk keresztmetszet lesz, főleg, ha egyszerre több írás megy rá. Ugyanis azt, hogy fizikailag hová ír, ma már nem nagyon lehet befolyásolni, emiatt viszont minél több fájlt írsz párhuzamosan, annál többet kell rángatni a fejet. Az pedig sokat tud lassítani.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
Újabb kvm -ben jártasabbnak biztosan bugyuta kérdésem lenen
PCI pass-through mi a bánatért nem megy? intel_iommu kernel para benn, mégis azt nyögi, hogy nem támogatott és az iommu csoportok is tök üresek. LOG: [link][ Szerkesztve ]
-
haddent
addikt
Egy elvetemült kérdés következik valami nagyon linuxos nagyon virtualizációs nagyon hálózatos szakember felé. Adott egy Dell Optiplex 7020, gen4 i3, 2x dedikált pci-e intel nic, 8gb ram. Bare-metal, Arch linux legleglegfrissebb kernel, mindenféle absztrakció nélkül sima iptables -szel WAN <-> LAN NAT throughput szépen szaturálja a Digi gigát megfelelő szervert választva (Antenna Hungária, JZT stb..) speedtesti-cli -vel, ~900+ Mbit/s. Eddig oké.
Adott továbbá egy KVM virtualizáció, melyhez VT-d bekapcsolva, IOMMU kernel param bekapcsolva, virtio type.
Teljesen azonos konfigokkal, 2gb ram, 2vcpu + ssd -n .qcow2 a következő érthetetlen értelmezhetetlen hülyeségek jöttek ki, teljesen azonos szabályokkal (a saját absztrakciójukon, meg ugye egyik bsd másik linux bf vs iptables stb., de elhisszük, hogy nagyjából ugyanazokra a kernel hívásokra "fordul") LAN <-> WAN NAT:OPNsense: ~4-500Mbit/s
ClearOS: ~300Mbit/s
VyOS: ~5-600Mbit/s
PfSense: ~900Mbit/sMinden esetben a guesten mindenféle hardware offload (checksum rx tx stb.) kikapcsolva. Tehát amennyire csak lehet teljesen egységes körülmények. Na most ilyenkor wattafakk van?
iptables vs bpf megérteném, de van 2 linux nagyon hasonló alapokon és 2 bsd ami egymás forkjai és ott is óriási különbségek vannakBónusz +1: hogy lehetne még többet kisajtolni? Egyelőre PfSense -nél ragadtam érthető okokból, de az az érzésem, hogy minimálisan ~50Mbit/s így is veszteséges, ami 1g -nél belefér, de ehh...
-
Cirbolya_sen
aktív tag
válasz haddent #29244 üzenetére
Én ennyire mélyen nem mentem bele, az előkészületeknél a leírások alapján egy mini pc-re, az ipFire maradt, erre ígérték, hogy működni fog Digi PPPoE gigán. A BSD verzióknál, az volt a mondás, hogy a több magot nem tudják lekezelni, és érdekes, mert az OPNsense és PfSense összehasonlításokban, egy picivel az OPN jött ki győztesnek
A mini pc telepítve, már csak idő kérdése, hogy megnézzem, hogyan muzsikál élesben.
Cirbolya_sentinel
-
samujózsi
tag
válasz haddent #29244 üzenetére
Szakértő nem vagyok, de... a kernelek gondolom, eltérő konfiggal működnek, tapasztalataim szerint ez bőven elég lehet jelentős eltérésekhez a performancia terén.
Nem állítom, hogy erről van szó, csak tipp.Amit viszont nem értek... [link] ennyire nem törődnek a doksival, vagy máshol kéne keresni? Mert ez nagyon elavult
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Szeretnék saját certificate-eket gyártani, saját CA használattal.
Részben a wifi authentikációt tenném át RADIUS-ra, EAP-TLS alapokon, részben web szervereket (a router admin felületét+egy sajátot) szeretnék tanúsítvánnyap ellátni, openvpn-t beüzemelni stb.
O.K., van valami easy-rsa csomag, amivel viszonylag egyszerű mindezt megcsinálni. De jó lenne érteni is, hogy mit csinálok. Tudna valaki ehhez valami tananyagot? Nem szakérteni akarok, csak felfogni, hogy mi történik amikor elkezdek tanúsítványokat osztogatni/visszavonni. Meg, hogy ez mit igényel a háttérben? (Kiragadott példa: korrekt hálózati struktúrát, lokális domain nevek használatával mindenképp, mert ugye a DN(?) tartalmaz domain nevet.)[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Esetleg arra van valakinek ötlete, hogy egy androidos telefont a notebookra dugva miért fagy le minden parancssoros alkalmazás, amivel a mobil fájlrendszerén matatnék?
Elmegyek a /run/user/10000/gvfs/mtp:host* könyvtárba, ott próbálok futtatni akár egy rsync-t, akár egy find-ot, lefagynak. Az rsync-nek hiába van bekapcsolva -v és --progress is, nem ír semmit, a find meg megakad egy fotókat tartalmazó könyvtárban, de az android simán kezeli azt a könyvtárat.
Mi a bánat baja lehet?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Hát az is lehet. De miért a könyvtár (ami úgy tűnik, következetesen a DCIM alatti könyvtárak egyike) n. fájljánál?
Ettől függetlenül sajnos igazad is lehet (bár ha azt veszem, hogy nem elhajt azzal, hogy nincs joga, hanem csak lefagy, akkor nem annyira security gond)A régi ubuntun mtp-tools segítségével egyáltalán nem férek hozzá, a 18.04-en meg van gnome, ott a gnome egyből mountolja(?), nem tudom, nem azzal akad-e össze a parancssor.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
Új hozzászólás Aktív témák
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- AKCIÓ! - STEAM kulcsok / Punch Club, Oddworld: Soulstorm, Children of Morta, stb. - 2024.05.16.
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs