Linux-kezdő

[megoldva] root partició kiterjesztése nem megy

Fórumok

Sziasztok,

most már pár napja szívok egy n00b problémával:

van egy RPI 64GB-os kártyával, amit szeretnék dd-vel átírni egy 256GB-os kártyára. Ez hibátlanul sikerül is, utána tudok bootolni a 256-os kártyáról.

A probléma ott kezdödik, hogy szeretném a 2. particiót a kártya maximális méretére kiterjeszteni. Két féleképp próbáltam, egyszer futó rendszernél és egyszer egy másik gép kártyaolvasójában. Csak a parancsok és méretek miatt a folyamat itt bemásolva:

pi@dockerpi:~ $ sudo parted /dev/mmcblk0
GNU Parted 3.2
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit chs
(parted) print
Model: SD SN256 (sd/mmc)
Disk /dev/mmcblk0: 31107,171,39
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 31107,255,63.  Each cylinder is 8225kB.
Partition Table: msdos
Disk Flags: 

Number  Start      End          Type     File system  Flags
 1      0,32,32    32,194,33    primary  fat32        lba
 2      32,194,34  7764,108,23  primary  ext4

(parted) resizepart 2 31107,171,39
(parted) 
(parted) print                                                            
Model: SD SN256 (sd/mmc)
Disk /dev/mmcblk0: 31107,171,39
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 31107,255,63.  Each cylinder is 8225kB.
Partition Table: msdos
Disk Flags: 

Number  Start      End           Type     File system  Flags
 1      0,32,32    32,194,33     primary  fat32        lba
 2      32,194,34  31107,171,39  primary  ext4

ezután még volt

sudo e2fsck -f /dev/mmcblk0p2
sudo resize2fs /dev/mmcblk0p2

aztán átrakva a pi-ba a bootolás során megáll az USB eszközök felismerésénél.

próbáltam úgy is, hogy letörlöm a particiót és újra, nagyobb méretben létrehozom resize helyett, de az eredmény mindig ugyanaz. Van egy leírás, ami a futó rendszer alatt csinálja végig az egészet, az is ugyanazt eredményezi.

Mit bénulok el?

Desktop linux a windows 11-el nem kompatibilis laptopra

Fórumok

Sziasztok!

Az otthoni laptopom nem kompatibilis a Windows 11-el, és idén lejár a windows 10 támogatása. Emiatt valamilyen linux distrót keresek helyette.

Böngészésre, filmnézésre, hobbiszerű fejlesztésre (nem üzleti) használom a laptopomat.

Az alap elvárásom, hogy legyen viszonylag stabil az alap hardwarek támogatása (monitor, egér, billentyűzet, wifi kártya) Speciálisabb driverekre (pl.: Nvidia driver) nincs szükségem. Néhány példa a korábbi problémákra, amik miatt visszaváltottam linuxra:

  • Kijött egy frissítés Ubuntura, amitől kezdve a GRUB-ból történő továbblépés után a laptop monitoron kikapcsolódott a háttérvilágítás, így csak erős fényben közelről lehetett látni bármit is a képből.
  • A touchpad gyakran nem működött és újra kellett hozzá indítani az oprendszert hogy működjön.
  • A Wifi sokkal lassabb volt, mint Windowson, rendszeresen megszakadt a kapcsolat, és a hálózati késleltetés sokszorosa volt a windowsosnak. (Inteles Wifi kártyám van, szóval elvileg támogatott linuxon...)

Ezen kívül érdekelne, hogy a streaming szolgáltatókat illetőleg van-e különbség az egyes distrók között.

Gnome keyring Chrome kikapcsolása

Fórumok

Az oprendszer Linux Mint 21.3 "Virginia" a DE Xfce. Szeretném a chrome böngészőt az bejelentkezési kulcstartó nélkül indítani. A /home/user/.local/share/keyrings/Alapértelmezett_kulcstartó.keyring fájlban találtam is bejegyzést a böngészőre vonatkozóan, de nem tudom mit kell módosítanom, hogy kikapcsoljam. Bemásolom a fájl tartalmást:

