Загрузчик Debian grub/проблемные суперблоки/UEFI
В настоящее время ваш скрипт написан таким образом, что он будет запускаться find, а затем запускать grepдля каждого найденного файла, для каждого ip, который он находит в ips.txt.
Вам не нужно запускать findкаждый раз, чтобы получить один и тот же список файлов, поэтому удалите его из цикла whileи назначьте его переменной. Вам также не нужно запускать grepдля каждого найденного файла, вы можете искать их все одной командой. Теперь, когда у вас есть список файлов, вы можете выполнить grepдля каждого ipи вернуть только первое совпадение. Теперь скрипт будет выглядеть примерно так:
files=$(find. -maxdepth 1 -type f -not -name ips.txt -not -name results.res)
while read ip; do
grep --with-filename --max-count=1 "$ip" $files | head -n 1 >> results.res
done < ips.txt
Это будет grepчерез каждый файл из команды findдля каждого ipв ips.txtи должно содержать строки, содержащие каждый IP-адрес,и первый файл, в котором он был найден в results.res.
РЕДАКТИРОВАТЬ:
После некоторого тестирования оказалось, что есть лучший способ, поскольку предыдущий код вообще не обрабатывает имена файлов с пробелами или нечетными символами. Поэтому я собираюсь избавиться от find, поскольку здесь он кажется ненужным.
Вы планируете grepпросматривать все файлы в текущем каталоге, кроме results.resи ips.txt, поэтому вы можете использовать grepвообще без поиска:
while read ip; do
grep --with-filename --max-count=1 --exclude={results.res,ips.txt} "$ip" * | head -n 1 >> results.res
done < ips.txt
Ваш sda6должен быть зашифрован или что-то в этом роде? Это может объяснить, почему Boot -Repair не имеет никакого смысла.
Вывод efibootmgr -vв Boot -сводка по ремонту может быть важным здесь:
efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004,0002,0003,0001
Boot0000* Windows Boot Manager HD(2,GPT,768a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...M................
Boot0001* debian VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002* UEFI : LAN : PXE IP4 Intel(R) Ethernet Connection (6) I219-V PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI : LAN : PXE IP6 Intel(R) Ethernet Connection (6) I219-V PciRoot(0x0)/Pci(0x1f,0x6)/MAC(1c697a017978,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0004* UEFI : USB : SanDisk : PART 0 : OS Bootloader PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)/HD(1,MBR,0x456c7,0x800,0x3a7f800)..BO
Отсюда вы можете видеть, что параметр загрузки UEFI с именем debianвсе еще существует, но, по-видимому, Windows отодвинула его назад в порядке загрузки и сделала себя первым элементом загрузки. Так что проблема может быть в настройках прошивки, а не в самом GRUB.
(По-видимому, по крайней мере некоторые версии Windows 10 действительно хотят иметь слот UEFI Boot0000для себя, но не будут возражать, если он не обязательно будет установлен первым в BootOrder. Но если Windows запущена и ее параметры загрузки UEFI отсутствуют, Windows определенно автоматически -восстановит себя как первую ОС в BootOrder в попытке -самовосстановления. При двойной загрузке -с UEFI было бы разумно предположить, что Windows всегда будет занимать Boot0000и соответствующим образом настроить другие ОС.)
Ваша загрузочная запись debianвыглядит немного странно. Он не относится к обычному загрузчику UEFI, как запись Windows Boot0000.Поскольку sda2, по-видимому, содержит действительный -выглядящий GRUB с именем пути, которое Debian обычно использует в системном разделе EFI, я ожидал, что обычная запись debian, совместимая с безопасной загрузкой -, будет выглядеть как:
Boot0001* debian HD(2,GPT,68a1a9a-11ae-40d1-a0d8-b52954fa5abc,0x109000,0x32000)/File(\efi\debian\shimx64.efi)
Но в вашей записи debianвместо этого VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb).
Это может означать, что ваш Debian использовал устаревший -метод загрузки, совместимый с BIOS, или, возможно, прошивка использует какой-то странный -специфический кладж поставщика.
Если вы можете вручную запустить efibootmgrс помощью Boot -Repair или любого другого Linux Live USB, возможно, вы могли бы довольно быстро исправить это с помощью:
efibootmgr -c -b 0005 -d /dev/sda2 -l \\efi\\debian\\shimx64.efi -L "Debian-UEFI"
efibootmgr -0 0005,0001,0000,0004,0002,0003
Первая команда определяет новую загрузочную запись UEFI для Debian, идентифицируя правильный диск и путь к разделу ESP (, который может совместно использоваться всеми загрузчиками UEFI, установленными в системе, в соответствии со спецификацией UEFI ). ].
Вторая команда изменит порядок загрузки, чтобы новая запись была первой, старая запись debianвторой, затем Windows в качестве третьего варианта, а затем все оставшиеся возможные варианты (, чтобы микропрограмма оставалась работоспособной. ).
Если вы не можете найти способ использовать efibootmgr, вы можете перейти к настройкам микропрограммы системы (, часто называемым «настройками BIOS», но технически это устаревший термин, поскольку UEFI не является BIOS ). ] и просто измените порядок загрузки, чтобы сначала попробовать загрузочную запись с именем debianперед Windows Boot Manager. Но это зависит от существующей странной загрузочной записи VenHwдля действительно работающего Debian... и это не совсем вселяет в меня уверенность. Но попробовать точно не помешает.