Lemezterület módosítása

csuhas32 · 18 napja

Rövid válasz:
[A megfelelő óvintézkedések (adat és rendszermentés készítése és visszaellenőrzése) után] egy live rendszer alól tudod átméretezni a rendszerhez működése során csatolva lévő partíciókat, így a rendszerpartíciót is.
Azonban én ezt most nem kapkodnám el.
Hosszabb válasz:
Bár nem ez a kérdésed, de szerintem igazából itt az érdekes, hogy nálad mi a nyavalya foglal 96 GB-ot a rendszerpartíción?
Lehet, ha ezt egy picit átbeszéljük, akkor eljutunk oda, hogy egy icipici átalakítás után neked is bőségesen elég lenne az eredetileg gondolt 512 GB-os helyett egy 256 GB-os rendszerpartíció.
Persze az is megeshet, hogy van néhány Snap alkalmazásod, ami ennyi helyet elfoglal, de én azt javasolnám, kezdjük ezzel, nézzük meg, mi foglal ekkora helyet a rendszerpartíción. Mit mutat a Lemezhasználat-elemző, mi zabálja fel a helyet?
Igazából ennek tisztázásával és esetleg a felhasználói szokásod megváltoztatásával juthatnál el oda, hogy esetleg sokkal kisebb rendszerpartíció is elég volna neked, jóval átláthatóbb lenne számodra is a rendszered és a lemezeid, partícióid kialakítása.
Terefere:
Extrém felhasználói járatlansággal találkoztam már, amikor talán 256 GB volt az egész lemez, amin a rendszer csücsült és kedves felhasználó elindított egy bányász programot, ami figyelmeztette is, hogy olyan 600 GB helyet fog elfoglalni. (Emlékeim szerint ez egy Flatpak alkalmazás volt, szóval valahová a felhasználó könyvtárába egy rejtett könyvtárba tette a letöltött dolgokat és mivel a home a rendszerpartíción belül kapott helyet, hamarost betelt a rendszerpartíció.)
Amit még el lehet követni az szerintem az, hogy ugyan van külön home vagy adatpartíció, de valaki a rendszermentés helyéül mégis a rendszerpartíciót adja meg és a rendszermentésbe belevesz mindent. Szóval nem csak magát a rendszert, hanem a felhasználói és adatfájlokat is. Na ha a következő rendszermentésben benne lesz ez a rendszermentés is, akkor létrejöhet elméletben egy jó nagy hurok.
De ha ilyeneket leszámítunk, tudjuk, hogy van egy jó nagy home partíció, akkor a rendszerpartíciónak igazából sokkal kisebb is elég kellene legyen.
Az én rendszerem egy picit sem óvott, napi használatban lévő, ütött-vágott rendszer, egy Linux Mint, vannak rajta Flatpak csomagok is.
A rendszerpartíción 18 GB foglalt (a 46 GB-ból).
A home partíción (a 279 GB-ból) 68 GB foglalt, úgy hogy itt van 8 GB-os swapfájl és Timeshift mentések is (persze az adatok [Dokumentumok, Letöltések, Képek] szokás szerint „kisymlinkelve” az adatpartícióra, szerintem ott azoknak a helye, de ez neked most mindegy, mert lehet minden ilyesmi a home partíciódon is.)

klt · 18 napja

tenkes Én általában nem spórolok a rendszer helyével (észszerű határok között),

Én meg spórolok, szintén ésszerű határok között.
Nyilván nem jó bájtra kicentizni, de a frissítések önmagukban nem okoznak észrevehető méretnövekedést.
Új szoftverek telepítése nyilván lehet, hogy igen, de nem mindegy, hogy egy 3MB-os Gimagereadert telepítünk, _90MB-os GIMP-et, vagy 9 GB-os Davincit.

tenkes hiszen azon történik a legtöbb lemezművelet, azon folyik a rendszer karbantartása

Ez felhasználás függő, ha valaki bebútol, aztán böngészőt indít, fészbúkozgat, akkor valóban ott történik a legtöbb olvasás. Írás jellemzően csak frissítésekkor, új program telepítésekor történik oda. Nem gondolnám ezt a legtöbbnek. Ha valaki dolgozik is a géppel, akkor szükségszerűen adatfájlokkal, dokumentumokkal, képekkel (esetleg RAW képekkel), netalántán videófájlokkal ügyködik, mindjárt 2-4 nagyságrenddel több lemezművelet adódik az adatterületekre.

