[gentoo-user] repoman the optimist

[Ian Zimmerman]

I am preparing some home made ebuilds and I run "repoman manifest" as
part of the process.  repoman downloads the upstream tarball for the
package from the SRC_URI location, but only after trying the distfiles
directory on all servers in my PORTAGE_MIRRORS.  This software is not
packaged by gentoo, so this always fails and it amounts to a useless
delay for me, and perhaps an annoyance for the servers.  How can I
disable it and make repoman go straight to the upstream location?

-- 
Ian

[gentoo-user] Re: For what is emerge waiting for...?

[Nikos Chantziaras]

On 05/04/2020 22:10, tu...@posteo.de wrote:

[...]
I start emerge with a bunch of packages to compile and
install.

And it happens from time to time that all cores seem to be
on holiday: No load at all. And emerge sits there and waits...
And the harddisk is not busy at all...no blinkenlights,
nothing.

Would it be possible, that there is kind of temporary
dead lock of some kind...when emerge is started with more
then one core?


It would have been helpful if you posted the output of emerge at the 
point it hangs.

Re: [gentoo-user] Re: Why busybox?

[Neil Bothwick]

On Sun, 5 Apr 2020 12:56:13 -0700, Ian Zimmerman wrote:

> The true reason I want to avoid it is that portage keeps spamming me
> about the configuration - handled by saveconfig or something.  It
> happens every time it is rebuild and I don't know how to stop it.

Read the spam, it tells you what to do ;-)


-- 
Neil Bothwick

The trouble with doing something right the first time is that nobody
appreciates how difficult it was.


pgph3yOM82R4b.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] For what is emerge waiting for...?

[tastytea]

On Sun, 5 Apr 2020 22:13:57 +0200 
Stefan Schmiedl  wrote:

> "tu...@posteo.de" , 05.04.2020, 21:58:
> 
> > if emerge encounters a have-to-use-one-core-onlu ebiuld and that one
> > is not constantlu writing to the disk I would expect one core busy
> > at least.  
> 
> > But no...nothing...as I said: All cores on holidays...:)  
> 
> I ran into this a few times when some host was unresponsive,
> so a package could not be downloaded, hence emerge did not
> have anything to build.
> 
> Check with htop's tree view or "ps faux" if emerge
> has a wget child process.
> 
> s.

The fetch process writes a log to /var/log/emerge-fetch.log. If
fetching a package is the problem, you should see it there.

tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpBq_S2xbJWT.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Why busybox?

[Jack]

On 2020.04.05 16:03, Mark Knecht wrote:
On Sun, Apr 5, 2020 at 10:54 AM Ian Zimmerman   
wrote:

>
> Why does portage insist on installing busybox for me?
>
> As far as I know the only use for it on a desktop system is for
> initramfs.  I have no initramfs, therefore I have no need for  
busybox.
> I unmerged it and nothing bad happened except for a warning from  
portage

> that it is part of my profile set.  I went ahead and ignored the
> warning.
>
> But now I updated the tree and emerge -p shows it will be installed
> again.  Why is that?  The only reverse dependencies are virtuals  
which

> are satisfied in other ways, like virtual/awk.  So is it the profile
> thing?  But I have done the same with other profile packages  
(notably

> editors/nano) and those are _not_ coming back.
>
> --
> Ian

emerge is your friend. Something like

emerge -p -e

should. I believe, tell you where every package dependency comes from.

It's not always fun to read but the answer to your question should be  
there.


- Mark
I find "emerge -p -c busybox" even easier, and it tells me busybox is  
required by @system.


Jack

Re: [gentoo-user] Why busybox?

[Mark Knecht]

On Sun, Apr 5, 2020 at 1:19 PM Dale  wrote:

> Mark Knecht wrote:
>
>
>
> On Sun, Apr 5, 2020 at 10:54 AM Ian Zimmerman 
> wrote:
> >
> > Why does portage insist on installing busybox for me?
> >
> > As far as I know the only use for it on a desktop system is for
> > initramfs.  I have no initramfs, therefore I have no need for busybox.
> > I unmerged it and nothing bad happened except for a warning from portage
> > that it is part of my profile set.  I went ahead and ignored the
> > warning.
> >
> > But now I updated the tree and emerge -p shows it will be installed
> > again.  Why is that?  The only reverse dependencies are virtuals which
> > are satisfied in other ways, like virtual/awk.  So is it the profile
> > thing?  But I have done the same with other profile packages (notably
> > editors/nano) and those are _not_ coming back.
> >
> > --
> > Ian
>
> emerge is your friend. Something like
>
> emerge -p -e
>
> should. I believe, tell you where every package dependency comes from.
>
> It's not always fun to read but the answer to your question should be
> there.
>
> - Mark
>
>
>
> I usually do a emerge -et either -p or -a then package name to get a tree
> list of what it depends on and what is pulling it in.  On some packages
> tho, it can get rather long.  Example:
>
> emerge -etp firefox
>
> or
>
> emerge -eta firefox
>
> Doesn't either one of those q commands or equery do this as well???
>
> Whichever works.  ;-)
>
> Dale
>
> :-)  :-)
>
>
> Yes, I forgot to add the 'tree' function. Thanks!

Re: [gentoo-user] Re: Why busybox?

[Ashley Dixon]

On Sun, Apr 05, 2020 at 12:56:13PM -0700, Ian Zimmerman wrote:
> As for rescue scenarios, that has been obsolete for a long time. For at least
> 10 years now

It is still used in some rescue situations, for example, an initramfs panic.
https://askubuntu.com/q/137655/ (This post was eight years ago but is still
applicable today. I still can't believe 2012 was almost a decade ago; it feels
like yesterday...)

> And this is a desktop.  BTW, I'm curious - are there really embedded
> systems, especially ones with extreme limitations, running gentoo?

I have seen them around. There used to be this great machine by Marvell called a
"SheevaPlug", and whilst its limitations weren't _extreme_, it could certainly
be classed as "embedded" by some. Think a power-line networking device, but a
full computer ! See [1], [2], and [3].

Anyway, that came with some peculiar variant of Linux with some proprietary
stuff on, which I (along with almost every other user, I assume), replaced with
a bare Gentoo installation. There was a moderately-sized mailing list a few
years ago which was dedicated to Gentoo on the Sheeva, although I think the
domain, and thus archives, have been lost to history.

> virtuals are another area which I need to study, sigh

They're not very intuitive, but just one of those things that you learn about
naturally while casually using Gentoo over a number of years.

[1] https://en.wikipedia.org/wiki/SheevaPlug
[2] https://wiki.gentoo.org/wiki/Embedded_Handbook/Boards/Marvell_Sheevaplug
[3] 
https://web.archive.org/web/20140717151031/https://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature

Re: [gentoo-user] Why busybox?

[Dale]

Mark Knecht wrote:
>
>
> On Sun, Apr 5, 2020 at 10:54 AM Ian Zimmerman  > wrote:
> >
> > Why does portage insist on installing busybox for me?
> >
> > As far as I know the only use for it on a desktop system is for
> > initramfs.  I have no initramfs, therefore I have no need for busybox.
> > I unmerged it and nothing bad happened except for a warning from portage
> > that it is part of my profile set.  I went ahead and ignored the
> > warning.
> >
> > But now I updated the tree and emerge -p shows it will be installed
> > again.  Why is that?  The only reverse dependencies are virtuals which
> > are satisfied in other ways, like virtual/awk.  So is it the profile
> > thing?  But I have done the same with other profile packages (notably
> > editors/nano) and those are _not_ coming back.
> >
> > --
> > Ian
>
> emerge is your friend. Something like 
>
> emerge -p -e
>
> should. I believe, tell you where every package dependency comes from.
>
> It's not always fun to read but the answer to your question should be
> there.
>
> - Mark
>


I usually do a emerge -et either -p or -a then package name to get a
tree list of what it depends on and what is pulling it in.  On some
packages tho, it can get rather long.  Example:

emerge -etp firefox

or

emerge -eta firefox

Doesn't either one of those q commands or equery do this as well???

Whichever works.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] For what is emerge waiting for...?

[Stefan Schmiedl]

"tu...@posteo.de" , 05.04.2020, 21:58:

> if emerge encounters a have-to-use-one-core-onlu ebiuld and that one
> is not constantlu writing to the disk I would expect one core busy
> at least.

> But no...nothing...as I said: All cores on holidays...:)

I ran into this a few times when some host was unresponsive,
so a package could not be downloaded, hence emerge did not
have anything to build.

Check with htop's tree view or "ps faux" if emerge
has a wget child process.

s.

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

On 04/05 08:41, J. Roeleveld wrote:
> On 5 April 2020 19:12:45 CEST, tu...@posteo.de wrote:
> >Hi,
> >
> >currentlu I am preparing a new Gentoo Linux by compiling all
> >the application I had on my old system.
> >
> >Due to delivery problems (corona) my SSD was delivered today
> >(or yesterday...it depends...;) .
> >
> >When the whole compilation has finished and the system boots it
> >needs to be transfered to the SSD.
> >
> >The SSD has a heat spreader...so it gets hot, when used.
> >
> >Is it wise to copy the whole root system to the SSD in one go
> >in respect to a not so healthy heat increase?
> >
> >And if not...how can I copy the root system in portions
> >to the SSD and do not miss anything?
> >
> >Are there SDD-friendly and SSD-unfriendlu methods of copying
> >greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> >What is recommended here?
> >
> >Thanks a lot for any help for a SSD newbie in advance!
> >
> >Cheers! And stay heathy!
> >Meino
> 
> I have been using SSDs for over 7 years now and never worried about them 
> overheating.
> In my opinion, if the drive can't handle a copy operation of 20GB (how much 
> bigger is your root partition?) it should be replaced from day one.
> 
> I only keep the portage compile dir and browser caches in RAM, the rest stays 
> on the SSD. And as I mentioned in a previous thread about SSDs, I only had 
> one failure after 6.5 years. (That drive also had SWAP on it and I didn't 
> offload the browser caches yet on that one).
> 
> Like Mark said, it is good to keep an eye on it, but if you use decent brand 
> SSDs (Samsung and Intel), you should be able to expect 5+ years of heavy 
> usage.
> 
> --
> Joost
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 


Hi,

I found a minute ago:

https://www.phoronix.com/scan.php?page=news_item=2020-Linux-Kernel-SATA-Temps

Cheers!
Meino

[gentoo-user] Re: simple image annotation software

[Grant Edwards]

On 2020-04-05, Urs Schütz  wrote:
> On 2020-04-02 15:57, Grant Edwards wrote:
[...]
>> I installed flameshot (required no additional packages be installed).
>> 
>> It can not be used to annotate existing image files.  There's a long
>> list of requests for that feature on the GitHub site, but apparently
>> no progress on that front.  According to some of those comments,
>> shutter can do it.
>> 
>> Personally, I don't really "get" the need for the capture
>> functionality. ImageMagick's 'import' command works for me...
>
> What about displaying an image and taking a screenshot? To clumpsy?

That doesn't work if the image size is larger than the display (which
is generally true for digital photos these days).

--
Grant

[gentoo-user] Re: Copying root to SSD in one go...a good idea...or?

[Grant Edwards]

On 2020-04-05, Mark Knecht  wrote:

> If copying 100GB causes too much heat watching smartctl will show you
> before it gets too hot and you can stop it.

If your SSD really can't handle large data transfers without damage,
I'd get a different one.  Copying a few hundred GB in one go golly
well better be a use case considered by the designer/manufacturer.  If
not, they're utterly incompetent and you shouldn't buy their products.

However, if do want to control the rate at which files are copied,
rsync has a --bwlimit option. But, the description of that option
specifically says it's for controlling bandwidth usage on "the
socket", so perhaps it's ineffective for local copies.

--
Grant

Re: [gentoo-user] Why busybox?

[Mark Knecht]

On Sun, Apr 5, 2020 at 10:54 AM Ian Zimmerman  wrote:
>
> Why does portage insist on installing busybox for me?
>
> As far as I know the only use for it on a desktop system is for
> initramfs.  I have no initramfs, therefore I have no need for busybox.
> I unmerged it and nothing bad happened except for a warning from portage
> that it is part of my profile set.  I went ahead and ignored the
> warning.
>
> But now I updated the tree and emerge -p shows it will be installed
> again.  Why is that?  The only reverse dependencies are virtuals which
> are satisfied in other ways, like virtual/awk.  So is it the profile
> thing?  But I have done the same with other profile packages (notably
> editors/nano) and those are _not_ coming back.
>
> --
> Ian

emerge is your friend. Something like

emerge -p -e

should. I believe, tell you where every package dependency comes from.

It's not always fun to read but the answer to your question should be there.

- Mark

Re: [gentoo-user] For what is emerge waiting for...?

[tuxic]

On 04/05 02:41, Dale wrote:
> tu...@posteo.de wrote:
> > Hi,
> >
> > no critism or anything else negative implied here...
> > ,..I am just asking out of coriosity:
> >
> > This day I am busy compiling all the application,
> > which are installed on my old system.
> >
> > I gave emerge 12 threads and 6 cores to do its work
> > (The CPU is a 6 core one).
> >
> > I start emerge with a bunch of packages to compile and
> > install.
> >
> > And it happens from time to time that all cores seem to be 
> > on holiday: No load at all. And emerge sits there and waits...
> > And the harddisk is not busy at all...no blinkenlights,
> > nothing.
> >
> > Would it be possible, that there is kind of temporary
> > dead lock of some kind...when emerge is started with more
> > then one core?
> >
> > What else than writing to disk and using the cores?
> >
> > Cheers!
> > Meino
> 
> I have seen this too. I read ages ago that some packages don't like
> parallel jobs so the dev sets it to 1 or 2 depending on what works best
> to limit those and build failures.  I don't know if that still applies
> to many packages or not but it is one possibility.  I think it is set in
> the ebuild so one may could look and see if that is the case.
> 
> Another option, it could be something the build process is doing that
> can't be done in parallel and is set by upstream.  It may not be in the
> ebuild but is in the sources itself.  It does seem to be a bottleneck
> but if it is set that way, there may be a good reason.  When compiling,
> I like to see my CPU utilized to the max but if it isn't possible, then
> I let it do its thing.  I know LOo does some strange things when it is
> compiling.  It will compile for a long time with little memory usage but
> all CPU cores at the max, even tho the work space is in tmpfs, and then
> all of a sudden, it starts eating memory until it is using several GBs. 
> Then it compiles some more and starts the install process.  I have no
> idea what makes it do that but it's the usual thing for LOo.
> 
> I'm sure someone else will have more ideas. 
> 
> Dale
> 
> :-)  :-) 
> 
> P. S. Back to the garden.  We supposed to stay home anyway so I'm taking
> down the electric fence, posts and getting ready to plow.  Dang it's wet
> out there tho.  At least I have a lift disc this year tho.  Maybe I
> won't get stuck. :/
> 
> 

Hi Dale,

if emerge encounters a have-to-use-one-core-onlu ebiuld and that one
is not constantlu writing to the disk I would expect one core busy
at least.

But no...nothing...as I said: All cores on holidays...:)

Cheers!
Meino

Re: [gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?

[Jack]

On 4/5/20 1:41 PM, Ian Zimmerman wrote:

On 2020-04-04 20:03, tu...@posteo.de wrote:


Wouldn't transferring the world file be enough?

Is it?

As far as I know, for having the same packages pulled in, this
is all that matters (plus possibly @world_sets as Neil mentions).

Of course you have all sorts of other configuration to replicate,
including portage's.  That's what git is for :-P.
I suspect those portage config files become even more important if you 
have any unstable (~) packages installed.  If a package has no stable 
versions in the tree, then I don't think it will get installed at all, 
without keywording it.  Even more true if you have a masked package 
installed.


Jack

[gentoo-user] Re: Why busybox?

[Ian Zimmerman]

On 2020-04-05 19:45, Ashley Dixon wrote:

> > Why does portage insist on installing busybox for me?
> 
> BusyBox is just a minimal set of utilities which would be useful for
> rescuing a system, or to be used on an embedded system with extreme
> limitations. There's not really any reason to remove this, but if you
> insist...

As for rescue scenarios, that has been obsolete for a long time.  For at
least 10 years now, whenever I need to rescue myself I boot from a
separate medium that is normally offline, a CD, an SD card or a thumb
drive.  And I did the same even when I had an initramfs.

And this is a desktop.  BTW, I'm curious - are there really embedded
systems, especially ones with extreme limitations, running gentoo?

> Read more about profiles at [1]; a guide to making custom profiles can
> be found as a subsection.

Indeed, profiles are a big hole in my gentoo knowledge.  Thanks for the
pointer.

> If you really don't want to have Portage install BusyBox, see the
> --exclude option of emerge. But again, there's really no need to
> remove BusyBox unless you're _very_ short on disk space.

The true reason I want to avoid it is that portage keeps spamming me
about the configuration - handled by saveconfig or something.  It
happens every time it is rebuild and I don't know how to stop it.

BTW, I found why app-editor/nano is different.  It is not part of the
profile set itself, it is just that it happens to satisfy virtual/editor
which is in the profile set.

virtuals are another area which I need to study, sigh

-- 
Ian

Re: [gentoo-user] For what is emerge waiting for...?

[tuxic]

On 04/05 08:38, Neil Bothwick wrote:
> On Sun, 5 Apr 2020 21:10:57 +0200, tu...@posteo.de wrote:
> 
> > And it happens from time to time that all cores seem to be 
> > on holiday: No load at all. And emerge sits there and waits...
> > And the harddisk is not busy at all...no blinkenlights,
> > nothing.
> 
> Is $PORTAGE_TMPDIR on a ramdisk?
> 

no...it is planned for the new system, when that one (or better the
mount point)  is on the SSD...

> 
> -- 
> Neil Bothwick
> 
> I'm Bugs Bunny of Borg.  What's up Collective?

Re: [gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?

[Jack]

On 4/5/20 1:41 PM, Ian Zimmerman wrote:

On 2020-04-04 20:03, tu...@posteo.de wrote:


Wouldn't transferring the world file be enough?

Is it?

As far as I know, for having the same packages pulled in, this
is all that matters (plus possibly @world_sets as Neil mentions).

Of course you have all sorts of other configuration to replicate,
including portage's.  That's what git is for :-P.


I suspect those portage config files become even more important if you 
have any unstable (~) packages installed.  If a package has no stable 
versions in the tree, then I don't think it will get installed at all, 
without keywording it.  Even more true if you have a masked package 
installed.


Jack

Re: [gentoo-user] Re: simple image annotation software

[Urs Schütz]

On 2020-04-02 15:57, Grant Edwards wrote:

On 2020-04-02, Grant Edwards  wrote:

On 2020-04-02, Ashley Dixon  wrote:


If your original images are screenshots, I'd recommend 'flameshot'.


They're not.  They're jpeg files produced by running photos though
some Imagemagick 'convert' operations.  Does that mean flameshot can't
be used to annotate them?


I installed flameshot (required no additional packages be installed).

It can not be used to annotate existing image files.  There's a long
list of requests for that feature on the GitHub site, but apparently
no progress on that front.  According to some of those comments,
shutter can do it.

Personally, I don't really "get" the need for the capture
functionality. ImageMagick's 'import' command works for me...

--
Grant


What about displaying an image and taking a screenshot? To clumpsy?
--
Urs

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Dale]

Neil Bothwick wrote:
> On Sun, 5 Apr 2020 14:09:16 -0500, Dale wrote:
>
>> I've used the watch command but don't quite get it yet.  With the
>> command below, how would watch be added to that to make it update every
>> set number of seconds, say 10 seconds or so?
>>
>> smartctl -a /dev/sdd | grep Temp
> watch -n 10 '(smartctl -a /dev/sdd | grep Temp)'
>
>


A, I tried to add it my way but it didn't work.  I didn't have the '
and ( ) in there tho.  Me makes a note on that.  ;-) 

Thanks much. 

Dale

:-)  :-) 

Re: [gentoo-user] For what is emerge waiting for...?

[Dale]

tu...@posteo.de wrote:
> Hi,
>
> no critism or anything else negative implied here...
> ,..I am just asking out of coriosity:
>
> This day I am busy compiling all the application,
> which are installed on my old system.
>
> I gave emerge 12 threads and 6 cores to do its work
> (The CPU is a 6 core one).
>
> I start emerge with a bunch of packages to compile and
> install.
>
> And it happens from time to time that all cores seem to be 
> on holiday: No load at all. And emerge sits there and waits...
> And the harddisk is not busy at all...no blinkenlights,
> nothing.
>
> Would it be possible, that there is kind of temporary
> dead lock of some kind...when emerge is started with more
> then one core?
>
> What else than writing to disk and using the cores?
>
> Cheers!
> Meino

I have seen this too. I read ages ago that some packages don't like
parallel jobs so the dev sets it to 1 or 2 depending on what works best
to limit those and build failures.  I don't know if that still applies
to many packages or not but it is one possibility.  I think it is set in
the ebuild so one may could look and see if that is the case.

Another option, it could be something the build process is doing that
can't be done in parallel and is set by upstream.  It may not be in the
ebuild but is in the sources itself.  It does seem to be a bottleneck
but if it is set that way, there may be a good reason.  When compiling,
I like to see my CPU utilized to the max but if it isn't possible, then
I let it do its thing.  I know LOo does some strange things when it is
compiling.  It will compile for a long time with little memory usage but
all CPU cores at the max, even tho the work space is in tmpfs, and then
all of a sudden, it starts eating memory until it is using several GBs. 
Then it compiles some more and starts the install process.  I have no
idea what makes it do that but it's the usual thing for LOo.

I'm sure someone else will have more ideas. 

Dale

:-)  :-) 

P. S. Back to the garden.  We supposed to stay home anyway so I'm taking
down the electric fence, posts and getting ready to plow.  Dang it's wet
out there tho.  At least I have a lift disc this year tho.  Maybe I
won't get stuck. :/

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Neil Bothwick]

On Sun, 05 Apr 2020 19:08:24 +0100, Peter Humphrey wrote:

> > I wonder, would there ever be any valid reason to have the E.S.P.\
> > and /boot as different partitions ?  
> 
> I found I had to do so. I couldn't get Neil's prererred layout to work.
> I forget the details now, but I only managed to build a usable system
> by leaving a small unformatted partition before the VFAT /boot
> partition. The first partition is marked bios_grub and the second
> 'boot, esp'.
> 
> I did try later to combine the two, but I still couldn't get it to
> work. Perhaps the BIOS has something odd in it.

If you are using a BIOS system, you need the compatibility partition at
the start. If you are using UEFI it shouldn't be necessary.


-- 
Neil Bothwick

Tribble math: * + * = ***


pgpIUEGmuJ4Kk.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] For what is emerge waiting for...?

[Neil Bothwick]

On Sun, 5 Apr 2020 21:10:57 +0200, tu...@posteo.de wrote:

> And it happens from time to time that all cores seem to be 
> on holiday: No load at all. And emerge sits there and waits...
> And the harddisk is not busy at all...no blinkenlights,
> nothing.

Is $PORTAGE_TMPDIR on a ramdisk?


-- 
Neil Bothwick

I'm Bugs Bunny of Borg.  What's up Collective?


pgprLFMtYfKe6.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Neil Bothwick]

On Sun, 5 Apr 2020 21:03:23 +0200, tu...@posteo.de wrote:

> And yes, Michael, same here. I am not veru convinced, that everything
> is well tested and tested for all use cases...
> 
I would say that copying an OS to the drive is the first use case most
SSDs experience, and one that occurs well within the warranty period. I
would imagine the manufacturers take care to ensure this first hurdle is
cleared easily.


-- 
Neil Bothwick

On the other hand, you have different fingers.


pgp1sJbOiHAiv.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Neil Bothwick]

On Sun, 5 Apr 2020 20:37:04 +0200, tu...@posteo.de wrote:

> which rises a question about how to resume an interrypted
> rsync-session.

Just run the rsync command again.


-- 
Neil Bothwick

Death is proven to be 99.9% fatal to all laboratory rats.


pgpvox39WKZa8.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Neil Bothwick]

On Sun, 5 Apr 2020 14:09:16 -0500, Dale wrote:

> I've used the watch command but don't quite get it yet.  With the
> command below, how would watch be added to that to make it update every
> set number of seconds, say 10 seconds or so?
> 
> smartctl -a /dev/sdd | grep Temp

watch -n 10 '(smartctl -a /dev/sdd | grep Temp)'


-- 
Neil Bothwick

Eye of newt, toe of frog, regular Coke and fries to go, please.


pgpcZflQM2hj7.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Dale]

tu...@posteo.de wrote:
>
> ...I just wanted to check, whether there is water in the pool... :)
>
> I minute ago I found this:
> https://unix.stackexchange.com/questions/203018/interrupting-rsync-with-ctrl-c-should-i-use-partial-or-append
>
> which rises a question about how to resume an interrypted
> rsync-session.
> It looks like the final answer was not found...
>
> Any additional ideas about that?
> Cheers!
> Meino
>

I have interrupted rsync quite a few times and never had it fail on
resume.  I've tested it to be sure.  I always use the -v and --progress
options so I can watch what it is doing.  If I restart it, it picks up
right where it left off, if no other files have changed since I stopped
it.  On occasion Seamonkey or Firefox will write to a file and it
catches those too but it updates the file it was stopped on and either
completes it or updates it one.  I don't know about the technical answer
but that's my experience with it. 

Another thing, if you do have to stop it and feel the need, rerun it
with a complete run afterwords to let it double check.  If nothing
changes, you should be fine.  Using du to check data sizes may help to,
although sometimes different file systems can change those. 

Just a couple thoughts. 

Dale

:-)  :-) 

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Dale]

tu...@posteo.de wrote:
> On 04/05 01:08, Dale wrote:
>> tu...@posteo.de wrote:
>>> On 04/05 10:33, Mark Knecht wrote:
 On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> Hi,
>
> currentlu I am preparing a new Gentoo Linux by compiling all
> the application I had on my old system.
>
> Due to delivery problems (corona) my SSD was delivered today
> (or yesterday...it depends...;) .
>
> When the whole compilation has finished and the system boots it
> needs to be transfered to the SSD.
>
> The SSD has a heat spreader...so it gets hot, when used.
>
> Is it wise to copy the whole root system to the SSD in one go
> in respect to a not so healthy heat increase?
>
> And if not...how can I copy the root system in portions
> to the SSD and do not miss anything?
>
> Are there SDD-friendly and SSD-unfriendlu methods of copying
> greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> What is recommended here?
>
> Thanks a lot for any help for a SSD newbie in advance!
>
> Cheers! And stay heathy!
> Meino
>
 Just my 2 cents...

 If the SSD cannot survive having data copied to it there's something
 seriously wrong with the drive. I don't think you should be overly worried
 about this but I do understand it's new technology so you want to be
 careful. Bravo for that.

 Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
 get to know your drive that way. You can most likely watch the drive temp
 as recorded by the drive.

 Best wishes,
 Mark
>>> Hi Mark,
>>>
>>> Yes, if a SSD could not survive writes, something is wrong with the
>>> SSD. But that was not my point.
>>> Copying about 100GB (roughly guessed) data in one go to the SSD is a
>>> use case, which is not common. And therefore possibly not taken into
>>> account by the company, which create that SSD.
>>> SSDs can create noticeable heat (mine has a minimalistic heat
>>> spreader therefore. Faster SSDs come with a substancial heatspreader).
>>>
>>> Smartctl will report problems when they are already there.
>>> I want to prevent problems beforehand.
>>>
>>> So -- does copying about 100 GB creates so much heat in the sillicone
>>> of the SSD, that it ages more than preferred?
>>>
>>> And if so, how can I prevent it by appluing other techniques to copy
>>> the data? 
>>> See additional questions in my initial posting for that.
>>>
>>> Thanks a lot for any helpful advice in advance!
>>> Cheers!
>>> Meino
>>>
>> If you are using rsync or cp -u you could start the copy then stop at it
>> certain points to let the SSD cool, then start it again.  It will
>> basically pick up where it left off.  You could monitor the temps while
>> doing that.  I use smartctrl and then grep temp on the end so I only get
>> the temp readings.  Something similar to this might help:
>>
>>
>> smartctl -a /dev/sdd | grep Temp
>>
>>
>> Another option, temporarily place a fan close to the drive to help cool
>> it.  Once you get everything copied, remove the fan and carry on. 
>>
>> Dale
>>
>> :-)  :-) 
>>
> Hi Dale,
>
> I have become a fan of your idea with the fan... :)
>
> Yes, of course! Great...after uears of thinking on software
> level such things, which provide a solution, which exists in
> the phusical world does not pop up in my head...
>
> Will do that! :)
> Cheers!
> Meino
>
>
>


My Cooler Master HAF-932 has a large fan on the side.  However, when I
remove the side, I have to unplug that fan.  Temps start rising even
with the side completely off the thing.  Years ago I bought a little 9
or 10 inch fan that plugs into the wall.  Usually I use it to cool my
upright freezer when I'm freezing fresh packed meat and the freezer has
a load on it for hours at a time.  I sometimes buy 40 or 50 lbs of meat
to freeze.  Anyway, when needed I use that fan to blow in place of the
side fan.  It blows a larger volume of air, even on low, but it keeps
the temps down to what they are with the side fan in place.  Sometimes
the temp rises 10 or 15F without that fan, mostly things like the video
card and such.  CPU stays pretty close to the same..  Amazing how that
slow spinning side fan does that.  ;-)

I usually place mine towards the front blowing towards the back.  That
is sort of the natural flow for this case.  However, in your case, you
want air blowing on the drive itself so I'd set it to blow across the
drive either at a upward or downward angle.  I'm not sure if the heat is
even or more on top or bottom.  Most likely, either will help. 

Yea, I'm a country guy who has learned to do things with little to
nothing.  I'm good at using something for something other than what it
was intended for.  o_O

Glad to help.  Sometimes the simple things even escape my notice.

Dale

:-)  :-) 

[gentoo-user] For what is emerge waiting for...?

[tuxic]

Hi,

no critism or anything else negative implied here...
,..I am just asking out of coriosity:

This day I am busy compiling all the application,
which are installed on my old system.

I gave emerge 12 threads and 6 cores to do its work
(The CPU is a 6 core one).

I start emerge with a bunch of packages to compile and
install.

And it happens from time to time that all cores seem to be 
on holiday: No load at all. And emerge sits there and waits...
And the harddisk is not busy at all...no blinkenlights,
nothing.

Would it be possible, that there is kind of temporary
dead lock of some kind...when emerge is started with more
then one core?

What else than writing to disk and using the cores?

Cheers!
Meino

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Dale]

Neil Bothwick wrote:
> On Sun, 5 Apr 2020 13:08:08 -0500, Dale wrote:
>
>> If you are using rsync or cp -u you could start the copy then stop at it
>> certain points to let the SSD cool, then start it again.  It will
>> basically pick up where it left off.
> Don't use cp -u, if you interrupt it while a file is being copied, that
> file will remain incomplete as it will have a newer timestamp than the
> original. rsync won't have this problem.
>
> I agree with the other comments that this is unlikely to cause a problem,
> but you could run hddtemp or smartctl with watch to keep an eye on the
> temperature during the copy.
>
>


Ahh, I've used dp -u in the past but never interrupted it.  Before I
started using rsync, I used that but it was run once until done and then
ran again on the next backup.  Good info to know tho.  That could cause
"issues".  :/

I've used the watch command but don't quite get it yet.  With the
command below, how would watch be added to that to make it update every
set number of seconds, say 10 seconds or so?

smartctl -a /dev/sdd | grep Temp

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

On 04/05 07:22, Michael wrote:
> On Sunday, 5 April 2020 18:54:25 BST tu...@posteo.de wrote:
> > On 04/05 10:33, Mark Knecht wrote:
> > > On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> > > > Hi,
> > > > 
> > > > currentlu I am preparing a new Gentoo Linux by compiling all
> > > > the application I had on my old system.
> > > > 
> > > > Due to delivery problems (corona) my SSD was delivered today
> > > > (or yesterday...it depends...;) .
> > > > 
> > > > When the whole compilation has finished and the system boots it
> > > > needs to be transfered to the SSD.
> > > > 
> > > > The SSD has a heat spreader...so it gets hot, when used.
> > > > 
> > > > Is it wise to copy the whole root system to the SSD in one go
> > > > in respect to a not so healthy heat increase?
> > > > 
> > > > And if not...how can I copy the root system in portions
> > > > to the SSD and do not miss anything?
> > > > 
> > > > Are there SDD-friendly and SSD-unfriendlu methods of copying
> > > > greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> > > > What is recommended here?
> > > > 
> > > > Thanks a lot for any help for a SSD newbie in advance!
> > > > 
> > > > Cheers! And stay heathy!
> > > > Meino
> > > 
> > > Just my 2 cents...
> > > 
> > > If the SSD cannot survive having data copied to it there's something
> > > seriously wrong with the drive. I don't think you should be overly worried
> > > about this but I do understand it's new technology so you want to be
> > > careful. Bravo for that.
> > > 
> > > Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> > > get to know your drive that way. You can most likely watch the drive temp
> > > as recorded by the drive.
> > > 
> > > Best wishes,
> > > Mark
> > 
> > Hi Mark,
> > 
> > Yes, if a SSD could not survive writes, something is wrong with the
> > SSD. But that was not my point.
> > Copying about 100GB (roughly guessed) data in one go to the SSD is a
> > use case, which is not common. And therefore possibly not taken into
> > account by the company, which create that SSD.
> > SSDs can create noticeable heat (mine has a minimalistic heat
> > spreader therefore. Faster SSDs come with a substancial heatspreader).
> > 
> > Smartctl will report problems when they are already there.
> > I want to prevent problems beforehand.
> > 
> > So -- does copying about 100 GB creates so much heat in the sillicone
> > of the SSD, that it ages more than preferred?
> > 
> > And if so, how can I prevent it by appluing other techniques to copy
> > the data?
> > See additional questions in my initial posting for that.
> 
> With rsync you could add the option:
> 
> --bwlimit=RATE  limit socket I/O bandwidth
> 
> and select a low enough bandwidth limit to keep the packets flowing at a low 
> rate to remain cool enough for your liking.  
> 
> However, I'll echo what other have said about not worrying about these 
> things.  
> The OEMs must run some rudimentary tests to establish performance envelopes 
> and keep everything tuned just so.
> 
> Nevertheless, if you do not trust them to produce the best quality products, 
> then we share something in common!  LOL!
> 
> In this case, you may want to open the PC case and use a desktop fan to keep 
> the interior of the case even cooler than usual, during your copying process.

That one is nice! Thanks a lot for that...

And yes, Michael, same here. I am not veru convinced, that everything
is well tested and tested for all use cases...

The fan is a nice idea also - these real world solytion does not pop
up in my head easily...they are kind of too real ;)
I will use a fan, if smartctl i.e. will report high temperatures...

Cheers!
Meino

Re: [gentoo-user] Why busybox?

[Ashley Dixon]

On Sun, Apr 05, 2020 at 10:53:50AM -0700, Ian Zimmerman wrote:
> Why does portage insist on installing busybox for me?

BusyBox is just a minimal set of utilities which would be useful for rescuing a
system, or to be used on an embedded system with extreme limitations. There's
not really any reason to remove this, but if you insist...

> As far as I know the only use for it on a desktop system is for
> initramfs.  I have no initramfs, therefore I have no need for busybox.
> I unmerged it and nothing bad happened except for a warning from portage
> that it is part of my profile set.  I went ahead and ignored the
> warning.
> 
> But now I updated the tree and emerge -p shows it will be installed
> again.  Why is that?  The only reverse dependencies are virtuals which
> are satisfied in other ways, like virtual/awk.  So is it the profile
> thing?  But I have done the same with other profile packages (notably
> editors/nano) and those are _not_ coming back.

Read more about profiles at [1]; a guide to making custom profiles can be found
as a subsection. Portage's attempts to reinstall BusyBox is not unexpected
behaviour, as the "profile" defines a core set of packages which should be
installed for a particular use case (e.g., desktop profiles mandate an X
server). Thus, when you invoke Portage to do a full overhaul, it interprets
anything defined in the profile which is not installed on the system to be an
error which needs to be rectified.

If you really don't want to have Portage install BusyBox, see the --exclude
option of emerge. But again, there's really no need to remove BusyBox unless
you're _very_ short on disk space.

[1] https://wiki.gentoo.org/wiki/Profile_(Portage)

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[J. Roeleveld]

On 5 April 2020 19:12:45 CEST, tu...@posteo.de wrote:
>Hi,
>
>currentlu I am preparing a new Gentoo Linux by compiling all
>the application I had on my old system.
>
>Due to delivery problems (corona) my SSD was delivered today
>(or yesterday...it depends...;) .
>
>When the whole compilation has finished and the system boots it
>needs to be transfered to the SSD.
>
>The SSD has a heat spreader...so it gets hot, when used.
>
>Is it wise to copy the whole root system to the SSD in one go
>in respect to a not so healthy heat increase?
>
>And if not...how can I copy the root system in portions
>to the SSD and do not miss anything?
>
>Are there SDD-friendly and SSD-unfriendlu methods of copying
>greater chunks of data to a SSD (rsync, tar-pipe, cp)?
>What is recommended here?
>
>Thanks a lot for any help for a SSD newbie in advance!
>
>Cheers! And stay heathy!
>Meino

I have been using SSDs for over 7 years now and never worried about them 
overheating.
In my opinion, if the drive can't handle a copy operation of 20GB (how much 
bigger is your root partition?) it should be replaced from day one.

I only keep the portage compile dir and browser caches in RAM, the rest stays 
on the SSD. And as I mentioned in a previous thread about SSDs, I only had one 
failure after 6.5 years. (That drive also had SWAP on it and I didn't offload 
the browser caches yet on that one).

Like Mark said, it is good to keep an eye on it, but if you use decent brand 
SSDs (Samsung and Intel), you should be able to expect 5+ years of heavy usage.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

On 04/05 01:08, Dale wrote:
> tu...@posteo.de wrote:
> > On 04/05 10:33, Mark Knecht wrote:
> >> On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> >>> Hi,
> >>>
> >>> currentlu I am preparing a new Gentoo Linux by compiling all
> >>> the application I had on my old system.
> >>>
> >>> Due to delivery problems (corona) my SSD was delivered today
> >>> (or yesterday...it depends...;) .
> >>>
> >>> When the whole compilation has finished and the system boots it
> >>> needs to be transfered to the SSD.
> >>>
> >>> The SSD has a heat spreader...so it gets hot, when used.
> >>>
> >>> Is it wise to copy the whole root system to the SSD in one go
> >>> in respect to a not so healthy heat increase?
> >>>
> >>> And if not...how can I copy the root system in portions
> >>> to the SSD and do not miss anything?
> >>>
> >>> Are there SDD-friendly and SSD-unfriendlu methods of copying
> >>> greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> >>> What is recommended here?
> >>>
> >>> Thanks a lot for any help for a SSD newbie in advance!
> >>>
> >>> Cheers! And stay heathy!
> >>> Meino
> >>>
> >> Just my 2 cents...
> >>
> >> If the SSD cannot survive having data copied to it there's something
> >> seriously wrong with the drive. I don't think you should be overly worried
> >> about this but I do understand it's new technology so you want to be
> >> careful. Bravo for that.
> >>
> >> Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> >> get to know your drive that way. You can most likely watch the drive temp
> >> as recorded by the drive.
> >>
> >> Best wishes,
> >> Mark
> > Hi Mark,
> >
> > Yes, if a SSD could not survive writes, something is wrong with the
> > SSD. But that was not my point.
> > Copying about 100GB (roughly guessed) data in one go to the SSD is a
> > use case, which is not common. And therefore possibly not taken into
> > account by the company, which create that SSD.
> > SSDs can create noticeable heat (mine has a minimalistic heat
> > spreader therefore. Faster SSDs come with a substancial heatspreader).
> >
> > Smartctl will report problems when they are already there.
> > I want to prevent problems beforehand.
> >
> > So -- does copying about 100 GB creates so much heat in the sillicone
> > of the SSD, that it ages more than preferred?
> >
> > And if so, how can I prevent it by appluing other techniques to copy
> > the data? 
> > See additional questions in my initial posting for that.
> >
> > Thanks a lot for any helpful advice in advance!
> > Cheers!
> > Meino
> >
> 
> If you are using rsync or cp -u you could start the copy then stop at it
> certain points to let the SSD cool, then start it again.  It will
> basically pick up where it left off.  You could monitor the temps while
> doing that.  I use smartctrl and then grep temp on the end so I only get
> the temp readings.  Something similar to this might help:
> 
> 
> smartctl -a /dev/sdd | grep Temp
> 
> 
> Another option, temporarily place a fan close to the drive to help cool
> it.  Once you get everything copied, remove the fan and carry on. 
> 
> Dale
> 
> :-)  :-) 
> 

