Helyzavar - ubuntu

Ubuntu Linux

Szasztok!

Odahaza van egy gépem (nem túl nagy) egy Django-t futtatok rajta. Az a különös helyzet állt elő hogy normál usernél azt mondja a home útvonalra hogy elfogyott a hely, root-ként meg hogy van 160 mega. ezt hogyan lehetne orvosolni (ilyet még nem láttam)

 

df ugyan azt mutatja:

Filesystem                        1K-blocks    Used Available Use% Mounted on
tmpfs                                343052    5668    337384   2% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   5263232 5099088         0 100% /
tmpfs                               1715260       0   1715260   0% /dev/shm
tmpfs                                  5120       0      5120   0% /run/lock
/dev/sda2                           1768056  151328   1508596  10% /boot
/dev/sda1                            549804    6216    543588   2% /boot/efi
tmpfs                                343052       4    343048   1% /run/user/1000
  • 1703 megtekintés

( trey | 2023. 05. 05., p – 08:34 )

Szerkesztve: 2023. 05. 05., p – 08:36

root usernek van reserved helye általában

ezt hogyan lehetne orvosolni

A root fájlrendszer bővítésével (nem ez az igaz út) vagy a /home külön diszkre, partícióra, volume-ra rakásával (inkább ezt csinálnám).

trey @ gépház

Hát, van még azért kapható 500 gigás hdd is. Továbbá ott vannak a 120 gigás, vagy a még kisebb ssdk. Ki ne vágyna egy Kingchuxing 64 gigás ssdre 3500 Ft áron, szállítással?
+1, hogy nőnek a szoftverek méretei, és az adatok is nőnek.. sok mpixeles kamerák, 4k videó...

Nem számít.

Personal lófasznál, ahol nincs elég tárhelyed sokkal inkább számít, hogy ki tudd használni a helyet.

Ha pedig külön akadnád szedni mondjuk a root-ot és a home-ot, akkor előre meg kell jósolnod a lehetetlent, hogy melyiknek mennyi kell majd. 

Amit kb esélytelen hogy eltalálj. Honnan kéne tudnod, hogy 2 verzió múlva a rendszered mennyit fog foglalni? Hogy mennyi logot, cache-t, szemetet fog termelni használat közben?

Azt tudod, hogy hagysz bőségesen helyet, amit aztán majd nem tudsz semmire se használni, és azon kapod magad, hogy hirtelen a root partícióra kezdesz adatokat mozgatni, meg körbe mountolgatod a fájlrendszert, hogy elférjen minden :) 

Vagy bővítesz hardvert. De ez nem mindig opció.

"Azt tudod, hogy hagysz bőségesen helyet, amit aztán majd nem tudsz semmire se használni," - annyit tudsz csinálni, hogy a vg-ből induláskor (telepítés) nem osztod ki a teljes szabad területet, csak annyit, amennyi minimum kell. Aztán ahogy nő itt-ott az igény, lehet oda pakolászni helyet.

És akkor, hogy teljes legyen a kép, van még a thinly-provisioned LVM pool is.

Ami kvázi egy kvóta: van egy pool-od (elfoglalja az egész VG-t), amit ugyan részekre osztasz (LV), de ezek össz. mérete nagyobb lehet, mint a pool (overprovisioning), tehát gyakorlatilag a filerendszer maximum méretét adod meg - mindeközben arra számítva, hogy nem telik be egyszerre az összes LV.

A rendszer működőképes marad, pont az említett reserved space miatt.

Csak saját célra egyedül használt desktop esetén semmi értelme külön tenni fájlrendszereket: ha kevés a hely, akkor csak szopás van azzal, hogy itt-ott van hely, csak nem használható; ha meg sok a hely, akkor teljesen mindegy, mert van bőven hely.

https://iotguru.cloud

Erről nem vagyok meggyőződve. Én két 500 GB-os SSD-re tettem az oprendszert RAID1-ben, és két 2TB-os HDD-re a /home-ot szintén RAID1-ben. Szerintem az alkalmazások berántása legyen gyors, a munkafile-ok legtöbb esetben nem olyan nagyok, de ott meg kell a sok hely. A virtuális gépek image-ei még az SSD-n vannak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyrészt itt egy darab 8GB mérető storage van, ha van kettő storage, ráadásul eltérő technológia, akkor kell és/vagy érdemes külön tenni, de én akkor se a /home és / kapcsán tenném külön, hanem minden egybe és egy külön felcsatolt bármi. Saját magad kezeled az egész eszközt, csak észreveszed, hogy csökken a szabad hely.

