Re: Trouble making bootable USB from ISO image

[Curt]

On 2019-05-06, Greg Wooledge  wrote:
> On Sat, May 04, 2019 at 09:54:52AM -, Curt wrote:
>> 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!

Re: Trouble making bootable USB from ISO image

[Greg Wooledge]

On Sat, May 04, 2019 at 09:54:52AM -, Curt wrote:
> 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.

Re: Trouble making bootable USB from ISO image

[Pascal Hambourg]

Le 04/05/2019 à 18:41, deloptes a écrit :

Nicolas George wrote:


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.


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.

Re: Trouble making bootable USB from ISO image

[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
--
Key ID4BFEBB31

RESOLVED: Trouble making bootable USB from ISO image

[Mark Fletcher]

On Sat, May 04, 2019 at 05:03:42AM +, Russell L. Harris wrote:
> On Sat, May 04, 2019 at 11:39:39AM +0900, Mark Fletcher wrote:
> 
> 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.

> 
> 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 
> " or with "dd if= of= 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.

> 
> 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)

> 
> 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

Re: Trouble making bootable USB from ISO image

[Joe]

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

> Nicolas George wrote:
> 
> > 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.  
> 
> 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.

-- 
Joe

Re: Trouble making bootable USB from ISO image

[deloptes]

Nicolas George wrote:

> 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.

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

Re: Trouble making bootable USB from ISO image

[Curt]

On 2019-05-04, Richard Owlett  wrote:
>
>
> On 05/03/2019 11:50 AM, Mark Fletcher wrote:
>> 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.

> 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.

-- 
The boys at first were very polite about my medals and asked me what I had done
to get them. I showed them the papers, which were written in very beautiful
language and full of fratellanza and abnegazione, but which really said, with
the adjectives removed, that I had been given the medals because I was 
an American. - "Another Country"

Re: Trouble making bootable USB from ISO image

[Richard Owlett]

On 05/03/2019 11:50 AM, Mark Fletcher wrote:

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?

Re: Trouble making bootable USB from ISO image

[Pascal Hambourg]

Le 04/05/2019 à 11:21, deloptes a écrit :

Thomas Schmitt wrote:


(A new thread would keep this one on topic.)


I agree.


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.


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.

Re: Trouble making bootable USB from ISO image

[Curt]

On 2019-05-04, Mark Fletcher  wrote:
> On Fri, May 03, 2019 at 12:54:17PM -0400, Greg Wooledge wrote:
>> On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
>> > it auto-mounted.
>> 
>> > So as root I did:
>> > 
>> > cp  /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). 

>> 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.
>

-- 
The boys at first were very polite about my medals and asked me what I had done
to get them. I showed them the papers, which were written in very beautiful
language and full of fratellanza and abnegazione, but which really said, with
the adjectives removed, that I had been given the medals because I was 
an American. - "Another Country"

Re: Trouble making bootable USB from ISO image

[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












On Fri, May 3, 2019 at 18:50 Mark Fletcher  wrote:

> 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.
>
> So as root I did:
>
> cp  /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

Re: Trouble making bootable USB from ISO image

[Thomas Schmitt]

Hi,

deloptes wrote:
> 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.

This is plausible together with Nicolas George's statement:
> > 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

Re: Trouble making bootable USB from ISO image

[deloptes]

Thomas Schmitt wrote:

> 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

Re: Trouble making bootable USB from ISO image

[Nicolas George]

deloptes (12019-05-04):
> 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,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Trouble making bootable USB from ISO image

[Thomas Schmitt]

Hi,

deloptes wrote:
> 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

Re: Trouble making bootable USB from ISO image

[deloptes]

Thomas Schmitt wrote:

> 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 :)

Re: Trouble making bootable USB from ISO image

[Thomas Schmitt]

Hi,

Mark Fletcher wrote:
> root@kazuki:/home/mark# xorriso -indev
> ~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  0x  0x00  8 513
> El Torito boot img :   2  UEFI  y   none  0x  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.)


> 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

Re: Trouble making bootable USB from ISO image

[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 
" or with "dd if= of= 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.

Re: Trouble making bootable USB from ISO image

[Mark Fletcher]

On Fri, May 03, 2019 at 12:54:17PM -0400, Greg Wooledge wrote:
> On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
> > it auto-mounted.
> 
> > So as root I did:
> > 
> > cp  /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  /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:

root@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  0x  0x00  8 513
El Torito boot img :   2  UEFI  y   none  0x  0x00  1 515
El Torito 

Trouble making bootable USB from ISO image

[Thomas Schmitt]

Hi,

Mark Fletcher wrote:
> 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

Re: Trouble making bootable USB from ISO image

[john doe]

On 5/3/2019 7:29 PM, Paul Sutton wrote:
>
> On 03/05/2019 18:24, James Medeiros wrote:
>> 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= of=/dev/sdf bs=8M
>>
>>
>>
>> On Fri, May 3, 2019 at 12:54 PM Greg Wooledge > > wrote:
>>
>> On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
>> > it auto-mounted.
>>
>> > So as root I did:
>> >
>> > cp  /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 

--
John Doe

Re: Trouble making bootable USB from ISO image

[Paul Sutton]

On 03/05/2019 18:24, James Medeiros wrote:
> 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= of=/dev/sdf bs=8M
>
>
>
> On Fri, May 3, 2019 at 12:54 PM Greg Wooledge  > wrote:
>
> On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
> > it auto-mounted.
>
> > So as root I did:
> >
> > cp  /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

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

Re: Trouble making bootable USB from ISO image

[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= of=/dev/sdf bs=8M



On Fri, May 3, 2019 at 12:54 PM Greg Wooledge  wrote:

> On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
> > it auto-mounted.
>
> > So as root I did:
> >
> > cp  /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.
>
>

Re: Trouble making bootable USB from ISO image

[Greg Wooledge]

On Sat, May 04, 2019 at 01:50:31AM +0900, Mark Fletcher wrote:
> it auto-mounted.

> So as root I did:
> 
> cp  /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.

Trouble making bootable USB from ISO image

[Mark Fletcher]

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.

So as root I did:

cp  /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