csuhas32 hogy nálad mi a nyavalya foglal 96 GB-ot a rendszerpartíción?

Csak (kb.) 72GB, amit az 1TB 7%-os foglaltságából vezettem le. A 96GB-ot én javasoltam a 72 alapján, hogy maradjon egy kis terület, hogy tudjon lélegezni a rendszer, de pocsékolásnak érzem, amit @tenkes javasol.
(Nyilván bennem van, hogy már túlzottan is hozzászoktam a Debianhoz.)
Emlékeim szerint van ott Blender, Krita, meg ki tudja még mi, szép testes darabok, persze valószínűleg minden snap-ből telepítve, mert az a jó az Ubuntunak, így nekem végül is hihetőnek tűnik a kb. 72GB.

Szerk.:
A VPS-emen a TELJES terület 20GB (mondjuk, az egyben van). Na most ezzel mit lehetne kezdeni a min. 128GB-os logika alapján?

Amúgy kb. félig van.

root@reflector:~# df -h
Fájlrendszer           Méret Fogl. Szab. Fo.% Csatol. pont
udev                    463M     0  463M   0% /dev
tmpfs                    97M  648K   96M   1% /run
/dev/mapper/vg-lv_root   19G  8,3G  9,3G  48% /
tmpfs                   483M     0  483M   0% /dev/shm
tmpfs                   5,0M     0  5,0M   0% /run/lock
/dev/sda1               234M   90M  133M  41% /boot
tmpfs                    97M     0   97M   0% /run/user/0
root@reflector:~#

csuhas32 · 18 napja

klt Emlékeim szerint van ott Blender, Krita, meg ki tudja még mi, szép testes darabok, persze valószínűleg minden snap-ből telepítve

Nekem valamiért AppImage vagy valamilyen honlapról letöltött és kicsomagolt változatokról vannak emlékeim, de ezen se fogunk összeveszni. Kérek szépen @KiralyMarta -tól egy snap list kimenetet és ha megkapom, máris látjuk a jelenlegi helyzetet ezen a fronton.

KKiralyMarta · 18 napja

csuhas32
Elnézést de váratlanul kellett elmennem. elfoglalt hely:
Lemezek:

Lemezhasználat:

/usr/lib 6,7GB, /usr/share 2,4 GB, /var/lib 22 GB, /var/log 11.6 Gb

Én a foglaltságot a Lemezek alapján adtam meg, de lehet látni nagy a különbség a két adat között okát nem tudom.
A Log könyvtárban több syslog fájl van mind nagy de egy syslog.1 8,6 GB. Mindenkinek köszönöm a válaszát.

csuhas32 · 18 napja

KiralyMarta /var/lib 22 GB

És nincs kedved a Lemezhasználat-elemzőben a kis füleket lejjebb nyitogatni, hogy mégis mi a /var/lib-ben 22 GB? (Nálam ugyanez 3,9 GB)

KiralyMarta /var/log 11.6 GB
syslog.1 8,6 GB

Én biztos vagyok benne, hogy egy 8 GB-os logfájlt nem fogsz végigolvasni, talán nem is tudja a rendszered megnyitni.
Magam ezt (meg a többi) nagy méretű logfájlt sudo rm -rf -fel szanálnám.
Előtte persze rendszergazdai joggal szerkeszteném a /etc/systemd/journald.conf fájlt és beletenném a
SystemMaxUse=50M
sort, hogy az újonnan létrejövő logfájlok majd már ne hízhassanak 50 MB-nál nagyobbra. (Lehet, hogy utána kell egy rendszer újraindítás, ezt nem tudom biztosra megmondani.)
Ez persze csak tüneti kezelés, utána jöhet a létrejövő kezelhető méretű logfájlok megnyitása, annak megkeresése, hogy miért logol folyton a rendszer és a hiba elhárítása.

Ezt követően a rendszerpartíciód foglaltsága máris csak 36 GB körül lesz a cirka 1000 GB-ból.
Talán tudunk majd még lejjebb is menni, ha megismerjük, mi van a /var/lib alatt, de szerintem már ez is eléggé kis szám, csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.

Rrapfen · 18 napja

Amikor nekem kellett átméretezést csinálni és gparteddel csináltam live-ban. Picike, de jól működő program.
50 GB-nál többet nem szoktam a rendszerpartíciónak adni, eddig mindig elég volt.

klt · 18 napja

csuhas32

csuhas32 hogy mégis mi a /var/lib-ben 22 GB?

