- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- btz: Internet fejlesztés országosan!
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Meggyi001: Nyilvános wc-k.....még mindig hiánypótló...
- Elektromos rásegítésű kerékpárok
Hirdetés
-
LOGOUT
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
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.
-
samujózsi
senior tag
Help! Ubuntu, LVM-re telepítve, automatikus particionálással.
A korábbi rendszerlemez USB-s házban, ugyanígy, automatikusan felosztott, LVM-es felállásban.
Ott a gond, hogy a volume groupok, logical volume-ok azonos néven szerepelnek. Hogy a bánatba tudom elérni az usb-s adatokat?
Mindez tetézve luks alapú titkosítással.
És az éles rendszerben nem tehet kárt a névütközés? -
-
lovi27
addikt
Let's Encrypt nem jó megoldás?
-
samujózsi
senior tag
-
-
samujózsi
senior tag
Szükségem volna saját, élesben is használható CA-ra.
Éles alatt persze nem céges felhasználásra gondolok, hanem itthoni VPN szerverre, RADIUS-t használó wifi kliensek tanúsítványainak, esetleg MOK-k aláírásra.
Egy gondom van: essek neki openssl-t tanulni az összes paramétereivel, vagy teljesen jó a debian/ubuntu/arch alatt (arch már újabb, mint amit valaha láttam) elérhető easy-rsa csomag?
A kettő közt felfedezni vélek némi verziószámbeli eltérést az openssl javára, viszont az ahhoz tartozó openssl.cnf elég sokban különbözik az easy-rsa openssl-1.0.0.cnf fájljától.Az easy-rsa-t kb. tudom használni minimális olvasgatás mellett, az openssl... hát az hosszú menet lesz, attól félek. Érdemes időt rááldozni? (valami dereng még régről, hogy nagyon nem mindegy, a kulcsokat, tanúsítványokat milyen paraméterrel hozza létre/írja alá stb. az ember)
-
haddent
addikt
-
haddent
addikt
válasz
samujózsi
#29280
üzenetére
2. -re: nem része, de nagyon egyszerű és elegáns megoldás van rá systemd -vel pl.:
https://wiki.archlinux.org/index.php/Rsync#Automated_backup_with_systemd_and_inotifyEz most épp backup, de nyilván a backup is csak egy copy, tehát ua.
-
samujózsi
senior tag
válasz
Dißnäëß
#29279
üzenetére
1. Én csak az "egyszeri" változatát ismerem. Gyakorlatilag valami hasonlítgatás+cp vagy scp (lokálisan azt hiszem, nem használ ssh-t)
2. Passz. Szerintem ez nem része az rsync-nek, de lehe, hogy hiányosak az ismereteim, valaki tán tud biztosat.
3. Utolsó emlékem, hogy egyirányú, de törölni is tud. (Ha valaki bővebb infóval rendelkezik, remélem, kijavít)
4. Elkezdi másolni, észreveszi, hogy változott, kezdi újra. Van egy limit, hogy hányszor próbálkozzon, utána eldobja. Ha csak nyitva van, de nem módosul a másolás alatt, akkor sikeresnek tekinti a másolást. Ez utóbbi kivédésére lvm snapshotot vagy ha a fájlrendszerben van snapshot funkció, akkor azt javasolnám használni, amit az rsync végén el lehet dobni. De csak akkor, ha a módosítás alatt álló fájlokról mindenképp akarsz másolatot. A példádban említett iso letöltéshez pont nem jó. -
Dißnäëß
nagyúr
Sziasztok,
nem vagyok valami nagy rsync guru, pedig alap eszköz, csak nekem még eddig nem nagyon kellett valahogy az elmúlt években. Szeretném megérteni a működését és ehhez kapcsolódóan lenne pár kérdésem, talán tudtok segíteni:
1. Egyszeri futtatású tool ? Gugliztam ezt a kis gyorstalpalót és nekem annak tűnik, de lehet, tévedek. Tehát lefuttatom, szinkronizál két target-et egymással és jónapot, elengedi őket, tehát miután lefutott a parancs, nem történik semmi ? (Ergo, sync után egyik könyvtárba ha másolok, nem szinkronizálódik le a másikban is, újabb futtatásig). Vagy tévedek ?
2. Van olyan opciója, hogy valami daemon monitorozza a háttérben a változásokat és automatikusan szinkronizál ? (Vagy cronjob-ból oldja meg az ember rendszeres időközönkénti futtatással?)
3. Egy irányú, vagy két irányú ? "A" könyvtár adott, "B" könyvtár üres, majd parancsot futtatva "B" -n is leképezem "A" tartalmát. De ha később "B"-be bemásolok valamit, az átjön "A"-ra ? (Ez oda-vissza irány lenne).
4. Ha van egy megnyitott fájlom (például letöltök épp valamit), azt is át-sync-eli a célkönyvtárba, vagy már csak miután le lett zárva a fájl ? Mondjuk töltök egy 2 Gigás Linux telepítő ISO-t torrent klienssel.
-
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.
-
samujózsi
senior tag
válasz
Frawly
#29274
üzenetére
Meg azon, hogy ne a partíció nevét adja meg eszköznév helyett.
Egyébként van két házam, ami belül SATA csatis, meg két vagy három gyárilag összerakott USB-s külső diszkem, még nem találtam olyat, amelyik a
smartctl -d sat ...
vagy a
smartctl -d scsi ...
parancsra ne reagált volna az elvárásoknak megfelelően. -
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.
-
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29270
üzenetére
Na így már más!
SMART Attributes Data Structure revision number: 10Vendor Specific SMART Attributes with Thresholds:ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE1 Raw_Read_Error_Rate 0x000f 083 066 006 Pre-fail Always - 2056617603 Spin_Up_Time 0x0003 095 095 000 Pre-fail Always - 04 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 85 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 07 Seek_Error_Rate 0x000f 100 253 045 Pre-fail Always - 2641169 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2 (236 70 0)10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 012 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0190 Airflow_Temperature_Cel 0x0022 057 057 040 Old_age Always - 43 (Min/Max 39/43)191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 23194 Temperature_Celsius 0x0022 043 043 000 Old_age Always - 43 (0 7 0 0 0)197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 1h+52m+02.507s241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 702777946242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 5398287 -
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29267
üzenetére
Annyi a vége. A -d kapcsolónál mit kellene néznem? A manpage nem segít túl sokat.
Amúgy alapból UAS módban ment, most átkapcsoltam mass-driver driverre, így az írási sebességem már USB3-as lett, 118MB/s-el tudok másolni a cuccra, ez a quirk kellett hozzá:
[link]
Viszont ennek semmilyen hatása nem volt a smart-ra. -
haddent
addikt
válasz
samujózsi
#29262
üzenetére
Frawly elhiszem, már van 2-3 éve Digi FTTH (családi ház) és a mai napig kissé felfoghatatlan, hogy mennyire jó és olcsó. Számomra azt hiszem így életem során eddig tapasztalt legmeglepőbb/jobb szolgáltatás amit valaha bárki fel tudott mutatni. Még a Google Fiber is max. annyival tud többet, hogy az szimmetrikus 1G, nem 1G/300M, de ez már a Digi köcsögölése nyilván tudná röhögve. Kitartás, egyszer mindenhol véget ér az internet sötét középkor
samujózsi ki kéne próbálnom, mert fejből azért ennyire nem megy, de azt hiszem alapból az rsa kulcs még encryptálva lett a "jelmondat" (húdefaszafordítások
) által, ezért még azt kibontja sima b64 encodedbe, majd parasztvakítással "megkeveri" . Azt hiszem csak utóbbi verzióval tud aláírni certeket, az encrypted nem sok mindenre jó magában, mint egy ssh key a jelszava nélkül kb.
De ezt az oldalt engedd el, borzalom a fordítás is, meg maga a parancsok is. Mi a bánatnak generálja le X néven, hogy aztán +5 paranccsal kevergesse?
[link] ez szerintem sokkal érthetőbb -
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29264
üzenetére
Nem persze, rendes telepítés alól.
sudo smartctl -A /dev/sdd1smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.2.11-3-CHAKRA] (local build)Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF READ SMART DATA SECTION ===Ez nem jelent jót azt hiszem.
-
samujózsi
senior tag
válasz
CPT.Pirk
#29263
üzenetére
A smartctl -A /dev/sdd1 mit mond rá? Ha hibát, akkor van remény.
Abban az esetben nézd meg a smartctl -d kapcsolóját a manualban! (ata,scsi,nvme,sat,usbcypress stb. Az nvme kivételével esélyes, hogy az egyik bejön - leginkább a sat)Ja, ugye nem virtuális gépből vagy valami konténerféleségből próbálod?
-
CPT.Pirk
Jómunkásember
Van egy Seagate külső HDD-m, USB-s. Ezek alapján tudná a smart-ot, de nincs bekapcsolva.
$ sudo smartctl -i /dev/sdd1smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.2.11-3-CHAKRA] (local build)Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF INFORMATION SECTION ===Vendor: SeagateProduct: Backup+ Hub BKRevision: D781Compliance: SPC-4User Capacity: 4.000.787.029.504 bytes [4,00 TB]Logical block size: 512 bytesPhysical block size: 4096 bytesLogical Unit id: 0x5000000000000001Serial number: NA9QKEBYDevice type: diskLocal Time is: Tue Dec 31 11:05:23 2019 CETSMART support is: Available - device has SMART capability.SMART support is: DisabledTemperature Warning: Disabled or Not SupportedEz alapján meg úgy érzem nem is lehet bekapcsolni:
$ sudo smartctl -s on /dev/sdd1smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.2.11-3-CHAKRA] (local build)Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF ENABLE/DISABLE COMMANDS SECTION ===Informational Exceptions (SMART) disabledTemperature warning disabledMert marad disabled-en a smart support. Lehet ezzel kezdeni valamit?
-
samujózsi
senior tag
Segítség, nem értem!
[link] ez egy nagyon régi leírás a tanúsítványokról és készítésükről, de gondolom, az alapok nem sokat változtak.
Szerepel benne egy ilyen:
Hozza létre a nem biztonságos, jelmondat nélküli kulcsot, és keverje meg a kulcsneveket:Ezt nem értem. Ennek (lásd kapcsolódó példát az oldalon!) mi értelme?
-
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 -
haddent
addikt
Érdekességképp megosztom a hetek óta tartó tesztelgetésem durva eredményeit. Sajnos ha én magam sokkal precízebben hajtom végre a teszteket sem lenne precíz, hiszen változik 2 mérés közt a hálózat és a távoli szerver terheltsége is. De több mérés alapján KVM virtualizáció esetén 3 dolog mondható ki: VIRTIO driver többségében nagyon jó, megfelelő beállítások és támogatottság esetén minimális <10% kb. a veszteség, ami néha erősen közelíti a nullát. Néha sajnos megmagyarázhatatlan okokból viszont elég erőteljesen megrogy, majd megint hozza a jó hatásfokot. Minden más virt-driver egy használhatatlan szemétdomb, kb. inverze az virtio-nak, 90% veszteség. A PCI pass-through továbbra is verhetetlen, mérési pontatlanságon bőven belül, nem kimutatható veszteség (ha egyáltalán van).
Mindez Digi gigabiten, ami 900-950Mbit/s stabilan tud szinte mindig. Nagyjából ezekre az eredményekre jutottak a Redhates srácok is, csak ők nagyobb 10 gigás ligában játszottak -
samujózsi
senior tag
válasz
Frawly
#29258
üzenetére
Ez ennél sokkal bonyolultabb. Sajnos.
Van kb. 100-150 olyan fájlom, aminek a nevében van spec. karakter, többségük olyan, hogy zárójelek közt egy szám. Például a CD gyűjteményem mp3-ba konvertálva, a könyvtárakban az albumborító is ott van JPEG-ben. Ezek közt is van néhány, ami zárójelet tartalmaz. Ezeken mégsem akad fenn a másolás.
Ugyanakkor kimásoltam az egyik DCIM/Camera könyvtárból a *(0).jpg fájlokat egy külön könyvtárba (ezeket egyébként az androidos képszerkesztőm hozza létre). Ettől kezdve az eredeti könyvtár használhatóvá vált, viszont az új könyvtár, amiben mindössze 15-20 ilyen fájl volt, már nem igazán volt másolható, listázható.
Szóval nem értem.
Majd még kísérletezek vele. Annyi biztos, hogy nálam segített, hogy a DCIM alól kiirtottam a zárójeleket. -
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.
-
samujózsi
senior tag
https://mobilarena.hu/tema/android_os-t_hasznalok_szakmai_topicja/hsz_38913-38913.html - a "megoldás". Nem tudom, hogy linux vagy android bug.
-
samujózsi
senior tag
válasz
samujózsi
#29255
üzenetére
Hát ez van. Google találatok alapján néhányan úgy gondolják, hogy ez bug lehet a gvfs környékén, mások szerint az mtp protokoll úgy szar, ahogy van.
Én úgy emlékeztem, hogy régebben (igaz, régebbi androidok alatt) működött gond nélkül... ooooopss... hát most másolgattam párom Huawei P8 Lite mobiljáról rengeteg fájlt, azzal nem volt ilyen gond... És ugyanígy, az új Samsung A20e mobiljára is fel tudtam másolni.Valamit itt nagyon nem kerek, de én kevés vagyok ahhoz, hogy kiderítsem, mivel van baj.
-
samujózsi
senior tag
válasz
Frawly
#29254
üzenetére
A poén, hogy androidból hozzáférek.
adb shell alól már csak a kártyához, a belső tárhelyen tárolt képekhez nem.
Valami miatt ahol nagyon sok fájl van, ott az mtp kapcsolat döglődni kezd.
Persze ez lehet akár linuxos mtp driver bug is, mindenesetre elég rendesen teleszemetelte az androidos logot, amikor másolni próbáltam, épp csak semmi érdemi üzenetet (olyat, amit értelmezni is tudnék) nem rakott közéjük.
A virtuális gép meg szép és jó, épp csak kvm-ben fogalmam sincs, hogy tudnám átadni az USB portot, virtualbox meg nem tűnik járhatónak, mert securebootos a gépem és ahhoz aláírt kernel modulok kellenek, legutóbb emiatt nem ment virtualbox-ból sem az USB átadása.
Szóval nem egyszerű.
Most fut egy adb backup, majd meglátom, mire megyek vele.
Arra nem jó, amire nekem kell, márcsak azért sem, mert nem tud inkrementális backupot, ha jól látom. -
-
samujózsi
senior tag
Csodás, valószínűleg a mobillal van valami gond, mert már nem csak parancssorból nem tudok hozzáférni a tartalmához. Szuperjó, hogy ha nincs windows-om, akkor esélyem sincs lokális backup készítésére, mert ugye ha ilyen bajom van, azzal a ferdeszeműek elküldenek, mondván, ők csak a windows-t támogatják, a linuxot nem.
-
samujózsi
senior tag
válasz
Frawly
#29251
üzenetére
Miután látom a tartalmát... igen, biztos, hogy ide van mountolva.
Nem rá, hanem róla szeretnék másolni (backup, de az adb nem jó)
Nem egy DCIM mappáról van szó, hanem többről.
Az egyik a mobil belső tárolóján van, a másik ugyanott, csak más néven, a régi mobilról, meg egy harmadik is az SD kártyán. Ami különlegességük van ezeknek a könyvtáraknak, hogy sokkal több fájl van bennük, mint a többiben.És legutóbb (ma még nem próbáltam) a gnome fájlkezelőjével simán tudtam másolni a mobil tartalmát...
-
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.
-
samujózsi
senior 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.
-
samujózsi
senior 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? -
samujózsi
senior 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.) -
samujózsi
senior 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
-
#29245
Cirbolya_sen
aktív tag
haddent
#29244
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.
-
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 vannak Bó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...
-
#29242
samujózsi
senior tag
unknownerror
#29241
samujózsi
senior 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.
-
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
-
#29239
samujózsi
senior tag
unknownerror
#29236
samujózsi
senior tag
válasz
unknownerror
#29236
üzenetére
Egyébként itt: [link] esetleg többen tudnak segíteni.
-
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
-
#29237
samujózsi
senior tag
unknownerror
#29236
samujózsi
senior 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? -
#29236
unknownerror
tag
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 -
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 -
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 rwA /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.
-
samujózsi
senior 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. -
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!
-
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/cmdlineAz 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.
-
-
samujózsi
senior 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. -
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.
-
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.
-
samujózsi
senior 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. -
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
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ó.
-
samujózsi
senior 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. -
-
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
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.
-
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. -
samujózsi
senior 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ő) -
samujózsi
senior 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. -
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.
-
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.
-
samujózsi
senior 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. -
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.
-
samujózsi
senior 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.
-
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.
) által, ezért még azt kibontja sima b64 encodedbe, majd parasztvakítással "megkeveri" 
De legalább qemu-kvm-ben nem lassul, igaz nincs is hova neki, mert akkor átmenne negatívba a sebessége 
Új hozzászólás Aktív témák
Hirdetés
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Villanyszerelés
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Kínai és egyéb olcsó órák topikja
- Sorozatok
- btz: Internet fejlesztés országosan!
- E-roller topik
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- Hálózati / IP kamera
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Assassin's Creed Shadows Collector's Edition PC
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- BESZÁMÍTÁS! ASUS Z390 i7 9700 32GB DDR4 240GB SSD 1TB HDD RTX 2070 Super 8GB NZXT H510 ADATA 600W
- Apple iPhone 7 128GB Yettel Függő 1Év Garanciával
- Microsoft Surface Pro 9 i5-1245U 16GB 512GB 1év garancia
- Apple Air Pad 5.generácio / 32GB / Wi-fi / 12Hó garancia
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
Állásajánlatok
Cég: FOTC
Város: Budapest