LINUX.ORG.RU

linux странности с fat32 на флешках

 , ,


0

3

Здравствуйте, коллеги!

С Наступающим Новым Годом!

Пытаюсь доделать скрипт, создающий загрузочные флешки, с последующим наполнением нужным софтом.

Идея следующая: флешка (допустим /dev/sdc) бьется на 2 раздела.

/dev/sdc1 = весь объем - 1,5Гб (ext4 или, впоследствии, NTFS),

/dev/sdc2 = 1,5Гб (fat32 EFI)

Интерес, в данный момент представляет /dev/sdc2.

Что же на этом разделе?

На /dev/sdc2 устанавливается grub.

https://pendrivelinux.com/boot-multiple-iso-from-usb-via-grub2-using-linux/

Так же, туда кладется squashfs образ + vmlinuz + initrd (собственного производства). grub.cfg настраивается на загрузку и, вроде, все пучком! Но не все…

Некоторые флешки, например моя Transcend ведет себя полностью предсказуемо и все прекрасно работает, но есть и другие «маргинальные» флеш накопители, на которых результат не прогнозируем!

Например, моя прекрасно «бутится» и работает, а вот «маргинальные» могут совсем не загружаться. Даже заставки grub не видно.

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

Дальше заливаю на /dev/sdc2 squashfs образ, размером 800мб и… И дальше все не прогназируемо.

Может все будет загружаться. Может не будет. Иногда, странная фигня начинает твориться с файлами. У некоторых искажаются названия, размеры и, вообще, твориться черти что. И все это происходит всего лишь после заливки файла в 800мб!

Т.е. ни чего больше не трогается. Только на /dev/sdc2 посредством cp копируется файл, но этого часто оказывается достаточно, что бы grub отказывался загружаться, на «маргинальных» флешках.

Пробовал сначала залить большие файлы, потом ставить grub.

Вотще!

Результат не прогнозируемый! Может она будет загружаться. Может нет. А может «побиться» squashfs.

При этом, если на маргинальные флешки поредством dd залить iso образ, то с вероятностью в 99% она будет загрузочной и рабочей.

Разумеется, можно пытаться бить флешку на 3 раздела: /dev/sdc1 по прежнему, /dev/sdc2 1G ext4, /dev/sdc3 - fat32 EFI. Но этого делать не хочется!

Почему такая фигня может происходить?

UPD После каждой операции вызываю sync. Т.е. не должно быть пропажи недописанных данных.

Нужно попробовать изменить на монтирование с sync…



Последнее исправление: HighMan (всего исправлений: 1)

У некоторых искажаются названия, размеры

А если добиться такой записи, чтобы все названия, размеры и хеш-суммы совпадали с оригинальными?

Может быть при записи больших объёмов флешка перегревается? Попробуй записывать медленнее.

https://unix.stackexchange.com/questions/735738/cgroup-v2-io-max-limit-not-applied

https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

https://andrestc.com/post/cgroups-io/

anonymous
()
Ответ на: комментарий от anonymous

А если добиться такой записи, чтобы все названия, размеры и хеш-суммы совпадали с оригинальными?

Может быть при записи больших объёмов флешка перегревается? Попробуй записывать медленнее.

Если все сравнивать, то одна флешка за сутки не будет готова.

Я сделал монтирование EFI (/dev/sdc2) раздела с синхронизацией

mount -t vfat -o sync /dev/sdc2 /mnt

Запись банальных директорий с содержимым efi и grub идет почти минуту, а там объем-то кот наплакал.

Решил плюнуть на время и кроме efi & grub еще squashfs образ записал…. Флешка не грузится :)

Переделал.

Теперь флешка бьется на 3 раздела: /dev/sdc1 - неизменно, /dev/sdc2 - ext4 1G, /dev/sdc3 - vfat EFI 512М

В /dev/sdc3 втыкиваю лишь efi и grub

В /dev/sdc2 - squashfs, vmlinuz, initrd

Так даже маргинальная флешка получается загрузочной.

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 1)
Ответ на: комментарий от HighMan

Может тогда флешка битая? Если её контроллер не умеет исключать плохие блоки, то на какой-то области данные могут портиться. Можно попытаться найти плохие блоки через badblocks.

anonymous
()
Ответ на: комментарий от anonymous

Может тогда флешка битая? Если её контроллер не умеет исключать плохие блоки, то на какой-то области данные могут портиться. Можно попытаться найти плохие блоки через badblocks.

В общем, дело плохо.

Разбил на 3 раздела, как писал выше.