$ cat /home/piros/.local/share/keyrings/Alapértelmezett_kulcstartó.keyring 
[keyring]
display-name=Alapértelmezett kulcstartó
ctime=1671196917
mtime=0
lock-on-idle=false
lock-after=false

[2]
item-type=0
display-name=Chrome Safe Storage Control
secret=The meaning of life
mtime=1732801117
ctime=1732801117

[2:attribute0]
name=explanation
type=string
value=Because of quirks in the gnome libsecret API, Chrome needs to store a dummy entry to guarantee that this keyring was properly unlocked. More details at http://crbug.com/660005.

[2:attribute1]
name=xdg:schema
type=string
value=_chrome_dummy_schema_for_unlocking

[3]
item-type=0
display-name=Chrome Safe Storage
secret=3btjl+uElsNy/8ZV+RpEEw==
mtime=1732801117
ctime=1732801117

[3:attribute0]
name=application
type=string
value=chrome

[3:attribute1]
name=xdg:schema
type=string
value=chrome_libsecret_os_crypt_password_v2
 

Köszönöm a segítséget!

/MEGOLDVA/ //.config/kreadconfig5rc nem írható

Fórumok

Mageia9 KDE, hiba előzménye: Szerettem volna bejelentkezés nélkül bebootolni, itt a kdewallet jelezte, hogy a jelszótárolót akarom-e módosítani. Bezártam, hogy nekem ő nem kell. Illetve az sddm-nél állítottam be olyat, hogy nincs sddm, egy üres fehér háttérre klikkelve.

Innentől kezdve hibaüzenetek fogadnak a grafikus felületen ott, ahol már be kellene jelentkezni, az egyik ez: //.config/kreadconfig5rc nem írható. Beléptem recovery módban, majd rákerestem erre a fájlra, de nem a home/user/.config ahol megtaláltam, hanem az usr/bin . Adtam neki ott mindenféle jogot, plusz kínomban futtatható is lett, majd ezt átmásoltam a home/user/.config helyre úgy, hogy ott a jogot átírtam a root helyett userre és itt is kapott mindenféle jogot a file. kreaáltam új usert, de ez sem segített belépnem.

Mit javasoltok, hogyan tovább? Tudom gyorsabb volna reinstall a rendszer, de akkor soha nem fogom megérteni ezt a folyamatot. Itt olvastam erről, bár a megoldás nekem nem jó ebben az esetben:

https://bugs.kde.org/show_bug.cgi?id=492887

 

Megoldás: reinstall a rendszer, csak a / formázása és telepítése, a Home tartalma változatlan maradt, így a régi rendszerem köszönt vissza.

Régi „lvm”-ek újracsatolása [Megoldva]

Fórumok

Szervusztok!

Elnézést kérek, nem vagyk tisztában annyira a szakkifejezésekkel.

Ubuntu 24.04.01 . 22.04-ről frissítettem, azelőtt előtt külön meghajtón, egy ssd-n volt a rendszerem, a /home könyvtárat pedig egy két lemezből álló „LVM”-re raktam. A frisstés során sikerült egy áramszünetet csinálnom, úgyhogy inkább az ssd-re újrahúztam a rendszert. Gondoltam utóag az /etc/fstab fájlba írom, hogy hol legyen a /home könyvtár.

 

Igen ám, de a két lemezes lvm-et most külön látom a gnome-disks progiban, nem mutat semmi egységet a dolog. Az /etc/fstab-ban csak az ssd szerepel alapból

tartalomra azt írja mindkét lemeznél: LVM2 Physical Volume (LVM2 001)

Partíciótípusra "Linux LVM"-et ír mindkét meghajtóra.

 

A thunar nem lát más meghajtót.

Hogyan tudnám ezt a két lemezt ismét egységesíteni, hogy a régi adataimat tudjam használni?

Reménykedek a segítségetekben, annak ellenére, hogy valószínűleg elég pongyola voltam.

samba vírusírtás

