Problem Z Logowaniem - Zwalnianie Miejsca Na Dysku Czy Zmiana Wielkosci Partycji Przez Gparted

[wannolot]

Witam wszystkich

 

Mam kłopot, bo nie mogę się normalnie w trybie graficznym zalogowac na Fedorze 14 do systemu na HDD, bo sciągając na komputer Fedore 16 tak zawalilem sobie partycję główną danymi (prawdopodobie paczkami ściąganymi prze yum-a), że nie startuje mi Avahi Daemon przy starcie Fedory, bo po prostu nie ma miejsca na jego pliki. Moja partycja główna ma 4,8GiB i nie ma na niej katalogów z plikami użytkowników. Przeczytałem sobie kilka rad dotyczących czyszczenia dysku stąd:

 

http://forums.fedoraforum.org/showthread.php?t=169306

 

ale niewiele mi to pomogło, bo jako niedoświadczony użytkownik mam obawy przed usuwaniem plików czy katalogów ręcznie, a yum clean z terminala nie chce mi ruszyć, bo też nie ma miejsca na pliki tymczasowe. Przeczytałem sobie taki wątek na naszym forum:

 

http://forum.fedora.pl/index.php?/topic/11840-powiekszanie/page__p__71424__hl__%2Bzwalnianie+%2Bmiejsca+%2Bna+%2Bdysku__fromsearch__1#entry71424

 

I tu mam 3 pytania:

 

1. Czy w takim układzie zmiana rozmiaru tej partycji GParted-em naLiveCD jest dobrym pomysłem, czy też ktoś poleci inny sposób na zwolnienie miejsca na na tej zapchanej partycji na tyle, żeby zaczął chodzić yum clean.

 

2. czy w takiej sytuacji update FC14 do FC16 przez preupdate (jak próbowałem to zrobić) wykorzystuje więcej miejsca na tej partycji, niż update przez cd - myślę, że nie, ale wolę przy okazji Was o to spytać.

 

3. Czy ktoś może polecić jakiś "okienkowy" manager plików działający pod MiniLinuxem, który jakoś bardziej przejrzyście niż MidnightCommander i PC-Man FM pokazuje rozmiary plików które przeznaczam do usunięcia? Z tego, co widzę po rozmiarach katalogów w tych managerach plików, to każdy z - powiedzmy - 60 głównych katalogów w tym systemie plików ma średnio po kilkanaście kB, więc jakim cudem zapełniają cały dysk 4.8GiB? W takiej sytuacji człowiek jest trochę wygłupiony, no bo co tu pousuwać, żeby zwolnić kilkaset mega w sysemie plików.

 

dzięki z góry za pomoc

 

Wannolot

[@jszubiak]

Hej,

 

Zanim się weźmiesz za gparted wklej proszę wynik poleceń 'df -Ph' i 'vgs'

 

Pozdr.

J.Sz

[@WalDo]

Z tego, co widzę po rozmiarach katalogów w tych managerach plików, to każdy z - powiedzmy - 60 głównych katalogów w tym systemie plików ma średnio po kilkanaście kB, więc jakim cudem zapełniają cały dysk 4.8GiB?

Na początek pytanie: mówimy o jakimś MiniLinuksie czy o Fedorze?

 

Co do wielkości katalogów w MC - czy patrzysz na pliki w katalogu czy na sam katalog? W trybie tekstowym nic chyba lepszego od MC nie znajdziesz. Szczegółową wielkość poszczególnych plików i katalogów pokazuje polecenie "du" z odpowiednimi opcjami ("man du" wyjaśni wszystko).

[wannolot]

Na wstępie dzięki serdeczne za Waszą uwagę i Wasze rady

 

Zanim się weźmiesz za gparted wklej proszę wynik poleceń 'df -Ph' i 'vgs'

 

ok - spróbuję, tylko zaznaczam, że nie wiem, czy dam radę wydać takie polecenie nawet z konsoli, bo Fedora startuje półżywa i czasami nawet nie mogę się w konsoli zalogować. Czy wydanie takich poleceń z minilinuxa (uruchamianego ratunkowo, na tym samym komputerze, ale z LiveCD) ma jakiś sens? Oczywiście zaznaczę, z czego wydałem te polecenia

 

Na początek pytanie: mówimy o jakimś MiniLinuksie czy o Fedorze?

 