В /dev/sdc3 засунул grub & efi под sync

В /dev/sdc2 записал squashfs. При этом /dev/sdc3 был размонтирован.

umount /dev/sdc*
fsck.vfat /dev/sdc3
...
Cluster 116987 out of range (239061857 > 155085). Setting to EOF.
Cluster 116988 out of range (24908700 > 155085). Setting to EOF.
Cluster 116989 out of range (153068198 > 155085). Setting to EOF.
Cluster 116990 out of range (135203958 > 155085). Setting to EOF.
Cluster 116991 out of range (194823008 > 155085). Setting to EOF.
Cluster 116992 out of range (37128914 > 155085). Setting to EOF.
Cluster 116993 out of range (67728886 > 155085). Setting to EOF.
Cluster 116994 out of range (25862631 > 155085). Setting to EOF.
Cluster 116995 out of range (178218608 > 155085). Setting to EOF.
Cluster 116996 out of range (233821473 > 155085). Setting to EOF.
Cluster 116997 out of range (213986564 > 155085). Setting to EOF.
Cluster 116998 out of range (93586520 > 155085). Setting to EOF.
Cluster 116999 out of range (111777554 > 155085). Setting to EOF.
Cluster 117000 out of range (1700783 > 155085). Setting to EOF.
Cluster 117001 out of range (62600632 > 155085). Setting to EOF.
Cluster 117002 out of range (209204871 > 155085). Setting to EOF.
Cluster 117003 out of range (231578604 > 155085). Setting to EOF.
Cluster 117004 out of range (238384031 > 155085). Setting to EOF.
Cluster 117005 out of range (200658175 > 155085). Setting to EOF.
Cluster 117006 out of range (218545559 > 155085). Setting to EOF.
Cluster 117007 out of range (166212692 > 155085). Setting to EOF.
Cluster 117008 out of range (250658756 > 155085). Setting to EOF.
Cluster 117009 out of range (202719575 > 155085). Setting to EOF.
Cluster 117010 out of range (121505691 > 155085). Setting to EOF.
Cluster 117011 out of range (8837561 > 155085). Setting to EOF.
Cluster 117012 out of range (204379214 > 155085). Setting to EOF.
...
Unfinished long file name "d".
  (Start may have been overwritten by jı░óØ┴¦1.Êl()
1) Delete LFN
2) Leave it as it is
3) Fix numbering (truncates long name and attaches it to short name jı░óØ┴¦1.Êl()
[123?q]?

Выходит, что маргинальная флешка конкретно убита, хоть она и совсем новая…

HighMan
() автор топика
Ответ на: комментарий от HighMan

ыыы….

badblocks -v /dev/sdc3
Checking blocks 0 to 621567
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Я думал конец флешки испорчен. Ан нет! Она, по ходу, конченая от рождения.

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 1)
Ответ на: комментарий от anonymous

Да флешка просто фальшивка

Вполне возможно.

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

Можете посоветовать линуксовое средство для проверки флешки?

Беда в том, что, на первый взгляд, флешка рабочая. badblock ни чего страшного не видит. При записи (с синхронизанизацией) все записывается нормально, но вот потом файловая система сыпется к чертовой матери.

В крайнем случае, подойдет и виндовая утилитка. У меня винды нет, но у коллег есть.

HighMan
() автор топика
Ответ на: комментарий от HighMan

Я перестал, что либо понимать.

Разбил маргинальную флешку на 2 раздела: /dev/sdc1 50G, /dev/sdc2 все оставшееся место. Примерно 8Gb.

mkfs.ext4 /dev/sdc2

mount /dev/sdc2 /mnt

# заполняем всяким хламом
rsync -a /usr /mnt

sync

umount /dev/sdc*

fsck.ext4 /dev/sdc2
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdc2: clean, 228191/564144 files, 2248481/2252544 blocks

Это как???? Все в порядке! fs не рассыпалась! АшЫПок нет!

Что это за магия, если в ext4 все путем, а вот vfat сыпется по факту записи?

Это что? Linux не умеет с fat32 работать?

Тестировалось на Fedora 37 и alt 10. FAT32 сыплется сразу! Записал кучку файлов, синхронизировал, размонтировал, проверил: fschk /dev/sdc2 и… Море АшЫПок!

Если же отформатировать в ext4 и забить всяким хламом то все в полном порядке!

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 3)
Ответ на: комментарий от slowpony

Дяденька, стесняюсь спросить, а вы unmount делаете прежде чем флешки вытаскивать?

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

