Trouble making bootable USB from ISO image

[Greg Wooledge]

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp. This may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.

If the device is mounted, that will interfere with the raw byte writing
you're doing. The results are unpredictable.

[Paul Sutton]

I usually use dd; the following should also work (someone jump in if
I'm misunderstanding the question). Also second what Greg said, make
sure your USB isn't mounted.
dd if=<ISO file> of=/dev/sdf bs=8M

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp.  This
may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.
If the device is mounted, that will interfere with the raw byte writing
you're doing.  The results are unpredictable.

Just to add that if you put status=progress at the end you should get a
progress bar as it writes,  this is handy otherwise you are sitting
around for what seems ages while it writes away in the background.

Hope this helps


Paul

[john doe]

Post by Paul Sutton

I usually use dd; the following should also work (someone jump in if
I'm misunderstanding the question). Also second what Greg said, make
sure your USB isn't mounted.
dd if=<ISO file> of=/dev/sdf bs=8M

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp.  This
may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.
If the device is mounted, that will interfere with the raw byte writing
you're doing.  The results are unpredictable.

Just to add that if you put status=progress at the end you should get a
progress bar as it writes,  this is handy otherwise you are sitting
around for what seems ages while it writes away in the background.

It should be noted that a regular cp command could be used as well:

$ cp *.iso /dev/sdX

To unmount something from the command line you would do something like:

$ umount <WHERE-IT-IS-MOUNTED>

--
John Doe

[James Medeiros]

I usually use dd; the following should also work (someone jump in if I'm
misunderstanding the question). Also second what Greg said, make sure your
USB isn't mounted.

dd if=<ISO file> of=/dev/sdf bs=8M

Post by Greg Wooledge

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp. This may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.
If the device is mounted, that will interfere with the raw byte writing
you're doing. The results are unpredictable.

[Thomas Schmitt]

Hi,

Any suggestions of what I could do to diagnose the problem?

What do you get from this inspection run:

xorriso -indev ...path.to.iso.image... \
-report_system_area plain \
-report_el_torito plain


Have a nice day :)

Thomas

[Mark Fletcher]

Post by Greg Wooledge

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp. This may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.
If the device is mounted, that will interfere with the raw byte writing
you're doing. The results are unpredictable.

This makes sense to me; confession time -- I originally ejected the pen
drive when Gnome auto-mounted it, but then found I couldn't do anything
with the device at all, so concluded that contrary to my memory it
needed to be mounted. Web pages I'd found said nothing about unmounting
the device before writing, so again I thought my memory was faulty. What
I failed to consider was the difference between unmounting and ejecting.

So this time, I booted the machine, logged out of Gnome taking me back
to the gdm2 login screen, and switched to a second virtual terminal,
logging in there as root.

I then plugged in the pen drive. After a second or so, I saw a message
in the console:
sd 10:0:0:0 [sdf] No Caching mode page found
sd 10:0:0:0 [sdf] Assuming drive cache: write through

ls /dev/sd* indeed showed a sdf device that hadn't been there before,
and df confirmed it had not auto-mounted (which makes sense since I
wasn't logged into Gnome)

so next I did cp <iso file> /dev/sdf

The hard disk light flashed for I would say about 20 seconds, then went
dark. Nothing apparently happened for about 2 minutes, then in the
console there appeared:
systemd.udevd: blocked for more than 120 seconds

together with advice about a value in /proc/sys to set to 0 to suppress
that warning. This appeared 2 more times; the process took in total
about 6 minutes before the command line returned without further console
messages. Looking in journalctl there were lots of references to what
look like system calls, and at the end evidence of systemd killing and
restarting systemd.udevd.

For good measure I executed a sync command, as the debian wiki advice
for writing ISO images mentions it (admittedly in conjunction with dd)
and I assumed the worst it would do was nothing. Then I removed the pen
drive, logged out, and switched back to the virtual terminal with gdm2
running.

Logging back in to Gnome, I inserted the pen drive and it promptly
automounted and I am able to see what looks like a healthy file system
containing a boot dir, efi boot stuff etc, plus the usual Autorun stuff
a microsoft ISO usually contains. It _looks_ OK to my untutored eye.
Gparted still does not like it though (saying Unallocated and saying
there is no partition table).

And, as you've probably guessed by now, the machine still won't boot from it.

Beginning to suspect something wrong with the pen drive, I also tried
reformatting the pen drive in Gnome with a FAT32 file system, and
checked I could write text files onto it after doing so and that they
persisted across unmount and remounts. All was well. Then I repeated the
above image-copying process and got the same result.

I am very reluctantly being drawn towards the conclusion there is
something wrong with the ISO image -- this sounds very unlikely to me as
it was downloaded from Microsoft and while they are not exactly my
favourite software maker in the world I would expect them not to publish
a duff ISO, and then leave it sitting there for months without fixing it.

Thomas asked for the output of a particular xorriso command -- here it is:

***@kazuki:/home/mark# xorriso -indev ~mark/Downloads/Win10_1809Oct_v2_Japanese_x64.iso -report_system_area plain -report_el_torito plain
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1 nodes read in 1 seconds
libisofs: WARNING : Found hidden El-Torito image. Its size could not be figured out, so image modify or boot image patching may lead to bad results.
libisofs: WARNING : Found hidden El-Torito image. Its size could not be figured out, so image modify or boot image patching may lead to bad results.
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev '/home/mark/Downloads/Win10_1809Oct_v2_Japanese_x64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito
Media summary: 1 session, 2591375 data blocks, 5061m data, 631g free
Volume id : 'CCCOMA_X64FRE_JA-JP_DV9'
xorriso : NOTE : No System Area was loaded
El Torito catalog : 22 1
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 8 513
El Torito boot img : 2 UEFI y none 0x0000 0x00 1 515
El Torito img blks : 1 2
El Torito img blks : 2 2590860


The only thing there that catches my untutored eye is the thing about
the El Torito boot information being currently set to be discarded --
doesn't sound healthy. Apart from that I don't know what to make of that
output...

Mark

[Russell L. Harris]

On Sat, May 04, 2019 at 11:39:39AM +0900, Mark Fletcher wrote:

In Jessie and Stretch, gnome-disk-utility-3.22.1 (which labels itself
"Disks") sometimes balks at the instructions I give it. But that is
what happens when you use a GUI instead of the command line, and
particularly when the utility utilizes ambiguous symbols rather than
clear English words. Not everyone assigns the same meaning to a
particular symbol.

Nonetheless, I do find "Disks" handy to identity the device associated
with a USB memory stick just plugged in, and to indicate at a glance
the partitioning and formatting.

According to "https://www.debian.org/CD/faq/#write-usb", all Debian
i386 and amd64 images are created using the isohybrid technology, so
that they may be copied to USB flash drives which boot directly from
the BIOS or EFI firmware of most PCs. In Linux, copy with "cp <file>
<device>" or with "dd if=<file> of=<device> bs=4M; sync". And be sure
you are copying to the device (such as "/dev/sdd") and not to a
partition of the device (such as "/dev/sdd1").

In the case of a USB flash drive which refuses to boot, you might try
using "fdisk" to delete all existing partitions and create a new
partition, followed by "mkfs.msdos" before you copy the ISO image to
the drive.

If everything else fails, before you toss the drive into the dumpster,
plug the drive into a Window$ box and allow Window$ to format the
drive. Now and then a Window$ box can do something useful.

[Mark Fletcher]

Post by Russell L. Harris
Nonetheless, I do find "Disks" handy to identity the device associated
with a USB memory stick just plugged in, and to indicate at a glance
the partitioning and formatting.

Indeed I used that at one point to see what state it thought the disk
was in after I'd written the ISO image.

Post by Russell L. Harris
According to "https://www.debian.org/CD/faq/#write-usb", all Debian
i386 and amd64 images are created using the isohybrid technology, so
that they may be copied to USB flash drives which boot directly from
the BIOS or EFI firmware of most PCs. In Linux, copy with "cp <file>
<device>" or with "dd if=<file> of=<device> bs=4M; sync". And be sure
you are copying to the device (such as "/dev/sdd") and not to a
partition of the device (such as "/dev/sdd1").

Indeed, that was how I did it. The Windows download page clearly
indicated that the ISO was for USB sticks or DVDs. Someone else also
asked about the size of the image, being too big for a single-layer DVD.
In answer to their question yes the download page did point that out, if
one read as far as the troubleshooting section where it said something
like "If your burner says there isn't enough space on the DVD, it means
you need a dual-layer DVD" or similar." Since I was using a 16GB pen
drive I wasn't worried about that element of things.

Post by Russell L. Harris
In the case of a USB flash drive which refuses to boot, you might try
using "fdisk" to delete all existing partitions and create a new
partition, followed by "mkfs.msdos" before you copy the ISO image to
the drive.

I essentially did that at one point while troubleshooting the pen drive,
except using Gnome's ability to "format" the device (now there's a blast
from the past)

Post by Russell L. Harris
If everything else fails, before you toss the drive into the dumpster,
plug the drive into a Window$ box and allow Window$ to format the
drive. Now and then a Window$ box can do something useful.

Would only be an option if you have a windows machine to do it on.
Someone did suggest installing kvm and launching the ISO as a VM, and
then using that to burn the ISO onto a USB stick -- that was a creative
solution I hadn't thought of. Using a VM for the entire experiment in
the first place could almost have been a solution, actually -- except
that I want my son to be able to access the machine when I'm not around.

But in the end it turned out the image was fine -- and the very first
burn I did was probably also fine. Thank god we are past the days of
DVDs or I would have had half a dozen shiny new coasters for no good
reason.

The issue was Secure Boot. Specifically, in the case of my test machine,
it's too old to support secure boot, and in the case of the final target
machine, secure boot was turned off in the BIOS so that I could boot
Buster which is what this machine was previously running. When I
switched the CSM and also turned on Secure Boot (both settings needed to
be changed) in the BIOS, the machine finally booted from the USB stick,
and all proceeded smoothly from there.

So the issue in the end, contrary to my instincts, was nothing to do
with errors or mistakes in writing the image to the pen drive (although
I'm grateful for the memory refresh around the difference between
unmounting and ejecting removable drives and the confirmation of the
common-sense point that a drive needs to not be mounted when you write
an image to it. In practice I think it actually worked, since the result
looked healthy when I mounted it, but the advice is good nonetheless)

Thanks all for your help. And now as a result of this exercise I've had
returned to me another machine which can be my new Buster toy :)

