GNU bug report logs - #41792
dd function – message: "No boot sector on USB device""

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41792 in the body.
You can then email your comments to 41792 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ricky Tigg <ricky.tigg <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: dd function – message: "No boot sector on USB device""
Date: Wed, 10 Jun 2020 18:49:28 +0300

[Message part 1 (text/plain, inline)]

*Component*: coreutils.x86_64  8.32-4.fc32.; *OS*: Linux Fedora

Source of file:
https://www.microsoft.com/en-us/software-download/windows10ISO

Disc image file
- checked against its SHA-256 checksum was correct
- written successfully with that command:
# dd if=Win10_2004_Finnish_x64.iso of=/dev/sdc bs=4M oflag=direct
status=progress && sync

Once written, the partition is as follows:
$ mount | fgrep /run/media/$USER
/dev/sdb on /run/media/yk/CCCOMA_X64FRE_FI-FI_DV9 type udf
(ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)

While the USB device was booted in BIOS, the following message was
produced  "*No boot sector on USB device*"".

Using *Gparted*, while the device's partition was unmounted, the flags
could not be managed thus no boot flag was added. The following warning was
present:
*2.66 GiB of unallocated space within the partition.*

[Message part 2 (text/html, inline)]

Message #8 received at 41792 <at> debbugs.gnu.org (full text, mbox):

From: Ricky Tigg <ricky.tigg <at> gmail.com>
To: 41792 <at> debbugs.gnu.org
Subject: dd function – message: "No boot sector on USB device"
Date: Wed, 10 Jun 2020 18:59:02 +0300

[Message part 1 (text/plain, inline)]

$ file -b Win10_2004_Finnish_x64.iso
ISO 9660 CD-ROM filesystem data 'CCCOMA_X64FRE_FI-FI_DV9' (bootable)

[Message part 2 (text/html, inline)]

Message #11 received at 41792 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ricky Tigg <ricky.tigg <at> gmail.com>, 41792 <at> debbugs.gnu.org
Subject: Re: bug#41792: dd function – message: "No boot sector on USB device""
Date: Thu, 11 Jun 2020 23:53:40 +0200

tag 41792 notabug
close 41792
stop

response below...

On 2020-06-10 17:49, Ricky Tigg wrote:
> *Component*: coreutils.x86_64  8.32-4.fc32.; *OS*: Linux Fedora
> 
> Source of file:
> https://www.microsoft.com/en-us/software-download/windows10ISO
> 
> Disc image file
> - checked against its SHA-256 checksum was correct
> - written successfully with that command:
> # dd if=Win10_2004_Finnish_x64.iso of=/dev/sdc bs=4M oflag=direct
_____________________________________________^^^

> status=progress && sync
> 
> Once written, the partition is as follows:
> $ mount | fgrep /run/media/$USER
> /dev/sdb on /run/media/yk/CCCOMA_X64FRE_FI-FI_DV9 type udf
_______^^^
> (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)

sdc vs. sdb?
You wrote to a different disk.

Apart from that, there's not proof that this problem is related to dd(1).
As such, I'm marking this as "not a bug" in our bug tracker.  However. the
discussion can of course continue, and we could even re-open the issue once
it would - unlikely - turn out to be a dd(1) bug.

Have a nice day,
Berny

Message #14 received at 41792 <at> debbugs.gnu.org (full text, mbox):

From: Ricky Tigg <ricky.tigg <at> gmail.com>
To: 41792 <at> debbugs.gnu.org
Subject: Re: bug#41792: Acknowledgement (dd function – message: "No boot sector on USB device"")
Date: Fri, 12 Jun 2020 14:33:20 +0300

[Message part 1 (text/plain, inline)]

The difference of device path is due to the fact that the USB media was
plugged out after the write-operation was achieved on the Linux computer
then plugged into a computer –Asus– whose Windows OS has to be restored,
then plugged back to the same computer but to a *different* USB port. It's
safe to open the present issue-ticket.

*Source media*:
https://www.microsoft.com/en-us/software-download/windows10ISO

*Rufus v4.1.4* – I couldn't use it since The Windows OS installed is
missing some system's files. Will convert it to fit on Fedora at release of
version 33 which will update the uniformly mingw component and thus
mingw64-headers which is old and is the cause of a known issue.

I wrote the disc image as well using those tools then booted the USB device
having the disc image written on.:

*Fedora Media Writer v4.1.4* – Officially does not support Microsoft
Windows disc images. I did not know that before writing.

*Unetbootin v677* – It writes partially the disc image thus the installer
is operational partially. Issue was already reported by someone on Git.

*Woeusb v3.3.1* – Installer is operational on BIOS but not on EFI systems.
Issue was already reported by someone on Git.

*Balena Etcher v1.5.9*8 x64 as AppImage format – The device is not listed
at boot.

ke 10. kesäk. 2020 klo 18.51 GNU bug Tracking System (help-debbugs <at> gnu.org)
kirjoitti:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-coreutils <at> gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 41792 <at> debbugs.gnu.org.
>
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 41792: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41792
> GNU Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems
>

[Message part 2 (text/html, inline)]

Message #17 received at 41792 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Ricky Tigg <ricky.tigg <at> gmail.com>
Cc: 41792 <at> debbugs.gnu.org
Subject: Re: bug#41792: Acknowledgement (dd function – message: "No boot sector on USB
 device"")
Date: Wed, 24 Jun 2020 16:14:13 -0600

close 41792
thanks

Since the discussion has moved away from anything GNU Coreutils
related and doesn't seem to be reporting any bugs in any of the
utilities I am going to close the bug ticket.  But discussion may
continue here regardless.  If we see a dd bug we can re-open the
ticket.

