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