The other thing this has surfaced is all that noise in the logs when
writing using a motherboard-builtin USB2 socket. When I tried the
process in a USB3 socket provided by an add-in card, I didn't get all
that noise in the log with system call quotes and compaints about
systemd-udevd being blocked for too long. Interesting but I no longer
think evidence of an actual problem, as I now believe all image writes
worked correctly.

Mark

[Thomas Schmitt]

Hi,

Post by Mark Fletcher
~mark/Downloads/Win10_1809Oct_v2_Japanese_x64.iso -report_system_area plain
-report_el_torito plain
...
Media summary: 1 session, 2591375 data blocks, 5061m data, 631g free
Volume id : 'CCCOMA_X64FRE_JA-JP_DV9'
xorriso : NOTE : No System Area was loaded
El Torito catalog : 22 1
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 8 513
El Torito boot img : 2 UEFI y none 0x0000 0x00 1 515
El Torito img blks : 1 2
El Torito img blks : 2 2590860

There is indeed no partition table to see in the ISO.
So at least EFI won't recognize it as bootable from USB stick.

It has El Torito boot equipment for DVD. Usable with legacy BIOS and
with EFI.

Whether it has usable MBR boot code for old BIOS would have to
be checked by e.g. cprogram "file".
This is how it would lool like if there was a MBR signature:

