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
