Различный опыт загрузки после клонирования SSD
, который я использую для Ubuntu, установленного на SSD 64 ГБ ... но затем нужно больше емкости.
Итак, я клонировал SSD в одну мощность 128 ГБ с использованием приложения «дисков» на Ubuntu (который приходит предварительно установленным при использовании живого загрузки Ubuntu (от USB в моем случае))
Теперь, когда я загружаюсь, Я получаю экран, который я не получил раньше и должен ждать еще несколько минут, чем обычно. Экран, который я получаю:
Если я нажимаю кнопку «del» (удалить), она показывает некоторые детали о том, что он делает:
Я не знаю, что это значит, и было бы полезно, это кто-то может объяснить это поведение и как это исправить.
(после ожидания еще несколько минут компьютер загружается как обычно, и работает, как ожидалось. SSD успешно клонен)
Обновление 1:
My / etc / fstab Как:
~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=6b1b7475-bcd1-426b-b60d-5488f952ef1a / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=bcd1-426b /boot/efi vfat umask=0077 0 1
/swapfile
Вывод команды sudo lsblk -o uuid, name, fstype, размер, mountpoint, метка, модель :
~$ sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
[sudo] password for user:
UUID NAME FSTYPE SIZE MOUNTPOINT LABEL MODEL
loop0 squashfs 143.8M /snap/code/52
loop2 squashfs 15.3M /snap/deno/15
loop3 squashfs 55.4M /snap/core18/1944
loop4 squashfs 217.9M /snap/gnome-3-34-1804/60
loop5 squashfs 219M /snap/gnome-3-34-1804/66
loop6 squashfs 163.3M /snap/gitkraken/167
loop7 squashfs 149.8M /snap/code/53
loop8 squashfs 161.1M /snap/gitkraken/168
loop9 squashfs 125.9M /snap/docker/471
loop10 squashfs 97.9M /snap/core/10577
loop11 squashfs 64.4M /snap/gtk-common-themes/1513
loop12 squashfs 95.8M /snap/rpi-imager/137
loop13 squashfs 95.8M /snap/rpi-imager/150
loop14 squashfs 31.1M /snap/snapd/10707
loop15 squashfs 97.9M /snap/core/10583
loop16 squashfs 64.8M /snap/gtk-common-themes/1514
loop17 squashfs 51M /snap/snap-store/518
loop18 squashfs 51M /snap/snap-store/498
loop19 squashfs 31.1M /snap/snapd/10492
loop20 55.5M /snap/core18/1988
sda 223.6G CT240BX500SSD1
174D-C0A1 ├─sda1 vfat 512M
├─sda2 1K
6b1b7475-bcd1-426b-b60d-5488f952ef1a └─sda5 ext4 223.1G /
sdb 465.8G WDC_WDS500G2B0A-00SM50
C0FB-211B ├─sdb1 vfat 100M
├─sdb2 16M
C27AFBDE7AFBCD63 ├─sdb3 ntfs 465.2G
1A20494E20493255 └─sdb4 ntfs 505M
Я вижу, что нет матча для BCD1 -426B .
2 ответа
Выяснили из этого ответа , что smtp-соединения не отфильтрованы hosts.deny, поскольку Postfix не ссылается на библиотеку tcp-оберток.
-121--910628-Ядро 5.11 все еще находится на этапе RC (кандидат на освобождение), поэтому Nvidia еще не должна его поддерживать.
Идите с 5.10.x, там все работает нормально. Для двойного монитора может потребоваться переключение первичного графического процессора.
-121--911848-Моя дикая догадка заключается в том, что он может пытаться смонтировать дополнительный диск или раздел, которого нет, и ожидает тайм-аута.
Просмотрите файл /etc/fstab и попробуйте обнаружить предметы, которые, по вашему мнению, недействительны. В случае сомнений, не стесняйтесь изменить свой вопрос.
Обновление:
Я почти уверен, что уникальные идентификаторы дисков или разделов отличаются от используемых вашей клонированной системой.
Следующая команда покажет текущие UUID дисков и разделов:
sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
Возможно, потребуется обновить проблемную запись в /etc/fstab с помощью текущего UUID.
Является ли взорванным способом, но у меня была потрясающая проблема. Я бегаю Ubuntu LiveCD, а затем Grub-Repair. Я следовал инструкциям здесь: https://www.howtogeek.com/114884/how-to-repair-grub2-when-ubuntu-wont-boot/