Powolne uruchamianie - „uruchomione jest zadanie uruchamiania Dev-Disk-by…”

Nie przypominam sobie, kiedy problem zaczął się pojawiać, ale jest prawdopodobne, że przeniosłem obraz VMWare Ubuntu na zewnętrzny dysk SSD, aby móc korzystać z systemu operacyjnego na dowolnym komputerze. W Google nie ma wielu linków na ten temat, ale te, o których się mówi, mówią fstab. Na przykład powolny rozruch - co to jest „Uruchomione zadanie startowe dla Dev-Disk- By ...”? - Forum OpenSUSE .

Wzmianki o konieczności usunięcia partycji wymiany i jej ponownym utworzeniu.

Mogę spróbować to zrobić w Gparted, ale moim głównym zmartwieniem jest utrata mojego obecnego ustawienia w Ubuntu, ponieważ nie jestem całkowicie pewien, co się stanie, jeśli zepsuję się z zamianą, jak sugerowano w wątku. Czy ktoś jest w stanie pomóc?

Jeśli pojawi się „zadanie uruchamiania uruchomione przez dev-disk-by ..”, a następnie 90 sekundowe opóźnienie podczas każdego rozruchu, wykonaj następujące czynności:

1. Zainstaluj gparted za pomocą Centrum oprogramowania
2. Otwórz gparted i zobacz, jakich partycji używa obecnie Ubuntu

3. Edytuj plik fstab, korzystając z poniższego wiersza.

   sudo -H gedit /etc/fstab
   

4. Znajdź urządzenie, którego obecnie nie używasz

5. Wstaw a #i spację na początku tego wiersza, skomentuj to.

6. Zresetuj, mam nadzieję, że to zadziała!

Wygląda na to, że problem był spowodowany faktem, że chociaż fstab miał wpis do zamiany, tak naprawdę nie był. Użyłem GParted do zmiany rozmiaru partycji i utworzyłem nową zamianę. Następnie skopiowałem UUID do pliku fstab ...

1. Teraz mam zamianę
2. A rozruch spada do kilku sekund w porównaniu do ponad 90 sekund

Miałem ten sam problem po zmianie rozmiaru partycji podstawowej na mojej maszynie wirtualnej, ponieważ gparted live zmusił mnie do usunięcia i ponownej inicjalizacji wymiany. Spowodowało to ustawienie nowego UUID, który nie pasuje do pliku fstab.

Aby uniknąć problemu, /etc/fstabmożesz albo

• Zamień UUID wymiany na nowy (uruchom, sudo blkidaby go znaleźć) po zmianie rozmiaru partycji podstawowej.

• Lub skomentuj partycję wymiany przed (lub po) zmianą rozmiaru partycji podstawowej.

Poleciłbym ten pierwszy, ponieważ jest to sposób konfiguracji systemu operacyjnego.

W moim przypadku wcześniej korzystałem z szyfrowanej wymiany i wspomniano o zadaniu uruchamiania /dev/mapper/cryptswap1. Aby rozwiązać problem, musiałem również usunąć plik /etc/crypttab, oprócz kroków opisanych w odpowiedzi Williama MacDonalda.

Podczas zmiany rozmiaru lub usuwania partycji za pomocą gparted często musisz utworzyć nową partycję wymiany.

Następnie konieczne jest aktywowanie zamiany za pomocą gparted po jej utworzeniu (istnieje polecenie „Aktywuj zamianę”).

Ponadto musisz skopiować nowy UUID do / etc / fstab, aby go zamontować, w przeciwnym razie podczas rozruchu system operacyjny spróbuje go znaleźć, ale na próżno, ponieważ plik fstab zawiera UUID odnoszący się do starej zamiany. Gparted dostarcza informacje dla UUID, ale możesz łatwo uruchomić w terminalu:

sudo blkid

znaleźć to.

Miałem ten sam problem podczas uruchamiania.