$ file debian-9.3.0-amd64-netinst.iso
debian-9.3.0-amd64-netinst.iso: DOS/MBR boot sector ...

(This would not necessarily mean that it contains x86 boot code.
But at least it could. Then you could try CSM Legacy mode with your
EFI firmware.)

Post by Mark Fletcher
The only thing there that catches my untutored eye is the thing about
the El Torito boot information being currently set to be discarded --
doesn't sound healthy.
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded

It is only an announcement of xorriso that an ISO-to-ISO copy will not
preserve bootability with the current settings about boot equipment.
(Severity "NOTE" is rather harmless. "WARNING" and "SORRY" indicate minor
flaws. "FAILURE" and "FATAL" mean your xorriso run failed substantially.)

------------------------------------------------------------------------

If no boot equipment is present for hard-disk-like devices, then you
probably have a use case for something like Rufus
https://kb.iu.edu/d/bciz#rufus

But you may first try a hack:

We now know that the EFI boot image begins at 2048-bytes block 515.
In principle it will work as EFI System Partition too. (Question is
whether the software in it can work with anything else but DVD.)

So you could use a partition editor to create an MBR partition of type
"EF" which begins at 512-block 515 * 4 = 2060 and has 2,590,860 * 4 =
10,363,440 blocks.
(The EFI image is probably smaller. But El Torito can mark only sizes
up to 32 MiB or unlimited size. Microsoft decided for unlimited. So
the only limit is the ISO's end.)

MBR partition is less tricky than GPT. If it must be GPT, then create a
partition of the proposed start and size and Type GUID
C12A7328-F81F-11D2-BA4B-00A0C93EC93B . (Do this only if the ISO is already
copied to USB stick. Putting GPT into the image file could overwrite its
last few blocks by GPT backup.)

------------------------------------------------------------------------

In the end i wonder about the ISO's size of 5 GiB. Too much for a normal
single-layer DVD. One would have to use DVD+R DL or BD media.
Was this announced by the download site ?

(The "DV9" at the end of the Volume Id could be a hint for DVD+R DL.)


Have a nice day :)

Thomas

[deloptes]

Post by Thomas Schmitt
So you could use a partition editor to create an MBR partition of type
"EF" which begins at 512-block 515 * 4 = 2060 and has 2,590,860 * 4 =
10,363,440 blocks.
(The EFI image is probably smaller. But El Torito can mark only sizes
up to 32 MiB or unlimited size. Microsoft decided for unlimited. So
the only limit is the ISO's end.)
MBR partition is less tricky than GPT. If it must be GPT, then create a
partition of the proposed start and size and Type GUID
C12A7328-F81F-11D2-BA4B-00A0C93EC93B . (Do this only if the ISO is already
copied to USB stick. Putting GPT into the image file could overwrite its
last few blocks by GPT backup.)

don't forget that to create UEFI bootable partition, you need to boot in
UEFI. It does not work if you boot in legacy MBR - unfortunately - it took
me 1 day to find out :)

[Thomas Schmitt]

Hi,

Post by deloptes
don't forget that to create UEFI bootable partition, you need to boot in
UEFI. It does not work if you boot in legacy MBR - unfortunately - it took
me 1 day to find out :)

I doubt that this applies to the situation of Mark Fletcher.
The goal of the hack is not to create the content of the EFI partition but
only to mark its position and purpose by an entry in the partition table.

The partition editor should of course refrain from altering the partition
content. Therefore i'd try /sbin/fdisk rather than the extra smart ones,
which create new filesystems.


The problem which you mention could be interesting, too. How about a
sketch of what you tried, what failed, and what succeeded ?
(A new thread would keep this one on topic.)


Have a nice day :)

Thomas

[deloptes]

Post by Thomas Schmitt
The problem which you mention could be interesting, too. How about a
sketch of what you tried, what failed, and what succeeded ?
(A new thread would keep this one on topic.)

Perhaps I should start another thread, but it is somehow in the context of
this, because I was trying to setup UEFI bootable USB. All worked fine
until grub told me something I do not recall exactly at the moment, but
answers I found were pointing to the fact that you can not do grub
update/install of UEFI if you are not booted into UEFI.

regards

[Thomas Schmitt]

Hi,

Post by deloptes
I was trying to setup UEFI bootable USB. All worked fine
until grub told me something I do not recall exactly at the moment, but
answers I found were pointing to the fact that you can not do grub
update/install of UEFI if you are not booted into UEFI.

Post by Nicolas George
To edit UEFI variables, the computer need to have booted in UEFI mode.