Fórumok

Sziasztok,

Tegnap kaptam egy levél sorozatot, hogy szokatlan IP tartományból történt sikeres bejelentkezés, először azt hittem hogy szokásos spam e-mail sorozat, de nem. Valószínű hogy az internet szolgáltatónál vacakolt valami, mert az eszközök stimmeltek, de azért lefuttattam az egész rendszeren és a hálózaton egy vírusírtót, hátha. Szerencsére semmi találat.

Ennek ellenére, ugyan mindenhol aktiválva van a kétlépcsős azonosítás, nehéz jelszavak, stb... szeretnék egy vírusírtót üzemeltetni a fájl szerveren legalább, hogy oda nehogy bármi bejusson. 

Célom az lenne, hogy valós idejű szkennelés történjen, nagyjából 5TB adat van ami folyamatosan változik és ez smb szerverrel megosztva Windows klienseknek amiken szintén nagy mennyiségű adat van és folyamatosan változik.

ClamAV erre mennyire alkalmas és milyen megoldás van rá, hogy folyamatosan szkenneljen? Erőforrás van rá.

Thunderbird "Could not connect..."

Fórumok

Kedves Tanult/Tapasztalt Fórumtársak!

Adott egy Thunderbird, kezel több postafiókot, a postafiókok beállításai stabilan megvannak igen hosszú évek óta, és zavartalanul működött minden hosszú ideje (jelentős levélforgalmat bonyolítva). Tegnap este volt egy pár másodperces áramszünet, ami valamibe nagyon belezavart. Két accountot ugyanazon a kiszolgálón kezel, egyiknél a "Could not connect mail server <távoli kiszolgáló>; the connection was refused" üzenetet adja, a másiknál a "Your message was sent but a copy was not placed in your sent folder (Sent) due to network or file access errors." A távoli kiszolgáló elérése ssh alagutakon keresztül történik, a TB úgy tudja, hogy az imap kiszolgáló a localhost:1143, az smtp pedig a localhost:2525-ön van. Az adott portokra telnettel kapcsolódva elérhető az imap, ill. smtp kiszolgáló, tehát a portforward működik. A helyi gépről ugyanilyen módon másik helyi felhasználó levelezése probléma nélkül működik, igaz, ő az áramkimaradáskor nem csinált semmit.

A helyi gépen (amelyiken a TB fut) nem látok semmi furcsát a logban, viszont a távoli kiszolgálón a syslogban lett egy csomó "May 28 07:17:22 turul sshd[15713]: error: connect_to 127.0.0.1 port 1143: failed." bejegyzés. Ez a távoli sshd újraindítása után is fennál.

Mi az, amire nem jövök rá, merre keressem a megoldást?

Üdvrivalgással:
KEA.

Particionálás (túlbonyolítása)

Fórumok

Sziasztok!

Csak egy alapvető témát szeretnék feldobni, és inkább kezdő linuxos kérdés. A megfelelő particionálással nagyobb biztonságot lehet biztosítani (pl céges környezetben): pl kivédhető, hogy alkalmazások a root partíciót teleírják, vagy mástól vegyék el a helyet stb...

Egy desktop gépre most a Fedora BTRFS-sel alapértelmezetten a következőket hozná létre (vagyis ezt ajánlja fel a kézi particionáláskor):

  • /boot
  • /boot/efi
  • /
  • /home
  • /var
  • swap

Ha jól emlékszem.

Van aki csak egy root-ot hoz létre.

Régebbi rendszereknél úgy emlékszem, több partíciót volt szokás létrehozni. (desktopon lehet, hogy nem). Érdemes lehet ezt tovább bonyolítani desktopon?

