-
Fototrend
Fototrend
Új hozzászólás Aktív témák
-
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? -
-
Let's Encrypt nem jó megoldás?
Ők csak olyat írnak alá, amit verifikálni tudnak, tehát el tudják érni wan -ról. Persze megteheted, hogy kiengeded, aláírják, és lezárod, de tudod ki csinálná ezt 3 havonta egy lokális cuccnak amit aláírok magamnak 10 évre
-
Szerintem nem vészes az openssl, ha nem szorulsz rá és van időd, én nem mennék bele felesleges absztrakciókba. Igazából tök felesleges fejből tudni a kapcsolókat, szerintem, tehát jó vagy. Én openssl -el állnék neki
Ebben van valami...
Különösen, hogy az easyrsa egy openvpn mellékág, nem igazi céleszköz. -
Félreértesz: némi önirónia volt a kommentem.
Elfrlejtettem, hogy nemrég hasonlót kérdeztem.
Csak mikor harmadszor futottam neki a keresésnek, akkor szúrtam ki, hogy feltételezhetően a téma szakértői ritkán nárnak erre, nálam meg kopogtat dr. Alzheimer.
-
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)
-
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)
-
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.
Tökéletes, valami ilyesmin kattogok. Köszönöm
-
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ó. -
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.
-
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.
-
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.Nekem két olyan van, amikből Windows alatt se tud kiszedni semmit a HDSentinel, túl kínai a chipset rajtuk.
-
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.
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. -
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.
-
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?
-
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Így esetleg a -s is működni fog
-
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. -
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őbbNekem ez: https://pki-tutorial.readthedocs.io/en/latest/ jobban tetszik. Abba az ubuntusba csak véletlenül futottam bele és elkezdtem olvasgatni.
-
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.
Ennyi a vége vagy ki is írja az adatokat? Ha itt a vége, akkor goto 1!
(nézd meg a -d lehetőségeit)
Ha ki is írta az adatokat, akkor tényleg nincs tippem. -
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 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 -
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?
-
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?
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?
-
É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É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 -
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.
-
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.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.
-
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.
-
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.
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...
-
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? -
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.
-
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? -
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...
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
-
Cirbolya_sen
aktív tag
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...
É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...
-
samujózsi
senior tag
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
-
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
-
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
-
samujózsi
senior 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 -
hcl
titán
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
-
samujózsi
senior 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 -
unknownerror
tag
-
ötlet:
1. szét kellene kapcsolni az iptablest meg az ebtablest
2. utána rendbe kellene rakni a routingot.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 -
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!
-
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. -
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.
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!
-
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ó.
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...
-
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.
-
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.
-
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.
-
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ó.
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. -
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. -
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.
-
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.
-
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.
-
-
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.
-
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.
-
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ő) -
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.
-
"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.
-
Hol? Az előbb átfutottam a hozzászólásokat, de nem találtam meg...
Egyébként ha megvan még a history-ban, hogy a hogyan fordítottad és telepítetted, esetleg ránéznék én is.
A make clean-től kellene asszem (ha jól rémlik, valahogy úgy megy, hogy make clean ; make defconfig ....)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.
-
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.
-
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.
-
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.
-
"É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.
-
1. Virtuális gépről volt szó, ott _elvileg_ lehet, mert a hyoervisor kezeli a konzolt
2. De ha mégsem (végülis tévedhetek), javasoltam egy módszert, amivel a guest konzolja mindenestől fájlba vagy egy tcp/udp portra irányítható. Utóbbi esetben egy netcat elég hozzá, hogy nézegesd, vissza tudj lapozni, de még be is tudsz lépni...És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni. Egy zx spectrumon még lehetett tudni bájtról-bájtra, hogy hol, mi van, mi, mit jelent stb. Aki kicsit ass3mblyvel játszott, annak nem okozott gondot. Itt is ez van, csak pár nagyságrenddel több tudás kell hozzá. Amivel én nem rendelkezem.
-
1. Virtuális gépről volt szó, ott _elvileg_ lehet, mert a hyoervisor kezeli a konzolt
2. De ha mégsem (végülis tévedhetek), javasoltam egy módszert, amivel a guest konzolja mindenestől fájlba vagy egy tcp/udp portra irányítható. Utóbbi esetben egy netcat elég hozzá, hogy nézegesd, vissza tudj lapozni, de még be is tudsz lépni...És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni. Egy zx spectrumon még lehetett tudni bájtról-bájtra, hogy hol, mi van, mi, mit jelent stb. Aki kicsit ass3mblyvel játszott, annak nem okozott gondot. Itt is ez van, csak pár nagyságrenddel több tudás kell hozzá. Amivel én nem rendelkezem.
) á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
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Pictonico: a Nintendo mobiljátéka a fotóidból csinál minijátékokat
- OpenMediaVault
- Apple asztali gépek
- Házimozi belépő szinten
- iPhone topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy Watch8 és Watch8 Classic – lelkes hiperaktivitás
- AMD Navi Radeon™ RX 9xxx sorozat
- V.Milán: Kezeket fel kollégák
- További aktív témák...
- Lenovo ThinkPad X13 Gen 3 i5-12. gen-16GB DDR5 RAM 256GB SSD FHD+ gari. 4g modem Érintőkijelző
- Tablet felvásárlás! Samsung Galaxy Tab S10+, Samsung Galaxy Tab S10 Ultra, Samsung Galaxy Tab S10 FE
- Apple iPad 2025 (A16) 128GB & 256GB Wi-fi / 5G Bontatlan Összes Szín / 27% áfás ár
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- GYÖNYÖRŰ iPhone 14 Pro 256GB Space Black -2 ÉV GARANCIA - Kártyafüggetlen, MS5415
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest