Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208078 > unrolled thread

Re: Trouble making bootable USB from ISO image

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Trouble making bootable USB from ISO image Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-03 19:00 +0200
    Re: Trouble making bootable USB from ISO image Paul Sutton <zleap@disroot.org> - 2019-05-03 19:30 +0200
      Re: Trouble making bootable USB from ISO image john doe <johndoe65534@mail.com> - 2019-05-03 19:40 +0200
    Re: Trouble making bootable USB from ISO image James Medeiros <james.medeiros@gmail.com> - 2019-05-03 19:30 +0200
    Re: Trouble making bootable USB from ISO image Mark Fletcher <mark27q1@gmail.com> - 2019-05-04 04:50 +0200
      Re: Trouble making bootable USB from ISO image "Russell L. Harris" <rlharris@oplink.net> - 2019-05-04 07:30 +0200
        RESOLVED: Trouble making bootable USB from ISO image Mark Fletcher <mark27q1@gmail.com> - 2019-05-05 05:30 +0200
      Re: Trouble making bootable USB from ISO image "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-04 08:40 +0200
        Re: Trouble making bootable USB from ISO image deloptes <deloptes@gmail.com> - 2019-05-04 09:20 +0200
          Re: Trouble making bootable USB from ISO image "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-04 09:30 +0200
            Re: Trouble making bootable USB from ISO image deloptes <deloptes@gmail.com> - 2019-05-04 11:30 +0200
              Re: Trouble making bootable USB from ISO image "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-04 11:50 +0200
              Re: Trouble making bootable USB from ISO image Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-05-04 14:40 +0200
          Re: Trouble making bootable USB from ISO image Nicolas George <george@nsup.org> - 2019-05-04 10:20 +0200
            Re: Trouble making bootable USB from ISO image deloptes <deloptes@gmail.com> - 2019-05-04 18:50 +0200
              Re: Trouble making bootable USB from ISO image Joe <joe@jretrading.com> - 2019-05-04 21:30 +0200
              Re: Trouble making bootable USB from ISO image Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-05-05 11:00 +0200
      Re: Trouble making bootable USB from ISO image Curt <curty@free.fr> - 2019-05-04 12:00 +0200
        Re: Trouble making bootable USB from ISO image Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-06 14:50 +0200
          Re: Trouble making bootable USB from ISO image Curt <curty@free.fr> - 2019-05-06 16:10 +0200

#208078 — Re: Trouble making bootable USB from ISO image

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.

[toc] | [next] | [standalone]

#208081

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=<ISO file> of=/dev/sdf bs=8M
>
>
>
> On Fri, May 3, 2019 at 12:54 PM Greg Wooledge <wooledg@eeg.ccf.org
> <mailto:wooledg@eeg.ccf.org>> 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.
>

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

[toc] | [prev] | [next] | [standalone]

#208083

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=<ISO file> of=/dev/sdf bs=8M
>>
>>
>>
>> On Fri, May 3, 2019 at 12:54 PM Greg Wooledge <wooledg@eeg.ccf.org
>> <mailto:wooledg@eeg.ccf.org>> 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.
>>
>
> 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

[toc] | [prev] | [next] | [standalone]

#208082

[Multipart message — attachments visible in raw view] — view raw

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



On Fri, May 3, 2019 at 12:54 PM Greg Wooledge <wooledg@eeg.ccf.org> 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.
>
>

[toc] | [prev] | [next] | [standalone]

#208096

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

[toc] | [prev] | [next] | [standalone]

#208098

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.

[toc] | [prev] | [next] | [standalone]

#208175 — RESOLVED: Trouble making bootable USB from ISO image

On Sat, May 04, 2019 at 05:03:42AM +0000, 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 <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.

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

[toc] | [prev] | [next] | [standalone]

#208099

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


> 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

[toc] | [prev] | [next] | [standalone]

#208101

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

[toc] | [prev] | [next] | [standalone]

#208102

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

[toc] | [prev] | [next] | [standalone]

#208107

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

[toc] | [prev] | [next] | [standalone]

#208108

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

[toc] | [prev] | [next] | [standalone]

#208113

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.

[toc] | [prev] | [next] | [standalone]

#208106

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#208126

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

[toc] | [prev] | [next] | [standalone]

#208144

On Sat, 04 May 2019 18:41:18 +0200
deloptes <deloptes@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#208181

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.

[toc] | [prev] | [next] | [standalone]

#208110

On 2019-05-04, Mark Fletcher <mark27q1@gmail.com> 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 <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). 

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

[toc] | [prev] | [next] | [standalone]

#208266

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

[toc] | [prev] | [next] | [standalone]

#208279

On 2019-05-06, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Sat, May 04, 2019 at 09:54:52AM -0000, 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!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web