Lefogadom, hogy /var/lib/snapd/ méretes lesz (oda mennek a szappan darabok).

csuhas32 /var/log 11.6 GB

Itt én is sejtek spórolási lehetőséget. Nálam 30MB most éppen...

csuhas32 csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.

Még ezt is sokallom, de nem az én rendszerem.

rapfen 50 GB-nál többet nem szoktam a rendszerpartíciónak adni,

️
Dettó. Csak tényleg indokolt esetben!

csuhas32 · 17 napja

klt Még ezt is sokallom, de nem az én rendszerem.

Igazából ma nem is illik engedni a '48-ból, ha te rendszered lenne ragaszkodnék ehhez.
Itt nagyságrendileg 500 GB-ról kezdjük az alkudozást, ha 120-ra le tudunk menni, szerintem szép eredmény.
Majd egy következő lépésben megfelezi a 120-at és akkor is megmarad a működő rendszere plusz lesz egy tartalék rendszerpartíciója egy másik rendszer számra. :-)
(Nálam már az 50 GB körüli rendszerpartíció is olyan „sose telik be, ne kelljen már figyelni rá még egy kicsit se” szándékos túlzásnak számít, a 120 GB még akkor is elég lesz szerintem, ha Márta véletlenül néha félrenyúl.)

Llala2 · 17 napja

klt
Nálam a /var/log/journal mappa hízott folyamatosan.
Mígnem meguntam, és egy root script minden rendszer indításkor törli a tartalmat.
https://ibb.co/G4Xnn12r
Mivel, octet-stream fájlokról van szó, van mivel megnyitni/megnézni őket?
En nem ismerek ilyet.

KKiralyMarta · 17 napja

csuhas32
/var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet. Log fájlal nem tudtam mit lehet kezdeni de megcsinálom amit mondasz.

klt · 17 napja

KiralyMarta Log fájlal nem tudtam mit lehet kezdeni

sudo journalctl --vacuum-time=5m

Ezt így próbaképp...

KKiralyMarta · 17 napja

csuhas32
Mielőtt futtatnám sudo rm -rf fájlnév egyenként?n itt több log fájlból is van több darab azokat is törölhetem?

