-
IT café
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
tlac
nagyúr
Tudtok mondani nekem olyan live linux-ot, az sem baj, ha nem végleges kiadás, amiben legalább 3.15.5-ös kernel van?
Vettem egy usb3-as mobilrack-et és úgy néz ki, hogy csak ettől a verziótól lett egy hiba javítva, a korábbiakkal hibásan működik.
Kiszeretném próbálni, hogy ott tényleg működik-e már.[ Szerkesztve ]
-
Rimuru
veterán
-
tlac
nagyúr
válasz Rimuru #20454 üzenetére
nem biztos
találtam másik disztrót, az uhulinux-ot, ebben is 3.15.5-ös kernel van, de sajnos ezzel sem jó, csak kicsit más hibák vannak
szerintem csak hibajavítások
[link]
elvileg nekem ez kellene:Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs. This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.[ Szerkesztve ]
-
Nem kell semmifele bovitmeny egyik bongeszo alatt sem a HTML5-hoz.
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
_Dumber_
őstag
Egy kis segítségre szorulnék.
Adott egy sda5, 7 és 9 es partíció.
Grub csak a 7es hez volt. Ez indította az 5 es a 9 est is.
Egy okosan végrehajtott update-grub után a 7-hez kötött grub, csak az 5-ost volt képes megjeleniteni a menüben.
Gondoltam egye fene. Boot az 5-re, majd oda és onnan feltelepítettem a grubot. De az update-grub szintén csak az 5-öt látja.
A 7 et és a 9 is fel tudom mountolni, tehát az adatok megvannak.A sikeresen végrehajtott update-grub elött az /etc/grub.d könyvtárból szedtem ki a duplikált dolgokat
. Ezután végrehajtott update-grub már csak az sda5-ot látta. -
_Dumber_
őstag
válasz _Dumber_ #20458 üzenetére
Szerk lejárt:
Annyit találtam, hogy lehet nincs fent az os-prober az 5-ön. (ez egy aránylag friss arch). Ugyanakkor a 7-en azt nem értem, hogy ott meg a sajátját nem ismeri fel, és a külsősök közül is csak az egyiket.
5-arch
7-manjaro
9-archÖsszekutyulódhatott valami egy update-grub-bal, hogy 7-töl felfelé nem lát semmit a grub egyik rendszerről sem?
[ Szerkesztve ]
-
_Dumber_
őstag
válasz _Dumber_ #20459 üzenetére
Hazaértem.
Az arch (sda5)-re feltelepítettem az os-prober csomagot. Ezek után gond nélkül berakta a grub menübe az sda7 és az sda9 partíciót is.Továbbiakban:
Beboot sda7 (manjaro)-ra,
pacman -Rs grub - letakarítva
Kézzel töröltem a /etc/grub.d és a /boot/grub könyvtárat.
Grub újratelepítése.Update grub futtatása - minden rendben bootol a gép...
Most már csak azt mondja meg valaki, hogy manjaro alatt (Arch alatt nincs ilyen problémám), az update-rub futása közben a No volume groups found sorok után miért vár 5-10 percet a gép
Igy kb 10-15 percembe telik mire lefut az update-grub
[root@Gabor-Acer boot]# update-grub
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
Found linux image: /boot/vmlinuz-310-x86_64
Found initrd image: /boot/initramfs-310-x86_64.img
Found initrd fallback image: /boot/initramfs-310-x86_64-fallback.img
Found linux image: /boot/vmlinuz-310-x86_64
Found initrd image: /boot/initramfs-310-x86_64.img
Found initrd fallback image: /boot/initramfs-310-x86_64-fallback.img
/dev/cdrom: open failed: Nem található adathordozó
No volume groups found
Found Arch on /dev/sda5
Found Arch Linux (rolling) on /dev/sda9
Found memtest86+ image: /boot/memtest86+/memtest.bin
No volume groups found
Found Arch on /dev/sda5
Found Arch Linux (rolling) on /dev/sda9
Found memtest86+ image: /boot/memtest86+/memtest.bin
doneMár azon gondolkodom, hogy a syslinux nem lenne e jobb és egyszerűbb....
[ Szerkesztve ]
-
Sobriety
tag
Debian alatt - több gépen, több videokártyával is - a monoscape kivételével horizontálisan durván egymásra, egymásba csúsznak a karakterek terminál emulátorban, weblapokon is furák egyes karakterek távolságai és az élsimítás is bajos. Mindkettőre érdekelne megoldás, meglátás, tapasztalat.
[ Szerkesztve ]
-
McSzaby
őstag
Sziasztok,
LVM alóli boot-t támogatnak már az újabb Linuxok? Centi 6.5-n még nem tudtam megcsinálni, azt tudom.
#ThankYouSirAlex #ThankYouLouis
-
CloZee
aktív tag
Még mindig szükségem lenne egy olyan programra, amivel jobb klikk -> titkosítás módszerrel tudok mappát vagy fájlt titkosítani, úgy hogy megnyitáskor jelszót kérjen.
-
CloZee
aktív tag
válasz lev258 #20476 üzenetére
Ó köszi. Meg is találtam és mint kiderült, alapból tartalmazza a Mint 17.
-
OddMan
őstag
Szoftveres (mdadm) raid-el kapcsolatban lenne egy kérdésem.
Szóval van 2db raid1 tömböm, ami 2 diszken helyezkedik el. Név szerint md0 és md1. A kérdésem, hogyha tönkremegy az egyik diszk, akkor a csere után először létre kell hoznom a partíciókat az új diszken és csak utána rakhatom vissza a lemezen lévő partíciókat a tömbbe illetve tömbökbe?
Egy virtuális rendszeren kísérletezgettem a diszkek megsemmisítésével és azt vettem észre, hogy miután visszaraktam egy üres diszket az mdadm elkezdte visszaszinkronizálni az adatokat, viszont a partíciók nem kerültek vissza az új diszkre. Parted programmal ellenőriztem.
Hardveres raid esetén ilyet még nem tapasztaltam. Ez szoftveres raid esetén normális működésnek számít? Esetleg létezik olyan program, ami képes lemásolni a még jól működő diszk partíciós tábláját és azt áthelyezni az új diszkre, persze csak a partíciókat, adatok nélkül?''A szíved szabad! Légy bátor és kövesd!''
-
dabadab
titán
válasz OddMan #20479 üzenetére
Az mdadm-et nem erdekli, hogy mit kap - particio, egesz disc, (loopbackkel mountolt) file: mindegy neki, azt fogja hasznalni. Szoval ha azt mondod neki, hogy "mdadm --add /dev/md0 /dev/sdb", akkor nekiall siman a komplett sdb-t hasznalni (amin ezek utan nem lesz particios tabla).
Ha szeretned hogy az uj HDD-n (a peldaban /dev/sdb) ugyanaz a particios table legyen, mint a mar meglevon (a peldaban /dev/sda), akkor mondd azt, hogy
sfdisk -d /dev/sda | sfdisk /dev/sdb
Ezt termeszetesen azelott kell megcsinalnod, mielott az sdb-t hozzaadnad a tombhoz.
DRM is theft
-
válasz OddMan #20479 üzenetére
a kernel kicsit össze-vissza kezeli a partíciós táblát, ezt úgy értem, hogy van, amikor újra be kellene olvasnia, de nem teszi (pl. ha olyan diszken módosítod, amin van mountolt partíció).
ezért az egyszerűség kedvéért ha partíciós táblát buherálsz, mindig reboot. nem állítom, hogy mindig kell reboot, csak egyszerűbb gondolkodás nélkül rebootolni, mint agyalni, hogy most kell vagy nem kell.
tehát én azt javaslom, hogy új diszknél particionálás, reboot, majd mdadm.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
BoB
veterán
openSUSE bejelentés: mostantól az openSUSE Factory stabil, önálló rolling release disztribúció.
[ Szerkesztve ]
You may corrupt the souls of men, but I am steel. I am doom.
-
#40935168
törölt tag
Sziasztok,
eldöntöttem, hogy itthonra a fotóim miatt Debian alapú NAS-ra állok rá a NAS4Free-ről, mert kell a pusztán NAS funkció mellé még rengeteg minden nekem..
Röviden a problémám: a HDD-k seek-elnek, a LED villog. Üresjáratban is 2mp-enként pozicionál vagy hármat a fej a raid tömbön.
Setup:
- Gigabyte mezei alaplap (LGA1055, 6xSATA3)
- Pentium proci
- 8G RAM
- 3 x 4TB Seagate NAS HDDA Seagate NAS HDD-k egyikéről fut a rendszer, a másik kettőre még nincs replikálva és raid-be téve az ottlévő partíció, csak elő van készítve (sfdisk-el backup-oltam az elsőről a teljes GPT part. táblát és ezt visszanyomtam a másik kettőre).
Egyelőre /dev/sd[abc]4-ből csináltam egy raid5 arrayt, /dev/md4p1 néven. 3db totál egyező 3.9TB-s partíció, md4p1-et ext4-re formáztam.
Minden csodálatos, minden szuper. Lefutott a szinkronizálás is, mdstat:
root@nas:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md4 : active raid5 sda4[0] sdc4[3] sdb4[1]
7733499632 blocks super 1.2 level 5, 4k chunk, algorithm 2 [3/3] [UUU]unused devices: <none>
Írási sebesség 1 HDD szintje körül van, olvasás elég gyors.
Smart értékek abszolút jók, 3 vadonatúj HDD, mind 100/100, előbb HD Sentinellel néztem őket másik gépben, végül beszereltem ide.Mi lehet a seek-ek oka ? Nem sima HDD seek-ek, ami HDD hibára utalna, mivel a LED világít, tehát az OS-től jön-megy valami kérés a raid tömb irányába.
- Ha az array-t umount-olom, megszűnik a seek-elés és tök csend és nyugi: a HDD-k pörögnek, a rendszer áll csendben és nem történik tényleg semmi.
Ha az array-t mount-olom, indul a kb. 2 mp-enkénti seekelés, LED villogással együtt, tehát VALAMIT csinál az oprendszer az array-en. Ami nem a recovery/resync, mint látjuk fentebb az mdadm stat-ból.
Egy külföldi fórumon egyedül ennyit találtam, mert más is küszködött már hasonlóval:
- lehet kernel bug, de javították, enyém pedig friss wheezy (stable) és full up-to-date
- tippelt valaki arra, hogy az array-en ext4 létrehozás gyorsan megtörténik, de ezután ténylegesen a rendszer csak később, működés közben incializálja az inode-okat, ez valami lazy-inode init ...és elvileg elmúlik idővel, ahogy végzett, csak hát itt most bárhogy nézem, közel 8 terát kell inicializálnia, ha ez a inode-os feltételezés igaz..Mount-olás noatime-al történik fstab-ból .. az ext4 journal sem lehet szerintem..
Nem vagyok nagy guru, inkább amolyan lelkes kezdő-középhaladó. Lenne ötlet, mi dolgoztatja a HDD-ket felmountolt array esetén ?
-
#40935168
törölt tag
Semmi.. minden nullán áll, közben nulla és 1M/sec között váltakozik lustán a Total DISK Write.
Total DISK READ: 0.00 B/s | Total DISK WRITE: 1016.31 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
4096 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0]
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init [2]
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
6 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
7 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
8 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
10 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
12 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
13 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuset]
14 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khelper]
15 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kdevtmpfs]
16 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [netns]
17 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [sync_supers]
18 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [bdi-default]
19 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kintegrityd]
20 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kblockd]
21 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khungtaskd]
22 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kswapd0]
23 be/5 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksmd]
24 be/7 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khugepaged]
25 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [fsnotify_mark]
26 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [crypto]
2652 be/4 Debian-e 0.00 B/s 0.00 B/s 0.00 % 0.00 % exim4 -bd -q30m
4103 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [flush-8:0]
2604 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog
4104 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sshd: root@pts/0
2150 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % supervising syslog-ng
2625 be/4 messageb 0.00 B/s 0.00 B/s 0.00 % 0.00 % dbus-daemon --system
2742 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sshd
589 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kpsmoused]
4109 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % -bash
.
.
. -
#40935168
törölt tag
Talán még ez segíthet ?
root@nas:~# mdadm -D /dev/md4p1
/dev/md4p1:
Version : 1.2
Creation Time : Sun Jul 27 16:33:01 2014
Raid Level : raid5
Array Size : 7733497856 (7375.24 GiB 7919.10 GB)
Used Dev Size : unknown
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistentUpdate Time : Tue Jul 29 22:29:19 2014
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0Layout : left-symmetric
Chunk Size : 4KName : nas:4 (local to host nas)
UUID : b3387dba:1f157a9d:cdca131e:f12e4b93
Events : 829Number Major Minor RaidDevice State
0 8 4 0 active sync /dev/sda4
1 8 20 1 active sync /dev/sdb4
3 8 36 2 active sync /dev/sdc4 -
#40935168
törölt tag
Megoldottam. Töröltem a teljes fájlrendszert és kapott egy btrfs-t az md4 array. (Egyelőre ahogy gugliztam, inkább softraid és arra btrfs még, mintsemhogy fájlrendszer szinten btrfs-ből raid5-özzek zfs raid-z1 módra). Nyugi is van, semmi sem írogat rá ha nem kell. Vmi hülyeség van ext4 körül..
-
őstag
-
olivera88
veterán
Véletlen nem lehet valahogy előkeresni a vágólap előzményeket? Az idióta weboldalunk kiléptetett mikor mentettem volna a cikket. Meg volt Copyban a szöveg, csak véletlen megfeledkeztem róla és másoltam valamit a vágólapra. Bezzeg ha Suse-t használtam volna most az LMDE helyett akkor meglenne a klipperben.
[ Szerkesztve ]
LG Velvet 5G Android 11 - Windows 10 Pro x64 & Debian 11 Bullseye - WoWS unsinkable_sam_
-
Lenry
félisten
ha egy gépre nincs nyomtató kötve, akkor kell a CUPS bármire? (értsd: kukázhatom?)
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
#40935168
törölt tag
válasz lionhearted #20490 üzenetére
Több ismert disztró is defaultból ajánlani fogja, még a hivatalosan stabillá tétel előtt. Szerintem túl van hype-olva az instabilitása (ami kezdetben valid volt amúgy), ettől függetlenül nem fogok megint ext4-et tenni rá, hogy hülyére seek-eljen 3 vinyó a semmire.. úgyhogy egyelőre igen, a raid5 md4p1 array-t ezzel formáztam le.
4 másik külső HDD-n itt-ott megvan minden, egyelőre őket sem törlöm egy darabig (hátha meggondolom magam mégis).
-
őstag
válasz #40935168 #20496 üzenetére
Persze, én értem, bár hogy mi lesz a default ajánlás, az egy másik kérdés, tény, hogy egyes fícsőreivel jobb, mint az ext4, főleg backupként. Gondolva itt a transzparens tömörítésről, vagy arról, hogy 1 adatot csak 1 helyen tárol, vagy csak a különbségek kiírása...stb. Bár éppen ez utóbbi fícsörje egy szép nagy drawback is, rendesen tud kattogni a winyó a töredezettségtől, ha erről programok / OS fut.
Másfelől, mivel épp Debian alól használod, ami nem arról híres, hogy a latest kernel fut rajta, így nem is gondolnám, hogy a latest BTRFS driver mellett fogsz dolgozni, így azért több buggal szembesülhetsz, persze backportból keresgélhetsz frissebb kerneleket.Azt, hogy mennyire hájp az instabilitása, azt nem tudom felmérni, saját tapasztalataim igazából egy szobával arrébbról szereztem, neki volt, hogy napokig várnia kellett a fixelő toolokra a fejlesztőtől, mert összeomlott a fájlrendszer. Azért szép volt látni, hogy winre kényszerült egy hétre a hülye bétafájlrendszer-mániája miatt.
De, azt nem tudom neked megmondani, hogy mitől seekel be az ext4. Lehet az is valami kernel bug, de nem hinném, hogy ezt senki ne vette volna észre... ilyen problémába még nem ütköztem.
[ Szerkesztve ]
Tegnap még működött...
-
#40935168
törölt tag
válasz lionhearted #20497 üzenetére
Nekem inkább kényszer. Az ext4 problémámra itt senki nem reagált, a neten sem lettem okosabb, most formázzam ntfs-re a raid tömböt ? (Megfordult a fejemben)..
Na az morbid lenne (elvből)
-
őstag
válasz #40935168 #20498 üzenetére
FAT32
Én csak felhívtam a figyelmet, hogy instabil fájlrendszer sosem nagy ötlet, főleg, ha azokon vannak a "mentéseink", és pótolhatatlan dolgaink.
Nem tudom, hogy mennyire kényszer vagy sem, hogy ext4 is csak valami bugot talált, lehet idővel megoldódott volna, vagy újraformázás... vagy új kernel. Tényleg nem tudom.
Egyébként van azért még fájlrendszer, XFS, JFS, ZFS (bár ezt a kernel licenc okok miatt nem támogathatja).Tegnap még működött...