But as said, the hack only tries to lure EFI into considering the block
range 2060 to 10365499 as (alternative) System Partition. It is a mere
partition table operation, no installation of a boot loader.

The loader and subsequent system are already prepared in the EFI partition
and the ISO. After EFI did its work of starting program \EFI\BOOT\BOOTX64.EFI
it depends on them whether they can deal with being on a not intended storage
medium. (The initrd of Debian ISOs has shell code which finds out the device
where the ISO is stored.)

The individual EFI firmware which shall act on the USB stick is actually
not determined when the ISO gets prepared. So there is no occasion or desire
to set non-volatile variables before the ISO gets booted.


Have a nice day :)

Thomas

[Pascal Hambourg]

Post by deloptes

Post by Thomas Schmitt
(A new thread would keep this one on topic.)

I agree.

Post by deloptes
Perhaps I should start another thread, but it is somehow in the context of
this, because I was trying to setup UEFI bootable USB.

No, it is a completely different topic.

Post by deloptes
answers I found were pointing to the fact that you can not do grub
update/install of UEFI if you are not booted into UEFI.

Short answer : this assertion is wrong.
Long answer : I will gladly develop if you start a new thread.

[Nicolas George]

Post by deloptes
don't forget that to create UEFI bootable partition, you need to boot in
UEFI.

That is absolutely not true. Partition data, UEFI or not, bootable or
not, are just octets on a medium. They could be created with an Atari if
Atari had USB plugs, that would not make any difference.

The vague truth behind your statement is:

To edit UEFI variables, the computer need to have booted in UEFI mode.

The UEFI variables, the contents of the computer's non-volatile internal
memory. Not the contents of the drive. They contain, amongst other
things, the default boot options. They are not used when selecting the
boot option manually.

Regards,

[deloptes]

Post by Nicolas George
That is absolutely not true. Partition data, UEFI or not, bootable or
not, are just octets on a medium. They could be created with an Atari if
Atari had USB plugs, that would not make any difference.
To edit UEFI variables, the computer need to have booted in UEFI mode.
The UEFI variables, the contents of the computer's non-volatile internal
memory. Not the contents of the drive. They contain, amongst other
things, the default boot options. They are not used when selecting the
boot option manually.

Yes, this is what I wanted to say - you are right. You can create the
partition with fdisk or alike, but grub refuses to install if it is not
booted in UEFI

[Joe]

On Sat, 04 May 2019 18:41:18 +0200

Post by deloptes

Post by Nicolas George
That is absolutely not true. Partition data, UEFI or not, bootable
or not, are just octets on a medium. They could be created with an
Atari if Atari had USB plugs, that would not make any difference.
To edit UEFI variables, the computer need to have booted in UEFI mode.
The UEFI variables, the contents of the computer's non-volatile
internal memory. Not the contents of the drive. They contain,
amongst other things, the default boot options. They are not used
when selecting the boot option manually.

Yes, this is what I wanted to say - you are right. You can create the
partition with fdisk or alike, but grub refuses to install if it is
not booted in UEFI

Datum: I bought a Win10 netbook six months ago. It doesn't do legacy.
It appeared that Stretch was up to the job, so I made a netinstall USB
stick, plugged it in and booted...

Just like a normal installation, and it even left Win10 bootable at the
end.

[Pascal Hambourg]

Post by deloptes

Post by Nicolas George
That is absolutely not true. Partition data, UEFI or not, bootable or
not, are just octets on a medium. They could be created with an Atari if
Atari had USB plugs, that would not make any difference.
To edit UEFI variables, the computer need to have booted in UEFI mode.
The UEFI variables, the contents of the computer's non-volatile internal
memory. Not the contents of the drive. They contain, amongst other
things, the default boot options. They are not used when selecting the
boot option manually.

Yes, this is what I wanted to say - you are right. You can create the
partition with fdisk or alike, but grub refuses to install if it is not
booted in UEFI