Összesen 8,3G
drwxrwxr-x  18 root              syslog          4,0K márc  15 07:11 .
drwxr-xr-x  15 root              root            4,0K febr  10 15:43 ..
-rw-r--r--   1 root              root            1,4K márc  11 14:02 alternatives.log
-rw-r--r--   1 root              root            3,8K febr  19 10:24 alternatives.log.1
-rw-r--r--   1 root              root             459 jan   29 06:55 alternatives.log.2.gz
-rw-r--r--   1 root              root             236 dec   22 09:05 alternatives.log.3.gz
-rw-r--r--   1 root              root             872 nov   30 07:14 alternatives.log.4.gz
-rw-r--r--   1 root              root             545 okt   24 06:01 alternatives.log.5.gz
-rw-r--r--   1 root              root            4,2K szept 30 08:37 alternatives.log.6.gz
-rw-r--r--   1 root              root            4,9K aug   29  2024 alternatives.log.7.gz
-rw-r-----   1 root              adm                0 márc  13 06:54 apport.log
-rw-r-----   1 root              adm              112 márc  12 16:25 apport.log.1
-rw-r-----   1 root              adm              134 márc   2 13:28 apport.log.2.gz
-rw-r-----   1 root              adm              116 márc   1 17:52 apport.log.3.gz
-rw-r-----   1 root              adm              134 febr  23 17:55 apport.log.4.gz
-rw-r-----   1 root              adm              134 febr   7 15:48 apport.log.5.gz
-rw-r-----   1 root              adm              268 febr   1 11:45 apport.log.6.gz
-rw-r-----   1 root              adm              215 jan   18 07:26 apport.log.7.gz
drwxr-xr-x   2 root              root            4,0K márc  13 07:26 apt
-rw-r-----   1 syslog            adm             150K márc  15 13:02 auth.log
-rw-r-----   1 syslog            adm             257K márc   9 07:15 auth.log.1
-rw-r-----   1 syslog            adm              11K márc   2 07:16 auth.log.2.gz
-rw-r-----   1 syslog            adm              27K febr  23 06:54 auth.log.3.gz
-rw-r-----   1 syslog            adm              27K febr  16 07:27 auth.log.4.gz
-rw-------   1 root              root            5,2K márc  15 07:11 boot.log
-rw-------   1 root              root             23K márc  15 07:11 boot.log.1
-rw-------   1 root              root             35K márc  14 07:04 boot.log.2
-rw-------   1 root              root             24K márc  13 06:54 boot.log.3
-rw-------   1 root              root             22K márc  12 07:00 boot.log.4
-rw-------   1 root              root             23K márc  11 07:04 boot.log.5
-rw-------   1 root              root             12K márc  10 07:12 boot.log.6
-rw-------   1 root              root             23K márc   9 07:15 boot.log.7
-rw-r--r--   1 root              root            106K aug    9  2022 bootstrap.log
-rw-rw----   1 root              utmp               0 márc   1 07:24 btmp
-rw-rw----   1 root              utmp               0 febr   1 07:30 btmp.1
drwxr-xr-x   2 root              root            4,0K márc  15 07:11 cups
drwxr-xr-x   2 cups-browsed      lpadmin         4,0K szept 22 19:01 cups-browsed
drwxr-xr-x   3 root              root            4,0K szept 22 19:24 dist-upgrade
-rw-r-----   1 root              adm              92K márc  15 07:11 dmesg
-rw-r-----   1 root              adm              92K márc  14 18:33 dmesg.0
-rw-r-----   1 root              adm              23K márc  14 07:04 dmesg.1.gz
-rw-r-----   1 root              adm              22K márc  13 18:56 dmesg.2.gz
-rw-r-----   1 root              adm              22K márc  13 16:04 dmesg.3.gz
-rw-r-----   1 root              adm              23K márc  13 06:54 dmesg.4.gz
-rw-r--r--   1 root              root            132K márc  13 07:26 dpkg.log
-rw-r--r--   1 root              root            350K febr  23 08:14 dpkg.log.1
-rw-r--r--   1 root              root            6,8K jan   29 06:56 dpkg.log.2.gz
-rw-r--r--   1 root              root             12K dec   28 16:08 dpkg.log.3.gz
-rw-r--r--   1 root              root             16K nov   30 07:14 dpkg.log.4.gz
-rw-r--r--   1 root              root             11K okt   31 06:46 dpkg.log.5.gz
-rw-r--r--   1 root              root            174K szept 30 08:37 dpkg.log.6.gz
-rw-r--r--   1 root              root            152K aug   31  2024 dpkg.log.7.gz
-rw-r--r--   1 root              root             32K szept 22 19:25 faillog
drwxr-xr-x   2 root              root            4,0K febr   9  2022 firebird
-rw-r--r--   1 root              root             15K márc  11 14:02 fontconfig.log
drwx--x--x   2 root              gdm             4,0K aug   21  2024 gdm3
-rw-r--r--   1 root              root            1,9K márc  15 07:11 gpu-manager.log
-rw-r--r--   1 root              root            1,9K márc  15 12:31 gpu-manager-switch.log
drwxr-xr-x   3 root              root            4,0K aug    9  2022 hp
drwxrwxr-x   2 root              root            4,0K aug   21  2024 installer
drwxr-xr-x   2 root              root            4,0K febr  10 15:43 ipp-usb
drwxr-sr-x+  3 root              systemd-journal 4,0K aug   21  2024 journal
-rw-r-----   1 syslog            adm             2,2M márc  15 13:02 kern.log
-rw-r-----   1 syslog            adm             2,9M márc   9 07:15 kern.log.1
-rw-r-----   1 syslog            adm             115K márc   2 07:16 kern.log.2.gz
-rw-r-----   1 syslog            adm             306K febr  23 06:54 kern.log.3.gz
-rw-r-----   1 syslog            adm             308K febr  16 07:27 kern.log.4.gz
-rw-rw-r--   1 root              utmp            286K szept 22 19:25 lastlog
drwxr-xr-x   2 root              root            4,0K márc  22  2022 openvpn
drwx------   2 root              root            4,0K aug    9  2022 private
lrwxrwxrwx   1 root              root              39 szept 22 18:54 README -> ../../usr/share/doc/systemd/README.logs
drwx------   2 speech-dispatcher root            4,0K júl   21  2022 speech-dispatcher
-rw-r-----   1 syslog            adm             285M márc  15 13:04 syslog
-rw-r-----   1 syslog            adm             8,0G márc   9 07:15 syslog.1
-rw-r-----   1 syslog            adm             630K márc   2 07:16 syslog.2.gz
-rw-r-----   1 syslog            adm             1,7M febr  23 06:54 syslog.3.gz
-rw-r-----   1 syslog            adm              15M febr  16 07:27 syslog.4.gz
drwxr-xr-x   2 root              root            4,0K jan    9  2024 sysstat
-rw-r--r--   1 root              root               0 szept 22 18:34 ubuntu-advantage-apt-hook.log
-rw-r--r--   1 root              root               0 szept 23 07:04 ubuntu-advantage.log
-rw-r--r--   1 root              root            2,7K szept 22 19:07 ubuntu-advantage.log.1
drwxr-x---   2 root              adm             4,0K márc   1 07:24 unattended-upgrades
drwxr-xr-x   2 root              root            4,0K szept 22 19:07 upgrade
-rw-r--r--   1 root              root             102 márc   6 07:25 vbox-setup.log
-rw-r--r--   1 root              root             102 márc   2 12:02 vbox-setup.log.1
-rw-r--r--   1 root              root             102 febr  12 18:42 vbox-setup.log.2
-rw-r--r--   1 root              root             102 jan   29 15:32 vbox-setup.log.3
-rw-r--r--   1 root              root             102 jan   28 00:17 vbox-setup.log.4
-rw-rw-r--   1 root              utmp            650K márc  15 07:12 wtmp
root@marta-ubuntu:/var/log#

