Mailing List Archive

LiveGUI USB Image
Hi there,

long time since I needed something to boot the pc. I see there is a
LiveGUI USB Image to download but the handbook does not mention it. How
to get a bootable USB stick?

Reagds
Re: LiveGUI USB Image [ In reply to ]
hitachi303 wrote:
> Hi there,
>
> long time since I needed something to boot the pc. I see there is a
> LiveGUI USB Image to download but the handbook does not mention it.
> How to get a bootable USB stick?
>
> Reagds
>
>

You can get it here:


https://www.gentoo.org/downloads/


I suspect most just use dd to put the iso on the stick.  You can use
Ventoy as well.  It allows you to put multiple ISOs on a single stick. 
I was made aware of it a while back and used it several times on another
rig.  It is awesome.  Just copy it over to a directory and boot it. 


https://www.ventoy.net/en/index.html


That thing is the best thing since sliced bread and frozen pizza. 
Instead of 4 or 5 USB sticks, I have one, with everything from memtest
to rescue images up to full distro install media. 

If you plan to use dd, this is the command I have in my notes. 


dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress


Replace the obvious bits. 

That help?

Dale

:-)  :-) 
Re: LiveGUI USB Image [ In reply to ]
On Saturday, 30 December 2023 21:41:40 GMT Dale wrote:
> hitachi303 wrote:
> > long time since I needed something to boot the pc. I see there is a
> > LiveGUI USB Image to download but the handbook does not mention it.
> > How to get a bootable USB stick?
>
> You can get it here:
>
> https://www.gentoo.org/downloads/
>
> I suspect most just use dd to put the iso on the stick.

I've alwas done that too, until I bought this new NUC i5, which wouldn't boot
from any of my USB sticks. I had to use an app to make the transfer to USB. I
forget what it was now. Nel B. can explain about ISO images and booting.

--->8

> If you plan to use dd, this is the command I have in my notes.
>
> dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress
>
> Replace the obvious bits.

I've tried a few values of block size over the years, but so far I haven't
noticed any difference. I haven't run any proper tests though.

--
Regards,
Peter.
Re: LiveGUI USB Image [ In reply to ]
>
> > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress
> >
> > Replace the obvious bits.
>
> I've tried a few values of block size over the years, but so far I haven't
> noticed any difference. I haven't run any proper tests though.
>

I think it's just that the default blocksize is (or was) very small (512
bytes?) so setting it to anything non-small helps a lot.

eg one example (from
https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204)
seems to show that most gains are in by around 16k. There's probably a lot
of testing noise in these results.

$ ./dd_obs_test.sh
block size : transfer rate
512 : 11.3 MB/s
1024 : 22.1 MB/s
2048 : 42.3 MB/s
4096 : 75.2 MB/s
8192 : 90.7 MB/s
16384 : 101 MB/s
32768 : 104 MB/s
65536 : 108 MB/s
131072 : 113 MB/s
262144 : 112 MB/s
524288 : 133 MB/s
1048576 : 125 MB/s
2097152 : 113 MB/s
4194304 : 106 MB/s
8388608 : 107 MB/s
16777216 : 110 MB/s
33554432 : 119 MB/s
67108864 : 134 MB/s
Re: LiveGUI USB Image [ In reply to ]
On Thursday, 4 January 2024 02:48:13 GMT Adam Carter wrote:
> > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress
> > >
> > > Replace the obvious bits.
> >
> > I've tried a few values of block size over the years, but so far I haven't
> > noticed any difference. I haven't run any proper tests though.
>
> I think it's just that the default blocksize is (or was) very small (512
> bytes?) so setting it to anything non-small helps a lot.
>
> eg one example (from
> https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with
> -diskdump-dd#234204) seems to show that most gains are in by around 16k.
> There's probably a lot of testing noise in these results.
>
> $ ./dd_obs_test.sh
> block size : transfer rate
> 512 : 11.3 MB/s
> 1024 : 22.1 MB/s
> 2048 : 42.3 MB/s
> 4096 : 75.2 MB/s
> 8192 : 90.7 MB/s
> 16384 : 101 MB/s
> 32768 : 104 MB/s
> 65536 : 108 MB/s
> 131072 : 113 MB/s
> 262144 : 112 MB/s
> 524288 : 133 MB/s
> 1048576 : 125 MB/s
> 2097152 : 113 MB/s
> 4194304 : 106 MB/s
> 8388608 : 107 MB/s
> 16777216 : 110 MB/s
> 33554432 : 119 MB/s
> 67108864 : 134 MB/s

Interesting. I think I'll stick to my usual 64MB block size.

--
Regards,
Peter.
RE: LiveGUI USB Image [ In reply to ]
>-----Original Message-----
>From: Peter Humphrey <peter@prh.myzen.co.uk>
>Sent: Thursday, January 4, 2024 5:01 AM
>To: gentoo-user@lists.gentoo.org
>Subject: Re: [gentoo-user] LiveGUI USB Image
>
>On Thursday, 4 January 2024 02:48:13 GMT Adam Carter wrote:
>> > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress
>> > >
>> > > Replace the obvious bits.
>> >
>> > I've tried a few values of block size over the years, but so far I
>> > haven't noticed any difference. I haven't run any proper tests though.
>>
>> I think it's just that the default blocksize is (or was) very small
>> (512
>> bytes?) so setting it to anything non-small helps a lot.
>>
>> eg one example (from
>> https://superuser.com/questions/234199/good-block-size-for-disk-clonin
>> g-with
>> -diskdump-dd#234204) seems to show that most gains are in by around 16k.
>> There's probably a lot of testing noise in these results.
>>
>> $ ./dd_obs_test.sh
>> block size : transfer rate
>> 512 : 11.3 MB/s
>> 1024 : 22.1 MB/s
>> 2048 : 42.3 MB/s
>> 4096 : 75.2 MB/s
>> 8192 : 90.7 MB/s
>> 16384 : 101 MB/s
>> 32768 : 104 MB/s
>> 65536 : 108 MB/s
>> 131072 : 113 MB/s
>> 262144 : 112 MB/s
>> 524288 : 133 MB/s
>> 1048576 : 125 MB/s
>> 2097152 : 113 MB/s
>> 4194304 : 106 MB/s
>> 8388608 : 107 MB/s
>> 16777216 : 110 MB/s
>> 33554432 : 119 MB/s
>> 67108864 : 134 MB/s
>
>Interesting. I think I'll stick to my usual 64MB block size.
>
>--
>Regards,
>Peter.

So, basically the default is 512, and if you're copying to something where the hardware block size is larger than that (4096 is common on a lot of things these days) then every block on the physical device has to be rewritten multiple times. (Eight times in the example case.)

Needless to say, that's... rather slow. Also rather hard on your device.

Once you get larger than the physical block size, as long as you have an even multiple of the physical block size, then any additional gains come solely from the IO scheduler being able to make slightly more intelligent choices with larger chunks.

LMP