Again, this is not true. GRUB will install, but it will just not be able
to update EFI boot variables. Note that you do not need to update EFI
boot variables if you install GRUB in the removable media path
(--removable). At least with GRUB versions up to Stretch which relied on
efibootmgr to update EFI boot variables. Maybe this has changed with
Buster's GRUB version which does not rely on efibootmgr any more. Not
tested yet.

[Curt]

Post by Mark Fletcher

Post by Greg Wooledge

it auto-mounted.
cp <ISO file> /dev/sdf

You need the device NOT to be mounted when you do the cp. This may mean
you have to turn off your auto-mounter, or (better still) just log out of
your Desktop Environment entirely, and log in as root on a text console
for this operation.

I'm intervening here merely to point out that just because the user's
external usb device is auto-mounted does not mean that said device
cannot be unmounted by the usual methods (at least I have yet to
encounter Greg Wooledge's auto-mounter from Hell that will not permit
it).

Post by Mark Fletcher

Post by Greg Wooledge
If the device is mounted, that will interfere with the raw byte writing
you're doing. The results are unpredictable.

This makes sense to me; confession time -- I originally ejected the pen
drive when Gnome auto-mounted it, but then found I couldn't do anything
with the device at all, so concluded that contrary to my memory it
needed to be mounted. Web pages I'd found said nothing about unmounting
the device before writing, so again I thought my memory was faulty. What
I failed to consider was the difference between unmounting and ejecting.

[Greg Wooledge]

Post by Curt
I'm intervening here merely to point out that just because the user's
external usb device is auto-mounted does not mean that said device
cannot be unmounted by the usual methods (at least I have yet to
encounter Greg Wooledge's auto-mounter from Hell that will not permit
it).

I never said anything about not being able to unmount.

If a partition from a medium (USB or whatever) is mounted read-write,
during the time that you execute a "cp foo.iso /dev/sdx" command
to write a disk image to said medium, you are going to have problems
of the corruption kind, not of the "cannot unmount it" kind.

Unmounting the file system is going to write some information to the
medium in the place where the operating system thinks the file system
is. But that file system isn't there any more, because your cp (or dd
or whatever) command overwrote it. But the file system driver, upon
unmounting the file system, is supposed to write stuff -- flushing
the cache, setting the "this has been cleanly unmounted" flags, etc.
All of that stuff that it writes will corrupt whatever part of the ISO
image it happens to land on.

[Curt]

Post by Greg Wooledge

Post by Curt
I'm intervening here merely to point out that just because the user's
external usb device is auto-mounted does not mean that said device
cannot be unmounted by the usual methods (at least I have yet to
encounter Greg Wooledge's auto-mounter from Hell that will not permit
it).

I never said anything about not being able to unmount.

Actually, you said:

You need the device NOT to be mounted when you do the cp. This may mean
you have to turn off your auto-mounter, ...

I inferred from this you felt that in some instances auto-mounting would
preclude any subsequent unmounting, failing to conceive of another
reason the radical measure of disabling automounting entirely would be
required to ensure it.

or (better still) just log out of your Desktop Environment entirely,
and log in as root on a text console for this operation.

Root? Première nouvelle!

[An Liu]

Hello
from my experience
cp windows.iso /dev/sdf should work for windows version higher than win
7and not work for xp


What i usually do is the best following way rather tban cp or dd because it
preserve my disk table i only need do rm or not even you dont bother
install media in root partition tableleave it as in case you need it a
second timedata still can be add or remove as regular ones
mkdir /mnt/usb -p
mkdir /mnt/iso -p

1format the /dev/sdf1 as fat32
2mount windows iso either automount to /media/xxx or mount -o loop
windows.iso /mnt/iso
mount /dev/sdf1 /mnt/usb

