После изменения размера раздела NTFS на внешнем GPT-диске с помощью Gparted том, похоже, больше не будет автоматически монтироваться на Ubuntu (или других дистрибутивах, таких как OSMC). Раньше он работал нормально. Он по-прежнему работает нормально в macOS и Windows 10, где я смог просмотреть его просто хорошо и использовать его в качестве цели резервного копирования.
gdisk
сообщает, что оба типа разделов - 0700 - основные данные Microsoft
. Я не знаю, что еще нужно Дискам Гнома, кроме этого. gdisk
для снятия обычной бомбы замедленного действия (а.k.a. гибридный MBR), который Gparted всегда так задумчиво надевает на любой защитный диск MBR, к которому он прикасается. После перезагрузки оказалось, что это не имеет эффекта, что разумно, так как диски никогда не использовали MBR в любом случае. mount -t ntfs -o nls = utf8, umask = 0222/dev/sdc2 ./mount-point
. В рамках операции упоминалась нечистая файловая система, и что это «Исправление»... Видимо, он сработал, так как том был доступен впоследствии, но он все равно не будет автоматизирован после перезагрузки. chkdsk/f
в Windows 10 сообщает об отсутствии ошибок. Я не уверен, почему только Ubuntu (и другие ОС на основе Linux) больше не могут идентифицировать тип раздела и автоматически монтировать том. Есть ли простой способ проверить?
Забыл ли я что-то?
-121--899019-Я работал над примером, опубликованным Эндрю Лоутером по адресу Automated 20.04 Server Installation using PXE and live server image . Например, используя linux cmdline, подобный:
linux /vmlinuz ip=dhcp url=http://${pxe_default_server}/tftp/ubuntu-20.04-live-server-amd64.iso autoinstall ds=nocloud-net\;s=http://${pxe_default_server}/tftp/
.... и получил вещи работают (Спасибо Эндрю!)
Еще один вопрос у меня после работы с этим немного. Как видно, установщик собирается загрузить ISO с http ://$ {pxe _ default _ server }/tftp/ubuntu-20.04-live-server-amd64.iso
в этом примере. В моих журналах httpd я вижу, что ISO загружается 3 раза по сети при выполнении одной автоматической установки.Есть ли способ заставить меня этого не делать?
192.168.1.225 - - [06/Apr/2021:22:09:47 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Wget"
192.168.1.225 - - [06/Apr/2021:22:13:24 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Cloud-Init/20.2-45-g5f7825e2-0ubuntu1~20.04.1"
192.68.1.225 - - [06/Apr/2021:22:16:50 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Cloud-Init/20.2-45-g5f7825e2-0ubuntu1~20.04.1"
Спасибо!
Я видел, что получил ответ на Discourse , но подумал, что поделюсь тем, что нашел.
Добавление cloud-config-url = / dev / null
к аргументам ядра не позволяет cloud-init
загружать ISO, а ISO загружается только один раз. Полная строка grub теперь
linux /vmlinuz ip=dhcp url=http://${pxe_default_server}/tftp/ubuntu-20.04-live-server-amd64.iso autoinstall ds=nocloud-net\;s=http://${pxe_default_server}/tftp/ cloud-config-url=/dev/null
При использовании PXE конфигурация автоматической установки
требует добавления параметра url =
к аргументам ядра, чтобы указать расположение ISO файл. Я считаю, что casper
обрабатывает это, и аргумент должен быть в форме url = *. Iso
cloud-init
также проанализирует url
аргумент ядра и попытка использовать его (по-видимому, дважды). Из https://github.com/canonical/cloud-init/blob/fc5d541529d9f4a076998b7b4a3c90bb4be0000d/doc/sources/kernel-cmdline.txt
, когда запускается 'cloud-init start', он проверяет, что {{1 }} посмотрите, появляется ли один из 'cloud-config-url' или 'url' в режиме "ключ-значение" в командной строке ядра ... Cloud-init затем прочитает содержимое данного URL-адреса.
Как указано в сообщении Discourse, cloud-config-url
проверяется первым , поэтому вы можете использовать кладж, чтобы избежать дополнительных загрузок.