Web lists-archives.com

Re: Trouble making bootable USB from ISO image




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

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