Нет загрузочного сектора на USB-устройстве
Нет, такой темы значков нет.
Is there an icon pack that don't override the default icons of certain applications?
Для файлового менеджера значок по умолчанию — system-file-managerсогласно Спецификации именования значков . Для любой среды рабочего стола по умолчанию устанавливается только один файловый менеджер, который будет использовать один и тот же значок.
Like in this picture, almost all those file manager have the same icons.
На показанном рисунке PCManFM использует значок по умолчанию , который находится по адресу /usr/share/icons/THEME. Значок по умолчанию выглядит одинаково независимо от темы значка в соответствии со спецификацией. Некоторые темы значков, такие как elementary Xfce, предоставляют значок pcmanfm, но в любом случае это символическая ссылка на тот же значок.
$ cat /usr/share/applications/pcmanfm.desktop | grep Icon
Icon=system-file-manager
$ ls -l /usr/share/icons/elementary-xfce/apps/48/pcmanfm.png
lrwxrwxrwx 1 root root 23 Nov 6 2015 /usr/share/icons/elementary-xfce/apps/48/pcmanfm.png -> system-file-manager.png
В отличие от этого, Thunar использует резервную иконку , которая находится в /usr/share/icons/hicolorвместо /usr/share/icons/THEME. Это произойдет всякий раз, когда в установленной теме значков нет необходимого значка для определенного приложения, в данном случае Thunar.
$ cat /usr/share/applications/Thunar.desktop | grep Icon
Icon=Thunar
$ ls -l /usr/share/icons/hicolor/48x48/apps/Thunar.png
-rw-r--r-- 1 root root 4261 Apr 9 2014 /usr/share/icons/hicolor/48x48/apps/Thunar.png
$ ls -l /usr/share/icons/elementary-xfce/apps/48/Thunar.png
lrwxrwxrwx 1 root root 23 Nov 6 2015 /usr/share/icons/elementary-xfce/apps/48/Thunar.png -> system-file-manager.png
Пользователь увидит только уникальный значок , используемый для кроссплатформенного или независимого от рабочего стола файлового менеджера. Хорошим примером является Double Commander , у которого действительно есть собственная иконка, в отличие от других файловых менеджеров.
TL;DR Большинство файловых менеджеров используют один и тот же значок по умолчанию в соответствии со спецификацией.
Этот образ ISO можно загрузить только как (настоящий или виртуальный )компакт-диск -ROM; у него нет дополнительных структур, чтобы он также отображался как действительный загрузочный образ жесткого диска.
Загрузка с USB-накопителей в системах с BIOS обычно выполняется путем отображения USB-накопителя как жесткого диска. Жесткий диск будет загружать BIOS -, если он имеет действительную главную загрузочную запись (MBR )в качестве первого блока.
С другой стороны, CD -ROM является загрузочным, если он содержит загрузочные заголовки Eltorito среди расширений файловой системы ISO 9660... и эти расширения обычно расположены не в самом начале диска, а в расположение определяется структурой файловой системы ISO 9660.
Можно создать файл образа.ISO, который также анализируется как допустимый образ жесткого диска, добавив MBR в самое начало диска и расположив содержимое файловой системы ISO9660 в способ, который также совместим с ним. Но это не вариант по умолчанию:хотя большинство современных установочных ISO-образов Linux готовятся таким образом, но не все.
Этот конкретный ISO явно не является,так как вы можете сбросить первые 512 байт образа ISO и увидеть, что он содержит только нули:
$ dd if=CentOS-7-i386-Minimal-2009.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 7.6959e-05 s, 6.7 MB/s
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
000200
Первые 512 байт образа ISO, который был подготовлен для использования в качестве образа загрузочного жесткого диска -BIOS, будут выглядеть немного сложнее. Пример:
$ dd if=/usr/lib/ipxe/ipxe.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 0.00298604 s, 171 kB/s
000000 33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >3...............<
000010 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >................<
000020 33 ed fa 8e d5 bc 00 7c fb fc 66 31 db 66 31 c9 >3......|..f1.f1.<
000030 66 53 66 51 06 57 8e dd 8e c5 52 be 00 7c bf 00 >fSfQ.W....R..|..<
000040 06 b9 00 01 f3 a5 ea 4b 06 00 00 52 b4 41 bb aa >.......K...R.A..<
000050 55 31 c9 30 f6 f9 cd 13 72 16 81 fb 55 aa 75 10 >U1.0....r...U.u.<
000060 83 e1 01 74 0b 66 c7 06 f3 06 b4 42 eb 15 eb 02 >...t.f.....B....<
000070 31 c9 5a 51 b4 08 cd 13 5b 0f b6 c6 40 50 83 e1 >1.ZQ....[...@P..<
000080 3f 51 f7 e1 53 52 50 bb 00 7c b9 04 00 66 a1 b0 >?Q..SRP..|...f..<
000090 07 e8 44 00 0f 82 80 00 66 40 80 c7 02 e2 f2 66 >..D.....f@.....f<
0000a0 81 3e 40 7c fb c0 78 70 75 09 fa bc ec 7b ea 44 >.>@|..xpu....{.D<
0000b0 7c 00 00 e8 83 00 69 73 6f 6c 69 6e 75 78 2e 62 >|.....isolinux.b<
0000c0 69 6e 20 6d 69 73 73 69 6e 67 20 6f 72 20 63 6f >in missing or co<
0000d0 72 72 75 70 74 2e 0d 0a 66 60 66 31 d2 66 03 06 >rrupt...f`f1.f..<
0000e0 f8 7b 66 13 16 fc 7b 66 52 66 50 06 53 6a 01 6a >.{f...{fRfP.Sj.j<
0000f0 10 89 e6 66 f7 36 e8 7b c0 e4 06 88 e1 88 c5 92 >...f.6.{........<
000100 f6 36 ee 7b 88 c6 08 e1 41 b8 01 02 8a 16 f2 7b >.6.{....A......{<
000110 cd 13 8d 64 10 66 61 c3 e8 1e 00 4f 70 65 72 61 >...d.fa....Opera<
000120 74 69 6e 67 20 73 79 73 74 65 6d 20 6c 6f 61 64 >ting system load<
000130 20 65 72 72 6f 72 2e 0d 0a 5e ac b4 0e 8a 3e 62 > error...^....>b<
000140 04 b3 07 cd 10 3c 0a 75 f1 cd 18 f4 eb fd 00 00 >.....<.u........<
000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
0001b0 48 07 00 00 00 00 00 00 c4 7a ef 12 00 00 80 00 >H........z......<
0001c0 01 00 17 3f 20 01 00 00 00 00 00 10 00 00 00 00 >...?...........<
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............U.<
000200
Первая часть — это загрузочный код в MBR (, в данном случае, очевидно, используется ISOLINUX из семейства загрузчиков SYSLINUX, что имеет смысл, поскольку тип файловой системы в основной части образа диска будет ISO9660 ), затем фактическая таблица разделов MBR, а два последних байта содержат байты подписи 0x55 0xaa.
Почему сборщики дистрибутива CentOS пропустили этот этап подготовки образа ISO в данном конкретном случае? Только они сами могут знать :, что, возможно, это ошибка, и кто-то просто забыл включить это в процесс выпуска 32 -битного минимального установочного носителя. Или, возможно, они решили сделать это по какой-то причине.
Просто для полноты картины:
Если ISO-образ также должен загружаться в микропрограмме UEFI с использованием собственного процесса загрузки UEFI (, а не механизма поддержки совместимости с BIOS ), применяется еще один набор требований. Таблица разделов (либо MBR, либо GPT )в начале образа должна содержать как минимум один раздел FAT32, помеченный специальным идентификатором типа системного раздела EFI (0xef для разбиения MBR., GUID определенного типа раздела для разбиения GPT ). И этот раздел должен иметь загрузчик как специально -именованный файл :для 32 -битной архитектуры x86, который будет \EFI\BOOT\BOOTIA32.EFIвыражен как путь в стиле Windows -. Для 64-битной архитектуры x86 -путь загрузки UEFI будет \EFI\BOOT\BOOTX64.EFI.
На практике в некоторых реализациях прошивки UEFI эти требования несколько смягчены.Съемный носитель может рассматриваться микропрограммой UEFI как загрузочный, если он содержит файл загрузчика с соответствующим -именем по правильному пути в любой файловой системе, доступной для чтения данной конкретной реализации микропрограммы UEFI . ]. Все реализации прошивки UEFI должны понимать FAT32 как часть спецификации UEFI; но разные реализации могут добавлять другие типы файловых систем. Например, UEFI от Apple также изначально понимает файловые системы HFS+.