Ricky Tigg wrote:
> The difference of device path is due to the fact that the USB media was
> plugged out after the write-operation was achieved on the Linux computer
> then plugged into a computer –Asus– whose Windows OS has to be restored,
> then plugged back to the same computer but to a *different* USB port. It's
> safe to open the present issue-ticket.

Hmm...  There is no reason that the Linux kernel would renumber the
device simply because it was removed and inserted again.  Therefore me
thinks that it was not cleanly removed.  Me thinks that something in
the system had mounted it keeping it busy preventing it from cleanly
being ejected.  This "something" may have been an automatic mounting
of it as many Desktop Environments unfortunately default to doing.
IMNHO automated mounting is a bad idea and should never be enabled by
default.

> *Source media*:
> https://www.microsoft.com/en-us/software-download/windows10ISO

The source media doesn't matter to GNU utilities.  The 'dd' utility
treats files as raw bytes and does not treat MS-Windows-10 ISO images
any differently than any other raw data.  It might be that or pictures
of your dog or random cosmic noise recorded from your radio.  It
doesn't matter.  It's just data.

Your Desktop Environment may take action however.  It is possible that
your DE will probe the device, detect that it is an ISO image, and
automatically mount that ISO image.  That's bad.  But that's your
Desktop Environment and unrelated to 'dd'.  But it always been a bad
idea.  Regardless of how many people do it.

> *Rufus v4.1.4* – I couldn't use it since The Windows OS installed is
> missing some system's files. Will convert it to fit on Fedora at release of
> version 33 which will update the uniformly mingw component and thus
> mingw64-headers which is old and is the cause of a known issue.
>
> I wrote the disc image as well using those tools then booted the USB device
> having the disc image written on.:
>
> *Fedora Media Writer v4.1.4* – Officially does not support Microsoft
> Windows disc images. I did not know that before writing.

My first thought was, huh?  Why would Fedora Media Writer not treat
files as raw files?  My second thought was that the question was for a
Fedora Media Writer mailing list as this bug ticket is not the place
to be discussing other random projects.

> *Unetbootin v677* – It writes partially the disc image thus the installer
> is operational partially. Issue was already reported by someone on Git.
>
> *Woeusb v3.3.1* – Installer is operational on BIOS but not on EFI systems.
> Issue was already reported by someone on Git.
>
> *Balena Etcher v1.5.9*8 x64 as AppImage format – The device is not listed
> at boot.

Gosh.  Reading your report makes MS-Windows seem like such a terrible
system!  I read about all of your pain of working on it.  You have
tried all of these tools and nothing is working for you.  It is
reading these types of reports that I am thankful I am working on a
Free(dom) Software operating system where things Just Work!

Meanwhile...  Let's get back to your information about 'dd'.

> $ file -b Win10_2004_Finnish_x64.iso
> ISO 9660 CD-ROM filesystem data 'CCCOMA_X64FRE_FI-FI_DV9' (bootable)

That looks like you were successfully able to write the ISO image to
the device.  Looks okay.

> *Component*: coreutils.x86_64  8.32-4.fc32.; *OS*: Linux Fedora

Good.

> Source of file:
> https://www.microsoft.com/en-us/software-download/windows10ISO
>
> Disc image file
> - checked against its SHA-256 checksum was correct
> - written successfully with that command:
> # dd if=Win10_2004_Finnish_x64.iso of=/dev/sdc bs=4M oflag=direct status=progress && sync

I don't see any error messages.  That's good.

The oflag=direct should use direct I/O.  Which means that the 'sync'
shouldn't matter since there should be no file system buffer to flush.
It will simply flush other unrelated buffers.  Won't hurt though.

The bs size seems very small at 4M to me.  Especially for use with a
NAND flash USB storage device.  I would select a much larger size.  I
would probably use 64M which is likely to be an integral size of your
original ISO image but that should be verified.

> Once written, the partition is as follows:
> $ mount | fgrep /run/media/$USER
> /dev/sdb on /run/media/yk/CCCOMA_X64FRE_FI-FI_DV9 type udf
> (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)

WHY is this mounted?  That seems like a problem.

You said that the device was removed and replaced and went from sdc to
sdb?!  Probably because it was mounted.

This feels like the root cause of all of your problems.  It feels to
me that something is automatically mounting the device.  That's bad.
Then the device is written to the base partition under the file
system.  Then I think likely the sync is flying data to the file
system on top of it which would corrupt the resulting image.

If it were me I would seek and stop all automated mounting.  It's
always bad and particularly a problem due to these types of things.

It does not make sense to me that the device would be written to as
sdc and then removing and inserting it again would rotate it to sdb, a
lower letter.  And it makes no sense to me that it would become
mounted.

If I were writing a USB device with data and then wanted to verify
that the data was written correctly I would read the data back and
verify that the sha256sum matched the data that was written.  If the
check digest matched then I would know the data on the device was
correct.

The image being written is likely smaller than the physical device.
Therefore one can't simply read the device and get a checksum.  One
must read and check only the size of the original image.  Otherwise
the extra data on the end will produce a different digest hash.

There are many ways to do this.  I might note down the size of the ISO
being written as N.  Then use "head --bytes=N /dev/sdb | sha256sum" to
produce the digest hash and then compare what was written to what was
read back.  Or there are probably better ways too.

> While the USB device was booted in BIOS, the following message was
> produced  "*No boot sector on USB device*"".

I think this result was likely due to automatic mounting by the
Desktop Environment.  But without debugging to root cause that is
simply a guess.

> Using *Gparted*, while the device's partition was unmounted, the flags
> could not be managed thus no boot flag was added. The following warning was
> present:
> *2.66 GiB of unallocated space within the partition.*

I think this is not important.  I think this is due to the ISO image
being smaller than the size of your physical device.  Which it must be
in order to hold the image.  I think this is normal and expected.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.