https://iotguru.cloud

Jó fej vagy, a /-ben a /home, mint üres alkönyvtár nyilván az SSD-n van nálam is, s csak annak belseje, tartalma van a HDD-ről a /home alá mount-olva.

Ahhoz is tehetség kell, hogy valaki összesen 8 GB storage-re tegyen oprendszert, majd azt desktopként kezdje használni. Szép rendszertervezői teljesítmény eredménye. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó fej vagy, a /-ben a /home, mint üres alkönyvtár nyilván az SSD-n van nálam is, s csak annak belseje, tartalma van a HDD-ről a /home alá mount-olva.

Pont ezt kérdezem, hogy miért nem az van HDD-n, ami csak ott fér el? A /home alatt ott van rengeteg dolog, aminek jót tesz, ha SSD-n van, ahogy bármi másnak is. Addig nem használnék semmire HDD-t, amíg van hely az SSD-n, maximum backup célokra.

Ahhoz is tehetség kell, hogy valaki összesen 8 GB storage-re tegyen oprendszert, majd azt desktopként kezdje használni. Szép rendszertervezői teljesítmény eredménye. :)

Olvass többet és akkor nem kérdezed meg, ami le van írva.

https://iotguru.cloud

Már csak 95 GiB szabad helyem van az SSD-n, ami kb. elhanyagolható. Semmi kedvem belefutni egy frissítés kapcsán abba, hogy teleszaladt az rpm adatbázis, hogy nem tud hova logolni a gép, hogy nincs hely egy virtuális gépnek vagy egy új alkalmazásnak. A HDD-n viszont van még 1.35 TiB szabad helyem, azzal elvagyok még egy darabig.

Valóban nem olvastam el, milyen gyermekkori trauma okozta ezt a 8 GB-os háttértárat, de akkor megnézem, hátha valóban nagyon indokolt. Jó, ha valaki egy router-ből csinál desktopot, és a flash csip a PCB-re van forrasztva, akkor mindent értek. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Már csak 95 GiB szabad helyem van az SSD-n, ami kb. elhanyagolható.

Értem, csak minden szar miatt a HDD fog teljesen feleslegesen pörögni és a mindenféle cache is lassú lesz HDD-n. Te tudod, csak antipattern, amit csinálsz, vélhetően valami 20 éves berögződés miatt.

Semmi kedvem belefutni egy frissítés kapcsán abba, hogy teleszaladt az rpm adatbázis, hogy nem tud hova logolni a gép, hogy nincs hely egy virtuális gépnek vagy egy új alkalmazásnak.

És erre nem elég 95 GB?

https://iotguru.cloud

a HDD fog teljesen feleslegesen pörögni

