Винда отстой

debug.com

ТАК НАДО БЫЛО СПЕРВА С БОЖЕСТВЕННОГО ЛИНУКСА ФЛЭШКУ ЗАПИСАТЬ, А ПОТОМ ЕГО СНОСИТЬ, НУБИЩЕ.

У меня кстати Rufus из Windows без проблем работает с Haiku и Линуксами.

Хорошая мысля приходит опосля.

для записи образов на флешку под виндой есть tuxboot.

Взял бы ventoy и не мучился. На работе держу флешку с виндами/линуксами и всякими мемтестами. Удобно.

Но винда всё равно отстой, тут не поспоришь.

Такое ощущение, что надо самому брать MSVC и писать цикл

хм… а разве mingw’шного компилятора GCC не достаточно?

firkax, я в чём-то ошибся?)

Ты не просто ошибся, ты присунул оффтоп хотя автор вполне понятно для всех написал что пытается записать линуксовый установочный диск.

А я пробовал поставить винду из этого вашего линукса. Говорят, надо dd использовать из консоли. Ну мы люди не гордые, можем и до консольного интерфейса опуститься, ради нормального десктопа. dd завершился, никаких ошибок, пытаемся загрузиться - ни хрена не работает, не видит фирмварь во флешке загрузочного кандидата.

Пришлось искать другой комп с виндой и там запускать Руфус. Что за говенный линукс, даже флешку с вендой не может записать!

А, вон в чём дело. Сорян, замотался.

Всё так. С тем отличием, что аналог руфуса на линуксе есть.

Эта хорошая мысля должна была придти еще лет двадцать назад и остаться навсегда.

А вообще, раз так любишь dd, то воткни виртуалку в венду и в ней орудуй, загрузившись с той же исошки, например.

Загружаюсь, делаю dd

Или вот еще: ты с флэшки загрузился и потом ее же чексумму сравниваешь с исошкой? А там, случайно, какой-нибудь EFI-раздел в RW автоматом не смонтировался?

Говорят у винды iso не гибридные. Нельзя их напрямую dd-шкой лить на флешку.

Вот такой микрософт отстой, даже iso приготовить не могут

Я вентоем пользуюсь, но у руфуса там вроде какие-то настройки есть, которые вмешиваются в образ (типа разрешение использования локального пользователя и т.п.), а вот как он дд-шит - я не знаю, может он сначала образ трогает, а потом дд делает…

Пришлось искать другой комп с виндой и там запускать Руфус. Что за говенный линукс, даже флешку с вендой не может записать!

Это проблемы винды, а не линукса, да и если помню правильно, была какая-то тулза - аналог видосовского флэшера под линуксом, но давно было дело…

С винды скачал ISO.

дядь, fedora live уже годы как позволяет работать на десктопе без установки. Зачем тебе венда для скачивания образа?

И как подготовить юсб флешку с федора лайв в виндоус? Та же самая проблема.

Или вот еще: ты с флэшки загрузился и потом ее же чексумму сравниваешь с исошкой?

Конечно.

А там, случайно, какой-нибудь EFI-раздел в RW автоматом не смонтировался?

Вряд ли.

Собственно если оно нормально записано, то потом всё прекрасно чексуммится. А если с винды, то не чексуммится, причём встроенной в дистрибутив проверкой.

Да, виндовые ISO нужно распаковывать и копировать файлы на FAT раздел. Причём не просто копировать, а преобразовывать вендовыми инструментами, т.к. там файл install.wim слишком большой для FAT32. Собственно я даже не знаю, как это можно сделать на линуксе. Единственное, что можно сделать, то использовать NTFS вместо FAT, но с такого в теории не каждый UEFI загрузится.

А если предположить, что есть сдвиг данных от начала диска? Тупо открыть диск в HxD - посмотреть где начало, там же открыть файл ISO чтобы посмотреть с чего он начинается и сравнить от указанной позиции.

Если что, кроме «ventoy (1.099)» ещё пользуюсь unetbootin. До UEFI, на Legacy активно использовал Grub2. Rufus-ом вообще редко пользуюсь, использовал в нём dd и это (MX вроде) грузилось, но хэш не проверял.

Собственно я даже не знаю, как это можно сделать на линуксе.