Egy példa: 1Tb-os ssd-n titkosított (800 GiB), és nem titkosított (200 GiB) volume létrehozása, és azokon a következő subvolume-ok:

  • / - Nem titkosított
  • /usr - Nem titkosított
  • /usr/local - Nem titkosított
  • /root - Titkosított
  • /home - Titkosított
  • /opt - Titkosított
  • /srv - Titkosított
  • /var - Titkosított
  • /var/cache - Titkosított
  • /var/log - Titkosított
  • /var/spool - Titkosított
  • /var/lib - Titkosított
  • /var/lib/machines - Titkosított
  • /var/lib/docker - Titkosított
  • /var/lib/libvirt - Titkosított
  • /var/lib/containers - Titkosított
  • /tmp - Titkosított
  • swap - Opcionális

Ezeknek a subvolume-oknak a mérete utána finomhangolható, pl: / 40 GiB, /tmp 5 GiB, stb...

Érdekes, hogy a Fedora kérdezés nélkül létrehoz egy /var/lib/machines subvolume-ot, lehet hogy valami technikai oka van, de akkor érdemes lehet a docker-nek, podmannek, és a libvirt-nek is külön partíciót csinálni.

A swap partició: több memóriával rendelkező gépen gondolom nem érdemes külön swap-et csinálni, kivéve ha valaki hibernálni akarja a gépét. A Fedora így is csinál valami zram-os megoldást, ahol a RAM-ban van a swap, tömörítve a benne lévő adat. (ha jól értem).

Desktop-on nem valószínű, hogy az ember belefut olyan problémákba, ami miatt ezt ennyire el kellene bonyolítani, lehet hogy ez így túl overkill. Vagy manapság már ez nem szokás, pl külön rakni a /usr-t? A otthoni gépeteken ez hogy van?

[Megoldva!] SELinux + root password visszaállítása

Fórumok

Sziasztok!

Én Az egyik ismerősőm :) egy desktop gépen, amin van egy root user, és egy regular user véletlen egy rosszul kiadott usermod paranccsal kivette magát a wheel groupból. Ez egy Fedora 40 egyébként, és a root bejelentkezés pedig le van tiltva. Tehát sikeresen kitiltotta magát, mint adminisztrátor, ezt ugye jól gondolom?

Már túl vagyok a dolgokon, de három lehetőséget találtam, itt van leírva kettő:

https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/

A harmadik, hogy felmountolom a home-ot, gyorsan csinálok még egy mentést, és 15-30 perc alatt újrahúzom a rendszert (ami kb meg is lehet az összes beállítással).

Az első két megoldással elszórakoztam kb 2 órát,

1. Rescue módban ha megváltoztatom a jelszót, hiába hozok létre egy /.autorelabel fájlt, utána nem lehet belépni egy jelszóval sem.

Kicsit kutakodva, korábban a /etc/init.d/fuctions fájlban volt egy ilyen:
https://github.com/aababilov/systemd/blob/master/fedora-autorelabel
Most ez sehol nincs (vagyis én nem találtam), és a .autorelabel is ott marad a root könyvtárban reboot után, tehát nem is futott ilyesmi.
Ha kézzel akarom futtatni az itt leírt parancsokat, persze az nem működik, nem írtam fel a hibaüzeneteket, de selinux-os problémákra hivatkozott. (szerinten nem megfelelő context volt beállítva, vagy hasonló).

2. Live CD:

Miután felmountoltam mindent, és chroot-al root könyvtárat váltottam, kiadnám a passwd-t, de a következő hibát adja:

authentication token manipulation error

Tehát a Fedora-s leírások (2022-ben update-elték utoljára) igazából Fedora 40-el nem működnek/én a selinux-hoz se értek, meg kellene tanulni..

3. Újra telepítés: Ez itthon megtehető (máshol már nem), ez persze működik, gyorsan meg is van, csak nem ez lenne a módja.

Az is simán lehetséges, hogy valami pofon egyszerű egyéb módszerrel meg lehet ezt oldani, és feleslegesen bonyolítottam.

Most már nem kisérletezek vele, minden működik, de foglalkoztat, hogy mi a rendes megoldás, esetleg valaki járt már így?
Best practice, hasonló esetek kivédésére: Van a gépeden plusz user, vagy engeded a root-nak a belépést?

Megoldás:

Lásd: https://hup.hu/comment/3055661#comment-3055661