Nowe posty Problem z kartą sieciową (3) 2023-05-30, 14:20:32
Długo czekam na uruchamianie się programów w Arch'u (3) 2023-05-21, 17:06:09
Ten sam profil Firefox dla Arch i Windows. Da się to zrobić? (3) 2023-05-19, 22:02:18
Jak uruchomić automatycznie Xfce4 przy uruchamianiu Arch? (1) 2023-05-17, 23:01:47
Instalacja Mint Cinnamon (4) 2023-05-17, 16:27:17
Arch długo czeka na myszkę, pad działa ale myszka nie (0) 2023-05-17, 13:11:03
[ROZWIĄZANY] Jak zamontować dysk rozpoznany jako PTTYPE=PMBR? (5) 2023-05-17, 07:22:30
programista php - zdalnie B2B (1) 2023-05-16, 02:51:11
Instalacja - pytania (7) 2023-05-14, 17:24:22
[Rozwiązany] Problem z XFce w Debian 11 (4) 2023-05-12, 20:02:19
|
Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.
Wiadomości - badpixel
Strony: [1]
1
« dnia: 2022-01-06, 05:32:29 »
tmpfs bedzie najłatwiejszym, najszybszym i najpewniejszym rozwiązaniem (wystarczy dodać jedną linijkę do /etc/fstab) o ile pliki nie są na tyle wielkie, by zapchac wikększą część RAMu.
SystemD domyslnie montuje tmpfs jako /home/guest we współczesnych dystrybucjach, tak więc powinno być OK.
2
« dnia: 2022-01-06, 05:25:25 »
Najlepiej wyciąć wszystko(włącznie z głownym katalogiem), to wtedy nie będzie się gdzie miało cholerstwo zamontować (włacznie z systemem ;-)
Alternatywnym rozwiązaniem jest korzystanie ze statycznego /dev i wywalenie zbednych wpisów (a na koniec samego mknoda ;-)
3
« dnia: 2018-12-14, 18:26:52 »
http://www.ultimatebootcd.com/http://www.system-rescue-cd.org/Polecam powyższe gdyż istnieja od lat i posiadają wszelkie potrzebne oprogramowanie do testowania sprzętu, partycjonowania, backupów, itd. Jeżeli chodzi o stress-test procesora, to cpuburn. Bardzo przydatne narzedzie przy podkręcaniu procka lub undervoltingu. Jeżeli by miał dysk twardy/SSD, to poleciłbym smartctl (lub doowlny inny program do sprawdzenia wartości S.M.A.R.T.a. Przydatny też jest mhdd lub badblocks. Co do RAMu, to polecam memtest/memtest+ - odpala się go z poziomu bootloadera, więc sprawdzi wiecej pamięci niż program odpalony z poziomu innego OSu. Jeżeli chodzi o zasilacz(który jest najczęstszą przyczyną BSOD po RAMie, sofcie i badblockach), to sprawdź którąś z "czarnych listy zasilaczy": https://www.elektroda.pl/rtvforum/topic1199271.htmlPoza tym jeżeli chodzi o płytę główną i zasilacz, to należy się przyglądnąc elektrolitom, czy nie są wybrzuszone: https://www.elektroda.pl/rtvforum/topic316154.html
4
« dnia: 2018-08-16, 23:50:25 »
Mam tylko dostęp do tego komputera bez uprawnień administratora na którym program działa i do jego wszystkich plików, do administratora się nie dostanę, gdyż bootowanie jest zablokowane a nie chce się bawić w bardziej skomplikowane przejmowanie hasła administratora. Nawet nazwy programu niepodałeś (a na pewno jakaś jest) Poza tym bootowanie nie może byc zablokowane, skoro system startuje (zapewne chodzi o dynamiczną edycję konfiguracji gruba z jego poziomu). Ale jeżeli odpalenie rescue z pendrivea/płyty, złożenie macierzy(lvm, mdadm), podmontowanie systemów plików (mount)i wywołanie 'passwd' ze chroota Cię przerasta, to lepiej odpuść i zleć to zadanie komuś, kto ma jakieś podstawowe pojęcie o systemie linux. To co cię czeka dalej, będzie o wiele bardziej skomplikowane niż zmiana hasła administratora na niezaszyfrowanym dysku. Jakby Ci się jednak chciało, to polecam nauczyć się następujących komend: strace, cp -av, passwd, chmod, chown, ldd(widać których bibliotek brakuje), su -l (podstawa jak chce się coś debugować, co startuje z innego konta), strukturę pliku /etc/passwd .bashrc oraz .bash_profile (o ile w /etc/passwd jest bash jako shell). Poza tym trzeba wiedzieć jak przekierowywać standardowe wyjście+błędu do pliku, przydatny też będzie znajomość grepa. O ile nie ma jakiś bardziej wymyślnych zabezpieczeń przed kopiowaniem, to w strace powinno wszystko wyjść i robota niepowinna zająć więcej niż godzinę, jak się wie co robi. Jak jesteś programistą, to powinieneś to opanować te polecenia maks w ciągu paru godzin. A jak nie, to ześ ciapa albo leń i lepiej komuś zapłacić.
5
« dnia: 2011-06-24, 12:38:26 »
Od kolejności wykrycia, w dużej mierze BIOSa. generalnie libata, bym nawet rzekł że losowo, gdyż nie ma już ustalonych primary/secondary master/slave jak to bylło w przypadku dawnych sterowników opartych o IDE(a nie libata) dla dysków PATA(IDE). Jezeli chcesz miec montowanie w /etc/fstab i GRUBie niezależnie od /dev/sdX, to używaj UUID, lub ewnetualnie LABELi(większa szansa kolizji nazw).
A co do rebootu, to troche dziwne. Skoro postawiles gentoo, to zakladam że umiesz korzystać z rescuecd. Na poczatek przelec fsck -f /dev/sdXX. Potem podmontuj system plików z gentoo(mkdir /dest; mount /dev/sdaXX /dest), podbinduj /dev ze chroota(mount -obind /dev /dest/dev), chrootuj sie(chroot /dest), no i na koniec wywołaj 'mount -a'). Jeżeli podmontowało się wszystko bez problemu, to przejdź dalej, jeżeli coś nie tak, to popraw /etc/fstab w chroocie, warto także sprawdzic czy /etc/mtab nie jest popsuty(jezeli problem przy starcie jest zwiazany z niemozliwoscia przemontowania z ro do rw). A teraz wywołaj 'telinit 3' czy tudzież 'init 3' ze chroota. Powinien wstać system ze chroota(twoje gentoo) na jajku z rescuecd. Jeżeli wstanie, to bym zaczął od initrd/initramfs czy ewentualnie przeinstalowania jajka.
A jeżeli powyższe instrukcje nie pomogą, to bym sprawdził czy wszystkie urzadzenia są dopięte po zamianie dysków(szczególnie karta graficzna, jeżeli to podczas startu demonów[ładowanie radeon/i9xx z KMS?]), wyłączył wszelkie demony z readahead, itd, komunikujące się z dyskiem bezpośrednio({h,s}dparm, smartdaemon, itd. No i oczywiście sprawdził czy sprzęt jest sprawny, memtest86+(RAM), na tomiast dysk twardy przeleciał badblocks(troche to trwa, ale możliwe ze dysk ma bady, szczególnie w przypadku tanich atrap zasilaczy typu LC/Codegen/Modecom z serii FEEL/Deer), no i oczywiście odpalil jakieś livecd, bo może coś się źle skopiowało po prostu.
6
« dnia: 2008-05-02, 03:28:01 »
Pamietam jak 10 lat temu wchodzil dopiero co natywny interfejs ATAPI w jakims 2.4, ale wiekszosc programow byla przystosowana do scsi i slabo sobie z tym radzila, wiec emulacja byla polecana. Obecnie ten podsystem ATAPI(razem z podsystemem IDE) jest porzucany na rzez libata, i znow sa problemy. Ja na szczescie nie mam nowego kompa, i wiem ze nawet w 2.6.24 byly problemy z czytaniem niektorych plyt DVD przez libata, zgrywaniem cd-audio(niestety wiekszosc coftu opiera sie o przestarzala cdparanoie), a co najgorsze wypalaniem plytek. micu: glupoty gadasz, 2.6.18 to w miare swieze jajko, w ktorym bodajze nastapila migracja z natywnego sterownika ATAPI/IDE na libata, a to do czego dales linka to chodzilo o jajka 2.4, gdzie natepowala migracja z emulacji scsi na podsystem ATAPI.
Strony: [1]
|