Hi Dale,

I have become a fan of your idea with the fan... :)

Yes, of course! Great...after uears of thinking on software
level such things, which provide a solution, which exists in
the phusical world does not pop up in my head...

Will do that! :)
Cheers!
Meino

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

On 04/05 11:12, Mark Knecht wrote:
> On Sun, Apr 5, 2020 at 10:54 AM  wrote:
> >
> > On 04/05 10:33, Mark Knecht wrote:
> > > On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> > > >
> > > > Hi,
> > > >
> > > > currentlu I am preparing a new Gentoo Linux by compiling all
> > > > the application I had on my old system.
> > > >
> > > > Due to delivery problems (corona) my SSD was delivered today
> > > > (or yesterday...it depends...;) .
> > > >
> > > > When the whole compilation has finished and the system boots it
> > > > needs to be transfered to the SSD.
> > > >
> > > > The SSD has a heat spreader...so it gets hot, when used.
> > > >
> > > > Is it wise to copy the whole root system to the SSD in one go
> > > > in respect to a not so healthy heat increase?
> > > >
> > > > And if not...how can I copy the root system in portions
> > > > to the SSD and do not miss anything?
> > > >
> > > > Are there SDD-friendly and SSD-unfriendlu methods of copying
> > > > greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> > > > What is recommended here?
> > > >
> > > > Thanks a lot for any help for a SSD newbie in advance!
> > > >
> > > > Cheers! And stay heathy!
> > > > Meino
> > > >
> > >
> > > Just my 2 cents...
> > >
> > > If the SSD cannot survive having data copied to it there's something
> > > seriously wrong with the drive. I don't think you should be overly
> worried
> > > about this but I do understand it's new technology so you want to be
> > > careful. Bravo for that.
> > >
> > > Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> > > get to know your drive that way. You can most likely watch the drive
> temp
> > > as recorded by the drive.
> > >
> > > Best wishes,
> > > Mark
> >
> > Hi Mark,
> >
> > Yes, if a SSD could not survive writes, something is wrong with the
> > SSD. But that was not my point.
> > Copying about 100GB (roughly guessed) data in one go to the SSD is a
> > use case, which is not common. And therefore possibly not taken into
> > account by the company, which create that SSD.
> > SSDs can create noticeable heat (mine has a minimalistic heat
> > spreader therefore. Faster SSDs come with a substancial heatspreader).
> >
> > Smartctl will report problems when they are already there.
> > I want to prevent problems beforehand.
> >
> > So -- does copying about 100 GB creates so much heat in the sillicone
> > of the SSD, that it ages more than preferred?
> >
> > And if so, how can I prevent it by appluing other techniques to copy
> > the data?
> > See additional questions in my initial posting for that.
> >
> > Thanks a lot for any helpful advice in advance!
> > Cheers!
> > Meino
> >
> 
> If copying 100GB causes too much heat watching smartctl will show you
> before it gets too hot and you can stop it.
> 
> 100GB of data as a copy is only 1 write cycle to any given data block on
> the drive. It's not going to matter how you get it there but something like
> rsync _might_ allow a restart in the middle of the copy if your rsync
> operation was to fail part way through.
> 
> I don't personally think there's anything at all for you to worry about
> with this but I can see it's not my words that will get you there. I will
> only offer that I've used SSDs for 5-6 years now and only had the first one
> I purchased fail. I ran Gentoo with nightly code compiles for about 2 years
> before moving away from Gentoo and never had a problem with any of that.
> 
> I think you're just going to have to hold your nose and jump in the pool.
> We welcome you. The water is fine!
> 
> Mark

...I just wanted to check, whether there is water in the pool... :)

I minute ago I found this:
https://unix.stackexchange.com/questions/203018/interrupting-rsync-with-ctrl-c-should-i-use-partial-or-append

which rises a question about how to resume an interrypted
rsync-session.
It looks like the final answer was not found...

Any additional ideas about that?
Cheers!
Meino

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Neil Bothwick]

On Sun, 5 Apr 2020 13:08:08 -0500, Dale wrote:

> If you are using rsync or cp -u you could start the copy then stop at it
> certain points to let the SSD cool, then start it again.  It will
> basically pick up where it left off.

Don't use cp -u, if you interrupt it while a file is being copied, that
file will remain incomplete as it will have a newer timestamp than the
original. rsync won't have this problem.

I agree with the other comments that this is unlikely to cause a problem,
but you could run hddtemp or smartctl with watch to keep an eye on the
temperature during the copy.


-- 
Neil Bothwick

Q:  Why is top-posting evil?
A: backwards read don't humans because


pgpEK4DNlWLkK.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Michael]

On Sunday, 5 April 2020 18:54:25 BST tu...@posteo.de wrote:
> On 04/05 10:33, Mark Knecht wrote:
> > On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> > > Hi,
> > > 
> > > currentlu I am preparing a new Gentoo Linux by compiling all
> > > the application I had on my old system.
> > > 
> > > Due to delivery problems (corona) my SSD was delivered today
> > > (or yesterday...it depends...;) .
> > > 
> > > When the whole compilation has finished and the system boots it
> > > needs to be transfered to the SSD.
> > > 
> > > The SSD has a heat spreader...so it gets hot, when used.
> > > 
> > > Is it wise to copy the whole root system to the SSD in one go
> > > in respect to a not so healthy heat increase?
> > > 
> > > And if not...how can I copy the root system in portions
> > > to the SSD and do not miss anything?
> > > 
> > > Are there SDD-friendly and SSD-unfriendlu methods of copying
> > > greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> > > What is recommended here?
> > > 
> > > Thanks a lot for any help for a SSD newbie in advance!
> > > 
> > > Cheers! And stay heathy!
> > > Meino
> > 
> > Just my 2 cents...
> > 
> > If the SSD cannot survive having data copied to it there's something
> > seriously wrong with the drive. I don't think you should be overly worried
> > about this but I do understand it's new technology so you want to be
> > careful. Bravo for that.
> > 
> > Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> > get to know your drive that way. You can most likely watch the drive temp
> > as recorded by the drive.
> > 
> > Best wishes,
> > Mark
> 
> Hi Mark,
> 
> Yes, if a SSD could not survive writes, something is wrong with the
> SSD. But that was not my point.
> Copying about 100GB (roughly guessed) data in one go to the SSD is a
> use case, which is not common. And therefore possibly not taken into
> account by the company, which create that SSD.
> SSDs can create noticeable heat (mine has a minimalistic heat
> spreader therefore. Faster SSDs come with a substancial heatspreader).
> 
> Smartctl will report problems when they are already there.
> I want to prevent problems beforehand.
> 
> So -- does copying about 100 GB creates so much heat in the sillicone
> of the SSD, that it ages more than preferred?
> 
> And if so, how can I prevent it by appluing other techniques to copy
> the data?
> See additional questions in my initial posting for that.

With rsync you could add the option:

--bwlimit=RATE  limit socket I/O bandwidth

and select a low enough bandwidth limit to keep the packets flowing at a low 
rate to remain cool enough for your liking.  

However, I'll echo what other have said about not worrying about these things.  
The OEMs must run some rudimentary tests to establish performance envelopes 
and keep everything tuned just so.

Nevertheless, if you do not trust them to produce the best quality products, 
then we share something in common!  LOL!

In this case, you may want to open the PC case and use a desktop fan to keep 
the interior of the case even cooler than usual, during your copying process.

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: SDD, what features to look for and what to avoid.

[Peter Humphrey]

On Saturday, 4 April 2020 10:51:42 BST Peter Humphrey wrote:
> On Friday, 3 April 2020 16:14:33 BST Frank Steinmetzger wrote:
> > Well, raw throughput is great ’n all, but in real-life you won’t notice
> > much difference between a SATA and an NVME drive.
> 
> Not so. The difference is dramatic.

For example, when I dep-cleaned gentoo-sources-4.19.97 this morning, it took 
11 seconds. That's real write performance.

-- 
Regards,
Peter.

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Mark Knecht]