HighMan
() автор топика
Ответ на: комментарий от anonymous

badblocks фейк не покажет, тут F3 нужен.

Я попробую на ночь комп зарядить, пусть на запись проверяет. Но я сомневаюсь, что это что-то даст.

Я же забивал все пространство файлами и проверял после. Если fs ext4, то всё проходит без проблем.

Проблемы начинаются, как только fs fat

HighMan
() автор топика
Ответ на: комментарий от HighMan

При этом ты не написал, какая у тебя таблица разделов.
Если GPT, то почему ты не оставил раздела под bios-boot, а если MBR, то помещение EFI-system не в первый раздел - очень плохая идея.

ABW ★★★★★
()
Ответ на: комментарий от ABW

При этом ты не написал, какая у тебя таблица разделов. Если GPT, то почему ты не оставил раздела под bios-boot, а если MBR, то помещение EFI-system не в первый раздел - очень плохая идея.

Таблицу делал и так и так. В данном случае не важно какая таблица если рассыпается efi раздел.

Что же касается EFI не первым разделом при MBR, то порядок следования не важен. Главное что бы он был! Ventoy, не к ночи будт помянут, так же системные разделы в конец диска запихивает.

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

HighMan
() автор топика
Ответ на: комментарий от slowpony

Вы точно не путаете mount -o sync и umount / eject? Потому что -o sync никак не препятствует дернуть флешку из порта посреди операции записи.

Не путаю.

У меня твердо въевшаяся привычка всегда размонтировать перед вытаскиванием.

Если вы посмотрели примеры кода выше, то должны были увидеть: umount /dev/sdc*

HighMan
() автор топика
Ответ на: комментарий от anonymous

badblock -v -w /dev/sdc > sdc.txt молотит уже двое суток. sdc.txt на текущий момент 138мб и останавливаться на достигнутом, явно не собирается.

tail -f sdc.txt

Сразу заполняет экран цифрами.

Я правильно понимаю, что магические числа, которые содержатся в этом файле - битые блоки?

Если да, то флешка мертворожденная. Убитая до рождения. Жертва аботрта!

HighMan
() автор топика
Ответ на: комментарий от HighMan

138мб

Ого! Это многовато что-то.

tail -f sdc.txt Сразу заполняет экран цифрами.

Числами, по одному на строку? Да, это номера плохих блоков.

молотит уже двое суток. … останавливаться на достигнутом, явно не собирается

Это странно, конечно, что так долго проверяет. Хотя, если флешка большая и скорость медленная, то всё может быть. Он каждый блок по 4 раза перезаписывает - с разными паттернами.

Ещё при запуске можно было выбрать размер блока, соответствующий размеру страницы флешки, я не знаю точно, но это может быть 4096 байт. Так и флешка меньше убивается и программа должна отработать быстрее. По умолчанию размер блока равен 1024 байтам.

Странно ещё то, что работает с ext4 и с маленькими файлами. Хотя, при создании фс есть возможность проверить и исключить плохие блоки, если указать ключ -c. Но тогда бы фс создавалась не быстрее, чем сейчас отрабатывает badblocks.

anonymous
()
Ответ на: комментарий от anonymous

Ну, да.

Многовато бэдов для новой флешки.

По логике получается, что она вся сплошной бэд.

Но, блин, хоть как-то она работает! А на чтение, так и вовсе, все замечательно!

Смущает, что при ext4 все нормально, хотя… С ext4 я проверял лишь один раз раздел размером, примерно 8Гб.

Возможно, если сделать несколько записей то и ext4 рухнет. Ведь случалось же чудо, что даже FAT записывался нормально. Правда, лишь единожды :)

Но самое веселое - мой старинный Transcend пашет совершенно нормально. При любой фс. Другое дело, что badblocks я ее не проверял.

Да старый Transcend не поражает скоростью, но, хотя бы работает!

В общем я на работе ультимативно заявлю, что с маргинальными флешками работать больше не буду.

Пусть берут брендовые. Тратить столько времени на пляски с говнофлешками я больше не буду.

Я потратил 2 рабочих дня! Одной ЗП за эти 2 дня ушло столько, что хватило бы купить с полсотни Trascend на 64 Гб.

HighMan
() автор топика
Ответ на: комментарий от anonymous

хм…

f3probe --destructive --time-ops /dev/sdc

На маргинальной 64Гб флешке висит уже более часа и когда закончит не ясно)

Прогнал свой скрипт создания системной флешки на SunDisk 32Гб. Все заработало, как на Transcend. fat32 не сыпется.

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 1)