Miért lenne felesleges? Hozzátartozik a működési elvéhez. Amúgy nem állítom le a HDD-t, tudtommal nem áll meg soha. Ezen felül nem használom a sync mount opciót, van disk cache, egyáltalán nem érzem lassúnak a gépet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A /home/<user> alatt vannak olyanok, mint pl. .config/*, .bashrc, ... tehát könnyen előállhat az a helyzet, amikor a hdd idle, nyitsz egy terminált, az meg egy bash-t, és csak emiatt kell felpörögjön a hdd. Vagy távolról bejelentkezve a .ssh/* elérése miatt. Ezért jobb, ha a /home/* ssd-n van, a hdd pedig /storage vagy /home/media alatt. Ettől függetlenül, /, /home, /var lehet külön.

Amúgy ez a szétpartícionálás vs. mindenegyeben vita már 20 éve is uncsi volt. :)

Szerintem nem triviális, hogy mi az alapvető probléma.

Simán lehet, hogy az, hogy a kérdező most már tudja, hogy miért van ez, meg is nyugszik, és jó így neki.

Lehet, hogy a probléma az, kurvára kell neki valamire még az a 160 mega hely. Ez esetben a tune2fs (akár ideiglenes) használata megoldás lehet, ahogy valami egyéb "csináld meg a root nevében, amit most akartál" megoldás is.

Az pedig, hogy desktopon egy / van, az egyáltalán nem biztos, hogy nem jó. Én is jobban szeretem külön a /home-ot, de őszintén szólva desktopon nem tudom, ez mennyire stockholm szindróma. Azért ha minden egyben van, akkor szinte biztosan jobban ki fogom tudni használni a helyet, mint ha szétszedném, és kellene valami puffer, hogy ennyi hely biztos elég lesz a szoftvereknek (logoknak, stb stb), szóval ekkora lesz a / (/var stb stb), és a többit hagyom a homenak. Desktopon az üzembiztonságnak kb mindegy, meg nem fog állni a root reserveje miatt, ha elhasználtam a helyet, arra meg nem biztos, hogy szükségem (vagy tudásom) van, hogy külön legyen, és ezért tudjak mindenfélét bűvészkedni.

Nem értek egyet. Messziről lerí, hogy kinőtte a tárhelyet. 8 giga SSD mai rendszerek alá smafu. Még ha valami spéci vékonykliens is, ahogy írja, vesz bele egy olcsó SSD-t, 256 gigáig újonnan is olcsók, használtan meg végképp filléres, nekem pl. van egy potom pénzért vett 60 gigás Sasmsung PM800-as, sok éves, még a SATA2 korszakból való, de használtan véve mindig bírja (nem csoda, ezek még klasszik, nagy csíkszélességű MLC-k voltak), alig volt pár ezres. A 128-asok sem sokkal drágábbak, itt az angol eBay-en, ami egy túlárazott lehúzóhely, 2-4k forintnak megfelelő összegekért vannak. Ezeket a 60-128 gigás SSD-ket a legtöbb user már fiókban tartja, mert desktopra kinőtte, nem tud vele mit kezdeni (nincs annyi csatlakozó/hely a gépben, hogy megtartsa), így olcsón megválnak tőle, még az se lehetetlen, ha a topiknyitó az ismerősi körében szétnéz, akár ingyen is kaphat valakitől ilyet. Szerverre bőven elegek ezek a kisebbek, a sebessége sem kritikus, főleg nem gyenge vékonyklilensbe.

tune2fs-ezhet, az a lényegen nem változtat, tárhelyet kell bővíteni. Ezzel nem azt akarom mondani, hogy ne futtassa, mert nagyon ideiglenes megoldásnak, pár napig, míg nem bővít, addig segíthet egyszer, ahogy a journalctl-es nyírogatás is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem értek egyet.

Azt természetesen lehet. :) Azt viszont nem értem, hogy aztán a hozzászólásod többi része hogy jön ehhez? Mármint egy szót nem szóltam arról, hogy bővítsen, vagy ne bővítsen, elég-e az a hely, vagy nem. Én csak arra reagáltam, hogy biztosan baj-e, ha egy darab root partíció van, vagy az akár úgy jó is lehet.

Külön megjegyezném, hogy akkor még semmit se nem tudtunk arról, hogy ez egy vékony kliens. :) (Egyébként meg szerintem eleve ott van elkefélve, vett a kolléga egy vékonyklienst, ami arra való, hogy a gui fusson rajta, majd azt nem akar rajta futtatni, hanem mindenféle szolgáltatásokat, django, nextcloud (lol, semmi hellyel nextcloud)), és szegény most veri be a fejét mindenbe, ahelyett, hogy vett volna valami randomfaszom micropct játszani magának.

szerk: annyit most visszanézve látok, hogy a kurvára kell neki a 160 gigát én úgy értettem, hogy ideiglenesen, és a zárójeles megjegyzés arra vonatkozott, hogy azt vissza lehet ám csinálni, de valóban lehet ezt úgy is olvasni, hogy maradhat úgy. Nem, az valóban nem jó ötlet.

Ja, bocs, akkor félreértettelek. Az egy darab root partícióval ilyen vékonyklienses, mikroszerveres felhasználásánál nincs baj szerintem sem. Desktopon nem csinálnám. Főleg, ha úgyis LVM van, amin vannak logikai kötetek, azokat rugalmasan lehet tologatni. De elhiszem, hogy a jelen helyzet nem a kolléga hibája, hanem a gány Uborka telepítő hozta össze ilyenre automatán.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem érted... ha minden egyben van, a'la c:\ akkor nem kell tologatni sem, meg húzogatni sem :-D Egyébként meg nem csak az átrendezhetőség az előny, hanem a különböző mount opciókkal is lehet operálni - pl. a /home simán mehet nosuid,nodev, a /var/log ezen felül még noexec és hasonlók...

pl. a /home simán mehet nosuid,nodev, a /var/log ezen felül még noexec és hasonlók...

Erre SELinux is jó. És lehet így faragni a dolgokat, de personal desktop esetén sok értelme nincs, nem nagyon tudsz mutatni feltört Linux gépeket, mert nem volt noexec flag a /var/log alatt...

https://iotguru.cloud

Ubuntu és SELinux? :-P

Mert? Egy sorral telepíthető, ha az Apparmor nem tetszik a limitált lehetőségek miatt - ami szintén telepíthető, ha alapból nem telepedne.

Egyébként meg attól, hogy kicsi a kockázat, még a lehetséges védelmi megoldásokat nem kellene elfelejteni/elhagyni...

Értem, tehát SELinux/Apparmor az pfúj, de keveset segítő és könnyen kikerülhető mount option az bizony must have...

https://iotguru.cloud

Nem érted, csak kötekedsz. Az Ubuntu esetén az Apparmor a default, az van, nem a SELinux, ergo mondhattam volna azt, hülyeség, amit írtál - de nem mondom :-P

Egyik sem pfúj, mindkettő a megfelelő terjesztésben _egy_ lehetséges védelmi megoldás, amit _ugyanúgy_ nem kéne elfelejteni/elhagyni, de ha van mellette n+1 másik (_például_ a mount opciók, _például_ a fájlrendszerben megadott jogosultságok, satöbbi), amivel lehet élni, akkor azt is célszerű használni. Minden védelem kijátszható, de minél kevesebb lehetőséget adunk rá, annál jobb.

Az Ubuntu esetén az Apparmor a default, az van, nem a SELinux, ergo mondhattam volna azt, hülyeség, amit írtál - de nem mondom :-P

Egyrészt fel lehet telepíteni, az Apparmor nem tud annyit, mint a SELinux, másrészt a sub-szálban locsemege gépéről van már szó, ő meg Fedora-pozitív, ott SELinux van. Amúgy egy `sudo apt install selinux-basics` mitől komplex és lehetetlen?

(_például_ a mount opciók, _például_ a fájlrendszerben megadott jogosultságok, satöbbi)

Ezek a mount opciók teljesen feleslegesek SELinux és Apparmor esetén, nem fokoznak a biztonságon. El kellene felejteni, hogy szétfarigcsált fájlrendszeren mount opcióktól várjuk a megváltást.

Minden védelem kijátszható, de minél kevesebb lehetőséget adunk rá, annál jobb.

Egyrészt nyilván egy personal desktop gépen fognak ilyeneket játszani a támadók... másrészt, ha eljutnak oda, hogy a SELinux/Apparmor védelmet kikapcsolják, akkor semmi akadálya nincs a mount opciók kikapcsolásának sem.

https://iotguru.cloud

Mert utólag az igények alapján derül ki, hogy jó lenne egy kicsit más topológia, ugyanakkor nem akarod újratelepíteni az oprendszert.

Ha minden egyben van, akkor pont mindegy, hogy utólag mi derül ki, mert amíg van szabad hely összességében, addig minden működik. Amikor elfogy, akkor a rendszer alapja megy gond nélkül, a user meg észreveszi, hogy nincs hely, ha nem vette észre időben, hogy fogy a hely.

https://iotguru.cloud

Mert ha már LVM van, az pont erre való, hogy a logikai kötetek utólag is rugalmasan átméretezhetők legyenek. De abban igazad van, hogy a mindent egyben, az egész meghajtó egyben root-nak megoldás még egyszerűbb, annak csak az a hátránya, hogy ha adatokat kell menteni, akkor ki kell halászgatni a rendszerből, meg ha OS újratelepítés történik, akkor az adatokat is újra kell rakni, míg egy különálló /home-on megmaradna. Én ezért is tartom külön a /home-ot, meg ugye az EFI partíció is külön kell, hogy legyen az UEFI boot miatt (MBR + CSM Legacy bootot már kb. 10 éve nem használok, ha egy mód van rá, csak régi gépeken, amik nem támogatnak mást), így mikor esetleges rendszer-újratelepítés van, csak felnyomom az új rendszert, kézi telepítéskor beállítom, hogy a meglévő /home és /boot partíciót használja (a boot partíción ráadásul a systemd-boot configokban PART-UUID-k szerint van megadva, azok újratelepítéskor, formázáskor nem változnak), így csak felhúzom a rendszert, de megmarad minden adat, a rendszer továbbra is bootképes (Arch nem igényli ilyenkor a bootloader újrahúzását, ez nem hülyebiztos, automatizált, GUI installeres Ubuntu). De ez desktop usecase, ilyen thin szerverre végül is elmegy a mindent egyben megoldás, kicsit igénytelen, de túl nagy hátránya azért nincs.

LVM-et nem tudom miért erőlteti az Ubuntu default telepítésen. Néha lehet előnye, pl. tologatás, amiről beszélünk, vagy pl. LUKS-szal titkosított egész rendszer esetén, ha az ember a /-tól eltérő köteteket is akar használni, és nem akarja bootkor mindegyiknek a jelszavát külön begépelgetni, hanem elég az LVM on LUKS partíciónak a jelszavát gépelni, és az egy lépésben nyitja a rajta lévő össze logikai kötetet. Vagy ha több lemezt kell egy kötetté összekapcsolni, stb., de ezek tipikusan nem átlag useres, default install felhasználási körök.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

És tökönbökni saját magát... Első körben a /var/cache/apt/archives/ alatt néznék szét/takarítanék, utána a /var/log alatt is meg lehet nézni, hogy melyik log zabál sokat (nem, a /var/log/lastlog az nem baj, hogy esetleg bődületesen nagynak néz ki, mert sparse file), utána pedig a journal-t nézném meg, hogy mennyi időt tart meg, és azon faragnék/dobnám el a régieket.
 

( Azim | 2023. 05. 05., p – 08:44 )

tune2fs felszabadított annyi helyet hogy a hétvégéig tudjak működni és beszerezni, a megoldás a bővítés lesz. köszönöm mindkettőtöknek

( fsanyee | 2023. 05. 05., p – 09:54 )

mekkora az sda? nincs már szabad hely a vg-ben?

Ha minimumra méretezi az lv-t (azaz a vg-ben van még szabad hely), akkor jó lehet a vgs (mennyi hely van?) és utána az lvextend -vr... satöbbi _és_ utána visszaállítani a root-nak fenntartott helyet (tune2fs). Vagy csinálni néhány másik lv-t, és szétpakolni a dolgokat (nálam indulásnak a /var (2G), /var/log/ (2G) a /home igény szerint, ha van DB, akkor az szintén külön lv-n csücsül, nem a /var-t eszi, de ez ízlés és igény kérdése)

( uid_17626 | 2023. 05. 05., p – 11:49 )

Szerkesztve: 2023. 05. 05., p – 11:51

lsblk, pvs, vgs, lvs

 

Jöhetnek a kimenetek.

lsblk:

NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                         8:0    0  7.5G  0 disk
├─sda1                      8:1    0  538M  0 part /boot/efi
├─sda2                      8:2    0  1.8G  0 part /boot
└─sda3                      8:3    0  5.2G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0  5.2G  0 lvm  /

pvs:

  PV         VG        Fmt  Attr PSize PFree
  /dev/sda3  ubuntu-vg lvm2 a--  5.18g    0

vgs:

  VG        #PV #LV #SN Attr   VSize VFree
  ubuntu-vg   1   1   0 wz--n- 5.18g    0

lvs:

  LV        VG        Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ubuntu-lv ubuntu-vg -wi-ao---- 5.18g

a változás a tegnapi állapothoz képest annyi hogy lekerült a snap összes csomagja

Nekem még egy dolog szúr szemet. Az /boot/efi és a /boot miért olyan nagy? Az 500 mega okés lenne, nekem is annyi körül van Arch-on, de nekem nem 8 gigás SSD-m van, hanem 2,5 terányi SSD. Ezen kívül, ha 500 megás is a /boot/efi, akkor a /bootnak miért kell még ezen felül is 1,8 gigának lenni? Mert oké, legyen 500 mega, de akkor legyen az egyben /boot, legyen ugyanott a /boot/efi is, és kész. Mindenesetre ezt ragozhatjuk, centizhetjük, lehet trükközni, de hosszú távon nem úszod meg a tárhelybővítést. Az a 8 giga már 15 éve sem volt sok mindenre elég, nem hogy most.

Amit még tudsz csinálni átmenetileg, míg nem bővítesz, hogy betolsz egy 4-8 gigás pendrive-ot, vagy SD-kártyát, állandóra bent hagyod, és azt fogod be /boot partíciónak. A bootolást nem fogja jelentősen lelassítani, és a /boot-ra a rendszer nem ír sokat, kernelt, meg grub-ot, és azt is csak frissítéskor, annyi írást kibír egy pendrive.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( gazsiazasz | 2023. 05. 05., p – 15:01 )

"Linux Desktop éve már rég eljött"

És tényleg! Valami olyamit kérdezett az osx anno az egyi barátomtól,  hogy kíván-e helyet felszabadítani? Értette ez alatt a  nem használt képek törélését. Kívánta, mert nem tudta ez mit jelent. Majd engem kérdezett,  hogyan lehet visszaállítani ezeket  a képeket. Több évnyi nyaralási emlék.

Tévedés. Ez bármelyik OS-sel megtörténhet, főleg, ha ilyen p‘csányi tárhelyen erőlteted, ami nem elég neki. Abból mindig csak a szopás van a legmodernebb rendszereken is, pl. a drágalátos desktop king (*egyre használhatatlanabb desktopra is) Windows is belehal simán, hogy nincs elég szabad hely, nem tud update-elni, rendszer-visszaállítási pontot létrehozni, stb.. Én azért is szoktam mindenből nagyobbat venni, időtállóság, nem kell túl hamar bővítéssel fetrengeni, és a partícióknál is figyelembe veszek nagyvonalú ráhagyást, hogy előre nem látott usecase-ek esetén se szívjak. Így én kb. 15-20 éve nem fogytam ki tárhelyből, azóta sose kellett ilyen takarítós mutatványokat betolni, hogy működőképesen tartsam a rendszert. Nem csak tárhelynél, memóriánál is így járok el. Egyszerűen semmit nem érdemes szűkre, pont most elégségesre szabni, az IT-ben mindig gondolni kell a jövőtállóságra is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Melyik szerinted normalis oprendszer fer el 8 GB-on ugy hogy szerver es nem bassza tele mondjuk a logokat a /var-ban ha az is ugyanazon a filerendszeren van (mondjuk)? 

A windows ami 40GB alatt meg se nyikan es alapbol az eventeket sem bassza kulon particiora? Filagosits meg minket fenyesseges elmeddel :)

Csak szolok, hogy ha rendesen be van allitva a reserved sace akkor a 100% eseten is fut tovabb a Linux. Ezt a windows hogy csinalja, mikor 0% szabad heluy van es el kellene indulnia? Mert  linux elindul. Csak ugy mondom hogy 20 evvel ezelott is elindult ellentetben a win NT-vel :D

( Azim | 2023. 05. 06., szo – 04:09 )

Nem gondoltam volna hogy ilyen népszerű lesz a topik, de akkor folytatom a történetet.

Ez a vas egy vékony kliens (HP t620- 30ojro plusz szállítás) 8GB ssd-vel (szervernek készül, gui nélkül. nincs az az isten hogy ne férjen el 1 gigán! Első hiba :D) Legyen rajta django, docker, nextcloud, mittudomén, csak elfér! (Hige Hopes - második hibapont) Ebből maradt a django (és mint kiderült a snap "kapaszkodó szemete" - de majd erről egy kicsit később)

a további bővítési lehetőségek: vagy usb-n keresztül vagy lecserélem az m3 socketen az ssd-t (aminek biztos van valami más neve)

"egybebaszva az egész" - kezdőségem/hozzánemértésem ékes példája. ÉS igen , ha beüt a krash akkor fejetlen csirke módjára rohangálok a googli és a hup között, mivel nincs meg az az üzemeltetési tapasztalat/ismeret hogy "mit csináljunk az aknamezőn" az meg végképp nincs meg hogy "hogyan kerüljük el az aknamezőt". De ez - a lustaságom mellett - azért is lehet mert nem ebből élek és sem magamat, sem másokat nem áltatom azzal hogy rendszergazda vagyok :)

Disztribúció választás: fedórát kipróbáltam volna de nem akart elsőre felmenni, debiannak gondja volt a videókártyával (nem ártott volna számítási feladatokhoz), proxmox-ról nemrég találkoztam ismertető videóval, szimpatikus de még soha nem használtam. Akko legyen azzubuntu

mind1, rengeteg sebből vérzik ez a történet (azt nem is meséltem hogy van másfél kernelem...) (/var/log csak 66MB volt, a /var/cache/apt/archives meg már más leírás alapján volt takarítva) A jelenlegi akadály a SNAP:

 

--- /snap ---------------------------------------------------------------
  878.5 MiB [##########] /nextcloud
  541.6 MiB [######    ] /kata-containers
  497.1 MiB [#####     ] /docker
  405.1 MiB [####      ] /core20
  384.0 MiB [####      ] /snapd
  338.6 MiB [###       ] /core18
    4.0 KiB [          ] /bin
    4.0 KiB [          ]  README

a nextcloud-nak és a docker-nak mennie kell (kata-containers, én nem tudom mi az! lehet hogy neki is) A probléma a "kapaszkodó szemét", a read only-ra beállított file/path/izé amit rootként nem tudok törölni

findmnt

├─/snap/core18/2714               /dev/loop0       squash ro,nodev,relati
├─/snap/core20/1852               /dev/loop1       squash ro,nodev,relati
├─/snap/docker/2746               /dev/loop4       squash ro,nodev,relati
├─/snap/core18/2721               /dev/loop3       squash ro,nodev,relati
├─/snap/core20/1879               /dev/loop2       squash ro,nodev,relati
├─/snap/snapd/18933               /dev/loop7       squash ro,nodev,relati
├─/snap/kata-containers/2446      /dev/loop6       squash ro,nodev,relati
├─/snap/snapd/19122               /dev/loop5       squash ro,nodev,relati
├─/snap/nextcloud/33908           /dev/loop8       squash ro,nodev,relati

szóval most ezzel játszok (pontosabban a googlival). Kedves @NevemTeve (Te vagy a "tevegyilkos"?) az AI szerepében tetszelgek mikrométerrel(nagyjából csak a racsni van meg belőle és az is berohadt), krétával, és baltával :D 

( Azim | 2023. 05. 06., szo – 19:51 )

A nagytakarítás project elkészült! Az eredmények:

lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                         8:0    0  7.5G  0 disk
├─sda1                      8:1    0  538M  0 part /boot/efi
├─sda2                      8:2    0  1.8G  0 part /boot
└─sda3                      8:3    0  5.2G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0  5.2G  0 lvm  /

df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              336M  5.2M  330M   2% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  5.1G  3.1G  2.0G  61% /
tmpfs                              1.7G     0  1.7G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          1.7G  148M  1.5G  10% /boot
/dev/sda1                          537M  6.1M  531M   2% /boot/efi
tmpfs                              336M     0  336M   0% /run/user/1000

ncdu /
--- / ----------------------------------------------------------------------------------------
    2.6 GiB [##########] /usr
  229.7 MiB [          ] /var
  181.1 MiB [          ] /home
  153.8 MiB [          ] /boot
    5.4 MiB [          ] /etc
    5.2 MiB [          ] /run
    2.4 MiB [          ] /root
   56.0 KiB [          ] /tmp

A margóra: SNAPD teljes eltávolítása kb 1.6G helyet szabadított fel (ebben az esetben nekem nincs szükségem erre a szolgáltatásra) https://itsfoss.com/remove-snap/ ezen leírás alapján. Annyi hogy nálam még a /var/lib/snapd (ha jól emlékszem) megmaradt (~1G) amit nekem kellet törölnöm. 

A köztes beragadt kernel eltávolítása után már le tudott frissülni az 5.15.0-71, ez után már csak a maradék feleleges kernel eltávolítás és az apt autoclean maradt (az mennyire durva hogy kb. 2G kell egy kenelfrissítéshez?)

 Amik segítettek:

Még egyszer köszönöm azoknak akik segítettek megoldani/áthidalni a problémát. Az új ssd meg bekerül amikor ideér