On Sun, Apr 5, 2020 at 10:54 AM  wrote:
>
> On 04/05 10:33, Mark Knecht wrote:
> > On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> > >
> > > Hi,
> > >
> > > currentlu I am preparing a new Gentoo Linux by compiling all
> > > the application I had on my old system.
> > >
> > > Due to delivery problems (corona) my SSD was delivered today
> > > (or yesterday...it depends...;) .
> > >
> > > When the whole compilation has finished and the system boots it
> > > needs to be transfered to the SSD.
> > >
> > > The SSD has a heat spreader...so it gets hot, when used.
> > >
> > > Is it wise to copy the whole root system to the SSD in one go
> > > in respect to a not so healthy heat increase?
> > >
> > > And if not...how can I copy the root system in portions
> > > to the SSD and do not miss anything?
> > >
> > > Are there SDD-friendly and SSD-unfriendlu methods of copying
> > > greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> > > What is recommended here?
> > >
> > > Thanks a lot for any help for a SSD newbie in advance!
> > >
> > > Cheers! And stay heathy!
> > > Meino
> > >
> >
> > Just my 2 cents...
> >
> > If the SSD cannot survive having data copied to it there's something
> > seriously wrong with the drive. I don't think you should be overly
worried
> > about this but I do understand it's new technology so you want to be
> > careful. Bravo for that.
> >
> > Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> > get to know your drive that way. You can most likely watch the drive
temp
> > as recorded by the drive.
> >
> > Best wishes,
> > Mark
>
> Hi Mark,
>
> Yes, if a SSD could not survive writes, something is wrong with the
> SSD. But that was not my point.
> Copying about 100GB (roughly guessed) data in one go to the SSD is a
> use case, which is not common. And therefore possibly not taken into
> account by the company, which create that SSD.
> SSDs can create noticeable heat (mine has a minimalistic heat
> spreader therefore. Faster SSDs come with a substancial heatspreader).
>
> Smartctl will report problems when they are already there.
> I want to prevent problems beforehand.
>
> So -- does copying about 100 GB creates so much heat in the sillicone
> of the SSD, that it ages more than preferred?
>
> And if so, how can I prevent it by appluing other techniques to copy
> the data?
> See additional questions in my initial posting for that.
>
> Thanks a lot for any helpful advice in advance!
> Cheers!
> Meino
>

If copying 100GB causes too much heat watching smartctl will show you
before it gets too hot and you can stop it.

100GB of data as a copy is only 1 write cycle to any given data block on
the drive. It's not going to matter how you get it there but something like
rsync _might_ allow a restart in the middle of the copy if your rsync
operation was to fail part way through.

I don't personally think there's anything at all for you to worry about
with this but I can see it's not my words that will get you there. I will
only offer that I've used SSDs for 5-6 years now and only had the first one
I purchased fail. I ran Gentoo with nightly code compiles for about 2 years
before moving away from Gentoo and never had a problem with any of that.

I think you're just going to have to hold your nose and jump in the pool.
We welcome you. The water is fine!

Mark

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Peter Humphrey]

On Sunday, 5 April 2020 13:56:55 BST Ashley Dixon wrote:

> I wonder, would there ever be any valid reason to have the E.S.P.\ and /boot
> as different partitions ?

I found I had to do so. I couldn't get Neil's prererred layout to work. I 
forget the details now, but I only managed to build a usable system by leaving 
a small unformatted partition before the VFAT /boot partition. The first 
partition is marked bios_grub and the second 'boot, esp'.

I did try later to combine the two, but I still couldn't get it to work. 
Perhaps the BIOS has something odd in it.

-- 
Regards,
Peter.

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Dale]

tu...@posteo.de wrote:
> On 04/05 10:33, Mark Knecht wrote:
>> On Sun, Apr 5, 2020 at 10:13 AM  wrote:
>>> Hi,
>>>
>>> currentlu I am preparing a new Gentoo Linux by compiling all
>>> the application I had on my old system.
>>>
>>> Due to delivery problems (corona) my SSD was delivered today
>>> (or yesterday...it depends...;) .
>>>
>>> When the whole compilation has finished and the system boots it
>>> needs to be transfered to the SSD.
>>>
>>> The SSD has a heat spreader...so it gets hot, when used.
>>>
>>> Is it wise to copy the whole root system to the SSD in one go
>>> in respect to a not so healthy heat increase?
>>>
>>> And if not...how can I copy the root system in portions
>>> to the SSD and do not miss anything?
>>>
>>> Are there SDD-friendly and SSD-unfriendlu methods of copying
>>> greater chunks of data to a SSD (rsync, tar-pipe, cp)?
>>> What is recommended here?
>>>
>>> Thanks a lot for any help for a SSD newbie in advance!
>>>
>>> Cheers! And stay heathy!
>>> Meino
>>>
>> Just my 2 cents...
>>
>> If the SSD cannot survive having data copied to it there's something
>> seriously wrong with the drive. I don't think you should be overly worried
>> about this but I do understand it's new technology so you want to be
>> careful. Bravo for that.
>>
>> Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
>> get to know your drive that way. You can most likely watch the drive temp
>> as recorded by the drive.
>>
>> Best wishes,
>> Mark
> Hi Mark,
>
> Yes, if a SSD could not survive writes, something is wrong with the
> SSD. But that was not my point.
> Copying about 100GB (roughly guessed) data in one go to the SSD is a
> use case, which is not common. And therefore possibly not taken into
> account by the company, which create that SSD.
> SSDs can create noticeable heat (mine has a minimalistic heat
> spreader therefore. Faster SSDs come with a substancial heatspreader).
>
> Smartctl will report problems when they are already there.
> I want to prevent problems beforehand.
>
> So -- does copying about 100 GB creates so much heat in the sillicone
> of the SSD, that it ages more than preferred?
>
> And if so, how can I prevent it by appluing other techniques to copy
> the data? 
> See additional questions in my initial posting for that.
>
> Thanks a lot for any helpful advice in advance!
> Cheers!
> Meino
>

If you are using rsync or cp -u you could start the copy then stop at it
certain points to let the SSD cool, then start it again.  It will
basically pick up where it left off.  You could monitor the temps while
doing that.  I use smartctrl and then grep temp on the end so I only get
the temp readings.  Something similar to this might help:


smartctl -a /dev/sdd | grep Temp


Another option, temporarily place a fan close to the drive to help cool
it.  Once you get everything copied, remove the fan and carry on. 

Dale

:-)  :-) 

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

On 04/05 10:33, Mark Knecht wrote:
> On Sun, Apr 5, 2020 at 10:13 AM  wrote:
> >
> > Hi,
> >
> > currentlu I am preparing a new Gentoo Linux by compiling all
> > the application I had on my old system.
> >
> > Due to delivery problems (corona) my SSD was delivered today
> > (or yesterday...it depends...;) .
> >
> > When the whole compilation has finished and the system boots it
> > needs to be transfered to the SSD.
> >
> > The SSD has a heat spreader...so it gets hot, when used.
> >
> > Is it wise to copy the whole root system to the SSD in one go
> > in respect to a not so healthy heat increase?
> >
> > And if not...how can I copy the root system in portions
> > to the SSD and do not miss anything?
> >
> > Are there SDD-friendly and SSD-unfriendlu methods of copying
> > greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> > What is recommended here?
> >
> > Thanks a lot for any help for a SSD newbie in advance!
> >
> > Cheers! And stay heathy!
> > Meino
> >
> 
> Just my 2 cents...
> 
> If the SSD cannot survive having data copied to it there's something
> seriously wrong with the drive. I don't think you should be overly worried
> about this but I do understand it's new technology so you want to be
> careful. Bravo for that.
> 
> Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
> get to know your drive that way. You can most likely watch the drive temp
> as recorded by the drive.
> 
> Best wishes,
> Mark

Hi Mark,

Yes, if a SSD could not survive writes, something is wrong with the
SSD. But that was not my point.
Copying about 100GB (roughly guessed) data in one go to the SSD is a
use case, which is not common. And therefore possibly not taken into
account by the company, which create that SSD.
SSDs can create noticeable heat (mine has a minimalistic heat
spreader therefore. Faster SSDs come with a substancial heatspreader).

Smartctl will report problems when they are already there.
I want to prevent problems beforehand.

So -- does copying about 100 GB creates so much heat in the sillicone
of the SSD, that it ages more than preferred?

And if so, how can I prevent it by appluing other techniques to copy
the data? 
See additional questions in my initial posting for that.

Thanks a lot for any helpful advice in advance!
Cheers!
Meino

[gentoo-user] Why busybox?

[Ian Zimmerman]

Why does portage insist on installing busybox for me?

As far as I know the only use for it on a desktop system is for
initramfs.  I have no initramfs, therefore I have no need for busybox.
I unmerged it and nothing bad happened except for a warning from portage
that it is part of my profile set.  I went ahead and ignored the
warning.

But now I updated the tree and emerge -p shows it will be installed
again.  Why is that?  The only reverse dependencies are virtuals which
are satisfied in other ways, like virtual/awk.  So is it the profile
thing?  But I have done the same with other profile packages (notably
editors/nano) and those are _not_ coming back.

-- 
Ian

[gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?

[Ian Zimmerman]

On 2020-04-04 20:03, tu...@posteo.de wrote:

> Wouldn't transferring the world file be enough?
> 
> Is it?

As far as I know, for having the same packages pulled in, this
is all that matters (plus possibly @world_sets as Neil mentions).

Of course you have all sorts of other configuration to replicate,
including portage's.  That's what git is for :-P.

-- 
Ian

Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?

[Mark Knecht]

On Sun, Apr 5, 2020 at 10:13 AM  wrote:
>
> Hi,
>
> currentlu I am preparing a new Gentoo Linux by compiling all
> the application I had on my old system.
>
> Due to delivery problems (corona) my SSD was delivered today
> (or yesterday...it depends...;) .
>
> When the whole compilation has finished and the system boots it
> needs to be transfered to the SSD.
>
> The SSD has a heat spreader...so it gets hot, when used.
>
> Is it wise to copy the whole root system to the SSD in one go
> in respect to a not so healthy heat increase?
>
> And if not...how can I copy the root system in portions
> to the SSD and do not miss anything?
>
> Are there SDD-friendly and SSD-unfriendlu methods of copying
> greater chunks of data to a SSD (rsync, tar-pipe, cp)?
> What is recommended here?
>
> Thanks a lot for any help for a SSD newbie in advance!
>
> Cheers! And stay heathy!
> Meino
>

Just my 2 cents...

If the SSD cannot survive having data copied to it there's something
seriously wrong with the drive. I don't think you should be overly worried
about this but I do understand it's new technology so you want to be
careful. Bravo for that.

Possibly to ease your concerns a little bit use smartctl -a /dev/SSD and
get to know your drive that way. You can most likely watch the drive temp
as recorded by the drive.

Best wishes,
Mark

[gentoo-user] Copying root to SSD in one go...a good idea...or?

[tuxic]

Hi,

currentlu I am preparing a new Gentoo Linux by compiling all
the application I had on my old system.

Due to delivery problems (corona) my SSD was delivered today
(or yesterday...it depends...;) .

When the whole compilation has finished and the system boots it
needs to be transfered to the SSD.

The SSD has a heat spreader...so it gets hot, when used.

Is it wise to copy the whole root system to the SSD in one go
in respect to a not so healthy heat increase?

And if not...how can I copy the root system in portions
to the SSD and do not miss anything?

Are there SDD-friendly and SSD-unfriendlu methods of copying
greater chunks of data to a SSD (rsync, tar-pipe, cp)?
What is recommended here?

Thanks a lot for any help for a SSD newbie in advance!

Cheers! And stay heathy!
Meino

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Neil Bothwick]

