I have a bootrom file (binary file) which I copy it on a USB drive (to boot a target) using Linux cp (I have also tried with dd). The file is copied to the first partition which is formatted with FAT16 (bootrom requirement):

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63     3037859     1518898+   6  FAT16
/dev/sdc2         3037860    30361589    13661865    c  W95 FAT32 (LBA)

When I try to boot the target, the bootrom is loading (I know this because there are some chars printed during this phase) but then it just hangs. This issue doesn't occure if I copy the file from an Windows host. The content of the file doesn't change, whether I copy it from Linux or Windows, it's exactly the same. I have observed that this also occures if I rename a working file on the USB drive.

I don't think this is an issue regarding my Linux installation because I have also tried this on a different Linux host.

Host OS: Linux Mint 17.3 Cinnamon 64-bit
Kernel : 3.19.0-32-generic

EDIT: I have found a way to make this work by using mcopy.

I have added the following line in /etc/mtools.conf:

drive u: file="/dev/sdc1"

However, when I try to do the following:

$ mcopy bootrom.bin u:bootrom.sys
# for some reasons I get the following error:
Can't open /dev/sdc1: Permission denied
Cannot initialize 'U:'
Bad target u:bootrom.sys
# with sudo:
$ sudo mcopy bootrom.bin u:bootrom.sys
Cannot initialize 'U:'
Bad target u:bootrom.sys

So I proceeded with the following workaround which seems to work:

$ copy bootrom <mount_point>/file
$ cd 
$ mcopy file bootrom.sys
  • One way to debug it is to make a complete copy of the contents of the stick (/dev/sdc) with dd after copying the file from a Windows host, and compare it with the contents after copying the file from a Linux host. If there's any difference, it should show up. – dirkt Feb 21 '17 at 6:49
  • Thanks for the tip! However, this would take some time. I will look into it when I can and if I find something useful I'll post it here. – Iulian Paun Feb 22 '17 at 13:35
  • Maybe comparing the first 1000 or blocks at the beginning (use dd) will already show something - after all, the likely suspects are the paritition table, the FAT itself, the root directory etc. Ofc, if you don't find anything, you'll still have to do a full compare. – dirkt Feb 22 '17 at 14:37
  • I already did this, there is no difference. Some changes may occur where the file is located on the disk. – Iulian Paun Feb 23 '17 at 7:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.