https://wimlib.net

видимо сама винда портит какие-то данные на флешке в какой-то момент

С добрым утром.

Не портит, а обращается с системными полями разметки дисков по своему разумению. Под Windows, равно как и под macOS — вы в гостях у системы, а вовсе не полноценный хозяин своему железу, можно было бы уже привыкнуть.

  https://habr.com/ru/articles/304014/ 

ValdikSS:

…в MBR диска в поле Disk Signature указаны нули. Как только вы подключаете этот диск к компьютеру под управлением ОС Windows, она обнаруживает нули, ей это не нравится, ведь Windows использует Disk Signature в качестве уникального идентификатора диска, генерирует случайный и по-тихому записывает его на диск…

А вообще, уже десять раз можно было побайтовым сравнением найти, что именно меняется и где, а не разводить флудятину.

ностальгия..
rawrite.exe и куча дискеток для записи установки OS/2

делаю dd if=/dev/sda bs=2048 count=467733 | sha256sum, не совпадает.

Поехали. Работаю в Арче, «родной» ISO от 1 января 2026, BLAKE2b: f7cd388006cb787d4a8aecaeab914d9ef31dfeba148013e6a975402d372da9deac25571583f70aa76aabc3f70c2d41a197590e8d6cda159cc8c36da6b3fae4a2 archlinux-2026.01.01-x86_64.iso

$ fdisk -l /dev/sdc
Диск /dev/sdc: 1,88 GiB, 2019557376 байт, 3944448 секторов
Disk model: Transcend 2GB   
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0x2822af79

Устр-во    Загрузочный  начало   Конец Секторы Размер Идентификатор Тип
/dev/sdc1  *                64 2491103 2491040   1,2G             0 Пустой
/dev/sdc2              2491104 3005151  514048   251M            ef EFI (FAT-12/16/32)

$ wget -qO - https://mirror.yandex.ru/archlinux/iso/2026.01.01/archlinux-2026.01.01-x86_64.iso | dd of=/dev/sdc bs=512

3005215+3 records in
3005215+3 records out
1538670592 bytes (1,5 GB, 1,4 GiB) copied, 772,738 s, 2,0 MB/s

$ dd if=/dev/sdc bs=512 count=3005215 | b2sum -b
3005215+0 records in
3005215+0 records out
1538670080 bytes (1,5 GB, 1,4 GiB) copied, 70,6945 s, 21,8 MB/s
dabca0f9e1136d2acc9007841caa96b032fc5a6030e21984a880b4fd3875d635754075ddabc96a10b559c9b4827d2d69efbadbdeb31ab2162a7834239b7e7d9c *-

Как видим, контрольная сумма не совпадает.

fdisk -l archlinux-2026.01.01-x86_64.iso 
Диск archlinux-2026.01.01-x86_64.iso: 1,43 GiB, 1538670592 байт, 3005216 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0x2822af79

Устр-во                          Загрузочный  начало   Конец Секторы Размер Идентификатор Тип
archlinux-2026.01.01-x86_64.iso1 *                64 2491103 2491040   1,2G             0 Пустой
archlinux-2026.01.01-x86_64.iso2             2491104 3005151  514048   251M            ef EFI (FAT-12/16/32)

Это к слову о добром имени Rufus. Я не сторонник проприетарного ПО вообще, и уж тем более, проприетарного ПО от майков, но контрольные суммы ISO образа и реального содержимого диска совпадать не должны, потому что сырые данные, хранящиеся на диске, не идентичны полезным данным, хранящимся в файле на этом диске. У файловой системы есть inode, у каждого файла будут уникальные даты, и ты не можешь сохранить половинку inode, и контрольная сумма файла считается с учётом этого. Именно поэтому я выше предлагал пофайлово сравнивать.

Сдвиг всегда есть, для DOS-разметки – 63 сектора, для non-dos – 2048. Если посмотреть через HEX-редактор в ISO и на первые 4к данных на диске – все эти смещения и выравнивания видно невооружённым глазом.

Собственно я даже не знаю, как это можно сделать на линуксе

Для этого пакет есть.

А, нет, просто перед тем, как dd-шить образ, диск надобно весь забить нулями, а я этого не сделал. Тогда я неправ.