3cp -r /mnt/iso/* /mnt/usb

and this device should be bootable from UEFI

hope it helps


== you cant see the following ==

1install from window.iso in kvm you should have 1 month trial before
activate
2download ms usb creator
3create media within windows 10
4destroy kvm prepend nothing happens

Hello
I'm trying to use Stretch to write a .ISO image to a USB device. The
image is the Windows 10 installer (please don't flame me! It's part of
an education project for my son!) which I downloaded from Microsoft, and
which they claim should be able to be written to a USB device. Microsoft
would have me write the ISO using a tool of theirs, but since I don't
have another Windows device that isn't possible. They say that in that
case the ISO can be written to a pen drive using OS-specific tools.
I'm attempting to test the image before booting the installer on the
final computer earmarked for sacrifice to this project. The computer I
am testing on has successfully booted from a pen drive before and the
pen drive I am using has been used to boot this computer before, albeit
not this image.
After downloading the .iso file, I plugged in the USB stick. Because it
had something recognisable on it already, it auto-mounted. It was
assigned device /dev/sdf and mounted somewhere under /media, I don't
remember the exact path.
cp <ISO file> /dev/sdf
and waited a while. Eventually the copy finished (the ISO is between 5
and 6 GB, the capacity of the drive is 16GB). Then I did
eject /dev/sdf
and after a long wait, that command came back with no errors. I then
removed the drive.
On plugging the drive back in, Stretch can recognise there is a
filesystem on it and mount it. I can see the usual efi structure for
booting etc.
BUT, the test computer refuses to recognise it as bootable. The BIOS can
evidently see the device is there and is an option to boot from, but
when I try it fails and falls back to the machine's internal hard disk.
If I disable booting from the hard disk in the BIOS, it fails to boot at
all with an error message essentially saying "give me something to boot
from".
There is some discussion on the internet suggesting that the pen drive
additionally needs to be marked as bootable. I thought that was an old
pre-GPT partitioning thing, and I also would have thought that if it
were relevant the .ISO image should contain the necessary settings, but
hey I'll try anything once... gparted was suggested as the tool to mark
the partition as bootable but when I fire up gparted it doesn't seem to
recognise the pen drive as it says the 16GB pen drive is "14.7GB
unnallocated" and says there is no partition table on it. This despite
the fact that it auto-mounts when I stick it in while Stretch is
running...
I'm confused whether the problem is in something I did or didn't do
while copying the ISO image, or if there is something I need to set in
the BIOS to get it to boot (I have a dim memory of fannying around with
various settings a very long time ago when I first got booting from USB
to work, and the CMOS battery on this motherboard has died at least once
since then). I'm extremely doubtful that the ISO image just doesn't
work, and I know for a fact that this computer can be persuaded to boot
from a pen drive and that this pen drive has been used successfully in
the past.
Any suggestions of what I could do to diagnose the problem?
Thanks in advance
Mark
--

Liu An

[Richard Owlett]

Hello
I'm trying to use Stretch to write a .ISO image to a USB device. The
image is the Windows 10 installer ... which I downloaded from Microsoft, and
which they claim should be able to be written to a USB device. ...

What was the URL?
I've just read this thread for the first time, reading it as a unit. I'm
concerned that Microsoft's context{poor_word?} may be significantly
different from the assumptions being made in the replies.

I'm attempting to test the image before booting the installer on the
final computer earmarked for sacrifice to this project. ...

Why use the term "sacrifice"?

Also, the OP said that this is part of an educational project.
Does that put any constraint on how useful some answers may be?

[Curt]

Post by Richard Owlett

Hello
I'm trying to use Stretch to write a .ISO image to a USB device. The
image is the Windows 10 installer ... which I downloaded from Microsoft, and
which they claim should be able to be written to a USB device. ...

What was the URL?
I've just read this thread for the first time, reading it as a unit. I'm
concerned that Microsoft's context{poor_word?} may be significantly
different from the assumptions being made in the replies.

I'm attempting to test the image before booting the installer on the
final computer earmarked for sacrifice to this project. ...

Why use the term "sacrifice"?

To make clear his abhorrence of that other OS (he's only in this for the
sake of the kids), so he won't be banished east of Eden where the
closed-source devil is rife.

Post by Richard Owlett
Also, the OP said that this is part of an educational project.
Does that put any constraint on how useful some answers may be?

I made a kind of pedagogical foray earlier myself, now that you mention
it.

[mick crane]

I've had success using http://www.linuxliveusb.com/
with various isos.
Last time tho', installing Buster, the setup, after booting from the
USB, was looking for a CD/DVD and so I had to use the USB to boot from
and the CD/DVD in the player for the installation.

mick