Co do wielkości katalogów w MC - czy patrzysz na pliki w katalogu czy na sam katalog? W trybie tekstowym nic chyba lepszego od MC nie znajdziesz. Szczegółową wielkość poszczególnych plików i katalogów pokazuje polecenie "du" z odpowiednimi opcjami ("man du" wyjaśni wszystko).

 

Mówimy o Fedorze, WalDo. Ściślej o Fedorze 14. Minilinuxa odpaliłem z LiveCD tylko ratunkowo, żeby zajrzeć do dysku twardego, na któym jest Fedora. Zamontowałem - jeśli dobrze pamiętam - dev/sda3, czyli partycję główną Fedory i stąd wiem, że podczas próby startu Fedory Avahi Daemon pisze - jeśli dobrze pamiętam - w var/messages - że nie ma miejsca na dysku.

 

Jak chodzi o MidnightCommandera, to patrzę na rozmiar katalogów - z poziomu katalogu wyższego stopnia. Z tego, co piszesz wynika, że będę musiał wydać polecenie:

 

Code:

find . -type f -exec ls -l '{}' \; | awk '{print $5, $NF}' | sort -n | tail -10

, które podaje jeden z uczestników wątku, który znalazłem na temat czyszczenia dysku, żeby znaleźć największe pliki w systemie. Oczywiście podam, co znalazłem i spytam Was, czy mogę to usunąć.

Teraz nie mam dostępu do tego komputera, na którym cały ten problem się dzieje, więc będę kontynuował i podawał logi dopiero jak się do niego dostanę - mam nadzieję, że to będzie dzisiaj wieczorem.

Póki co dzięki za dotychczasowe wsparcie - ciąg dalszy nastąpi.

 

Wannolot

[@WalDo]

Mówimy o Fedorze, WalDo. Ściślej o Fedorze 14. Minilinuxa odpaliłem z LiveCD tylko ratunkowo

Nie wiem skąd wytrzasnąłeś nazwę "minilinux" To jest pełnowartościowa, stuprocentowa Fedora. Po wykonaniu chroot w trybie ratunkowym znajdujesz się w dokładnie takim samym środowisku jak po uruchomieniu Fedory w trybie tekstowym. Po uruchomieniu Fedory z LiveCD znajdujesz się w dokładnie takim samym środowisku Fedory jak po zainstalowaniu systemu z tegoż LiveCD na hdd.

 

Co do miejsca. Zależy jak szczegółowe chcesz mieć informacje ale

du -k /

poda Ci w kB ilość danych w katalogach od roota. Możesz "uszczegółowić" to do np. /var (tam na pewno jest sporo jeśli masz włączony syslog), podobnie /usr. Możesz ograniczyć się również do statystyk globalnych dodając parametr "-s". Możesz posortować wyjście "du" malejąco wg 1. kolumny co pokaże które katalogi zajmują najwięcej miejsca.

"Zakręcony" find wygląda bardzo pro (), ale wcale nie jest potrzebny, dopóki nie określisz katalogu który zajmuje najwięcej miejsca.

Wspomniany wyżej find znajdzie wyłącznie największe pliki w bieżącym katalogu. Można zmodyfikować podając zamiast "." katalog główny "/", ale znalezienie 10 największych plików może nie załatwić sprawy. Pamiętaj, że 1000 plików po 100kB każdy ma większą objętość niż 1 plik 10MB

 

jeśli dobrze pamiętam - w var/messages - że nie ma miejsca na dysku.

Problem prawdopodobnie leży w tym, że 4,8GB to trochę mało na system i logi. Zacznij od sprawdzenia /var/log - tam prawdopodobnie będziesz miał wcześniejsze pliki messages* (zachowane przez "logrotate"). Prawdopodobnie nei korzystasz z nich i możesz spokojnie usunąć wszystkie messages* z wyjątkiem aktualnego messages (bez żadnych przyrostków po tej nazwie)

[wannolot]

Nie wiem skąd wytrzasnąłeś nazwę "minilinux" To jest pełnowartościowa, stuprocentowa Fedora.

Odpalałem kompa nie z instalacyjnej LiveCD Fedory, tylko z Hiren's Boot CD - takiego zaopatrzonego w Bootloader zestawu narzędzi ratunkowych do padniętych komputerów. Tam właśnie - obok GParted-a znalazłem właśnie owego MiniLinuxa

 