klt · 17 napja

KiralyMarta A ###.szám.log és .gz simán törölheted, de szerintem nem érdemes görcsölni rajta. Alig jelent nyereséget. Neked a journal alatt lesz a sok szemét, arra meg jó a porszívózás, amit adtam.

csuhas32 · 17 napja

KiralyMarta Én itt egyetlen óriási fájlt látok, csak arra adnám ki a
sudo rm -rf /var/log/syslog.1 parancsot. A kicsikkel nem kell foglalkozni, semmi jelentőségük, nem zavarnak senkit és semmit, viszont lehet van bennük értékes információ, azokat nem bántanám.

klt · 17 napja

csuhas32 Én itt egyetlen óriási fájlt látok, csak arra adnám ki a
sudo rm -rf /var/log/syslog.1

Tényleg, ez hogy nem ütötte ki a szemem!?

Ttenkes · 17 napja

OFF
Azért érdekes, hogy a Windows van elkönyvelve egy végletekig feleslegesen növekvő rendszerré, miközben itt mindenkinek megvan a maga trükkje, hogyan szoktassa le erről a Linuxot.
Az ok amiért én más tárhely mértekben gondolkodom, nem feltétlen a Windows-Linux eltérésekből adódik, hanem mert egy ideje rászoktam arra, hogy a rendszer és a tárhely valóban külön fizikai meghajtón van. Így rendszerre a manapság elérhető legkisebb SSD méretekben gondolkodom 128/256. Mivel ezeknek csak a rendszer futtatása a feladatuk, nincs ok a méretek csökkentésére.
Egy 2TB-os tároló ilyen felosztása azért nem egy szokványos megoldás.
ON

csuhas32 · 17 napja

klt

Ezt viszont te találtad el:

KiralyMarta var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet.

Szerintem lassan megvagyunk, most már elegendő az információ, Márta el tudja dönteni mekkorára szeretné zsugorítani a rendszerpartícióját, a módja pedig már régen nem kérdés.

Ttenkes · 17 napja

A Snap és a Flatpak esetén is előfordul, hogy egy app futtatásához, egy nagyságrendileg nagyobb csomag letöltésére is szükség van (hiszen nincs benne az alaprendszerben). Miután ezt automatikusan teszi meg, okozhat meglepetést.

klt · 17 napja

tenkes OFF:
Ami a Win-t illeti, hozzám csak a problémás esetek jutnak el.
A csak hízásos WibSxS valós probléma, többször nőtte ki a tárhelyet (tényleg kicsi, 128GB-os meghajtón) és csak az újratelepítés segít olyankor, nem ismerek olyan segédprogramot, ami azt lefogyasztja (a lemezkarbantartó sem).
Ezt meg tudom különböztetni attól, amikor egy Windows.old ottmarad, és az foglalja el a helyet.
Nyilván nem mindenhol okoz gondot az említett hízás, ahogy nálad sem. Az sem kizárt, hogy valamilyen fura felhasználói szokás van a háttérben.
Ami Linux trükköket illeti: feltűnt, hogy az én gépeimen (mindenhol Debian megy, 11 vagy 12, armv7l, arm64, amd64 architektúrákon) és ilyen hízásgátló izék nem sehol sem kellenek.
Szerintem ez egy Ubuntu specifikus dolog lesz.
ON