Witam wszystkich,
od kilku dni borykam się z moim laptopem Dell Inspiron 1720 (4GB Ram, Intel Centrino 2x2,5GHz, 1TB Dysk). Od 3 lat mam na nim zainstalowane OpenSuse 13.2, które dotąd działało bez większych problemów. Niestety niedawno zacząłem używać polecenia "Hibernate", aby potem wracać do stanu sprzed hibernacji (otwarte aplikacje, pliki, strony itp.).
Po hibernacji oraz ponownym starcie:
1. Pojawiło się zwykłe menu GRUB2, po timeout'cie odpalił domyślny system z poleceniem
2.Pojawił się komunikat (zaczęły też migać diody CapsLock i Scroll Lock):
3.Po 90 sek komputer się wyłączył, a nie zrestartował.
Konfiguracja jest taka :
Wycinek z rezultatu polecenia
Próbowałem już wielu rzeczy:
1. przeskanowania dysku poleceniem "btrfs balance start /" oraz "btrfs scrub start /"
efekt:działał ponad godzinę, coś tam pozmieniał, dysk jest ok (ale działał nie na partycji SWAP tylko na / )
2. włączania komputera pozycją GRUB2
efekt: komputer się uruchamia, działa, choć grafika chodzi wolniej, bo wg "settings manager>Other>Nvidia X Server Settings" nie działają sterowniki Nvidii.
3. uruchamiania komputera pozycją GRUB2
efekt: komputer się nie uruchamia, następuje "Kernel Panic"
4. włączania komputera pozycją GRUB2
efekt: komputer się URUCHAMIA całkowicie poprawnie, chodzi ze sterami NVIDII piekielnie szybko
5.użycia polecenia "# mkinitrd"
efekt 1: tworzy nowe pliki w katalogu "/boot":
efekt 2: aktualizuje bootloader : "Update Bootloader....."
Komentarz: a więc niby tworzy te pliki initrd, niby aktualizuje bootloadera, proces kończy się pomyślnie, ale to nic nie daje, po restarcie znów jest "Kernel panic"
6.ładowania innej pozycji GRUB2:
efekt: NIE MA "Kernel Panic", mimo że wpis bootujący ZAWIERA polecenie "resume=/dev/disk/...", system startuje normalnie, dopiero podczas ładowania X-ów się krzaczy(to inny problem), ale konsola działa.
7. próba znalezienia ustawień programu kompresującego "xz", na które się system uskarża, a które powodują porażkę, się nie powiodła, nie wiem gdzie tego szukać, google zwraca jakieś brednie.
Poza tym, przy ładowaniu TEGO SAMEGO kernela 3.16.7-21 bez "resume", już tego problemu nie ma.
8. próba obejrzenia zawartości partycji SWAP poleceniem:
Wnioski:
1. Na moje oko, problem jest taki, że podczas nieudanej próby hibernacji na partycji SWAP (wystarczająco dużej, bo ma 5GB, a RAM 4GB) zapisał kilka dni temu jakiś sknocony obraz RAMu, który teraz próbuje wczytać, co mu się nie udaje.
2. W obu wpisach korzysta z TEGO SAMEGO KERNELA 3.16.7-21(wersja"recovery" czyli z "noresume" ładuje, ta normalna z "resume" daje "Kernel panic"), ale znowu przy próbie ładowania kernela 3.16.7-42 z poleceniem "resume=..."odnoszącym się do tej samej partycj SWAP, nie ma "kernel panic", system startuje dalej.
3. Główna (krytyczna) różnica pomiędzy 2 pozycjami menu GRUB2 z kernelem 3.16.7-21 jest taka: we wpisie z "recovery mode" jest polecenie "noresume" a we wpisie domyślnym "resume=/dev/disk..."
4. Mogę skasować polecenie "resume" z GRUB2, ale to jest likwidacja EFEKTU a nie PRZYCZYNY problemu
5. Nie wiem, jak wyczyścić SWAP.
6. Próba wykonania ponownej hibernacji po uruchomieniu w "recovery mode" się nie udaje, bo kernel poleceniem "noresume" ma zabronione przejście w stan hibernacji.
7. Ładowanie INNEGO kernela z poleceniem resume się udaje, mimo że, jak rozumiem, obraz pamięci zapisany na dysku SWAP jest ten sam.
Pytania:
1. Co mogę jeszcze zrobić ?
2. Czy po "mkinitrd" trzeba wykonać jakieś inne polecenie?
3. Gdzie i jak mogę sprawdzić ten zrzut na dysk (efekt hibernacji), ew. go skasować albo nadpisać?
4. Gdzie jest w końcu ten kernel, który przecież się przy "noresume" ładuje, no i dlaczego krzyczy "initramfs unpacking failed"?
5. Co odpowiedzialne jest za ładowanie "initramfs", który to z kolei przekazuje sterowanie dużemu kernelowi i montuje system plików root "/"?
6.Gdzie te "initramfs" się znajduje, jak go odnowić/nadpisać/zaktualizować?
7.Gdzie znajduje się proces/plik/skrypt/cokolwiek, który nie potrafi rozpakować "initramfs"?Jak go do tego zmusić?
8. Czy są jeszcze jakieś inne podejrzenia, co się wykrzaczyło?
Skończyły mi się pomysły oraz cierpliwość, aby eksperymentować na własną rękę. Reinstalacja systemu nie wchodzi w grę,
bo mam tu dużo rzeczy na dysku, a także optymalizacje (drivery drukarki, serwery usług do sieci lokalnej, konfiguracja) zajęły mi dużo czasu, nie chcę tego powtarzać.
Poza tym jestem pewien, że mając odpowiednią wiedzę można to dość prosto opanować (system w końcu w "recovery mode" chodzi dalej, do wszystkiego mam dostęp), ale ja nie wiem jak.
Wszelkie pomysły oraz porady mile widziane.
Pozdrawiam.
od kilku dni borykam się z moim laptopem Dell Inspiron 1720 (4GB Ram, Intel Centrino 2x2,5GHz, 1TB Dysk). Od 3 lat mam na nim zainstalowane OpenSuse 13.2, które dotąd działało bez większych problemów. Niestety niedawno zacząłem używać polecenia "Hibernate", aby potem wracać do stanu sprzed hibernacji (otwarte aplikacje, pliki, strony itp.).
Po hibernacji oraz ponownym starcie:
1. Pojawiło się zwykłe menu GRUB2, po timeout'cie odpalił domyślny system z poleceniem
Cytat:"linux /boot/vmlinuz-3.16.7-21-desktop root=UUID=43287c6f-9284-4eaf-ae42-5f058aca113e ${extra_cmdline} showopts
apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe processor.ignore_ppc=1"
2.Pojawił się komunikat (zaczęły też migać diody CapsLock i Scroll Lock):
Cytat:[ 0.583392] Initramfs unpacking failed : compression method xz not configured
[ 3.241030] Kernel panic - not syncing:VFS : Unable to mount root fs on unknown block (0,0)
(...)
[ 3.242013] Kernel Offset: disabled
[ 3.242013] Rebooting in 90 seconds.....
3.Po 90 sek komputer się wyłączył, a nie zrestartował.
Konfiguracja jest taka :
fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x40f7b971
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 209713151 209711104 100G 7 HPFS/NTFS/exFAT
/dev/sda2 * 209713152 419424255 209711104 100G 83 Linux
/dev/sda3 419424256 1943039999 1523615744 726.5G 7 HPFS/NTFS/exFAT
/dev/sda4 1943040000 1953523711 10483712 5G 82 Linux swap / Solaris
Disk /dev/sdb: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 625141759 625139712 298.1G 7 HPFS/NTFS/exFAT
cat /etc/fstab
UUID=b6aa0056-3dfa-4362-87c9-d163b7f940d7 swap swap defaults 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e / btrfs defaults 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /home btrfs subvol=home 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /opt btrfs subvol=opt 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /srv btrfs subvol=srv 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /tmp btrfs subvol=tmp 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /usr/local btrfs subvol=usr/local 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/crash btrfs subvol=var/crash 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/lib/named btrfs subvol=var/lib/named 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/log btrfs subvol=var/log 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/opt btrfs subvol=var/opt 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/spool btrfs subvol=var/spool 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /var/tmp btrfs subvol=var/tmp 0 0
UUID=43287c6f-9284-4eaf-ae42-5f058aca113e /.snapshots btrfs subvol=.snapshots 0 0
(...)
Wycinek z rezultatu polecenia
cat /boot/grub2/grub.cfg
(...)
menuentry 'openSUSE, with Linux 3.16.7-21-desktop' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.7-21-desktop-advanced-43287c6f-9284-4eaf-ae42-5f058aca113e' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod btrfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' 43287c6f-9284-4eaf-ae42-5f058aca113e
else
search --no-floppy --fs-uuid --set=root 43287c6f-9284-4eaf-ae42-5f058aca113e
fi
echo 'Loading Linux 3.16.7-21-desktop ...'
linux /boot/vmlinuz-3.16.7-21-desktop root=UUID=43287c6f-9284-4eaf-ae42-5f058aca113e ${extra_cmdline} resume=/dev/disk/by-uuid/b6aa0056-3dfa-4362-87c9-d163b7f940d7 splash=silent quiet showopts nouveau.modeset=0 processor.ignore_ppc=1
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-3.16.7-21-desktop
}
menuentry 'openSUSE, with Linux 3.16.7-21-desktop (recovery mode)' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.7-21-desktop-recovery-43287c6f-9284-4eaf-ae42-5f058aca113e' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod btrfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' 43287c6f-9284-4eaf-ae42-5f058aca113e
else
search --no-floppy --fs-uuid --set=root 43287c6f-9284-4eaf-ae42-5f058aca113e
fi
echo 'Loading Linux 3.16.7-21-desktop ...'
linux /boot/vmlinuz-3.16.7-21-desktop root=UUID=43287c6f-9284-4eaf-ae42-5f058aca113e ${extra_cmdline} showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe processor.ignore_ppc=1
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-3.16.7-21-desktop
}
(...)
Próbowałem już wielu rzeczy:
1. przeskanowania dysku poleceniem "btrfs balance start /" oraz "btrfs scrub start /"
efekt:działał ponad godzinę, coś tam pozmieniał, dysk jest ok (ale działał nie na partycji SWAP tylko na / )
2. włączania komputera pozycją GRUB2
Cytat:"openSUSE, with Linux 3.16.7-21-desktop (recovery mode)"
efekt: komputer się uruchamia, działa, choć grafika chodzi wolniej, bo wg "settings manager>Other>Nvidia X Server Settings" nie działają sterowniki Nvidii.
3. uruchamiania komputera pozycją GRUB2
Cytat:"openSUSE, with Linux 3.16.7-21-desktop"
efekt: komputer się nie uruchamia, następuje "Kernel Panic"
4. włączania komputera pozycją GRUB2
Cytat:, ale po ręcznym usunięciu frazy"openSUSE, with Linux 3.16.7-21-desktop"
Cytat:"resume=/dev/disk/by-uuid/b6aa0056-3dfa-4362-87c9-d163b7f940d7"
efekt: komputer się URUCHAMIA całkowicie poprawnie, chodzi ze sterami NVIDII piekielnie szybko
5.użycia polecenia "# mkinitrd"
efekt 1: tworzy nowe pliki w katalogu "/boot":
-rw-r--r-- 1 root root 9137700 Sep 10 14:10 initrd-3.16.7-21-desktop
-rw-r--r-- 1 root root 9129412 Sep 10 14:11 initrd-3.16.7-42-desktop
-rw-r--r-- 1 root root 9129680 Sep 10 14:13 initrd-3.16.7-53-desktop
-rw-r--r-- 1 root root 9278552 Sep 10 14:18 initrd-4.7.3-21-desktopefekt 2: aktualizuje bootloader : "Update Bootloader....."
Komentarz: a więc niby tworzy te pliki initrd, niby aktualizuje bootloadera, proces kończy się pomyślnie, ale to nic nie daje, po restarcie znów jest "Kernel panic"
6.ładowania innej pozycji GRUB2:
menuentry 'openSUSE, with Linux 3.16.7-42-desktop' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.7-42-desktop-advanced-43287c6f-9284-4eaf-ae42-5f058aca113e' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod btrfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' 43287c6f-9284-4eaf-ae42-5f058aca113e
else
search --no-floppy --fs-uuid --set=root 43287c6f-9284-4eaf-ae42-5f058aca113e
fi
echo 'Loading Linux 3.16.7-42-desktop ...'
linux /boot/vmlinuz-3.16.7-42-desktop root=UUID=43287c6f-9284-4eaf-ae42-5f058aca113e ${extra_cmdline} resume=/dev/disk/by-uuid/b6aa0056-3dfa-4362-87c9-d163b7f940d7 splash=silent quiet showopts nouveau.modeset=0 processor.ignore_ppc=1
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-3.16.7-42-desktop
}
efekt: NIE MA "Kernel Panic", mimo że wpis bootujący ZAWIERA polecenie "resume=/dev/disk/...", system startuje normalnie, dopiero podczas ładowania X-ów się krzaczy(to inny problem), ale konsola działa.
7. próba znalezienia ustawień programu kompresującego "xz", na które się system uskarża, a które powodują porażkę, się nie powiodła, nie wiem gdzie tego szukać, google zwraca jakieś brednie.
Poza tym, przy ładowaniu TEGO SAMEGO kernela 3.16.7-21 bez "resume", już tego problemu nie ma.
8. próba obejrzenia zawartości partycji SWAP poleceniem:
swapon -s
Filename Type Size Used Priority
/dev/sda4 partition 5241852 888 -1
Wnioski:
1. Na moje oko, problem jest taki, że podczas nieudanej próby hibernacji na partycji SWAP (wystarczająco dużej, bo ma 5GB, a RAM 4GB) zapisał kilka dni temu jakiś sknocony obraz RAMu, który teraz próbuje wczytać, co mu się nie udaje.
2. W obu wpisach korzysta z TEGO SAMEGO KERNELA 3.16.7-21(wersja"recovery" czyli z "noresume" ładuje, ta normalna z "resume" daje "Kernel panic"), ale znowu przy próbie ładowania kernela 3.16.7-42 z poleceniem "resume=..."odnoszącym się do tej samej partycj SWAP, nie ma "kernel panic", system startuje dalej.
3. Główna (krytyczna) różnica pomiędzy 2 pozycjami menu GRUB2 z kernelem 3.16.7-21 jest taka: we wpisie z "recovery mode" jest polecenie "noresume" a we wpisie domyślnym "resume=/dev/disk..."
4. Mogę skasować polecenie "resume" z GRUB2, ale to jest likwidacja EFEKTU a nie PRZYCZYNY problemu
5. Nie wiem, jak wyczyścić SWAP.
6. Próba wykonania ponownej hibernacji po uruchomieniu w "recovery mode" się nie udaje, bo kernel poleceniem "noresume" ma zabronione przejście w stan hibernacji.
7. Ładowanie INNEGO kernela z poleceniem resume się udaje, mimo że, jak rozumiem, obraz pamięci zapisany na dysku SWAP jest ten sam.
Pytania:
1. Co mogę jeszcze zrobić ?
2. Czy po "mkinitrd" trzeba wykonać jakieś inne polecenie?
3. Gdzie i jak mogę sprawdzić ten zrzut na dysk (efekt hibernacji), ew. go skasować albo nadpisać?
4. Gdzie jest w końcu ten kernel, który przecież się przy "noresume" ładuje, no i dlaczego krzyczy "initramfs unpacking failed"?
5. Co odpowiedzialne jest za ładowanie "initramfs", który to z kolei przekazuje sterowanie dużemu kernelowi i montuje system plików root "/"?
6.Gdzie te "initramfs" się znajduje, jak go odnowić/nadpisać/zaktualizować?
7.Gdzie znajduje się proces/plik/skrypt/cokolwiek, który nie potrafi rozpakować "initramfs"?Jak go do tego zmusić?
8. Czy są jeszcze jakieś inne podejrzenia, co się wykrzaczyło?
Skończyły mi się pomysły oraz cierpliwość, aby eksperymentować na własną rękę. Reinstalacja systemu nie wchodzi w grę,
bo mam tu dużo rzeczy na dysku, a także optymalizacje (drivery drukarki, serwery usług do sieci lokalnej, konfiguracja) zajęły mi dużo czasu, nie chcę tego powtarzać.
Poza tym jestem pewien, że mając odpowiednią wiedzę można to dość prosto opanować (system w końcu w "recovery mode" chodzi dalej, do wszystkiego mam dostęp), ale ja nie wiem jak.
Wszelkie pomysły oraz porady mile widziane.
Pozdrawiam.