Co do miejsca. Zależy jak szczegółowe chcesz mieć informacje ale

du -k /

poda Ci w kB ilość danych w katalogach od roota. Możesz "uszczegółowić" to do np. /var (tam na pewno jest sporo jeśli masz włączony syslog), podobnie /usr. Możesz ograniczyć się również do statystyk globalnych dodając parametr "-s". Możesz posortować wyjście "du" malejąco wg 1. kolumny co pokaże które katalogi zajmują najwięcej miejsca.

"Zakręcony" find wygląda bardzo pro (), ale wcale nie jest potrzebny, dopóki nie określisz katalogu który zajmuje najwięcej miejsca.

w katalogu var polecenie

du -k -h |sort -h 

dało długą listę plików i katalogów, której końcówka wygląda następująco:

 

52M	./cache/yum/preupgrade-main
53M	./cache/yum/preupgrade-updates
55M	./cache/beagle/indexes
56M	./cache/beagle
64M	./cache/yum/i386/14/adobe-linux-i386/packages
65M	./cache/yum/i386/14/adobe-linux-i386
75M	./lib/rpm
97M	./lib
142M	./cache/yum/i386/14/fedora
159M	./cache/yum/preupgrade-fedora
419M	./cache/yum/i386/14/updates/packages
539M	./cache/yum/i386/14/updates
769M	./cache/yum/i386
769M	./cache/yum/i386/14
1,1G	./cache
1,1G	./cache/yum
1,2G	.

 

natomiast największe pliki powyżej 10MB to:

./lib/rpm/Filedigests
./lib/rpm/Packages
./cache/beagle/indexes/manpages/PrimaryIndex/_48.cfs
./cache/beagle/indexes/documentation/PrimaryIndex/_13s.cfs
./cache/yum/preupgrade-main/1385b0f5805ae7a3715855c1236a8cdf4d9ca7e811ab817fe4b75799a878cf18-primary.sqlite
./cache/yum/i386/14/adobe-linux-i386/packages/AdbeRdr9.4.6-1_i486linux_enu.rpm
./cache/yum/i386/14/updates/packages/perl-5.12.4-148.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/kernel-2.6.35.14-106.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/xulrunner-1.9.2.24-1.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/openoffice.org-core-3.3.0-20.8.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/java-1.6.0-openjdk-1.6.0.0-55.1.9.10.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/thunderbird-3.1.16-1.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/openoffice.org-langpack-pl_PL-3.3.0-20.8.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/qt-x11-4.7.4-7.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/mono-core-2.6.7-4.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/firefox-3.6.24-1.fc14.i686.rpm
./cache/yum/i386/14/updates/packages/wxPython-2.8.12.0-1.fc14.i686.rpm
./cache/yum/i386/14/updates/27a0239b17bd22e1e5f7bcb009f69ee971a3f0520a836c9eae4827a40ed950e2-filelists.sqlite
./cache/yum/i386/14/updates/6b0a33a650fb35d25ad93ab0eb85939145bf9fb89d7147892f747ecceaf41114-primary.sqlite
./cache/yum/i386/14/updates/97e5dcf902d2dc2f6fb6d4067f6eec21808df451e49862d69b26b10c13b07bee-other.sqlite
./cache/yum/i386/14/fedora/72f870f3e28571eda6bed2c260d245a970fcc74786c5445e847a40890e1c471f-primary.sqlite
./cache/yum/i386/14/fedora/8b539c4008ba73254221717f04f3a6d6079962965ffe730a51861a3c53633320-filelists.sqlite
./cache/yum/preupgrade-updates/5bffeea2c561a2de5c5734205e2075a033438348e4c2b322dd1fcbd19f8e95f6-primary.sqlite
./cache/yum/preupgrade-updates/62babbd6a63df9dd2e1b27a162071413ecddb692e7a34e75adfc87166d5f127a-filelists.sqlite
./cache/yum/preupgrade-fedora/10f93f3e49d0a2abe524cec15eda8d89ee3023732be641e011eed92c236ee39e-filelists.sqlite
./cache/yum/preupgrade-fedora/1385b0f5805ae7a3715855c1236a8cdf4d9ca7e811ab817fe4b75799a878cf18-primary.sqlite

 