On Sun, 5 Apr 2020 13:56:55 +0100, Ashley Dixon wrote:

> > This isn't strictly true, the ESP must be vfat, but you can still
> > have an ext? /boot. However, it generally makes sense to have the ESP
> > and /boot as the same partition, that's how I generally do it. either
> > way, the handbook appears to need updating in this respect.  
> 
> Sorry, my mistake. I wonder, would there ever be any valid reason to
> have the E.S.P.\ and /boot as different partitions ?

Possibly if you have multiple distros installed. That way you could
isolate each distro.


-- 
Neil Bothwick

Politically Incorrect -- and damn proud of it!


pgpgclLjUqO2J.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Michael]

On Sunday, 5 April 2020 13:56:55 BST Ashley Dixon wrote:
> On Sun, Apr 05, 2020 at 01:52:52PM +0100, Neil Bothwick wrote:
> > This isn't strictly true, the ESP must be vfat, but you can still have an
> > ext? /boot. However, it generally makes sense to have the ESP and /boot
> > as the same partition, that's how I generally do it. either way, the
> > handbook appears to need updating in this respect.
> 
> Sorry, my mistake. I wonder, would there ever be any valid reason to have
> the E.S.P.\ and /boot as different partitions ?

Having two separate partitions for the same reason sounds superfluous, but 
there may be special reasons.

For example, you may want to have separate OS installations and each with 
their own standalone /boot partition.  When you uninstall one OS you won't 
have to fish into the EFI Boot partition for any entries specific to this OS.  
These days most OS tend to behave and install their boot manager/kernel images 
into separate subdirectories within the EFI Boot partition - but there are no 
guarantees.  What if rogue-OS decides to install its vmlinuz ontop of your own 
images, without even asking first?

Perhaps you could try chainloading various boot managers to try them out, so 
the EFI firmware could boot GRUB, which could chainload rEFInd, which could 
chainload C:\boot\bcd.exe, etc. After you finish with your experiment you 
could decide to remove a particular /boot partition with its boot manager 
altogether.  Tenuous, I know, but I'm trying to think for reasons to keep a 
separate /boot partition, without actually having a need for it myself.  ;-)

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Question about x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard

[Nikos Chantziaras]

On 04/04/2020 23:11, Alarig Le Lay wrote:

The news item from 2020-04-03 says “future removal of the legacy X11
input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard“
[...]

However, emerge --depclean doesn’t try to remove them.


That's normal. They are deps behind USE flags of x11-base/xorg-drivers. 
They will be removed in the future. When that happens, depclean will 
remove them.

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Ashley Dixon]

On Sun, Apr 05, 2020 at 01:52:52PM +0100, Neil Bothwick wrote:
> This isn't strictly true, the ESP must be vfat, but you can still have an
> ext? /boot. However, it generally makes sense to have the ESP and /boot
> as the same partition, that's how I generally do it. either way, the
> handbook appears to need updating in this respect.

Sorry, my mistake. I wonder, would there ever be any valid reason to have the
E.S.P.\ and /boot as different partitions ?

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Neil Bothwick]

On Sun, 5 Apr 2020 10:28:50 +0100, Ashley Dixon wrote:

> > Here /boot changes from fat32 to ext2. 
> > Since this is my first U/EFI system I am a little confused.  
> 
> Good morning Meino,
> 
> For U.E.F.I., the boot partition (/dev/sda2) must be FAT32. In your
> fstab file, this is written as (the last three arguments may vary for
> your system):
> 
> /dev/sda2 /boot vfat defaults,noatime 0 2
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Using_UEFI

This isn't strictly true, the ESP must be vfat, but you can still have an
ext? /boot. However, it generally makes sense to have the ESP and /boot
as the same partition, that's how I generally do it. either way, the
handbook appears to need updating in this respect.


-- 
Neil Bothwick

Don't just do something, sit there!


pgp9lQOkJXeLf.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[tuxic]

On 04/05 10:46, Michael wrote:
> Hi Meino,
> 
> On Sunday, 5 April 2020 09:17:41 BST tu...@posteo.de wrote:
> 
> > Hi,
> > 
> > a new morning... :)
> > 
> > Being on the way to install/setup the base system (mostly getting
> > stage3 uptodate) I came accross kinda inconsistency -- or at least
> > it looks like for me.
> > 
> > The system uses a 3T harddisc (and later a SSD) and therefore GPT.
> > GPT is the sister/brother of an U/EFI boot.
> > 
> > For that the documentation (AMD64 handbook):
> > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Using_UEFI
> > 
> > says:
> > Default partitioning scheme
> > Throughout the remainder of the handbook, the following partitioning scheme
> > will be used as a simple example layout: 
> 
> I think the following table provided in the handbook was probably written 
> some 
> time ago, when the migration was happening between legacy BIOS and UEFI 
> MoBos.  
> Others may know more about the rationale behind the partitioning scheme given 
> as an example in the handbook, but for what it's worth I share my 
> understanding below:
> 
> > Partition   Filesystem  Size   Description
> > /dev/sda1   (bootloader)2M  BIOS boot partition
> 
> The above is probably a manually created 'GPT protective MBR'.  This is now 
> created as a default by modern partitioning tools, but not if you're using 
> some old Knoppix CD you had burned in the early '00s.  Its purpose is to add 
> some code in the first 1M of the disk (LBA 0) to signify to a legacy BIOS or 
> OS the partition table is not bootable.  Old partitioning tools/OS' will show 
> the disk as already partitioned with 'Unknown Partition Type', thus prompting 
> the user not to mess up the partition table/partitions on this disk.  If you 
> use a modern fdisk/gptdisk/parted, etc. you won't see this first partition 
> mentioned above, but you will see the first partition starting at 1M, or on a 
> 512B sector size at 2048.
> 
> 
> > /dev/sda2   ext2 (or fat32 if UEFI is being used)  128M  Boot/EFI system
> 
> This the partition the UEFI firmware will jump to and load bootable code 
> from.  
> The GRUB efi boot binary (grubx64.efi) and any other kernel/initrd efi code 
> will be stored here.
> 
> 
> > and later on at
> > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System
> > 
> > FILE /etc/fstabA full /etc/fstab example
> > 
> > /dev/sda2   /bootext2defaults,noatime 0 2
> > /dev/sda3   none swapsw   0 0
> > /dev/sda4   /ext4noatime  0 1
> > 
> > /dev/cdrom  /mnt/cdrom   autonoauto,user  0 0
> > 
> > Here /boot changes from fat32 to ext2.
> 
> I think this is because the handbook really needs to be updated.  It mixes 
> old 
> with new.  All UEFI MoBos require a VFAT partition to boot from.
> 
> 
> > Since this is my first U/EFI system I am a little confused.
> > 
> > Currentlu it looks like the vmlinuz binaries will be installed on
> > a FAT32 filesystem. Since the kernel can be launched from a ext4
> > filesystem I cannot see, why this have to be a FAT32 filesystem.
> 
> You can chainload a vmlinuz binary stored on any other partition number and 
> type from a boot manager (e.g. GRUB).  The boot manager will have to be 
> stored 
> on the VFAT EFI boot partition for the MoBo UEFI firmware to be able to boot 
> it.  Future UEFI firmware may be able to boot from ext2, but AFAIK not 
> presently.
> 
> 
> > My plan (if this is possible), is to U/EFI-boot grub, from which
> > I can select the kernel in question as it has been on my old
> > system (MBR based).
> > 
> > My current partition table looks like (only relevant parts shown):
> > 
> > Number  Start   End SizeFile system NameFlags
> >  1  1049kB  3146kB  2097kB  grubbios_grub
> >  2  3146kB  137MB   134MB   fat32   bootboot, esp
> >  3  137MB   674MB   537MB   linux-swap(v1)  swap
> >  4  674MB   269GB   268GB   ext4root
> 
> Unless you intend to use the disk both on MBR and on UEFI MoBos 
> interchangeably, I suggest you stick with the GPT partitioning scheme and a 
> VFAT EFI Boot partition where GRUB and vmlinuz will be stored.
> 
> HTH.


Hi Michael,

Your posting helps me a LOT!!! :)

Thank you very much!!! :)

Cheers!
Meino

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Michael]

Hi Meino,

On Sunday, 5 April 2020 09:17:41 BST tu...@posteo.de wrote:

> Hi,
> 
> a new morning... :)
> 
> Being on the way to install/setup the base system (mostly getting
> stage3 uptodate) I came accross kinda inconsistency -- or at least
> it looks like for me.
> 
> The system uses a 3T harddisc (and later a SSD) and therefore GPT.
> GPT is the sister/brother of an U/EFI boot.
> 
> For that the documentation (AMD64 handbook):
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Using_UEFI
> 
> says:
> Default partitioning scheme
> Throughout the remainder of the handbook, the following partitioning scheme
> will be used as a simple example layout: 