W moim /etc/fstabpliku, moje partycje gdzie zdefiniowana jako /dev/sda1, /dev/sda2itp, ale podczas uruchamiania, kilka razy pojawił się komunikat „ Zadanie start działa dla dev-SDX ” ( „x” określa, które urządzenie lub partycja została dotknięta).

Aby to rozwiązać, zmieniłem wartość /dev/sdxidentyfikatora UUID partycji. Aby zobaczyć UUID, z poziomu terminalu lsblk -f. Następnie skopiuj identyfikator UUID odpowiedniej partycji i zapisz go w /etc/fstabpliku, zastępując /dev/sdaxw następujący sposób: /dev/sda1zmienia się na UUID=xxxxxxxxxxxxxxxxxx.

Działa dla mnie, mam nadzieję, że te informacje są przydatne.

Mój rozruch został spowolniony, ponieważ zamieniłem dysk, a identyfikator UUID nie pasował. To spowodowało, że Ubuntu wykonał skanowanie podczas rozruchu.

Często wymieniam dyski. Jeśli twoje wierzchowce są zawsze w tym samym miejscu (jak moje), możesz po prostu usunąć UUID i umieścić bezpośrednią ścieżkę, aby zapobiec wystąpieniu tego błędu skanowania ...

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0

Główna sytuacja:

Już odpowiedziałem szczegółowo ... (Musisz sprawdzić UUID w tych plikach)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

Alternatywna sytuacja I - Udev:

Może to być spowodowane przez udev, jeśli masz skrypt reguł,/etc/udev/rules.d/ który nie jest przeznaczony do uruchamiania w czasie rozruchu, jeśli skrypt się nie powiedzie, spowoduje to, że krok fstab będzie trwał wiecznie, po prostu edytuj skrypt, aby dopasować go do potrzeb lub usuń go.

Alternatywna sytuacja II - Crypted Dev:

Zaszyfrowane partycje mogą być mylące, ponieważ partycja główna ma UUID, a odwzorowana Odszyfrowana ma inny UUID inny niż główny dla pojedynczej partycji, należy je zdefiniować w innym miejscu etc/crypttabi/etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

Rzeczywisty UUID należy podać w etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

Wirtualny UUID musi znajdować się w /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

Alternatywna sytuacja III - Ghost Dev:

Urządzenie, które jest skonfigurowane do zamontowania podczas rozruchu, ale nie jest obecne w systemie lub odłączone jak dysk USB.

Sprawdź rzeczywiste podłączone urządzenia lsblk -o name,uuid,mountpointi edytuj, /etc/fstababy zachować tylko podłączone urządzenie LUB pozostaw tam niepodłączone urządzenie, ale skonfiguruj je tak, aby były ignorowane podczas uruchamiania z opcją noautoi ustaw linię w ten sposób

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

Sprawdzanie dzienników systemu

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

Oprócz sprawdzania /etc/fstablub /etc/crypttabjak wspomniano w innych odpowiedziach, sprawdź także UUID pochodzące z parametrów jądra w /etc/default/grub. Przez pewien czas byłem bardzo zdezorientowany przez system, który miał idealnie cromulent /etc/fstabtylko do odkrycia resume=…parametru jądra w konfiguracji GRUB.

Możesz pominąć oczekiwanie i przejść bezpośrednio do ekranu logowania, używając „ Ctrl+ c”, a następnie pracować nad rozwiązaniem. Czasami będzie to trwać wiecznie, jeśli nie.

Wiem, że to stare, ale natknąłem się na ten problem, ten sam komunikat o błędzie, podczas klonowania instalacji za pomocą rsync. nie mając błędów w fstab, problem został rozwiązany po ręcznej aktualizacji initrdfs. aby to osiągnąć,

1. uruchom komputer do działającej instalacji (maszyna z wieloma uruchomieniami, w przeciwnym razie na żywo)

2. zamontuj partycję root systemu z problemem

3. mount dev, sys i proc jak dla działającego chroota

4. chroot do katalogu głównego systemu plików

5. wykonać mkinitrd

6. wyjdź z chroota i uruchom ponownie.