czy coś z tego można wywalić (oczywiście biorąc pod uwagę fakt, że restartowałwm kompa po komunikacie yum-a, czy też innego programu ściągającego nową fedorę, że należy zwolnić około 1GB pamięci.

 

podobnie w katalogu usr końcówka listy obiektów najbardziej zajmujących przestrzeń wyglądała tak (jak chodzi o zużycie miejsca):

51M	./lib/thunderbird-3.1
59M	./share/doc/flumotion-0.6.1/html
61M	./share/doc/flumotion-0.6.1
61M	./share/fonts
67M	./lib/openoffice.org/basis3.3/share
74M	./share/icons/gnome
77M	./lib/mono/gac
84M	./lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib
85M	./lib/jvm
85M	./lib/jvm/java-1.6.0-openjdk-1.6.0.0
85M	./lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre
95M	./lib/locale
105M	./lib/mono
115M	./share/icons
118M	./share/gnome
118M	./share/gnome/help
140M	./bin
153M	./lib/python2.7/site-packages
178M	./lib/python2.7
192M	./share/doc
193M	./lib/openoffice.org/basis3.3/program
304M	./lib/openoffice.org/basis3.3
329M	./lib/openoffice.org
468M	./share/locale
1,5G	./lib
1,5G	./share
3,2G	.

 

polecenie vgs zgłosiło, że

no volume groups found

 

natomiast wynik drugiego polecenia, które zaproponował jszubiak:

#: df -Ph
System plikĂłw         rozm. uĹĽyte dost. %uĹĽ. zamont. na
/dev/sda3             4,9G  4,8G     0 100% /
tmpfs                 1,5G  144K  1,5G   1% /dev/shm
/dev/sda1             291M  179M  112M  62% /boot
/dev/sda5              28G   16G   12G  57% /home

 

tam prawdopodobnie będziesz miał wcześniejsze pliki messages* (zachowane przez "logrotate"). Prawdopodobnie nei korzystasz z nich i możesz spokojnie usunąć wszystkie messages* z wyjątkiem aktualnego messages (bez żadnych przyrostków po tej nazwie)

niestety wszystkie razem miały tylko około 1MB

 

pytanie więc, czy ma sens, żebym coś pousuwał z /var lub /usr, czy też od razu spróbować GParted-em partycję główną powiększać, jeśli tak, to czy przy linuksie obowiązują dla linuxa jakieś specjalne środki ostrożności przy GPartedzie.

I kolejne pytania, czy instalator FC16 skończy swoją działalność i czy zachowa ustawienia z FC14

 

pozdrawiam i dzięki za dotychczasowy support.

Wannolot

[@WalDo]

Po kolei:

w katalogu var polecenie

du -k -h |sort -h 

Opcje -k (kilobajty) i -h (czytelne dla czlowieka? human readable) sa wzajemnie sprzeczne Ale to na marginesie

 

52M	./cache/yum/preupgrade-main
53M	./cache/yum/preupgrade-updates
55M	./cache/beagle/indexes
[...]

Cache yuma mozesz wyczyscic (yum clean all), ale przy pierwszej aktualizacji sytuacja powróci. /lib to nawet nie próbuj ruszyc recznie, chyba ze lubisz reinstalacje.

 

 

podobnie w katalogu usr koncówka listy obiektów najbardziej zajmujacych przestrzen wygladala tak (jak chodzi o zuzycie miejsca):

51M	./lib/thunderbird-3.1
[...]

Tego typu rzeczy pozbywasz sie odinstalowujac pakiet (np.yum remove thunderbird)

 

 

natomiast wynik drugiego polecenia, które zaproponowal jszubiak:

#: df -Ph
System plikĂlw         rozm. uĹĽyte dost. %uĹĽ. zamont. na
/dev/sda3             4,9G  4,8G     0 100% /
tmpfs                 1,5G  144K  1,5G   1% /dev/shm
/dev/sda1             291M  179M  112M  62% /boot
/dev/sda5              28G   16G   12G  57% /home

Brak miejsca na / (root dir) i sporo na /home. Dwie opcje:

1.backup systemu, gparted zmniejszasz /home dodajac jakies 4-6GB na /

2.opcja mniej sluszna, ale prostsza i w tym wypadku byc moze bardziej elastyczna.

jako root:

#utworzenie katalogu
mkdir -p /home/usr/share 
#kopia zawartosci /usr/share z zachowaniem uprawnien (-p), rekursywnie z zachowaniem dowiazan, FIFO itp (-R)
cp -pR /usr/share* /home/usr/share/* 
#usuniecie WSZYSTKIEGO co w katalogu /usr/share i samego katalogu /usr/share
rm -rf /usr/share 
#utworzenie dowiazania symbolicznego do /usr/share na partycji /home
ln -s /home/usr/share /usr/share 

Powinno zadzialac, chociaz przed operacja warto wykonac solidny backup calego systemu. Taka operacja powinna zwolnic ok.1,5GB na / kosztem miejsca na /home

 

Ogólnie to troche malo miejsca na ten system masz → podzial dysku

Edytowane Styczeń 29, 2012 przez WalDo
poprawka odnośnika do wiki

[@jszubiak]

Hej,

 

WalDo ma dobry promysł, ja zapropnuję troszkę inny o wiele bardziej ryzykowny ale taki który pozwoli Twojej fedorce żyć o wiele dłużej bo z 5-cioma G na / bez osobnych /usr/, /var/, /tmp/ to daleko nie zajedziesz:

 

0. dd if=/dev/sda of=plik.mbr bs=512 count=1 + przegaj plik w bezpieczne miejsce. Jeśli masz gdzie to zrób backup ważnych rzeczy.

1. boot do rescue mode z płty F14 lub jakiegokolwiek bootcd + odmontowanie wszystkich /dev/sda*

2. resize2fs /dev/sda5 18G (przykładowo, możesz dać 20,22,byle by mniej niż aktualnie)

resize2fs pokaże Ci w 4k blokach ile wynosi aktualnie wielkość FS po shrinkowaniu - Zapisz tą wartość i oblicz sobie (_odrazu_ → od razu) ORT ile to jest w kB)

3. fdisk /dev/sda + usunięcie i założenie na nowo partycji 5 ale o wielkości odpwiadającej nowej wielkości FS, przy zakładaniu podaj last cylinder = +Ile_wyszło_z_obliczen_wyżejK ( albo poprostu jak dałeś np: 18GB to zapodaj wartość z obliczenia 18*1024*1024 ), nie zapomnij ok K na końcu.

4. załóż nową partycję nr. 6( najlepiej dociągnij ją końca )

5. mkfs.ext3 /dev/sda6

6. mkdir usr2 && mount /dev/sda6 usr2

7. mkdir temp && mount /dev/sda3 temp

8. cp -a temp/usr/* usr2/.

9. vi temp/etc/fstab + dopisanie: "/dev/sda6 /usr ext3 defaults 1 2"

10. umout usr2 && umount temp

11. fsck /dev/sda5, jeśli fsck nie pokaże Ci błędów to znaczy że nie walnąłeś się przy obliczenich wyżej i możesz kontynuować.

możesz ocjonalnie usunąć zawartość starego /usr/ wtedy robisz ( mount /dev/sda3 temp && rm -rf temp/usr/* )

12. reboot

 

P.S

 

Szkoda że nie robisz lvoli:-(

 

Pozdr.

J.Sz

[wannolot]

Dziękuję Wam jeszcze raz za cenną pomoc - ostatecznie jeszcze przed ostatnim postem J.Sz. zwiększyłem moją partycję główną o 4 GiB, a system wstał, tak, że mogłem wejść w Gnome. Pozostaje tylko bardzo ważne dla mnie pytanie, czy Anaconda na spółę z Preupgrade'em są na tyle "inteligentne", żeby zachować ustawienia Fedory związane z układem klawiatury i trybem pracy kamery do skype'a - pytanie dla mnie bardzo ważne, bo jak rok temu instalowałem F14, to zanim się dogooglałem, czemu mi to czy tamto nie chodzi, to minęły 4 dni, a nie honor mi było zawracać tym głowę komuś na forum. W zasadzie chcę zainstalować nową F16 tylko dlatego, że pod F14 nie chodzi mi sterownik drukarki, którą mogę tanio kupić, a ma dupleks, na którym mi zależy - pisałem o tym w wątku:

 

http://forum.fedora.pl/index.php?/topic/25040-drukarka-canon-pixma-mp252-cnijfilter-nie-widzi/page__view__findpost__p__156390__hl__%2Bwannolot+%2Bnie+%2Bwidzi__fromsearch__1

 

Jeśli miałbym po zainstalowaniu F16 ustawiać wszystko znów kilka dni, to zostanę sobie przy F14 i kupię inną drukarkę.

 

pozdr

Wannolot