I think the following table provided in the handbook was probably written some 
time ago, when the migration was happening between legacy BIOS and UEFI MoBos.  
Others may know more about the rationale behind the partitioning scheme given 
as an example in the handbook, but for what it's worth I share my 
understanding below:

> Partition   FilesystemSize   Description
> /dev/sda1   (bootloader)  2M  BIOS boot partition

The above is probably a manually created 'GPT protective MBR'.  This is now 
created as a default by modern partitioning tools, but not if you're using 
some old Knoppix CD you had burned in the early '00s.  Its purpose is to add 
some code in the first 1M of the disk (LBA 0) to signify to a legacy BIOS or 
OS the partition table is not bootable.  Old partitioning tools/OS' will show 
the disk as already partitioned with 'Unknown Partition Type', thus prompting 
the user not to mess up the partition table/partitions on this disk.  If you 
use a modern fdisk/gptdisk/parted, etc. you won't see this first partition 
mentioned above, but you will see the first partition starting at 1M, or on a 
512B sector size at 2048.


> /dev/sda2   ext2 (or fat32 if UEFI is being used)  128M  Boot/EFI system

This the partition the UEFI firmware will jump to and load bootable code from.  
The GRUB efi boot binary (grubx64.efi) and any other kernel/initrd efi code 
will be stored here.


> and later on at
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System
> 
> FILE /etc/fstabA full /etc/fstab example
> 
> /dev/sda2   /bootext2defaults,noatime 0 2
> /dev/sda3   none swapsw   0 0
> /dev/sda4   /ext4noatime  0 1
> 
> /dev/cdrom  /mnt/cdrom   autonoauto,user  0 0
> 
> Here /boot changes from fat32 to ext2.

I think this is because the handbook really needs to be updated.  It mixes old 
with new.  All UEFI MoBos require a VFAT partition to boot from.


> Since this is my first U/EFI system I am a little confused.
> 
> Currentlu it looks like the vmlinuz binaries will be installed on
> a FAT32 filesystem. Since the kernel can be launched from a ext4
> filesystem I cannot see, why this have to be a FAT32 filesystem.

You can chainload a vmlinuz binary stored on any other partition number and 
type from a boot manager (e.g. GRUB).  The boot manager will have to be stored 
on the VFAT EFI boot partition for the MoBo UEFI firmware to be able to boot 
it.  Future UEFI firmware may be able to boot from ext2, but AFAIK not 
presently.


> My plan (if this is possible), is to U/EFI-boot grub, from which
> I can select the kernel in question as it has been on my old
> system (MBR based).
> 
> My current partition table looks like (only relevant parts shown):
> 
> Number  Start   End SizeFile system NameFlags
>  1  1049kB  3146kB  2097kB  grubbios_grub
>  2  3146kB  137MB   134MB   fat32   bootboot, esp
>  3  137MB   674MB   537MB   linux-swap(v1)  swap
>  4  674MB   269GB   268GB   ext4root

Unless you intend to use the disk both on MBR and on UEFI MoBos 
interchangeably, I suggest you stick with the GPT partitioning scheme and a 
VFAT EFI Boot partition where GRUB and vmlinuz will be stored.

HTH.

signature.asc
Description: This is a digitally signed message part.

Re: [OT] Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Peter Humphrey]

On Sunday, 5 April 2020 10:21:32 BST Peter Humphrey wrote:
> On Saturday, 4 April 2020 20:59:56 BST tu...@posteo.de wrote:
> > I have some problems to understand, whether I understood...
> > 
> > In the german language the "'s are often used to express the
> > 
> > opposite of what is written in words. For example:
> > What a "nice" weather it is...!
> > 
> > will say:
> > For heavens sake, what the hell all this rain is coming
> > from!!!???
> 
> It's the same in English, except that "weather" is an uncountable noun, so
> you can't have "a weather" - it's just "weather".
> 
> I'd like to put in a word about punctuation. In English it is not
> permissible to put a comma between the verb and its object*. It seems to be
> required in German, but it destroys the natural flow in English. Thus, your
> first sentence quoted above should not include a comma.
> 
> HTH.
> 
> *   Sometimes you'll see a pair of commas there, setting off a parenthetical
> expression, but by the nature of those, they don't really contribute to the
> sentence, merely slipping a by-the-way phrase because it fits.

"...slipping in..."

Even Homer nods.  :(

-- 
Regards,
Peter.

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Ashley Dixon]

On Sun, Apr 05, 2020 at 10:17:41AM +0200, tu...@posteo.de wrote:
> Here /boot changes from fat32 to ext2. 
> Since this is my first U/EFI system I am a little confused.

Good morning Meino,

For U.E.F.I., the boot partition (/dev/sda2) must be FAT32. In your fstab file,
this is written as (the last three arguments may vary for your system):

/dev/sda2 /boot vfat defaults,noatime 0 2
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Using_UEFI

A conversation about the (sometimes-interchangeable) uses of "fat" vs. "vfat",
see https://docs.microsoft.com/en-us/previous-versions//cc750354(v=technet.10)

Regarding your question last night on the use of ellipses, unfortunately your
e-mail server (posteo.de) does not like my (domestic) I.P.\ address, and thus
assumed it spam when I tried to reply. I doubt the fine people of gentoo-user
will have much regard for a conversation about English linguistics. If you would
like to white-list my domain and I.P.\ (mail.suugaku.co.uk, suugaku.co.uk, and
90.193.124.236), I'll re-send in a few hours.

In short, I included an example of ellipses because as you are a non-native
English speaker, I did not want to cause undue confusion if you did not know the
meaning of the word 'ellipses'. That is all; no hidden meanings :)

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature

[OT] Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[Peter Humphrey]

On Saturday, 4 April 2020 20:59:56 BST tu...@posteo.de wrote:

> I have some problems to understand, whether I understood...
> 
> In the german language the "'s are often used to express the
> opposite of what is written in words. For example:
> 
> What a "nice" weather it is...!
> 
> will say:
> 
> For heavens sake, what the hell all this rain is coming
> from!!!???

It's the same in English, except that "weather" is an uncountable noun, so you 
can't have "a weather" - it's just "weather".

I'd like to put in a word about punctuation. In English it is not permissible 
to put a comma between the verb and its object*. It seems to be required in 
German, but it destroys the natural flow in English. Thus, your first sentence 
quoted above should not include a comma.

HTH.

*   Sometimes you'll see a pair of commas there, setting off a parenthetical 
expression, but by the nature of those, they don't really contribute to the 
sentence, merely slipping a by-the-way phrase because it fits.

-- 
Regards,
Peter.

Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?

[tuxic]

On 04/04 03:56, Grant Taylor wrote:
> On 4/4/20 11:34 AM, tu...@posteo.de wrote:
> > Hi,
> 
> Hi,
> 
> > I am currently preparing a new harddisc as home for my new Gentoo
> > system.
> > 
> > Is it possible to recreate exactlu the same pool of
> > applications/programs/libraries etc..., which my current system have -
> > in one go?
> 
> Baring cosmic influences, I would expect so.
> 
> > That is: Copy  from the current system into the chroot
> > environment, fire up emerge, go to bed and tommorow morning the new
> > system ready...?
> > 
> > Does this  exists and is it reasonable to do it this way?
> > 
> > Thanks for any hint in advance!
> 
> I think that any given system is the product of it's various components.
> Change any of those components, and you change the product.
> 
> I see the list of components as being at least:
> 
>  · world file
>  · portage config (/etc/portage)
> · USEs
> · accepted keywords
> · accepted licenses
>  · portage files (/usr/portage)
> · this significantly influences the version of packages that get
> installed, which is quite important
>  · kernel
> · version
> · config
> 
> Copying these things across should get you a quite similar system.  I
> suspect you would be down to how different packages are configured.
> 
> But the world file is only one of many parts that make up the system.
> 
> I didn't include distfiles because theoretically, you can re-download files.
> However, I've run into cases where I wasn't able to download something and
> had to transfer (part of) distfiles too.
> 
> If you're going to the trouble to keep a system this similar, why not simply
> copy the system from one drive / machine to another?
> 
> 
> 
> -- 
> Grant. . . .
> unix || die


Hi,

a new morning... :)

Being on the way to install/setup the base system (mostly getting
stage3 uptodate) I came accross kinda inconsistency -- or at least 
it looks like for me.

The system uses a 3T harddisc (and later a SSD) and therefore GPT.
GPT is the sister/brother of an U/EFI boot.

For that the documentation (AMD64 handbook):
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Using_UEFI

says:
Default partitioning scheme
Throughout the remainder of the handbook, the following partitioning scheme 
will be used as a simple example layout:
Partition   Filesystem  SizeDescription
/dev/sda1   (bootloader)2M  BIOS boot partition
/dev/sda2   ext2 (or fat32 if UEFI is being used)   128MBoot/EFI system 
partition
/dev/sda3   (swap)  512M or higher  Swap partition
/dev/sda4   ext4Rest of the diskRoot partition

and later on at https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System

FILE /etc/fstabA full /etc/fstab example

/dev/sda2   /bootext2defaults,noatime 0 2
/dev/sda3   none swapsw   0 0
/dev/sda4   /ext4noatime  0 1
  
/dev/cdrom  /mnt/cdrom   autonoauto,user  0 0

Here /boot changes from fat32 to ext2. 

Since this is my first U/EFI system I am a little confused.

Currentlu it looks like the vmlinuz binaries will be installed on 
a FAT32 filesystem. Since the kernel can be launched from a ext4
filesystem I cannot see, why this have to be a FAT32 filesystem.

My plan (if this is possible), is to U/EFI-boot grub, from which
I can select the kernel in question as it has been on my old
system (MBR based).

My current partition table looks like (only relevant parts shown):

Number  Start   End SizeFile system NameFlags
 1  1049kB  3146kB  2097kB  grubbios_grub
 2  3146kB  137MB   134MB   fat32   bootboot, esp
 3  137MB   674MB   537MB   linux-swap(v1)  swap
 4  674MB   269GB   268GB   ext4root

What did I messed up here?

Cheers!
Meino