Re: [gentoo-user] Re: Keep getting LC_ALL error during install.

[Eli Schwartz]

On 6/16/24 7:22 PM, Wols Lists wrote:
> On 16/06/2024 23:39, Nuno Silva wrote:
>>> And of course, all the rules get bent by the various
>>> manufacturers. Bear in mind that basic EFI predates vFAT so even in
>>> UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
>>> nothing stopping GNU's OpenBIOS project or whatever it is using
>>> ext4. But vFAT is the official "lowest common denominator" which
>>> everything must support if it's not "single vendor for hardware and
>>> software". Which is why, of course, MS can't play fun and games - if
>>> they say Windows won't support vFAT they'll get hammered for
>>> anti-trust.
> 
>> But there are systems using exFAT, right? You mean UEFI firmwares will
>> happily accept other filesystems?
> 
> I don't know. But the formal specification of UEFI says it must accept
> vFAT (I believe exFAT was not acceptable because Microsoft had patented
> it). It does not say it can't accept other stuff. Which is why Apple
> doesn't use vFAT.
> 
> And it explicitly states the version of vFAT. I don't know which
> version, but it's along the lines of "version X dated Y", so that is
> locked in stone.
> 
> So basically, the UEFI spec says it CAN accept multiple filesystems, but
> it MUST accept vFAT if it wants the moniker "Universal". So unless (and
> probably even if) it's Apple hardware, it does support vFAT.


https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format

"""
EFI encompasses the use of FAT32 for a system partition, and FAT12 or
FAT16 for removable media. The FAT32 system partition is identified by
an OSType value other than that used to identify previous versions of
FAT. This unique partition type distinguishes an EFI defined file system
from a normal FAT file system. The file system supported by EFI includes
support for long file names.
"""

It is permissible to additionally ship your own custom UEFI firmware
with arbitrary filesystem drivers that the specification does not
mandate support for, and Apple does this, but since Apple has to follow
the UEFI spec they support FAT as well.

You will notice upon reading, that UEFI mandates support for fat 12, but
permits a conforming implementation only support it for "removable media".

The firmware MUST support filesystem drivers for fat 12 / 16 / 32 in
order to satisfy this requirement, but is allowed to decline to use the
12 / 16 drivers unless the drive type is "removable media".

What that means in practice isn't obvious. But I somehow doubt any
firmware vendor is adding extra code to exercise their right to reject
the use of a driver they already had to commit to providing.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Keep getting LC_ALL error during install.

[Wols Lists]

On 16/06/2024 23:39, Nuno Silva wrote:

And of course, all the rules get bent by the various
manufacturers. Bear in mind that basic EFI predates vFAT so even in
UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
nothing stopping GNU's OpenBIOS project or whatever it is using
ext4. But vFAT is the official "lowest common denominator" which
everything must support if it's not "single vendor for hardware and
software". Which is why, of course, MS can't play fun and games - if
they say Windows won't support vFAT they'll get hammered for
anti-trust.



But there are systems using exFAT, right? You mean UEFI firmwares will
happily accept other filesystems?


I don't know. But the formal specification of UEFI says it must accept 
vFAT (I believe exFAT was not acceptable because Microsoft had patented 
it). It does not say it can't accept other stuff. Which is why Apple 
doesn't use vFAT.


And it explicitly states the version of vFAT. I don't know which 
version, but it's along the lines of "version X dated Y", so that is 
locked in stone.


So basically, the UEFI spec says it CAN accept multiple filesystems, but 
it MUST accept vFAT if it wants the moniker "Universal". So unless (and 
probably even if) it's Apple hardware, it does support vFAT.


Cheers,
Wol

Re: [gentoo-user] Re: (EE) AddScreen/ScreenInit failed for driver 0 [SOLVED]

[Michael]

On Tuesday, 11 June 2024 20:17:44 BST n952162 wrote:
> On 6/11/24 17:58, n952162 wrote:
> > Am I forgetting something ?
> 
> Yes. x11-drivers/xf86-video-intel

This package will be brought in as a dependency by emerge, as long as you have 
specified the correct VIDEO_CARDS="" drivers[1] in your make.conf and then 
emerged x11-base/xorg-server.[2]

Therefore it is not xf86-video-intel you forgot, but adding the necessary in 
make.conf.

[1] https://wiki.gentoo.org/wiki/Intel
[2] https://wiki.gentoo.org/wiki/X_server


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

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 3:33 PM Wols Lists  wrote:
>
> On 05/06/2024 20:15, Meowie Gamer wrote:
> > I must've taken too long to join the mailing list because I missed the 
> > first part of whatever's happening here. How did this turn from python 3.12 
> > to a conversation about USE?
> >
>
> Because they're using USE or whatever to force packages to stay on 3.11,
> because they won't build with 3.12.
>
> So it's not necessarily about USE, but about the tactics people use to
> make emerge work the way they want. It might be MASK, or any of the
> other package... directories.

It is a bit more than that.  Even if you never touch
/etc/portage/package.use, you effectively will have USE flags set on
packages that involve python simply due to the profile (and the change
therein).  That is why the news item has you put -* at the start of
the setting if you're overriding it - otherwise you'll just be
appending to the profile setting.

While these do end up setting USE flags, you should still set the USE
expand variables as directed in the news item and documentation, and
not manipulate the USE flags directly.

-- 
Rich

Re: [gentoo-user] Re: python 3.12 update

[Joost Roeleveld]

--- Original message ---
From: Grant Edwards 
To: gentoo-user@lists.gentoo.org
Date: Wed, 05 Jun 2024 22:07:06 +0200



On 2024-06-05, Wols Lists  wrote:

On 05/06/2024 13:12, Eli Schwartz wrote:

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


Ie people like me who don't give a monkeys about python, and  
consider it a necessary evil.


I care quite a bit about Python and do a fair amount of developemnt in
Python. Howver, I don't (at this point) give a monkey's about 3.12 vs
3.11, so I'm just going to delay the 3.12 upgrade on all my machines
except for the one where I got stuck after step 1 of the now-famouse
"3 step upgrade process". :)

That one machine seems to be working fine (though it's still missing a
few packages that I removed because the build failed with 3.12). So
I'm going to leave it where it is (possibly reinstalling the missing
packages as I run into the need for them).

At some point, emerge -auvND will complain because some installed
package doesn't support 3.11 any longer — and then I'll upgrade to
3.12.


Except, if you use Python for development, it's slotted, so you can  
install any version you need (as long as it's in portage or an overlay).


The issue here is the devs insistence on upgrading to 3.12 before all  
the packages are ready for this.


In all this, I have yet to see a good reason apart from "Oooh... shiny!"

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I see, thanks for clearing it up.

Meowie

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Meowie Gamer wrote:
> I must've taken too long to join the mailing list because I missed the first 
> part of whatever's happening here. How did this turn from python 3.12 to a 
> conversation about USE?
>
>


Because depending on what path you took to deal with this, you could end
up with entries in package.use for python 3.11. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 20:15, Meowie Gamer wrote:

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?



Because they're using USE or whatever to force packages to stay on 3.11, 
because they won't build with 3.12.


So it's not necessarily about USE, but about the tactics people use to 
make emerge work the way they want. It might be MASK, or any of the 
other package... directories.


Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Wols Lists wrote:
> On 05/06/2024 13:28, Rich Freeman wrote:
>> Implementing dynamic USE management would take somebody a fair bit of
>> effort, and for all I know it would make every emerge you run take an
>> hour to recompute the dependency tree.  The ability to configure USE
>> flags, along with the ability to dynamically decide the version of
>> dynamically linked packages, makes Gentoo have a dependency tree that
>> is MUCH larger than basically any other distro out there.  This is why
>> portage takes so long to decide what to install compared to basically
>> everything else.
>
> What I at least try to do is use "autounmask-write", or whatever the
> appropriate option is. This does I believe flag individual versions of
> whatever.
>
> Then I DON'T let etc-update append the changes to J Random File in
> whatever package... directory is appropriate !!!
>
> I rename the ._ file to usually the name of the package I'm interested
> in, or maybe the current date, or whatever. Point is, I don't get some
> humungous file full of assorted unrelated dependencies. And then when
> I'm bored I go through deleting loads of files maybe 6 months old or
> more. Seeing as the packages have usually been replaced by then, it
> rarely affects anything.
>
> Yes it's a minor pain I have to go through this for pretty much every
> package update if I've got a problem package, but I do a --update once
> a week at most, so it's very little hassle.
>
> And occasionally I'll add the flag to make.conf, instead ... :-)
>
> Cheers,
> Wol
>
>


Don't forget eix-test-obsolete which will find and list entries that are
no longer needed.  Bad thing is, it doesn't seem to say which file it is
in when you use a directory.  It just says the type of file, *.use,
*.mask, *.keyword etc. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 13:28, Rich Freeman wrote:

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.


What I at least try to do is use "autounmask-write", or whatever the 
appropriate option is. This does I believe flag individual versions of 
whatever.


Then I DON'T let etc-update append the changes to J Random File in 
whatever package... directory is appropriate !!!


I rename the ._ file to usually the name of the package I'm interested 
in, or maybe the current date, or whatever. Point is, I don't get some 
humungous file full of assorted unrelated dependencies. And then when 
I'm bored I go through deleting loads of files maybe 6 months old or 
more. Seeing as the packages have usually been replaced by then, it 
rarely affects anything.


Yes it's a minor pain I have to go through this for pretty much every 
package update if I've got a problem package, but I do a --update once a 
week at most, so it's very little hassle.


And occasionally I'll add the flag to make.conf, instead ... :-)

Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/5/24 2:05 PM, Grant Edwards wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
> 
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.


FWIW, I do think that for a large percentage of users, the lagging
packages simply aren't relevant to their use cases so it would indeed work.

Regardless, the purpose of the 3-step process I think is just to ensure
that portage doesn't trip while scheduling the rebuilds. If you are
getting dependency conflicts with the one-step process (emerge -puDU
@world) then steps 2 and 3 are likely not going to be able to be fully
carried out.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Arve Barsnes]

On Wed, 5 Jun 2024 at 20:05, Grant Edwards  wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
>
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.

Maybe I've been using gentoo too long, but I never assumed these three
steps were a 'single upgrade' recipe, I assumed each step were to be
undertaken as the portage tree allowed.

Reading the news item again, I see that no such thing is implied, but
perhaps it should have been? Otherwise, what is the point of these
steps as opposed to the automatic upgrade portage initially attempts?

The only way it is safer is if you have a complete functioning system
between each step, so I naturally assumed that there could be waiting
between each step to allow the tree to come to an upgradeable state.
Maybe some wording to that effect should be added when the 3.13 update
rolls around.

Either way, I went for the "bunch of 3.11 stuff in package.use" since
I "enjoy" that kind of process, so I wasn't impacted.

Regards,
Arve

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 6:41 AM Dr Rainer Woitok  wrote:
>
> And no,  I don't buy  the point of view  that it's the responsibility of
> the developers  when my personal set  of USE flags suddenly  causes con-
> flicts.
>

Agree, but keep in mind that having personal sets of USE flags is
basically a necessity in Gentoo, and not a choice, because Gentoo does
not dynamically manage USE dependencies.

On any distro, including Gentoo, if you manually installed the
dependencies of every package you use explicitly, you'd probably end
up with a hopeless mess of dependency conflicts within a few months.
Everybody who has used Linux for any period of time understands that
this is a bad practice, and you should explicitly install the packages
you directly use, and let the package manager dynamically manage their
dependencies.  Then when a dependency becomes obsolete and is
replaced, the updates will happen automatically without the user
needing to worry about them.

Gentoo does this with package/version dependencies, but not with USE
flag dependencies.  If a package requires some other package to be
built with a particular USE flag, then portage will output an error,
and you will need to put an entry in package.use to manually specify
the USE configuration, and that will resolve the conflict. Then 5
years later you'll get some mysterious error due to that USE flag
setting being obsolete, and you have no idea why you even had it in
the first place unless you took meticulous notes, because the setting
doesn't reflect your own preference, but the requirements of some
package, which might be so far down the dependency tree that you don't
even know what it does.

Python version settings are just fancy ways of expressing USE
dependencies.  Unless you develop things in Python, you probably don't
care what versions of Python you have installed, and it is reasonable
to expect that the package manager or distro just takes care of this
for you.  Gentoo does not.

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.

It is this clash of expectations vs reality that causes many
frustration, and this is understandable.  That said, improving the
situation is a lot of work, whether this is in the form of a lot of
coordination to deal with the lack of dynamic USE dependencies, or the
effort to implement this feature in the package manager (which has
been discussed here and there for a decade or so).  You can't fault
volunteers for not working on things that they aren't interested in
working on.  That said, I do appreciate the frustration people have,
personally.  This is just one of those things you need to understand
about Gentoo, and then weigh the pros vs the cons when you choose what
distro to use.  If you want a distro that will just accept daily
updates with zero fuss, that isn't Gentoo.

-- 
Rich

Re: [gentoo-user] Re: python 3.12 update

[Dr Rainer Woitok]

Grant,

On Tue, 4 Jun 2024 17:00:29 - (UTC) you wrote:

> ...
> I don't see how (even in theory) steps 2 and 3 can work when you have
> packages installed that won't build with 3.12.

That depends  on your definition  of "work".   It occurs even when doing
normal updates that you run into a USE flag conflict  you have to solve.
If you call this a "failed" upgrade  and stop there,  well, that's up to
you.  Others simply roll up their sleeves, investigate and change or add
a USE flag.  Here the problem was NOT that Python 3.11 had vanished, but
just that Python 3.12 had become the new default.  So a finite number of
USE flag changes solved this problem.

And no,  I don't buy  the point of view  that it's the responsibility of
the developers  when my personal set  of USE flags suddenly  causes con-
flicts.

Sincerely,
  Rainer

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/4/24 11:04 PM, Grant Edwards wrote:
> On 2024-06-04, Eli Schwartz  wrote:
>> If a package claimed to support python 3.12 and nonetheless failed to
>> build with it, that's a bug in the package -- can you provide more details?
> 
> IIRC, the first one was pycxx.  The build faild during the config
> step.  I uninstalled it (which meant I also had to uninstall pysvn,
> which I think means that meld is going to stop working).


Thanks for the report. This was migrated to python 3.12 in
https://bugs.gentoo.org/929486 and indeed it builds fine for me.

However, it is very obvious, *to me*, why it failed for you (even
without build logs). The package doesn't have a build dependency on the
dev-python/setuptools package, and python 3.12 removed a standard
library module (distutils) which is henceforth provided by this package.
And pycxx doesn't use pep517 mode either.

It's a trivial fix. You would have seen a build error that looked
something like

ModuleNotFoundError: No module named 'distutils'


I have queued the fix, so this should start working soon.

I do understand that this doesn't necessarily help you anymore, but
still. I am happy to at least make *one* package work reliably.

(Well, other packages too, just unrelated to your report.)


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/4/24 4:58 PM, Grant Edwards wrote:
> On 2024-06-04, Eli Schwartz  wrote:
> 
>> Note that it's not a build failure -- it is an upgrade calculation
>> failure. It fails before upgrading any packages since it knows it can't
>> resolve the dependencies.
> 
> I had plenty of both.


If a package claimed to support python 3.12 and nonetheless failed to
build with it, that's a bug in the package -- can you provide more details?


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 16:34, Dale wrote:

The way I did my last two rigs is this.  Find the fastest CPU.  Drop
down about 2 models.  That is not the fastest but very close to it but a
LOT cheaper.  Then buy a mobo and memory to go with it.  You get a
system that is likely close to 90% of the fastest you can get but a lot
cheaper.  Nowadays, even if you drop down a lot, it still costs a arm
and a leg and you get a lot less.


:-)

I look at tech as having two pricing models - the champagne model for 
the new stuff, where doubling performance doubles the price. And the 
coke model for older tech, where transport costs dominate, and different 
specs don't differ much in price. If I can get my tech at the "knee", 
where champagne prices become coke prices, I'm happy.


Cheers,
Wol

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Dale]

Wols Lists wrote:
> On 03/06/2024 12:07, MasterP wrote:
>> *NOTE*: Almost minutes after I wrote this, and before posting it, AMD
>> announced at Computex that the new gen will be available next month. So
>> maybe waiting for the new processors could be a good idea. Although
>> at the
>> launch, both the new boards and cpus are probably going to be very
>> expensive. Still, most new mid-to-high end boards will now have USB4
>> ports.
>
> My reaction - even if you buy the older version, this announcement
> will push down the "old tech" prices. Don't wait too long though, as a
> lot of stuff could be "end-of-lifed" and sold off cheap, rather than
> kept in production at a lower price point.
>
> Cheers.
> Wol
>
>


It is a delicate balance.  If you buy brand new tech, you pay for it,
BIG time.  If you drop down just a little, it is almost as fast but a
LOT cheaper. 

The way I did my last two rigs is this.  Find the fastest CPU.  Drop
down about 2 models.  That is not the fastest but very close to it but a
LOT cheaper.  Then buy a mobo and memory to go with it.  You get a
system that is likely close to 90% of the fastest you can get but a lot
cheaper.  Nowadays, even if you drop down a lot, it still costs a arm
and a leg and you get a lot less. 

Still a lot of think on.  I just wonder what prices will be like in 2 or
3 weeks.  Still, I do at least want AM5.  That AM4 is tempting tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 12:07, MasterP wrote:

*NOTE*: Almost minutes after I wrote this, and before posting it, AMD
announced at Computex that the new gen will be available next month. So
maybe waiting for the new processors could be a good idea. Although at the
launch, both the new boards and cpus are probably going to be very
expensive. Still, most new mid-to-high end boards will now have USB4
ports.


My reaction - even if you buy the older version, this announcement will 
push down the "old tech" prices. Don't wait too long though, as a lot of 
stuff could be "end-of-lifed" and sold off cheap, rather than kept in 
production at a lower price point.


Cheers.
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Waldo Lemmer]

On Sun, Jun 2, 2024, 13:28 Nuno Silva  wrote:

> (Well, one request I have is to please don't top-post in this
> list. That's not the common style in this list, and tends to be an
> approach mostly from the Microsoft and business worlds.)
>

Top-posting is the default in Gmail, and there's no intuitive way to avoid
doing it in the Gmail app.

By default, quoted text is hidden behind three dots. After expanding those
three dots, attempting to append text to the bottom results in that text
being included as part of the quoted text. To avoid that, the quoted text
first needs to be modified in some way. That allows a newline at the end to
escape out of the quoted portion.

Finally, the two empty lines before the quoted text should be removed.

Waldo

>

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Dale]

Nuno Silva wrote:
> Some people may prefer one method of communication to the other, and one
> thing that has perhaps been lacking in Gentoo is more people reading the
> mailing list, which might allow finding out about (and acting on) some
> issues sooner.

I agree with this.  I subscribe to the -dev mailing list for that
reason.  I see news items that are coming before they even available
elsewhere.  I just saw one on texlive having file collisions where you
must uninstall it first, then install the new version.  Having a heads
up that something outside the norm is coming can be handy. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Peter Humphrey]

On Sunday, 2 June 2024 01:54:08 BST Grant Edwards wrote:
> On 2024-06-01, Wol  wrote:
> > I've got news for you, there are quite a few weirdos on the list,
> 
> Hey! I resemble that remark.

Hey! Are you pinching my joke?

-- 
Regards,
Peter.


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

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Jun 1, 2024 at 1:16 PM Wol  > wrote:
> > I've got news for you, there are quite a few weirdos on the list, but it
> > adds spice!
> >
> Ah! I feel so at home!
>
> Thanks Wol!


+1.  I've been told I was weird all my life.  I kinda take offense when
someone says I'm not weird now.  ROFL 

Dale

:-)  :-) 

P. S.  On the subject of threads and Gentoo related.  I've decided to
use my credit card and buy the mobo, CPU and memory.  So, I'm going
through info that others posted in earlier threads and I'm about ready
to pull all my hair out.  To be blunt, none of the mobos are worth half
the price they want to charge.  I just watched a video of a guy ranting
about the exact same thing I'm thinking.  Make it flashy, use obscure
language to make something old sound new and raise the price to the
sky.  Oh, also put stuff on the mobo that should be handled with a PCIe
card, for those few who want that feature.  Don't forget, raise the
price some more for something the buyer doesn't want and intends to
disable at first boot up.  I realize this is basically a text only
mailing list.  Imagine a emoji thingy that is red from anger and very
frustrated.  I used to love to pick parts to build a system.  Now, I
just want it to be over with so I can end my misery.  It went from being
fun to being something akin to digging up a plugged sewer line, that you
know is going to spray you with some nasty stuff.  :-@

Expect another thread on this.  Whenever I get done letting the steam
escape from my eyes and ears. 

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Mark Knecht]

On Sat, Jun 1, 2024 at 1:16 PM Wol  wrote:
> I've got news for you, there are quite a few weirdos on the list, but it
> adds spice!
>
Ah! I feel so at home!

Thanks Wol!

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Kévin GASPARD DE RENEFORT]

Hello,

This was not a "moderator" like answer, more an advice: Since I started 
to translate some pages in French for the Wiki of Gentoo, I've already 
asked why IRC and not somewhere else, as **the mailing-list** dedicated 
to it. I do not link the oblivion that is an IRC channel, to be honest.


Somehow, it's (wiki's ML) unused, and more "regular" peoples, doing 
wiki's works since a while now, told me that… they do it on two places:


- #gentoo-w...@libera.chat

- Each discussion page for each dedicated subject.

I'm not on the #gentoo-wiki channel to explain how to do things at these 
contributors… doing it since years, or decade(s). I'm here to participate.


"Some complete" stranger to the list is happy to present himself: 
https://wiki.gentoo.org/wiki/User:Kgdrenefort


Joke aside, I just wanted to be nice and redirect another user to 
somewhere which could be, maybe, a better place to talk about it :).


Regards,
GASPARD DE RENEFORT Kévin

Le 01/06/2024 à 22:15, Wol a écrit :

On 31/05/2024 16:26, Nuno Silva wrote:

On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:

Is this not possible to go, as I said, on IRC or use the discussion 
page ?


This is not really the place for this topic, IMHO.


Why not? This is a Gentoo mailing list. Do you mean it should instead be
brought up in the Gentoo Documentation Project mailing list?

That was my sort-of reaction, but for somewhat different reasons. We 
have a regular poster on the list posting something a little bit 
weird, and then we have someone I've never seen on the list before, 
posting a moderator-like message.


Seriously? Some complete stranger to the list, telling off a regular 
for posting something weird?


I've got news for you, there are quite a few weirdos on the list, but 
it adds spice!


Cheers,
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Wol]

On 31/05/2024 16:26, Nuno Silva wrote:

On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:


Is this not possible to go, as I said, on IRC or use the discussion page ?

This is not really the place for this topic, IMHO.


Why not? This is a Gentoo mailing list. Do you mean it should instead be
brought up in the Gentoo Documentation Project mailing list?

That was my sort-of reaction, but for somewhat different reasons. We 
have a regular poster on the list posting something a little bit weird, 
and then we have someone I've never seen on the list before, posting a 
moderator-like message.


Seriously? Some complete stranger to the list, telling off a regular for 
posting something weird?


I've got news for you, there are quite a few weirdos on the list, but it 
adds spice!


Cheers,
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Jude DaShiell]

It went on irc.


--
 Jude 
 "There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo.
 Please use in that order."
 Ed Howdershelt 1940.

On Fri, 31 May 2024, Nuno Silva wrote:

> On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:
>
> > Is this not possible to go, as I said, on IRC or use the discussion page ?
> >
> > This is not really the place for this topic, IMHO.
>
> Why not? This is a Gentoo mailing list. Do you mean it should instead be
> brought up in the Gentoo Documentation Project mailing list?
>
>

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Michael]

On Tuesday, 28 May 2024 19:02:09 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-05-28, Dale  wrote:
> >> Grant Edwards wrote:
> >>> On 2024-05-21, Dale  wrote:
> > Here's my udev rules file that defines my network interface names
> > for the machine I'm on at the moment:
> > 
> > --/etc/udev/rules.d/70-my-persistent-net.rules
> > --- SUBSYSTEM=="net", ACTION=="add",
> > ATTR{address}=="2c:f0:5d:6f:10:af", NAME="net0" SUBSYSTEM=="net",
> > ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", NAME="net1"
> > -
> > >> 
> >> Got a little busy with my garden.  Found my first zucchini yesterday. 
> >> Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
> >> Did manage to create this rule tho.  This look reasonable?  I'm thinking
> >> it should be named something else tho.  It could clash with the usual
> >> name. 
> >> 
> >> # PCI device 0x11ab:0x4363 (Intel e1000e)
> >> #SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> >> ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
> >> KERNEL=="eth*", NAME="enp3s0"
> > 
> > Did my examples (with the MAC addresses and device names changed) not
> > work?
> > 
> >> I got the ATTR address from ifconfig.  I'm not real sure on the other
> >> ATTR variables tho.
> > 
> > I don't use the other other ATTRs, ACTION, DRIVERS, or KERNEL and I
> > don't know why you added them, so I can't comment.
> > 
> > --
> > Grant
> 
> Well, I found one with google and sort of went by that.  Now that I read
> yours again, yours makes more sense, from what little I know.  o_O
> 
> Is ATTR address the same as Mac address?  If so, why not have the same
> names for all tools  How's this look?

An ATTR can be any of the identifying attributes of your particular NIC.  Take 
a look in /sys/class/net/ to find out the current name of the device, e.g. 
enp4s0, then look at its attributes:

udevadm info -a /sys/class/net/enp4s0/

You can use any attributes which *uniquely* identify the NIC, e.g. vendor/
device ID, MAC address, etc. to avoid misidentification.


> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:05:ca:42:17:39",
> NAME="dale0"
> 
> 
> I gave it a different name this time.  I'm assuming I'd need to reboot to
> test this or is restarting udev enough??

If it is a remote PC and you're using netifrc, you'll need to create a new 
symlink, e.g.:

ln -s /etc/init.d/net.lo /etc/init.d/net.dale0

You probably know you can stop the predictable device naming by adding to your 
kernel command line:

net.ifnames=0

If you only have one wired NIC, then it will pop up as eth0.


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

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-28, Dale  wrote:
>> Grant Edwards wrote:
>>> On 2024-05-21, Dale  wrote:
>>>
> Here's my udev rules file that defines my network interface names
> for the machine I'm on at the moment:
>
> --/etc/udev/rules.d/70-my-persistent-net.rules---
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
> NAME="net0"
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
> NAME="net1"
> -
>> Got a little busy with my garden.  Found my first zucchini yesterday. 
>> Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
>> Did manage to create this rule tho.  This look reasonable?  I'm thinking
>> it should be named something else tho.  It could clash with the usual
>> name. 
>>
>> # PCI device 0x11ab:0x4363 (Intel e1000e)
>> #SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>> ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
>> KERNEL=="eth*", NAME="enp3s0"
> Did my examples (with the MAC addresses and device names changed) not
> work?
>
>> I got the ATTR address from ifconfig.  I'm not real sure on the other
>> ATTR variables tho.
> I don't use the other other ATTRs, ACTION, DRIVERS, or KERNEL and I
> don't know why you added them, so I can't comment.
>
> --
> Grant

Well, I found one with google and sort of went by that.  Now that I read
yours again, yours makes more sense, from what little I know.  o_O

Is ATTR address the same as Mac address?  If so, why not have the same
names for all tools  How's this look?

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:05:ca:42:17:39", 
NAME="dale0"


I gave it a different name this time.  I'm assuming I'd need to reboot to test 
this or is restarting udev enough?? 

Dang it's humid outside.  I feel like I need diving gear out there so I can 
breathe.  O_O 

Dale 

:-)  :-)  

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>>> Here's my udev rules file that defines my network interface names
>>> for the machine I'm on at the moment:
>>>
>>> --/etc/udev/rules.d/70-my-persistent-net.rules---
>>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
>>> NAME="net0"
>>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
>>> NAME="net1"
>>> -
>> Examples do help a lot.  I do use the enp* naming scheme.  My
>> understanding, that is the "new" way.
> The suffix for those enp* names comes from the PCI bus subsystem based
> on bus number, slot number, etc.  [Yes, slot number apparently does
> change based on what PCIe cards are present. No, that doesn't make
> sense to me either]
>
>> Based on your config, I would need to change the NAME= to enp* names
>> and that would correct that.
> I suppose you could, but I would not use enp* names. Those could
> conflict with the autogenerated names.
>
>> Where you have ATTR, is that a quote or did you edit to remove a
>> number, MAC address, IP or something? 
> What I posted is exactly what's in the file
> (without the --- delimiters).
>
> Here's more documentation:
>
> https://wiki.gentoo.org/wiki/Udev
> https://wiki.archlinux.org/title/udev
> https://wiki.archlinux.org/title/Network_configuration#Change_interface_name
>
> [The arch Wiki is always a good fallback if the Gentoo manual/Wiki
> don't have what you're looking for.]
>
>> If it is one of those, where do I find that info?  I checked
>> ifconfig and didn't see a MAC address.  I also checked lspci -v. 
>> I'm not sure where you get the needed info from.   BTW, right now,
>> I'm on my main rig. 
> The only thing you need to change from my example would be the mac
> address(es) (e.g. 2c:f0:5d:6f:10:af) and the names (e.g. net0).
>
>> I have the package net-misc/networkmanager installed.  Most likely
>> pulled in by something else.  Could I use it to configure this? 
> Possibly, I don't use networkmanager and don't know how it works on
> Gentoo.  I use the default Gentoo netifrc scheme
> https://wiki.gentoo.org/wiki/Netifrc.
>
>> I also have KDE installed on the NAS box, it is also a backup rig in
>> case my main rig dies.  It may have a GUI that I could use.  I'm not
>> opposed to the command line way tho.  Biggest thing, copy and paste
>> would be nice. 
> I don't know much of anything about KDE.
>
> --
> Grant

Got a little busy with my garden.  Found my first zucchini yesterday. 
Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
Did manage to create this rule tho.  This look reasonable?  I'm thinking
it should be named something else tho.  It could clash with the usual
name. 

# PCI device 0x11ab:0x4363 (Intel e1000e)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="enp3s0"

I got the ATTR address from ifconfig.  I'm not real sure on the other
ATTR variables tho.

I did this on my main rig.  It is commented out at the moment.  I'll use
it as a guide on the NAS box tho.  May enable this on my main rig, just
so they all the same.

Ironically, I removed the net.enp* from the default runlevel and put
dhcpd back.  It starts no matter where the card is located with that. 
It just sees it, starts it and carries on.  Still, I'd like all my
installs to be done the same way.  It's hard enough to remember how to
do things.  :/

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Sat, May 25, 2024 at 3:14 PM Grant Edwards 
wrote:
>
> On 2024-05-24, Mark Knecht  wrote:
>
> > The unit showed up today and was a breeze to set up and get running
> > at a basic level. The device requires an app on my phone.
>
> That sets of an alarm for me.
>
> > The app is available for Android and Apple but not available for the
> > Amazon Fire tablet.
>
> Good luck...  I avoid products like that. There have been too many
> "smart" things in the past that required an app -- then the app
> stopped working two or three years later. The purchaser of the thing
> now has a useless lump, and has to start shopping for a replacement.

Yeah, that's a reasonable point of view and one I hadn't considered.

Cheers.
Mark

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Fri, May 24, 2024 at 1:25 PM Tsukasa Mcp_Reznor 
wrote:
>
> For what it's worth I've been using gerbera for years, it'll pass-through
supported videos/codecs or you can set it up to transcode.   Highly
recommend it.  On my roku TV's I just use the roku media player, it'll see
UPnP servers just fine.

Thanks. Great info and much appreciated.

The unit showed up today and was a breeze to set up and get running at a
basic level. The device requires an app on my phone. The app is available
for Android and Apple but not available for the Amazon Fire tablet.

I was able to stream Internet Radio immediately. I then transferred
about 20% of my CD collection FLAC files to a flash drive and they play
fine and sound great. I am currently using the audio output on the unit but
will be testing my Schitt Modi DAC over the weekend, along with attempting
to connect to Plex.

One small problem I ran into is the unused flash drive I had in the flash
drive box had a default FAT filesystem on it and the FLAC library, ripped
mostly with k3b but also a little abcde, has characters in names that
aren't supported so I had some complaints getting things copied. I will say
that a big flash drive might be a great solution to not having to turn the
server on and having media available 24/7.

Cheers,
Mark

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Tsukasa Mcp_Reznor]

For what it's worth I've been using gerbera for years, it'll pass-through 
supported videos/codecs or you can set it up to transcode.   Highly recommend 
it.  On my roku TV's I just use the roku media player, it'll see UPnP servers 
just fine.

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Fri, May 24, 2024 at 8:26 AM Grant Edwards 
wrote:
>
> On 2024-05-24, Mark Knecht  wrote:
>
> > I'm a Plex user for video and have also ripped my CD
> > collection. Plex plays audio fine to TVs that have a Plex app but
> > apparently sometimes doesn't work well (as of yet untested by me) to
> > network streaming players.
>
> I never got the Plex app for Roku to work in a usable manner (and I
> think it eventually got discontinued?).  The Plex app in Kodi has
> always worked fine for me (though I haven't used it for probably about
> a year).  Plex also worked with other DLNA clients I've tried (Kodi, VLC).
>
> > While I don't know if the above will be a problem I've purchased a
> > network streaming player and will test it out over the weekend when it
> > arrives but if Plex doesn't work, or doesn't work well,
>
> I'd be interested to hear what player you got and how it works with Plex.
>

The Cambridge Audio MXN10 which is arriving today. Good reviews but I've
never listened to it so that will be interesting. I'll be using an older
NAD pre
and power amp and a pair of Theil 1.2's. I'll start without my old
subwoofer
and see what it's like but the 1.2's aren't the greatest at low-end so I'll
add the SW if necessary.

I'd like to start with my ripped CD content but for about $10/month it will
stream from Tidal and a few other sources so if I have any trouble serving
content then I'll get a Tidal subscription.

I'll report back on the Plex side as it goes as well as any other servers I
try out. I'm sorta leaning toward Gerbera for it's simplicity and clean
looking interface but it comes down to how the server works with the
C.A. StreamMagic app as this streamer has no front panel controls.

Thanks for the info.

Cheers,
Mark

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>
>>> If you want consisent network device names (even when you change
>>> hardware), you need to either
>>>
>>>  1. create udev rules that assign device names based on MAC addresses.
>>>
>>>  2. use a network configuration subsystem that assigns device names
>>> and configurations based on MAC addresses.
>> Do you, or someone else, know of a good howto on how to use MAC
>> addresses like that?  Given this thing is usually remotely accessed, I
>> really need it to be consistent with or without the card.  Maybe you
>> have a bookmarked link saved somewhere.  I'm on openrc to.  I'll google
>> around but you, or someone else here, may have a really good and simple
>> howto link. 
> The udev way is probably the most universal. Some distros will create
> udev rules automagically so that network interface names persist over
> hardware changes, but Gentoo doesn't.  Here's my udev rules file that
> defines my network interface names for the machine I'm on at the moment:
>
> --/etc/udev/rules.d/70-my-persistent-net.rules---
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
> NAME="net0"
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
> NAME="net1"
> -
>
> I used to use "ethN" instead of "netN", but those names are used
> internally by the kernel during startup, and people were warned not to
> use them in udev rules because of certain race conditions that might
> happen.  I never ran into problems using "ethN" names, but eventually
> decided not to push my luck.
>
> The network configuration route depends on what network configuration
> (and possibly init) system you use.  I know how to do it that way on
> Ubunutu (which is systemd based) using netplan...
>
> --
> Grant

Examples do help a lot.  I do use the enp* naming scheme.  My
understanding, that is the "new" way.  Based on your config, I would
need to change the NAME= to enp* names and that would correct that. 
Where you have ATTR, is that a quote or did you edit to remove a number,
MAC address, IP or something?  If it is one of those, where do I find
that info?  I checked ifconfig and didn't see a MAC address.  I also
checked lspci -v.  I'm not sure where you get the needed info from. 
BTW, right now, I'm on my main rig. 

I have the package net-misc/networkmanager installed.  Most likely
pulled in by something else.  Could I use it to configure this?  I also
have KDE installed on the NAS box, it is also a backup rig in case my
main rig dies.  It may have a GUI that I could use.  I'm not opposed to
the command line way tho.  Biggest thing, copy and paste would be nice. 
;-) 

I'm trying to hoe weeds in my garden at the moment.  Hoe a little, take
a break, then repeat.  I did sharpen the edge on my hoe tho.  If I touch
it, it's cut.  Makes it a lot easier. 

Thanks. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>> So they both show up.  When I try to start the network, it says:
>>
>> ERROR: Interface enp3s0 does not exist.
> Are you sure the network interface name hasn't changed?  What does
> "ifconfig -a" or "ip addr" show?
>
> After booting up, what does "dmesg | grep enp" show?
>
>> Ensure that you have loaded the correct kernel module for your hardware.
>>
>>
>> I find that odd since it obviously sees the card.  It's in the list
>> above after all.  So, it sees the card but can't see it.  0_o  Odd. 
> Identifying the presense of a PCI card and creating the device by
> which is is accessed are two different things.
>
>> I tried different slots for the SATA card and they all do the same
>> thing.  Wouldn't each slot have a different interrupt?
> No.  If cards are using legacy interrupts (most do) there are four
> interrupts (A,B,C,D) that are shared by all cards (just like there
> always were). Newer cards and motherboards can use something called
> MSI or MSI-X interrupts that aren't shared, but in my experience the
> use of those isn't very widespread.
>
>> It was at this point, I checked your suggestion.  I looked and noticed
>> that the network card was now at slot 4 not slot 3 like it used to be. 
>> So, I created a new link to slot 4.  The network came up.  So,
>> basically, it changed names as you suggested. I thought the purpose of
>> the enp* names was that they are consistent. 
> They are consistent through reboots.  They are not consistent if you
> change hardware.
>
>> Adding or removing cards wouldn't change the names of cards, like
>> network cards.
> Yes, it can.
>
>> It seems, in this case at least, the names can change.  Any way to
>> make adding the card not change this??  I tend to not have a monitor
>> or keyboard connected to this rig.
> If you want consisent network device names (even when you change
> hardware), you need to either
>
>  1. create udev rules that assign device names based on MAC addresses.
>
>  2. use a network configuration subsystem that assigns device names
> and configurations based on MAC addresses.
>
> --
> Grant

Do you, or someone else, know of a good howto on how to use MAC
addresses like that?  Given this thing is usually remotely accessed, I
really need it to be consistent with or without the card.  Maybe you
have a bookmarked link saved somewhere.  I'm on openrc to.  I'll google
around but you, or someone else here, may have a really good and simple
howto link. 

Well, learned something in the past couple days.  Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Neil Bothwick]

On Tue, 21 May 2024 06:51:51 -0400, Rich Freeman wrote:

>  I usually stick e*
> in my networkd config for the device name on single-NIC hosts.  If you
> have multiple NICs then I maybe there is a better way to go about it -
> maybe there is a network manager that can use more data from the NIC
> itself to track them.

systemd .network definitions can match on MAC address, if that helps.


-- 
Neil Bothwick

... "I dropped my toothpaste," Tom said, Crestfallen.


pgpGZMKuEyY6P.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[karl]

Dale:
...
> ERROR: Interface enp3s0 does not exist.
> Ensure that you have loaded the correct kernel module for your hardware.
...

 Do:
cat /proc/net/dev

Regards,
/Karl Hammar

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Rich Freeman]

On Tue, May 21, 2024 at 6:38 AM Dale  wrote:
>
> So, I created a new link to slot 4.  The network came up.  So,
> basically, it changed names as you suggested. I thought the purpose of
> the enp* names was that they are consistent.  Adding or removing cards
> wouldn't change the names of cards, like network cards.

Nope, persistent names are only persistent as long as there are no
hardware changes.

Under the old system if you had 10 NICs on a host, on any reboot some
of them could change names, at least in theory.  Under the new system
if you have 10 NICs on one host and don't touch the hardware, the
names will never change.

Under the old system if you had 1 NIC in a host, the name would never
change even if the hardware did change.  Under the new system if you
have 1 NIC in a host, the name could change if the hardware changes.

It is basically a tradeoff, which makes life much better if you have
multiple NICs, and marginally worse if you have only one.  However,
hardware changes than can cause a name change are probably rare, and
if you have only one NIC then ideally your network manager can just
use wildcards to not care so much about the name.  I usually stick e*
in my networkd config for the device name on single-NIC hosts.  If you
have multiple NICs then I maybe there is a better way to go about it -
maybe there is a network manager that can use more data from the NIC
itself to track them.

-- 
Rich

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-20, Dale  wrote:
>
> A 3.0 card is supposed to work fine in a 2.0 slot.
>
>> You, or anyone, have any idea why that card would kill my network? 
>> I suspect the card itself is fine.  It did see the drive.  I just
>> need the internet to work since it may be used in a NAS rig.
> Is it causing the network interface to not show up at all in lspci?
>
> Is it causing the network device name to change?
>
> Or is the network interface still detected, still named the same, and
> just doesn't send/receive packets?
>
> It could be some sort of interrupt sharing problem. Even with PCI
> express, cards still sometimes have to share interrupts.  Intel/IBM
> made that bad decision 45 years ago, and we're still suffering because
> of it.  If that the problem, sometimes you can avoid it by physically
> rearranging the cards.
>
> The later PCI hosts/boards finally came up with a way to avoid it, but
> a lot of cards still don't support that.
>
> --
> Grant


It does show up in lspci.  This is the output of lspci -tv.  The SATA
card is about 4 down.  The network is about 6 down. 



-[:00]-+-00.0  Advanced Micro Devices, Inc. [AMD/ATI] RX780/RX790
Host Bridge
   +-02.0-[01]--+-00.0  NVIDIA Corporation GK107 [NVS 510]
   |    \-00.1  NVIDIA Corporation GK107 HDMI Audio
Controller
   +-07.0-[02]00.0  ASMedia Technology Inc. ASM1166 Serial
ATA Controller
   +-09.0-[03]00.0  NEC Corporation uPD720200 USB 3.0 Host
Controller
   +-0a.0-[04]00.0  Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   +-11.0  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
   +-12.0  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
   +-12.1  Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB
OHCI1 Controller
   +-12.2  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
   +-13.0  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
   +-13.1  Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB
OHCI1 Controller
   +-13.2  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
   +-14.0  Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus
Controller
   +-14.1  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 IDE Controller
   +-14.2  Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia
(Intel HDA)
   +-14.3  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 LPC host controller
   +-14.4-[05]0e.0  Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link)
   +-14.5  Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
   +-18.0  Advanced Micro Devices, Inc. [AMD] Family 10h
Processor HyperTransport Configuration
   +-18.1  Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Address Map
   +-18.2  Advanced Micro Devices, Inc. [AMD] Family 10h
Processor DRAM Controller
   +-18.3  Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Miscellaneous Control
   \-18.4  Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Link Control



So they both show up.  When I try to start the network, it says:


ERROR: Interface enp3s0 does not exist.
Ensure that you have loaded the correct kernel module for your hardware.


I find that odd since it obviously sees the card.  It's in the list
above after all.  So, it sees the card but can't see it.  0_o  Odd. 

I tried different slots for the SATA card and they all do the same
thing.  Wouldn't each slot have a different interrupt?  It's been ages
since I had to deal with any of that.  Mostly it was on IDE drives and
the master/slave thing.  Oh, the other odd thing, it sees drives
connected to the SATA card as well. 

It was at this point, I checked your suggestion.  I looked and noticed
that the network card was now at slot 4 not slot 3 like it used to be. 
So, I created a new link to slot 4.  The network came up.  So,
basically, it changed names as you suggested. I thought the purpose of
the enp* names was that they are consistent.  Adding or removing cards
wouldn't change the names of cards, like network cards.  It seems, in
this case at least, the names can change.  Any way to make adding the
card not change this??  I tend to not have a monitor or keyboard
connected to this rig.

This is great tho.  I now have one extra SATA card already here. 
Another that I ordered a couple weeks ago that is still on the way.  I
also have two more from Amazon on the way.  Two 10 port cards, two 8
port ones.  That's 36 drives.  I think I'm all stocked up on SATA cards
now.  I need more hard drives, still.  According to du, I have 67TBs of
data here not including backups.  0_0

We got it all working.  It never occurred to me that the slot number
would change.  

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dr Rainer Woitok]

Michael,

On Thursday, 2024-05-16 17:46:04 +0100, you wrote:

> ...
> > The homepage returned by
> > 
> >$ eix --verbose sys-boot/elilo
> >* sys-boot/elilo
> > Available versions:  ~3.16-r5
> > ...
> >$
> > 
> > hints that this package is no longer maintained ... :-(
> > ...
> 
> Oh!  I haven't ever used it, but recalled its name and found it on the tree.  
> I suppose if it's stable and it works, it works whether maintained or not.

Well,  the "~" ahead of the  version number says  it's non-stable.   And
considering that booting is rather hardware, firmware and kernel related
and dependent, I personally would stay off of such a package :-/

Sincerely,
  Rainer

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 16 May 2024 17:41:20 BST Dr Rainer Woitok wrote:
> Michael,
> 
> On Thursday, 2024-05-16 09:26:39 +0100, you wrote:
> > ...
> > 
> > > > I liked lilo. And then it disappeared :-(
> > > 
> > > ...
> > > 
> > >  Still available and still working on non-uefi setups:
> > > https://packages.gentoo.org/packages/sys-boot/lilo
> > > 
> > > ...
> > 
> > There's also 'sys-boot/elilo' for EFI systems.
> 
> The homepage returned by
> 
>$ eix --verbose sys-boot/elilo
>* sys-boot/elilo
> Available versions:  ~3.16-r5
> Homepage:https://sourceforge.net/projects/elilo/
> Description: Linux boot loader for EFI-based systems such as
> IA-64 License: GPL-2
>$
> 
> hints that this package is no longer maintained ... :-(
> 
> Sincerely,
>   Rainer

Oh!  I haven't ever used it, but recalled its name and found it on the tree.  
I suppose if it's stable and it works, it works whether maintained or not.

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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dr Rainer Woitok]

Michael,

On Thursday, 2024-05-16 09:26:39 +0100, you wrote:

> ...
> > > I liked lilo. And then it disappeared :-(
> > ...
> >  Still available and still working on non-uefi setups:
> > https://packages.gentoo.org/packages/sys-boot/lilo
> > 
> > ...
> 
> There's also 'sys-boot/elilo' for EFI systems.

The homepage returned by

   $ eix --verbose sys-boot/elilo
   * sys-boot/elilo
Available versions:  ~3.16-r5
Homepage:https://sourceforge.net/projects/elilo/
Description: Linux boot loader for EFI-based systems such as 
IA-64
License: GPL-2
   $

hints that this package is no longer maintained ... :-(

Sincerely,
  Rainer

Re: [gentoo-user] Re: mtp cannot create directories on SD card on cellphone

[Walter Dnes]

On Thu, May 16, 2024 at 10:42:16AM +0100, Nuno Silva wrote

> Did anything change? Any tablet software upgrade? Did the MTP tool on
> the computer side change? Or perhaps the kernel, if it can influence
> this FUSE interaction somehow?

  Just the usual updates to world.
 
> At this point I'd consider testing with known good versions if possible
> (those that can run chown without that error).

  There are no "known good versions".

>  Is mkdir something that used to work too?

  I did some more dicking around, and it gets "curiouser and curiouser".
I mount the phone on /home/waltdnes/tablet then...

cd sdcard1

mkdir subdir
mkdir: cannot create directory ‘subdir’: Input/output error

  This happens even as root.. *BUT* even as a regular user I can
"cd /home/waltdnes/tablet/screenshots" and create+delete subdirectories
as well as files.  To summarize, I can do what I want in the "DCIM" and
"screenshots" subdirectories ("ownership" notwithstanding), but not in
the top-level "sdcard1" directory

===

[x8940][waltdnes][~] tabon
Device 0 (VID=1bbb and PID=f003) is a Alcatel OneTouch 6034R.
Android device detected, assigning default bug flags
[x8940][waltdnes][~] cd /home/waltdnes/tablet
[x8940][waltdnes][~/tablet] ll
total 24
drwxr-xr-x   4 root root  0 Dec 31  1969 .
drwxr-xr-x 144 waltdnes users 24576 May 16 10:40 ..
drwxr-xr-x   5 root root  0 Aug 30  4438198 sdcard
drwxr-xr-x   6 root root  0 Jun 21  4438201 sdcard1
[x8940][waltdnes][~/tablet] cd sdcard1
[x8940][waltdnes][~/tablet/sdcard1] ll
total 0
drwxr-xr-x 6 root root 0 Jun 21  4438201 .
drwxr-xr-x 4 root root 0 Dec 31  1969 ..
drwxr-xr-x 3 root root 0 Oct 10  2033 DCIM
drwxr-xr-x 2 root root 0 May 18  1950 LOST.DIR
drwxr-xr-x 2 root root 0 Sep 25  2019 screenshots
drwxr-xr-x 2 root root 0 Aug 19  1950 wlan_logs
[x8940][waltdnes][~/tablet/sdcard1] cd screenshots/
[x8940][waltdnes][~/tablet/sdcard1/screenshots] ll
total 0
drwxr-xr-x 2 root root0 Sep 25  2019 .
drwxr-xr-x 6 root root0 Jun 21  4438201 ..
-rw-r--r-- 1 root root 21669139 Aug  8  1934 walter.pdf
[x8940][waltdnes][~/tablet/sdcard1/screenshots] mkdir subdir
[x8940][waltdnes][~/tablet/sdcard1/screenshots] ll
total 0
drwxr-xr-x 3 root root0 Sep 25  2019 .
drwxr-xr-x 6 root root0 Dec 31  1969 ..
drwxr-xr-x 2 root root0 Dec 31  1969 subdir
-rw-r--r-- 1 root root 21669139 Aug  8  1934 walter.pdf
[x8940][waltdnes][~/tablet/sdcard1/screenshots] cd
[x8940][waltdnes][~] taboff

===

-- 
Roses are red
Roses are blue
Depending on their velocity
Relative to you

Re: [gentoo-user] Re: mtp cannot create directories on SD card on cellphone

[Michael]

On Thursday, 16 May 2024 10:42:16 BST Nuno Silva wrote:
> On 2024-05-16, Walter Dnes wrote:
> > On Wed, May 15, 2024 at 03:06:50PM -0700, Mark Knecht wrote
> > 
> >> Have you checked that the directory where you are attempting to
> >> do this is one that your account owns? I generally have to su - to
> >> root, create a directory at the top level, change it so that I own it and
> >> have rwx permissions, and then exit root. After that I can do what I
> >> want.
> >> 
> >   I have a short script ~/bin/tabon
> > 
> > [x8940][waltdnes][~] cat bin/tabon
> > #!/bin/bash
> > sudo /usr/bin/jmtpfs /home/waltdnes/tablet -o allow_other,auto_unmount,rw
> > #
> > # Only needed once
> > #sudo /bin/chown -R waltdnes:users /home/waltdnes/tablet
> > 
> >   The last (commented out) line *USED TO WORK*.  Now it spits out a
> > 
> > whole slew of...
> > 
> > /bin/chown: changing ownership of
> > '/home/waltdnes/tablet/sdcard1/blah_blah_blah': Function not implemented
> > 
> > ...one for each direcory and file.  I believe the phone formats the card
> > as either FAT32 or XFAT.
> 
> Did anything change? Any tablet software upgrade? Did the MTP tool on
> the computer side change? Or perhaps the kernel, if it can influence
> this FUSE interaction somehow?
> 
> At this point I'd consider testing with known good versions if possible
> (those that can run chown without that error). Is mkdir something that
> used to work too?
> 
> The "Function not implemented" looks off for something that used to work
> before. (Or was it failing silently before? If this is FAT* or exFAT,
> wouldn't ownership be a thing for the FUSE tool to set itself? Or does
> exFAT have the concept of ownership?)

FAT/exFAT do not support filesystem level user permissions and consequently 
you would get a "Function not implemented" error with chown.

When a USB device with a FAT/exFAT fs, is mounted with udisksctl they show up 
as:

$ lsblk -o PATH,TYPE,FSTYPE,OWNER,GROUP,MODE,MOUNTPOINT /dev/sdb1
PATH  TYPE FSTYPE OWNER GROUP MODE   MOUNTPOINT
/dev/sdb1 part vfat   root  disk  brw-rw /run/media/michael/CRUCIAL-8G

and the fs is mounted with the sticky bit so it writeable by the user:

$ ls -la /run/media/michael/CRUCIAL-8G/
total 2500976
drwxr-xr-x  2 michael michael  16384 Jan  1  1970  .
drwxr-x---+ 3 rootroot60 May 16 15:52  ..


exFAT looks the same if you have enabled the exFAT kernel driver, as opposed 
to using FUSE.

I don't have a device using MTP here to check how it is mounted over FUSE, but 
FUSE is meant to mount a device with the permissions of the user who mounts it 
AND the user can only mount on a mountpoint for which they have write 
permission.

However, there is a kernel bug if the default_permissions mount option has not 
been used, whereby results of the first permission check performed by the file 
system for a directory entry are cached and reused - even if the permissions 
have since changed - see here:

https://github.com/libfuse/libfuse

I do remember having some trouble creating directories on an SD card in a 
GARMIN GPS device.  I had to remove it and mount it on Linux to be able to 
work on it, but can't recall the details. 


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 16 May 2024 01:10:32 BST k...@aspodata.se wrote:
> Wol:
> > On 15/05/2024 11:40, Peter Humphrey wrote:
> > > I think whoever named grub had delusions of grandeur.  🙂  Anyway, I
> > > never let it near my systems.
> > 
> > I liked lilo. And then it disappeared :-(
> 
> ...
> 
>  Still available and still working on non-uefi setups:
> https://packages.gentoo.org/packages/sys-boot/lilo
> 
> Regards,
> /Karl Hammar

There's also 'sys-boot/elilo' for EFI systems.


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[karl]

Wol:
> On 15/05/2024 11:40, Peter Humphrey wrote:
> > I think whoever named grub had delusions of grandeur.  🙂  Anyway, I 
> > never let
> > it near my systems.
> 
> I liked lilo. And then it disappeared :-(
...

 Still available and still working on non-uefi setups:
https://packages.gentoo.org/packages/sys-boot/lilo

Regards,
/Karl Hammar

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 15/05/2024 11:40, Peter Humphrey wrote:

I think whoever named grub had delusions of grandeur.    Anyway, I never let
it near my systems.


I liked lilo. And then it disappeared :-(

Grub isn't that bad - it's just that insists on trying to do everything 
itself - and if you've got at all a strange setup it makes a complete 
hash of it.


LIKE GENTOO!

I've moaned about this before, but last time SUSE updated itself, it 
trashed grub.conf and left me with an unbootable system. And then gentoo 
sees that I've got an unmounted /boot and throws a complete and utter 
hissy fit because I told it not to touch it ...


Cheers,
Wol

Re: [gentoo-user] Re: Graphics configuration for a Ryzen 7 7700X chip and water cooling.

[Matt Connell]

On Wed, 2024-05-15 at 16:25 +, Grant Edwards wrote:
> You'll need kernel 5.18 and Mesa 22 plus recent firmware.
> 
> That article was almost 2 years old, so I'd be surprised if all those
> are not stable in Gentoo by now.

Mesa 22 is not.  Only version 24 is stable

:)

Re: [gentoo-user] Re: Encrypted drives, password generation and management howto, guide.

[Michael]

On Wednesday, 15 May 2024 15:37:22 BST Grant Edwards wrote:
> On 2024-05-15, Michael  wrote:

> > The Clipboard may be stored in RAM or cache of any applications
> > which use this method.
> 
> AFAICT, the clipboard contents is stored in the X server. When you
> cut/copy something, the application sends that something to the X
> server where it's stored.  When that application exits, the clipboard
> contents are still there in the X server, and can still be requested
> by other applications who want to do a "paste".

What you write makes sense.

I am not sure what happens in Wayland, where application windows are supposed 
to be isolated.  I recall in earlier days the Primary selection would not work 
between windows, which was rather frustrating.  I think at present the Plasma 
desktop clipboard application acts as a mediator, probably engaging Xwayland - 
but I am not sure.

There are quite a few settings in Plasma's clipboard application to configure 
interoperability between Primary & Clipboard selection and can be set to save 
the Primary selection in the Clipboard section and its history if so desired.

With my current settings I can middle click to paste a Primary selection into 
Konsole, but Shift+Insert which works with Xterm & friends does not work with 
Konsole.


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Peter Humphrey]

On Wednesday, 15 May 2024 08:42:14 BST Wols Lists wrote:
> On 02/05/2024 11:46, Peter Humphrey wrote:
> > When I started using Linux, the received wisdom was to keep a separate
> > /boot, and leave it unmounted during normal operation. The idea was that
> > a successful hacker would not, supposedly, be able to corrupt the kernel
> > ready for a reboot into their system.
> 
> And you can't have /boot on your system partition if, like me, you have
> one instance of grub booting into several different OSs or distros ...
> Less so now, but having multiple distros on one system was a popular
> hobbyist pastime!

I think whoever named grub had delusions of grandeur.  :)  Anyway, I never let 
it near my systems.

-- 
Regards,
Peter.


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 11:46, Peter Humphrey wrote:

When I started using Linux, the received wisdom was to keep a separate /boot,
and leave it unmounted during normal operation. The idea was that a successful
hacker would not, supposedly, be able to corrupt the kernel ready for a reboot
into their system.


And you can't have /boot on your system partition if, like me, you have 
one instance of grub booting into several different OSs or distros ... 
Less so now, but having multiple distros on one system was a popular 
hobbyist pastime!


(One distro's system partition is another distro's data partion :-)

Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 10:35, Michael wrote:

Besides the automation this feature affords, I find it useful to know what a
partition contains without having to mount it.  On GPT labelled disks I make
use both of the Partition Type UUID and the Partition Name.  A quick glance at
the gdisk output and if need be its 'i' option has saved my day from
formatting the wrong partition more than once!  


Iirc from the days of kernel 1.3 and 2.x, the partition type is not used 
- at all - by linux itself. Dunno about other OSs.


As you pointed out, though, it is used by other tools, which use it to 
identify what the partition is *supposed* to be used for. For example, 
auto-assemble with raid.


I'm not sure, but for example I think swap will quite happily let you 
"mount" a non-swap partiton with swap-on. You can format an allegedly 
DOS or NTFS partition with ext, and linux won't care ...


Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Peter Humphrey]

On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
> Grant Edwards wrote:
> > OK, so 'boot' is for the Linux /boot directory.  I was just curious
> > since I had never used one.

When I started using Linux, the received wisdom was to keep a separate /boot, 
and leave it unmounted during normal operation. The idea was that a successful 
hacker would not, supposedly, be able to corrupt the kernel ready for a reboot 
into their system.

Old habits die hard, though, and besides, a separate /boot has been handy in 
the copious reinstallations I've been through.

> I've used one ever since I started using Linux and it's as much habit as
> anything.  Given the size of drives nowadays, I have started putting
> /usr and /var on the root partition.  When I build my new rig tho, odds
> are /var will be on its own partition.  That way if a log file goes
> wonky, it can fill it up and not really do any harm. 

I do that too. It also helps with backups and new installations.

-- 
Regards,
Peter.


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Michael wrote:
> On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
>> Grant Edwards wrote:
>>> On 2024-05-01, Dale  wrote:
 Grant Edwards wrote:
> The partition type code for 'swap' is wrong -- it should be
> 8200. According to the gdisk help info Linux /home is supposed to be
> 8302, but I've always used the same generic "Linux filesystem" type
> for both /home and root.
>
> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> or both?  [I've never used a separate partition for Linux /boot, I
> just use a /boot directory on the root FS.]
 I noticed the other day that some new ones was added.  I always leave it
 as 8300 and it works.  It even works for swap.  I dunno. 
> In the legacy DOS partition tables the space available was limited to 32 
> bits, 
> while the GPT table specification provides 128 bytes for each block entry.  
> The extra space can be used to store information related to the intended OS 
> usage of each partition, by adding the corresponding Partition Type UUID.
>
> This has a number of benefits, described here:
>
> https://uapi-group.org/specifications/specs/
> discoverable_partitions_specification/
>
> Besides the automation this feature affords, I find it useful to know what a 
> partition contains without having to mount it.  On GPT labelled disks I make 
> use both of the Partition Type UUID and the Partition Name.  A quick glance 
> at 
> the gdisk output and if need be its 'i' option has saved my day from 
> formatting the wrong partition more than once!  ;-)


I always use labels which show up with cgdisk.  If I'm unsure how I
partitioned a drive for some reason, I just check it with cgdisk to see
what is what.  I use labels even tho a lot of the time I put UUIDs in
fstab.  I do similar when using LVM as well. 

There is more than one way to organize things tho.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-05-01, Dale  wrote:
> >> Grant Edwards wrote:
> >>> The partition type code for 'swap' is wrong -- it should be
> >>> 8200. According to the gdisk help info Linux /home is supposed to be
> >>> 8302, but I've always used the same generic "Linux filesystem" type
> >>> for both /home and root.
> >>> 
> >>> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> >>> or both?  [I've never used a separate partition for Linux /boot, I
> >>> just use a /boot directory on the root FS.]
> >> 
> >> I noticed the other day that some new ones was added.  I always leave it
> >> as 8300 and it works.  It even works for swap.  I dunno. 

In the legacy DOS partition tables the space available was limited to 32 bits, 
while the GPT table specification provides 128 bytes for each block entry.  
The extra space can be used to store information related to the intended OS 
usage of each partition, by adding the corresponding Partition Type UUID.

This has a number of benefits, described here:

https://uapi-group.org/specifications/specs/
discoverable_partitions_specification/

Besides the automation this feature affords, I find it useful to know what a 
partition contains without having to mount it.  On GPT labelled disks I make 
use both of the Partition Type UUID and the Partition Name.  A quick glance at 
the gdisk output and if need be its 'i' option has saved my day from 
formatting the wrong partition more than once!  ;-)


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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-05-01, Dale  wrote:
>> Grant Edwards wrote:
>>
>>> The partition type code for 'swap' is wrong -- it should be
>>> 8200. According to the gdisk help info Linux /home is supposed to be
>>> 8302, but I've always used the same generic "Linux filesystem" type
>>> for both /home and root.
>>>
>>> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
>>> or both?  [I've never used a separate partition for Linux /boot, I
>>> just use a /boot directory on the root FS.]
>> I noticed the other day that some new ones was added.  I always leave it
>> as 8300 and it works.  It even works for swap.  I dunno. 
> If you have an entry in /etc/fstab for swap, it might not matter if
> the partition type is set to 'Linux swap' or not. I always set the
> swap parition type to 'Linux swap', and then it doesn't seem to matter
> if there's a swap entry in the fstab or not.

I tend to put everything in fstab.  It's the way it was when I started
and I just keep doing it that way.  It could be that it isn't needed
anymore tho. 


>> The /boot is where kernels and init thingys go.  Keep in mind, this is
>> on a old rig that has no idea what UEFI is.  When I build my new rig
>> later, I'll do a install from scratch anyway.  Also, it will go on a SSD. 
> OK, so 'boot' is for the Linux /boot directory.  I was just curious
> since I had never used one. 
>

I've used one ever since I started using Linux and it's as much habit as
anything.  Given the size of drives nowadays, I have started putting
/usr and /var on the root partition.  When I build my new rig tho, odds
are /var will be on its own partition.  That way if a log file goes
wonky, it can fill it up and not really do any harm. 


>> I mostly want to post so that a person can see the layout.  Really, the
>> first one is what a person wanting to use GPT on a old BIOS system needs
>> to see.  After that, they can do partitions anyway they want.
> Right.


I'm to the good part of the install now.  With the partition layout
shown earlier, I get this. 


(chroot) livecd / # grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
(chroot) livecd / #


When I did that before, it puked on my keyboard.  This time with that
little unformatted partition, it just installed it.  So, muddy waters
pretty clear now.  :-D 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-05-01, Dale  wrote:
>
>> OK.  One last update in case someone googles and runs up on this
>> thread.  I'm using gdisk to display this, because I think it will do
>> better in email.  If I use cgdisk, it is wider and will wrap more. 
>> This is what the partition table looks like for GPT, old BIOS and no
>> uefi thingy.  Just a straight forward and simple old school setup. 
>> Once the first one is done, the rest can be anything.
>>
>>
>> Number  Start (sector)    End (sector)  Size   Code Name
>>    1    2048 10239  4.0 MiB EF02  BIOS-boot
>>    2   10240    4204543  2.0 GiB 8300  boot
>>    3 4204544  12593151    4.0 GiB 8300  swap
>>    4    12593152    327165951   150.0 GiB   8300  root
>>    5   327165952   625141759   142.1 GiB   8300  home
> The partition type code for 'swap' is wrong -- it should be
> 8200. According to the gdisk help info Linux /home is supposed to be
> 8302, but I've always used the same generic "Linux filesystem" type
> for both /home and root.
>
> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> or both?  [I've never used a separate partition for Linux /boot, I
> just use a /boot directory on the root FS.]
>
> --
> Grant

I noticed the other day that some new ones was added.  I always leave it
as 8300 and it works.  It even works for swap.  I dunno. 

The /boot is where kernels and init thingys go.  Keep in mind, this is
on a old rig that has no idea what UEFI is.  When I build my new rig
later, I'll do a install from scratch anyway.  Also, it will go on a SSD. 

I mostly want to post so that a person can see the layout.  Really, the
first one is what a person wanting to use GPT on a old BIOS system needs
to see.  After that, they can do partitions anyway they want.  I just
hope I got it right.  Right now, I'm to the stage where I do a emerge
-auDN world.  On that old rig, may take a little bit.  It's not bad
tho.  Old rig has 6 cores now. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Dale wrote:
> One last update.  I found a video.  They were using gdisk but the
> crucial part, he got it to display the partition layout.  It was like I
> described as for as the alignment thing, tiny partition with ef02 and
> then carry on as usual from there. 
>
> I need to do this on a disk complete with notes, so I don't forget.  My
> brain is going fast.  One day, I'll forget how to turn the puter on. 
> :'(  I already forget what I went to the kitchen for, it's only 20 feet
> away.  :/
>
> Thanks again. 
>
> Dale
>
> :-)  :-)
>


OK.  One last update in case someone googles and runs up on this
thread.  I'm using gdisk to display this, because I think it will do
better in email.  If I use cgdisk, it is wider and will wrap more.  This
is what the partition table looks like for GPT, old BIOS and no uefi
thingy.  Just a straight forward and simple old school setup.  Once the
first one is done, the rest can be anything.


Number  Start (sector)    End (sector)  Size   Code Name
   1    2048 10239  4.0 MiB EF02  BIOS-boot
   2   10240    4204543  2.0 GiB 8300  boot
   3 4204544  12593151    4.0 GiB 8300  swap
   4    12593152    327165951   150.0 GiB   8300  root
   5   327165952   625141759   142.1 GiB   8300  home


I'm about to start a fresh install on this so if it isn't right, let me
know soon.  I did make it a little larger than everyone says it needs to
be since grub does seem to grow.  That should be bigger than I'll ever
need in the lifetime of this old rig anyway. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wol]

On 28/04/2024 17:40, Grant Edwards wrote:

On 2024-04-28, Grant Edwards  wrote:


With DOS disk lables, Grub uses empty space between the boot sector
and the first partition as a location to store it's core image file.
That empty space does not exist when using GPT disk label. When using
a GPT disk label, Grub requires that you need to create a "BIOS Boot"
or "Grub Boot" partition so that Grub has somwhere to store it's core
image[1].

And it bears repeating that the bios/grub boot partition only needs to
be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
_not_ the same as either

  1) The "boot" directory where the kernel images and grubs other files
 are installed within a Linux filesystem. [Which you still need
 when booting in Legacy/BIOS mode.]

   or

  2) The UEFI partition that's formated with a FAT filesystem and used
 in UEFI boot mode [which you don't need when booting in
 Legacy/BIOS mode.]

Note that, for new installs, I generally say always create a decent 
sized partition for UEFI, so if you want to change you can, although it 
sounds like in your case it probably doesn't matter :-)



Cheers,

Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Dale wrote:
> Michael wrote:
>> On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
>>> Grant Edwards wrote:
 On 2024-04-28, Grant Edwards  wrote:
> With DOS disk lables, Grub uses empty space between the boot sector
> and the first partition as a location to store it's core image file.
> That empty space does not exist when using GPT disk label. When using
> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
> or "Grub Boot" partition so that Grub has somwhere to store it's core
> image[1].
 And it bears repeating that the bios/grub boot partition only needs to
 be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
 _not_ the same as either

  1) The "boot" directory where the kernel images and grubs other files
  
 are installed within a Linux filesystem. [Which you still need
 when booting in Legacy/BIOS mode.]
   
   or
  
  2) The UEFI partition that's formated with a FAT filesystem and used
  
 in UEFI boot mode [which you don't need when booting in
 Legacy/BIOS mode.]
>>> I think I got a grasp on this now.  Basically, partitions should be like
>>> this. 
>>>
>>>
>>> First spot is the alignment thing.  Usually a few MBs or so and unused.
>> This is created automatically by the partitioning tool, in your case cgdisk, 
>> when you create the first partition on the disk and accept the default 
>> starting sector.
>>
>>
>>> Grub boot partition with ef02 setting, not to be formatted.
>>>
>>> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
>>> for memtest, bootable rescue image etc. 
>>>
>>> / or root partition that is around 150GBs or so.  Enough to expand a bit
>>> and includes /usr and /var.
>>>
>>> /home  rest of disk unless some needed for something else.
>>>
>>>
>>> Do you recall when running grub-install what that command looks like? 
>>> Lets say the Grub partition with ef02 setting is sda1, would it be
>>> grub-install /dev/sda1 or just sda and it finds the empty partition on
>>> its own?
>> The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
>> GRUB when you run grub-install and it will store its core.img in there.
>>
>> You install GRUB's boot.img in the MBR and therefore you have to specify the 
>> disk, NOT a partition, e.g.:
>>
>> grub-install /dev/sda
>>
>> This command should:
>>
>> 1. Install GRUB's boot.img in the MBR of /dev/sda.
>> 2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
>> partition', type EF02.
>> 3. Create directory /boot/grub to install all the grub fs drivers and files.
>>
>> If you have mounted /boot, all is well.  If you are repairing an 
>> installation 
>> from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
>> specify this in the CLI:
>>
>> grub-install --boot-directory=/mnt/gentoo/boot /dev/sda
>>
>> NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
>> partition' with cgdisk "... by setting the partition type to 0xEF02 and 
>> giving 
>> it a label of gptbios".
>>
>> https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT
>>
> That's what I was thinking.  I think I got it.  I need to make notes of
> this tho.  Before I forget.  :/ 
>
> Thanks to all.
>
> Dale
>
> :-)  :-) 
>


One last update.  I found a video.  They were using gdisk but the
crucial part, he got it to display the partition layout.  It was like I
described as for as the alignment thing, tiny partition with ef02 and
then carry on as usual from there. 

I need to do this on a disk complete with notes, so I don't forget.  My
brain is going fast.  One day, I'll forget how to turn the puter on. 
:'(  I already forget what I went to the kitchen for, it's only 20 feet
away.  :/

Thanks again. 

Dale

:-)  :-)

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Michael wrote:
> On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
>> Grant Edwards wrote:
>>> On 2024-04-28, Grant Edwards  wrote:
 With DOS disk lables, Grub uses empty space between the boot sector
 and the first partition as a location to store it's core image file.
 That empty space does not exist when using GPT disk label. When using
 a GPT disk label, Grub requires that you need to create a "BIOS Boot"
 or "Grub Boot" partition so that Grub has somwhere to store it's core
 image[1].
>>> And it bears repeating that the bios/grub boot partition only needs to
>>> be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
>>> _not_ the same as either
>>>
>>>  1) The "boot" directory where the kernel images and grubs other files
>>>  
>>> are installed within a Linux filesystem. [Which you still need
>>> when booting in Legacy/BIOS mode.]
>>>   
>>>   or
>>>  
>>>  2) The UEFI partition that's formated with a FAT filesystem and used
>>>  
>>> in UEFI boot mode [which you don't need when booting in
>>> Legacy/BIOS mode.]
>> I think I got a grasp on this now.  Basically, partitions should be like
>> this. 
>>
>>
>> First spot is the alignment thing.  Usually a few MBs or so and unused.
> This is created automatically by the partitioning tool, in your case cgdisk, 
> when you create the first partition on the disk and accept the default 
> starting sector.
>
>
>> Grub boot partition with ef02 setting, not to be formatted.
>>
>> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
>> for memtest, bootable rescue image etc. 
>>
>> / or root partition that is around 150GBs or so.  Enough to expand a bit
>> and includes /usr and /var.
>>
>> /home  rest of disk unless some needed for something else.
>>
>>
>> Do you recall when running grub-install what that command looks like? 
>> Lets say the Grub partition with ef02 setting is sda1, would it be
>> grub-install /dev/sda1 or just sda and it finds the empty partition on
>> its own?
> The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
> GRUB when you run grub-install and it will store its core.img in there.
>
> You install GRUB's boot.img in the MBR and therefore you have to specify the 
> disk, NOT a partition, e.g.:
>
> grub-install /dev/sda
>
> This command should:
>
> 1. Install GRUB's boot.img in the MBR of /dev/sda.
> 2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
> partition', type EF02.
> 3. Create directory /boot/grub to install all the grub fs drivers and files.
>
> If you have mounted /boot, all is well.  If you are repairing an installation 
> from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
> specify this in the CLI:
>
> grub-install --boot-directory=/mnt/gentoo/boot /dev/sda
>
> NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
> partition' with cgdisk "... by setting the partition type to 0xEF02 and 
> giving 
> it a label of gptbios".
>
> https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT
>

That's what I was thinking.  I think I got it.  I need to make notes of
this tho.  Before I forget.  :/ 

Thanks to all.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-04-28, Grant Edwards  wrote:
> >> With DOS disk lables, Grub uses empty space between the boot sector
> >> and the first partition as a location to store it's core image file.
> >> That empty space does not exist when using GPT disk label. When using
> >> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
> >> or "Grub Boot" partition so that Grub has somwhere to store it's core
> >> image[1].
> > 
> > And it bears repeating that the bios/grub boot partition only needs to
> > be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
> > _not_ the same as either
> > 
> >  1) The "boot" directory where the kernel images and grubs other files
> >  
> > are installed within a Linux filesystem. [Which you still need
> > when booting in Legacy/BIOS mode.]
> >   
> >   or
> >  
> >  2) The UEFI partition that's formated with a FAT filesystem and used
> >  
> > in UEFI boot mode [which you don't need when booting in
> > Legacy/BIOS mode.]
> 
> I think I got a grasp on this now.  Basically, partitions should be like
> this. 
> 
> 
> First spot is the alignment thing.  Usually a few MBs or so and unused.

This is created automatically by the partitioning tool, in your case cgdisk, 
when you create the first partition on the disk and accept the default 
starting sector.


> Grub boot partition with ef02 setting, not to be formatted.
> 
> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
> for memtest, bootable rescue image etc. 
> 
> / or root partition that is around 150GBs or so.  Enough to expand a bit
> and includes /usr and /var.
> 
> /home  rest of disk unless some needed for something else.
> 
> 
> Do you recall when running grub-install what that command looks like? 
> Lets say the Grub partition with ef02 setting is sda1, would it be
> grub-install /dev/sda1 or just sda and it finds the empty partition on
> its own?

The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
GRUB when you run grub-install and it will store its core.img in there.

You install GRUB's boot.img in the MBR and therefore you have to specify the 
disk, NOT a partition, e.g.:

grub-install /dev/sda

This command should:

1. Install GRUB's boot.img in the MBR of /dev/sda.
2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
partition', type EF02.
3. Create directory /boot/grub to install all the grub fs drivers and files.

If you have mounted /boot, all is well.  If you are repairing an installation 
from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
specify this in the CLI:

grub-install --boot-directory=/mnt/gentoo/boot /dev/sda

NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
partition' with cgdisk "... by setting the partition type to 0xEF02 and giving 
it a label of gptbios".

https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT



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

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-04-28, Grant Edwards  wrote:
>
>> With DOS disk lables, Grub uses empty space between the boot sector
>> and the first partition as a location to store it's core image file.
>> That empty space does not exist when using GPT disk label. When using
>> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
>> or "Grub Boot" partition so that Grub has somwhere to store it's core
>> image[1].
> And it bears repeating that the bios/grub boot partition only needs to
> be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
> _not_ the same as either
>
>  1) The "boot" directory where the kernel images and grubs other files
> are installed within a Linux filesystem. [Which you still need
> when booting in Legacy/BIOS mode.]
>
>   or
>
>  2) The UEFI partition that's formated with a FAT filesystem and used
> in UEFI boot mode [which you don't need when booting in
> Legacy/BIOS mode.]
>


I think I got a grasp on this now.  Basically, partitions should be like
this. 


First spot is the alignment thing.  Usually a few MBs or so and unused.

Grub boot partition with ef02 setting, not to be formatted.

/boot partition for kernel and init thingy.  Usually 1GB or so, enough
for memtest, bootable rescue image etc. 

/ or root partition that is around 150GBs or so.  Enough to expand a bit
and includes /usr and /var.

/home  rest of disk unless some needed for something else.


Do you recall when running grub-install what that command looks like? 
Lets say the Grub partition with ef02 setting is sda1, would it be
grub-install /dev/sda1 or just sda and it finds the empty partition on
its own?  That's the only thing I'm not real sure of at this point.  I
think it is sda.  Maybe. ;-)

Or is all that above just plain wrong?  O-o 

Dale

:-)  :-) 

P. S.  Been on tractor with a box blade.  Did three very long driveways
and a couple short ones.  My neighbors have smooth driveways again.  :-D 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Grant Edwards wrote:
> On 2024-04-17, Dale  wrote:
>
>> I still use Nvidia and use nvidia drivers.  I to run into problems
>> on occasion with drivers and kernels.  When you switched from
>> Nvidia, what did you switch too?  Do you still use drivers you
>> install or kernel drivers?
> All in-tree kernel drivers for integrated GPUs:
>
>  * Intel UHD Graphics 620
>  * Intel HD Graphics 4000
>  * Intel Xeon E3-1200
>  * AMD Picasso Radeon Vega
>
> After I had to recycle my second perfectly functional NVidia card
> simply because NVidia stopped driver support, I got fed up.  I tried
> the open-source nvidia drivers for those cards, but could never get
> multiple screens to work.
>
>> How well does the video system work?  In other words, plenty fast
>> enough for what you do. 
> They're all fast enough for what I do (no heavy gaming, but I do play
> with an RC flight simulator).  All will drive at least two digital
> monitors.  The last machine that had an NVidia card removed is also
> the oldest of the machines (Gigabyte Z77X-UD5H Intel i5-3570K w/ HD
> 4000 graphics), and it's happily driving three monitors (1 HDMI, 1
> DVI, 1 DP).
>
> When running the flight-sim, the newest of them (the AMD/Radeon) is
> noticeably smoother and runs at higher frame rates than the older Intel
> GPUs.  I didn't really have any complaints about the older ones, but I
> don't expect a real gamer would have been satisfied with the Intel
> ones.
>
>> I don't do any sort of heavy gaming.  Since I have a nice game on my
>> cell phone now, I play it almost all the time.  I can't recall
>> playing a game of solitaire on my computer in a long while.  My
>> biggest thing, two video ports, one for monitor and one for TV. 
>> Most TV videos aren't very high def but some are 1080P.  That's all
>> my TV can handle. 
> They all seem to handle HD video playback just fine.
>
> How many and what type of monitors can be driven is very much
> dependent on the motherboard.
>
> --
> Grant
>
>
>


I've often thought of trying ATI or something but just never did.  My
video cards tend to age out too because of driver issues.  From a cost
perspective, I kinda get it.  Still, I hate pitching a otherwise working
card. 

Thanks for the info. More stuff to think on. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Grant Edwards wrote:
>
>  2) Lack of support for old hardware when running a newer kernels.
>
> I used to run into this when running nvidia-drivers.
> Gentoo-sources would mark a new kernel stable, but my video board
> would not be supported by nvidia-drivers versions that were
> supported for that new stable kernel.  I would mask newer kernels
> until and run older "longterm" kernels as long as I could. I would
> evenually be forced to buy a new video card. After going through
> that cycle a couple times, I swore off NVidia video cards and
> life's been much eaiser since.
> 


I still use Nvidia and use nvidia drivers.  I to run into problems on
occasion with drivers and kernels.  When you switched from Nvidia, what
did you switch too?  Do you still use drivers you install or kernel
drivers?  How well does the video system work?  In other words, plenty
fast enough for what you do. 

I don't do any sort of heavy gaming.  Since I have a nice game on my
cell phone now, I play it almost all the time.  I can't recall playing a
game of solitaire on my computer in a long while.  My biggest thing, two
video ports, one for monitor and one for TV.  Most TV videos aren't very
high def but some are 1080P.  That's all my TV can handle. 

Just exploring options. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Wols Lists]

On 17/04/2024 10:10, Michael wrote:

I am not sure the assumption "... aging hardware possibly can less and less
cope with newer and newer kernels" is correct.  As already mentioned newer
kernels have both security and bug fixes.  As long as you stick with stable
gentoo-sources you'll have these in your system.  Later kernels also come with
additional kernel drivers for new(er) hardware.  You may not need/want these
drivers if you do not run the latest hardware. Using 'make oldconfig' allows
you to exclude such new drivers, but include new security options and/or
functionality as desired.


Given that I remember the announcement that the linux kernel's memory 
requirements had increased to 6MB - in the days when Fedora et al 
demanded gigabytes simply to be able to run - I think almost any ancient 
hardware you can actually buy will be able to run the linux kernel no probs.


You might have difficulty compiling it, though, now 386 support has been 
pretty much dropped from the toolchain. Have they dropped i686 as well?


Cheers,
Wol

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

On Wednesday, 17 April 2024 11:37:04 BST Dr Rainer Woitok wrote:
> Grant,
> 
> On Tuesday, 2024-04-16 19:26:25 -, you wrote:
> > ...
> > That means that all gentoo-sources stable kernels are "longterm"
> > kernel versions on kernel.org.  It does not mean that all "longterm"
> > kernel versions from kernel.org are available as "stable" in
> > gentoo-sources.
> > 
> > It is a statement that "gentoo-sources stable" is a subset of
> > "kernel.org longterm".
> 
> This sort of deteriorates into a debate about words rather than meanings
> without explaining HOW LONG  such a series  of related kernels are main-
> tained and provided.   After all, "longterm" or "LTS" suggest that these
> lines of developement are less short-lived than others.   To give an ex-
> ample: the oldest "longterm" kernels  listed on "kernel.org" are 4.19.*,
> 5.4.* and 5.10.*.  Of these only 5.10.* is still available from Gentoo.
> 
> Digging through my Gentoo installation logs,  I can see that 4.19.72 was
> one of the first kernels I built myself.   This was somewhen in the mid-
> dle of 2019, that is, not yet five years back.  And this kernel line has
> already vanished  from Gentoo.   So what time span  are we talking about
> when we say "LTS Gentoo kernel"?  Roughly four, three or two years?  And
> why is the support provided by Gentoo significantly shorter than that by
> "kernel.org"?
> 
> Sincerely,
>   Rainer

LTS kernels were being supported for ~6 years, although the projected EOL I 
see here indicates later LTS releases may not be supported for as long:

https://www.kernel.org/category/releases.html

The stable gentoo-sources are tree cleaned more frequently, so the oldest 
stable release for amd64 in portage is now 5.10.212:

$ eix gentoo-sources
[I] sys-kernel/gentoo-sources
 Available versions:  
 (5.10.208) *5.10.208^bs
 (5.10.212) 5.10.212^bs
 (5.10.213) ~5.10.213^bs
 (5.10.214) ~5.10.214^bs
 (5.10.215) ~5.10.215^bs
 (5.15.147) *5.15.147^bs
 (5.15.151) 5.15.151^bs
 (5.15.152) ~5.15.152^bs
 (5.15.153) ~5.15.153^bs
 (5.15.154) ~5.15.154^bs
 (5.15.155) ~5.15.155^bs
 (6.1.74) *6.1.74^bs
 (6.1.81) 6.1.81^bs
 (6.1.83) ~6.1.83^bs
 (6.1.84) ~6.1.84^bs
 (6.1.85) ~6.1.85^bs
 (6.1.86) ~6.1.86^bs
 (6.6.13) *6.6.13^bs
 (6.6.21) 6.6.21^bs
 (6.6.24) ~6.6.24^bs
 (6.6.25) ~6.6.25^bs
 (6.6.26) ~6.6.26^bs
 (6.6.26-r1) ~6.6.26-r1^bs
 (6.6.27) ~6.6.27^bs
 (6.8.3) ~6.8.3^bs
 (6.8.4) ~6.8.4^bs
 (6.8.5) ~6.8.5^bs
 (6.8.5-r1) ~6.8.5-r1^bs
 (6.8.6) ~6.8.6^bs
   {build experimental symlink}
 Installed versions:  6.6.21(6.6.21)^bs(03:21:20 24/03/24)(-build -
experimental -symlink)
 Homepage:https://dev.gentoo.org/~mpagano/genpatches
 Description: Full sources including the Gentoo patchset for the 
6.8 kernel tree


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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

On Tuesday, 16 April 2024 20:26:25 BST Grant Edwards wrote:
> On 2024-04-16, Dr Rainer Woitok  wrote:
> > Arve,
> > 
> > On Tuesday, 2024-04-16 15:53:48 +0200, you wrote:
> >> ...
> >> Only LTS kernels get stabilised, so this information is readily
> >> available.
> > 
> > I'm sure I don't understand this: According to "https://www.kernel.org/;
> > kernel 6.6.27  is "longterm",  but according to  "eix"  the most  recent
> > 6.6.* kernels are 6.6.22 and 6.6.23  which both are non-stable  (well, I
> > ran my last "sync" immediately before the profile upgrade, so this might
> > not be current).  I'm still using stable kernel 6.6.13 as my backup ker-
> > nel, but this kernel is no longer provided by Gentoo.  So, what precise-
> > ly does LTS or "longterm" mean?

LTS stands for Long Term Support and it means the kernel maintainers will 
continue to backport bug fixes and security patches into the LTS kernels from 
the Mainline tree, as they progress in their development of the kernel code.  
When they do this backporting they bump the LTS kernel version, e.g. from 
6.6.24 to 6.6.25.

They will not go into this prolonged maintenance effort with the kernel's 
'Stable' tree, which has a higher churn as it acquires the Mainline kernels as 
soon as the latter are signed for release.


> That means that all gentoo-sources stable kernels are "longterm"
> kernel versions on kernel.org.  It does not mean that all "longterm"
> kernel versions from kernel.org are available as "stable" in
> gentoo-sources.
> 
> It is a statement that "gentoo-sources stable" is a subset of
> "kernel.org longterm".
> 
> It is not a statement that the two sets are identical.
> 
> In other words:
> 
>"ONLY LTS kernels get stabilized."
> 
> is a different statement from
> 
>"ALL LTS kernels get stabilized."
> 
> The former is true.  The latter is not.

Yes, precisely.  This happens because Gentoo acquire the latest LTS kernel, 
apply various Gentoo related patches, test and eventually mark as stable the 
corresponding version of the gentoo-sources in portage.  This process incurs 
some inevitable delay compared with the LTS kernel tree releases, but 
nevertheless the stable gentoo-sources follow the LTS releases.


> > But, to get back to the beginning of this discussion: if there is a
> > risk that my aging hardware possibly can less and less cope with
> > newer and newer kernels, should I put something like
> > 
> >>=sys-kernel/gentoo-sources-6.7.0
> > 
> > into file "package.mask" to stay with "longterm" 6.6.* kernels?
> 
> Yes: if you want to avoid getting upgraded to 6.8 when it gets
> kernel.org "longterm" status and gentoo-sources "stable" status, then
> a statement like that in in package.mask will keep you on
> gentoo-sources 6.6 kernels (which are "longterm" on kernel.org).
> 
> Again: not all longterm 6.6.x kernel versions get marked as "stable"
> for gentoo-sources. If you have not enabled the testing keyword for
> gentoo-sources, then you'll only get the 6.6.x kernel versions that
> the gentoo-sources maintainers have declared as "stable".
> 
> --
> Grant

I am not sure the assumption "... aging hardware possibly can less and less 
cope with newer and newer kernels" is correct.  As already mentioned newer 
kernels have both security and bug fixes.  As long as you stick with stable 
gentoo-sources you'll have these in your system.  Later kernels also come with 
additional kernel drivers for new(er) hardware.  You may not need/want these 
drivers if you do not run the latest hardware. Using 'make oldconfig' allows 
you to exclude such new drivers, but include new security options and/or 
functionality as desired.

It can happen for new code to introduce some software regression.  However, 
this is not limited to old hardware.  If there is no workaround, or some patch 
you can apply manually to your kernel from a later release, then by all means 
you can mask later minor LTS releases *for a little while only* and keep an 
eye open for the latest releases which could have addressed the bug you 
suffered from.

PS. Regarding your earlier question about different make *config commands and 
their meaning you can check the latest make help page:

$ cd /usr/src/linux
$ make help

Then take a look at the section "Configuration targets".


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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Grant Edwards wrote:
> On 2024-04-16, Arve Barsnes  wrote:
>> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok  
>> wrote:
 My understanding is the gentoo-sources kernels are aligned with the LTS
 upstream releases.
>>> Right,  they use the same version numbers.   But you can't see from just
>>> looking at the available "gentoo-sources" which one is LTS and which one
>>> is not.   You have to consult "https://www.kernel.org/;  to get this in-
>>> formation.
>> Only LTS kernels get stabilised, so this information is readily available.
> "Stablized" as in the corresponding gentoo-sources ebuild is marked as
> stable. [Not to be confused with Linux "stable" kernels -- not all of
> which end up with LTS status.]
>
> Getnoo-sources also includes "stable" but not "LTS" Linux kernels, but
> the gentoo-sources ebuild for those is always "testing".
>
> IOW, if you install gentoo-sources, and don't keyword it to allow
> "testing" ebuilds, then you won't get anything other than LTS kernel
> sources.


That's some helpful info.  That helps me too. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Arve Barsnes wrote:
> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok  
> wrote:
>>> My understanding is the gentoo-sources kernels are aligned with the LTS
>>> upstream releases.
>> Right,  they use the same version numbers.   But you can't see from just
>> looking at the available "gentoo-sources" which one is LTS and which one
>> is not.   You have to consult "https://www.kernel.org/;  to get this in-
>> formation.
> Only LTS kernels get stabilised, so this information is readily available.
>
> Regards,
> Arve

I've never understood what is supported long term either.  I use
gentoo-sources.  I've never figured out just how to pick a kernel that
is supposed to be stable for the larger version.  In other words, only
security and bug fixes, no new hardware.  Right now, 6.8.5 is the
highest version in the tree here but there are more versions of it to
come.  So, I tend to go back to 6.7.X and pick the highest version of
that.  The first two digits used to mean something but I think that
changed a long time ago. 

I try to avoid the absolute latest because my video drivers tend to lag
behind a little.  They won't emerge for anything very new sometimes. 
That's why I go back a little as described above.  Thing is, I have no
idea if that is the right way or if it really even matters if I pick
6.8.1 over 6.7.12 or vice versa. 

I wish they were clearly marked somehow myself.  Something in the name
that shows it is stable.  Given I rarely have problems with kernels,
maybe none of this matters.  Thing is, I plan to build a new rig soon. 
Might help then.  Maybe. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Jack]

On 4/16/24 7:15 AM, Michael wrote:

On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:

If you update often, it shouldn't take long answer the questions.  If
you do like me and don't update often, it may take longer but no more
time than it would if you updated often and added all the time
together.  As far as I know, if one manually updates their kernel, make
oldconfig is the safest and recommended method.  You are prompted for
new drivers/options and can see if they apply to you or not.  If you
don't want to update that way, I think there is a kernel that does it's
own thing.  I think it is sort of like boot media uses.  If the time
needed to answer all the questions isn't there, that may be a option to
look into.  It's called genkernel.  I've never used it but read it works.

The sys-kernel/genkernel package will automatically build & install your
kernel and initramfs in /boot, but it will NOT prepare a kernel configuration
tuned to your hardware and desired options.  It uses a generic default
configuration safe for most circumstances.  The user can tweak the default
configuration to suit their needs and genkernel will use that.
I manually run make xconfig (after running make olddefconfig) and have 
genkernel set to not use it's default config, sticking to the .config in 
the kernel tree (/usr/src/linux.)  That's been working fine for me for 
many years.

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Arve Barsnes]

On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok  wrote:
> > My understanding is the gentoo-sources kernels are aligned with the LTS
> > upstream releases.
>
> Right,  they use the same version numbers.   But you can't see from just
> looking at the available "gentoo-sources" which one is LTS and which one
> is not.   You have to consult "https://www.kernel.org/;  to get this in-
> formation.

Only LTS kernels get stabilised, so this information is readily available.

Regards,
Arve

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Michael wrote:
> On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:
>
>> If you update often, it shouldn't take long answer the questions.  If
>> you do like me and don't update often, it may take longer but no more
>> time than it would if you updated often and added all the time
>> together.  As far as I know, if one manually updates their kernel, make
>> oldconfig is the safest and recommended method.  You are prompted for
>> new drivers/options and can see if they apply to you or not.  If you
>> don't want to update that way, I think there is a kernel that does it's
>> own thing.  I think it is sort of like boot media uses.  If the time
>> needed to answer all the questions isn't there, that may be a option to
>> look into.  It's called genkernel.  I've never used it but read it works. 
> The sys-kernel/genkernel package will automatically build & install your 
> kernel and initramfs in /boot, but it will NOT prepare a kernel configuration 
> tuned to your hardware and desired options.  It uses a generic default 
> configuration safe for most circumstances.  The user can tweak the default 
> configuration to suit their needs and genkernel will use that.
>
> For quick(er) and automated kernel update and installation there are the 
> gentoo *distribution kernels*:
>
> https://wiki.gentoo.org/wiki/Project:Distribution_Kernel
>
>
>

I thought genkernel was the one.  Looking at your link, that would be a
option more closely to what I thought genkernel was.  So, genkernel
requires more effort than I thought and distribution kernel is the more
"automatic" way.  Now to remember that.  :/ 

I still like my old way.  It works.  It's rare that it fails.  It's been
years since I couldn't boot up due to a bad kernel.  Still good to have
options tho.  Not everyone is like me.  Thank goodness for that.  ROFL 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:

> If you update often, it shouldn't take long answer the questions.  If
> you do like me and don't update often, it may take longer but no more
> time than it would if you updated often and added all the time
> together.  As far as I know, if one manually updates their kernel, make
> oldconfig is the safest and recommended method.  You are prompted for
> new drivers/options and can see if they apply to you or not.  If you
> don't want to update that way, I think there is a kernel that does it's
> own thing.  I think it is sort of like boot media uses.  If the time
> needed to answer all the questions isn't there, that may be a option to
> look into.  It's called genkernel.  I've never used it but read it works. 

The sys-kernel/genkernel package will automatically build & install your 
kernel and initramfs in /boot, but it will NOT prepare a kernel configuration 
tuned to your hardware and desired options.  It uses a generic default 
configuration safe for most circumstances.  The user can tweak the default 
configuration to suit their needs and genkernel will use that.

For quick(er) and automated kernel update and installation there are the 
gentoo *distribution kernels*:

https://wiki.gentoo.org/wiki/Project:Distribution_Kernel


> In short, make oldconfig is the recommended way as far as I know.  In my
> opinion, it is the safest way to know what you are going to get.  Links
> for more info.
> 
> https://wiki.gentoo.org/wiki/Kernel/Upgrade
> 
> https://wiki.gentoo.org/wiki/Kernel/Configuration
> 
> Someone else may have a different opinion, even a better one.  This is
> how I always do it and kernel failure is rare.  Hope it helps. 
> 
> Dale
> 
> :-)  :-) 



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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Dr Rainer Woitok wrote:
> Michael,
>
> On Monday, 2024-04-15 12:48:34 +0100, you wrote:
>
>> ...
>> Why have you set your /boot to be mounted at boot?
> Well, I think, I then just followed the Gentoo Handbook.  But I see your
> point of saving time  which could be better used to successfully unmount
> the "/home/" partition.   I'll change my "/etc/fstab" file  as well as a
> few of my scripts.  Thanks for pointing that out :-)
>
>> ...
>> MoBo firmware can be notoriously buggy and is 
>> typically frozen/abandoned within a couple of years by the OEMs.  In 
>> addition, 
>> kernel code changes and any previous symbiosis with the firmware can fall 
>> apart with a later kernel release.
> Hm, this sounds a bit like  "never change your running kernel",  doesn't
> it?  But this brings up two related questions:
>
> 1. Why does Gentoo  not somehow mark  LTS kernels  either in the version
>number or in the slot name?  This would make it easier to prevent the
>installation of too modern kernels.
>
> 2. I'm building new kernels  with "make olddefconfig"  rather than "make
>oldconfig" because I thought providing default values to new configu-
>ration variables is a good idea.   But what precisely does "make old-
>config" do  with new configuration  variables instead?   Just leaving
>them out?  But what's the difference  between not defining a configu-
>ration variable and setting it to a default value?   Or is "make old-
>config" really the way to generate more conservative kernels which do
>not as quickly overburden aging motherboards?
>
> Sincerely,
>   Rainer


I rarely update my kernel given I don't reboot much.  I am working on
that tho.  I've updated my kernel three times recently but never
rebooted to use any of them.  If power fails and I have to reboot, they
are there at least.  All of us should update when we can. 

I been using Gentoo since around 2003.  I started out making my kernel
from scratch and updating the manual way.  I also install the manual way
with my own naming scheme, just close enough for dracut and grub to
recognize them.  I've always used make oldconfig and for most of the
driver questions, I answer no.  Given I start with a kernel config that
already contains everything I need, it is rare that I need anything
new.  So, I rarely need any of the new drivers.  You are likely the
same.  I think there is a option for it to default to no or yes for all
the questions automatically but not all questions are yes or no and
sometimes you may need a yes.  To me, it's best to use make oldconfig
and answer each question.  That way you can catch something you can use
but you also catch those questions that need a numbered option, 1, 2, 3,
4 or something. 

If you update often, it shouldn't take long answer the questions.  If
you do like me and don't update often, it may take longer but no more
time than it would if you updated often and added all the time
together.  As far as I know, if one manually updates their kernel, make
oldconfig is the safest and recommended method.  You are prompted for
new drivers/options and can see if they apply to you or not.  If you
don't want to update that way, I think there is a kernel that does it's
own thing.  I think it is sort of like boot media uses.  If the time
needed to answer all the questions isn't there, that may be a option to
look into.  It's called genkernel.  I've never used it but read it works. 

In short, make oldconfig is the recommended way as far as I know.  In my
opinion, it is the safest way to know what you are going to get.  Links
for more info.

https://wiki.gentoo.org/wiki/Kernel/Upgrade

https://wiki.gentoo.org/wiki/Kernel/Configuration

Someone else may have a different opinion, even a better one.  This is
how I always do it and kernel failure is rare.  Hope it helps. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

On Tuesday, 16 April 2024 10:04:43 BST Dr Rainer Woitok wrote:
> Michael,
> 
> On Monday, 2024-04-15 12:48:34 +0100, you wrote:
> > ...
> > Why have you set your /boot to be mounted at boot?
> 
> Well, I think, I then just followed the Gentoo Handbook.  But I see your
> point of saving time  which could be better used to successfully unmount
> the "/home/" partition.   I'll change my "/etc/fstab" file  as well as a
> few of my scripts.  Thanks for pointing that out :-)
> 
> > ...
> > 
> > MoBo firmware can be notoriously buggy and is
> > 
> > typically frozen/abandoned within a couple of years by the OEMs.  In
> > addition, kernel code changes and any previous symbiosis with the
> > firmware can fall apart with a later kernel release.
> 
> Hm, this sounds a bit like  "never change your running kernel",  doesn't
> it?  

Not really, because a newer kernel has any security patches, plus it can 
include bug fixes.  You won't know if a later release fixes or breaks 
something on your system until you tried it.


> But this brings up two related questions:
> 
> 1. Why does Gentoo  not somehow mark  LTS kernels  either in the version
>number or in the slot name?  This would make it easier to prevent the
>installation of too modern kernels.

My understanding is the gentoo-sources kernels are aligned with the LTS 
upstream releases.


> 2. I'm building new kernels  with "make olddefconfig"  rather than "make
>oldconfig" because I thought providing default values to new configu-
>ration variables is a good idea.

It is a good idea if the new config items are something you need/want on your 
system and in addition if the default setting suits your needs.


>But what precisely does "make old-
>config" do  with new configuration  variables instead?   Just leaving
>them out?  But what's the difference  between not defining a configu-
>ration variable and setting it to a default value?   Or is "make old-
>config" really the way to generate more conservative kernels which do
>not as quickly overburden aging motherboards?

The make oldconfig script will identify new config items not present in your 
old kernel config, show which is the default option and ask you to 
interactively select which one you prefer; e.g.

SPECULATION_MITIGATIONS [Y/n/m/?] (NEW)

The default option above has been identified as Y, if the devs have determined 
this is a safe default for the arch.  You can hit Enter to select Y, or type 
'n' for no, 'm' for module, or '?' to read the extended description and help 
for this option before you make up your mind.

With make olddefconfig the option 'Y' will be automatically selected without 
asking your input.


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

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Frank Steinmetzger]

Am Sun, Mar 31, 2024 at 08:33:20AM -0400 schrieb Rich Freeman:
> (moving this to gentoo-user as this is really getting off-topic for -dev)
> […]
> We're going on almost 20 years since the Snowden revelations, and back
> then the NSA was basically doing intrusion on an industrial scale.

Weeaalll, it’s been 11 years in fact. Considering that is more than 10 
years, one could argue it is approaching 20. ;-)

I can remember the year well because Snowden is the same vintage as I am and 
he became 30 about when this all came out.

-- 
Grüße | Greetings | Salut | Qapla’
Others make mistakes, too -- but we have the most experience in it.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

On Sunday, 14 April 2024 19:41:41 BST Dr Rainer Woitok wrote:
> Greetings,
> 
> On Friday, 2024-01-05 18:46:09 +0100, I myself wrote:
> > ...
> > since a few month or so off and on my laptop fails to resume from hiber-
> > nation due to the  "dirty bit" being set on  the ext4 "/home" partition.
> 
> I was reading this flickering by on the screen, and it wasn't quite cor-
> rect.  Meanwhile I found this in my "openrc.log":
> 
>fsck.fat 4.2 (2021-01-31)
>There are differences between boot sector and its backup.
>This is mostly harmless. Differences: (offset:original/backup)
>  65:01/00
>  Not automatically fixing this.
>Dirty bit is set. Fs was not properly unmounted and some data may be
> corrupt. Automatically removing dirty bit.
>*** Filesystem was changed ***
>Writing changes.
>/dev/sda1: 368 files, 116600/258078 clusters

Why have you set your /boot to be mounted at boot?

You can run 'fsck.fat -v /dev/sda1' after you unmount it to remove the dirty 
bit (if not already removed) and then change your fstab to 'noauto'.  Just 
remember to remount /boot before you make any changes to your boot manager/
kernels.


>/dev/sdb1: recovering journal
>/dev/sdb1: Clearing orphaned inode 54789026 (uid=1000, gid=1000,
> mode=0100600, size=32768) /dev/sdb1: Clearing orphaned inode 54788311
> (uid=1000, gid=1000, mode=0100600, size=553900) /dev/sdb1: clean,
> 172662/61054976 files, 36598898/244190385 blocks * Filesystems repaired
> 
> So one cause always is some problem  on disk "/dev/sda1/" ("/boot/") and
> another  cause are  one or  more  orphaned inodes  on disk  "/dev/sdb1/"
> ("/home/").   But while  the values of offset,  original and  backup for
> "/dev/sda1/" are  always the same  when this happens,  the number of or-
> phaned inodes  on "/dev/sdb1/"  and the inodes itself change from occur-
> rence to occurrence.  Besides it only happens sporadically when resuming
> from hibernation, not every time.   More precisely, the problem surfaces
> when resuming  from hibernation  but could as well  be caused during the
> hibernation process itself.
> 
> Does this ring some bell somewhere what could cause this?
> 
> Sincerely,
>   Rainer

Unlike the /boot partition, the /home partition has data written to it 
regularly.  The ext4 fs does not perform atomic writes - it is not a CoW fs.  
Therefore a sudden unsync'ed shutdown could leave it in a state of corruption 
- IF for some reason data in memory is not either fully written to disk or 
retained in memory.  The way ACPI interacts with firmware *should* ensure the 
S3 system state does not suspend I/O operations halfway through an inline 
write operation ... but ... MoBo firmware can be notoriously buggy and is 
typically frozen/abandoned within a couple of years by the OEMs.  In addition, 
kernel code changes and any previous symbiosis with the firmware can fall 
apart with a later kernel release.

On one PC of mine, with the same MoBo/CPU and the same version firmware, I 
have over the years experienced a whole repertoire of random problems resuming 
from suspend.  At this point in time I avoid placing this PC in sleep, because 
it always crashes with a Firefox related segfault, some time after waking up.

Check if the situation with /dev/sdb1 improves when you leave your /boot 
unmounted.  This may make more process time available for the system to finish 
I/O operations, which may then allow /dev/sdb1 to suspend cleanly.

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

Re: [gentoo-user] Re: New profiles 23.0

[J. Roeleveld]

On Saturday, 30 March 2024 19:34:42 CEST Walter Dnes wrote:
>   Thanks for the help. I've migrated my 3 operating Gentoo machines;
> main desktop, backup desktop, and an old used Lenovo Thinkpad X201.  The
> poor thing was thrashing away for over 18 hours with 657 packages on the
> emerge --emptytree!!!  And that's after using a homebrew bash script to
> select the max available speed on the CPU.  "time" output...

What does that script do?

> > real1086m47.440s
> > user1732m29.120s
> > sys 146m54.026s
> > 
> > > I got the news item when I ran "emerge --sync".  My understanding is
> > > that step 1 in the news item says "Please also update your system
> > > fully and depclean before proceeding" so I should update world
> > > first.
> > 
> > Yes.  And depclean.
> 
>   I ended up unmerging specific items manually.  Depclean is "rather
> agressive", and wants to remove all but the latest kernel, *EVEN A
> KERNEL THAT I'M CURRENTLY USING*.  I'm currently on 6.1.67...

Unless you plan on recompiling that kernel, there is no need to actually KEEP 
the sources.

> [x8940][waltdnes][~] eselect kernel list
> Available kernel symlink targets:
>   [1]   linux-6.1.57-gentoo
>   [2]   linux-6.1.67-gentoo *
>   [3]   linux-6.6.13-gentoo
>   [4]   linux-6.6.21-gentoo
> 
>   I ran into the Intel integrated graphics problem described in...
> https://discussion.fedoraproject.org/t/f39-kernel-6-6-x-no-video-on-intel-in
> tegrated-graphics/98360
> 
>   His solution...
> 
> > I was filling out the details for a bug report. Under the description,
> > it asked if I have tried rawhide. I installed 6.7.0-0.rc4.35.fc40
> > and it fixed the issue!
> 
>   This appears to be a bug in the 6.6.x kernels, which is fixed in
> 6.7.x.  My 2 desktops and the Thinkpad all have integrated Intel
> graphics, so I'll sit at 6.1.67 until 6.7.x, or higher, goes stable.
> /var/db/repos/gentoo/sys-kernel/gentoo-kernel/gentoo-kernel-6.7.10.ebuild
> is already present, but is keyworded "~amd64".

Re: [gentoo-user] Re: silencing distcc with systemd

[Daniel Frey]

On 3/31/24 14:32, Alexandru N. Barloiu wrote:
I think in the past, the service file had a -v. Somewhere near the 
present, they reverted to a non -v service file. So if you keep 
upgrading distcc, prolly the service file still has a -v from past 
installations. If you uninstall it, and install it again, then prolly 
you got the new service file which is without -v. That prolly explains 
why some machines still have it, and some don't.


On 4/1/2024 12:03 AM, Daniel Frey wrote:

On 3/31/24 13:59, Alexandru N. Barloiu wrote:
think the distcc.service file has an extra -v (--verbose). if you 
remove that, it will behave as expected.




I checked all the units on one of the machines still showing the 
problem and an extra '-v' is not present in any of the files.


That's a good thought though. I wouldn't have even thought about that 
when I was looking at the unit files initially.


Dan





I did check, there's no '-v' in ps output. The systemd installations 
were all new - they were converted from openrc.


   276 ?SN 0:00 /usr/bin/distccd --no-detach --daemon 
--port 3632 -N 15 --allow 127.0.0.1
277 ?SN 0:00 /usr/bin/distccd --no-detach --daemon 
--port 3632 -N 15 --allow 127.0.0.1
278 ?SN 0:00 /usr/bin/distccd --no-detach --daemon 
--port 3632 -N 15 --allow 127.0.0.1
279 ?SN 0:00 /usr/bin/distccd --no-detach --daemon 
--port 3632 -N 15 --allow 127.0.0.1


I don't think it has anything to do with upgrading systemd as it was 
installed fresh - I also replicated the issue after using an openrc 
machine to switch to merged-usr (no systemd on it.)


Dan

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Alexandru N. Barloiu]

No argument from me. That JiaTan dude had other projects forked he was 
looking at. And none of them are good news. zstd. lz4. libarchive. 
squashfs-tools. But still, I think its good news if people already 
figured how to turn it off in a few days.




On 4/1/2024 1:36 AM, Michael Orlitzky wrote:

On Mon, 2024-04-01 at 01:32 +0300, Alexandru N. Barloiu wrote:

https://piaille.fr/@zeno/112185928685603910

There's an ENV var you can set that is a kill switch for the whole thing :)


For the part that we found :)

The author of the backdoor had commit access to the upstream repository
for a long time:

   https://git.tukaani.org/?p=xz.git;a=search;s=Jia+Tan;st=author

Personally I would be skeptical of running any version of any package
that he has touched.

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Michael Orlitzky]

On Mon, 2024-04-01 at 01:32 +0300, Alexandru N. Barloiu wrote:
> https://piaille.fr/@zeno/112185928685603910
> 
> There's an ENV var you can set that is a kill switch for the whole thing :)
> 

For the part that we found :)

The author of the backdoor had commit access to the upstream repository
for a long time:

  https://git.tukaani.org/?p=xz.git;a=search;s=Jia+Tan;st=author

Personally I would be skeptical of running any version of any package
that he has touched.

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Alexandru N. Barloiu]

https://piaille.fr/@zeno/112185928685603910

There's an ENV var you can set that is a kill switch for the whole thing :)


On 4/1/2024 1:29 AM, Michael Orlitzky wrote:

On Sun, 2024-03-31 at 18:19 -0400, Michael Orlitzky wrote:

The old version will show up as liblzma.so.5.6.1. Restart anything that
uses it.

Or liblzma.so.5.6.0

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Michael Orlitzky]

On Sun, 2024-03-31 at 18:19 -0400, Michael Orlitzky wrote:
> 
> The old version will show up as liblzma.so.5.6.1. Restart anything that
> uses it.

Or liblzma.so.5.6.0

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Michael Orlitzky]

On Sun, 2024-03-31 at 12:04 -0400, Rich Freeman wrote:
> 
> It is not necessary to rebuild anything, unless you're doing something
> so unusual that you'd already know the answer to the question.
> 

You should probably reboot afterwards though.

For a more fine-grained approach, you can check for running processes
that still use the old library with something like,

  root # grep liblzma /proc/*/maps

The old version will show up as liblzma.so.5.6.1. Restart anything that
uses it.

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sun, Mar 31, 2024 at 5:36 PM Wol  wrote:
>
> On 31/03/2024 20:38, Håkon Alstadheim wrote:
> > For commercial entities, the government could just contact the company
> > and apply pressure, no need to sneak the backdoor in. Cf. RSA .
>
> Serving a "secret compliance" notice on a third party is always fraught
> with danger. Okay, I probably can't trust my own government to protect
> me, but if the US Government served a compliance notice on me I'd treat
> it with the respect it deserved - probably use it as loo paper!

I imagine most large companies would just comply with their local
government, but there are some major limitations all the same:

1. It isn't necessarily the local government who wants to plant the
back door.  The FBI can't just call up Huawei and get the same results
they would with Google.
2. Even if the company complies, there are going to be more people who
are aware of the back door.  Some of those could be foreign agents.
If you infiltrate the company and obfuscate your code, then only your
own agents are aware there is an intrusion.
3. The methods employed in your attack might also be sensitive, and so
that's another reason to not want to disclose them.  If you have some
way of subtly compromising some encryption scheme, you might not want
any employees of the company to even know the cryptosystem weakness
even exists, let alone the fact that you're exploiting it.  When the
methods are secret in this way it is that much easier to obfuscate a
clandestine attack as well.

When you look at engineer salaries against national defense budgets,
it wouldn't surprise me if a LOT of FOSS (and other) contributors are
being paid to add back doors.  On the positive side, that probably
also means that they're getting paid to fix a lot of bugs and add
features just to give them cover.

To bomb a power plant might take the combined efforts of 1-2 dozen
military aircraft in various roles, at $100M+ each (granted, that's
acquisition cost and not operational cost).  Installing a trojan that
would cause the plant to blow itself up on command might just require
paying a few developers for a few years, for probably less than $1M
total, and it isn't even that obvious that you were involved if it
gets discovered, or even after the plant blows up.

-- 
Rich

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Wol]

On 31/03/2024 20:38, Håkon Alstadheim wrote:
For commercial entities, the government could just contact the company 
and apply pressure, no need to sneak the backdoor in. Cf. RSA .


Apply pressure to who? At the end of the day, the only people the 
government can trust are their own agents.


Serving a "secret compliance" notice on a third party is always fraught 
with danger. Okay, I probably can't trust my own government to protect 
me, but if the US Government served a compliance notice on me I'd treat 
it with the respect it deserved - probably use it as loo paper!


Nobody should trust anybody else more than they have need to - and 
especially governments should not trust 3rd-party nationals! It's not 
worth it.


Cheers,
Wol

Re: [gentoo-user] Re: silencing distcc with systemd

[Alexandru N. Barloiu]

I think in the past, the service file had a -v. Somewhere near the 
present, they reverted to a non -v service file. So if you keep 
upgrading distcc, prolly the service file still has a -v from past 
installations. If you uninstall it, and install it again, then prolly 
you got the new service file which is without -v. That prolly explains 
why some machines still have it, and some don't.


On 4/1/2024 12:03 AM, Daniel Frey wrote:

On 3/31/24 13:59, Alexandru N. Barloiu wrote:
think the distcc.service file has an extra -v (--verbose). if you 
remove that, it will behave as expected.




I checked all the units on one of the machines still showing the 
problem and an extra '-v' is not present in any of the files.


That's a good thought though. I wouldn't have even thought about that 
when I was looking at the unit files initially.


Dan

Re: [gentoo-user] Re: silencing distcc with systemd

[Alexandru N. Barloiu]

/etc/systemd/system/distccd.service.d/00gentoo.conf or the service file. 
has to be. there cant be anything else. that's how distcc behaves when 
started with -v. do a ps axw. figure out where the -v is coming from. 
maybe a systemctl daemon-reload && systemctl restart distccd. cant be 
anything else but a -v



On 4/1/2024 12:03 AM, Daniel Frey wrote:

On 3/31/24 13:59, Alexandru N. Barloiu wrote:
think the distcc.service file has an extra -v (--verbose). if you 
remove that, it will behave as expected.




I checked all the units on one of the machines still showing the 
problem and an extra '-v' is not present in any of the files.


That's a good thought though. I wouldn't have even thought about that 
when I was looking at the unit files initially.


Dan

Re: [gentoo-user] Re: silencing distcc with systemd

[Daniel Frey]

On 3/31/24 13:59, Alexandru N. Barloiu wrote:
think the distcc.service file has an extra -v (--verbose). if you remove 
that, it will behave as expected.




I checked all the units on one of the machines still showing the problem 
and an extra '-v' is not present in any of the files.


That's a good thought though. I wouldn't have even thought about that 
when I was looking at the unit files initially.


Dan

Re: [gentoo-user] Re: silencing distcc with systemd

[Alexandru N. Barloiu]

think the distcc.service file has an extra -v (--verbose). if you remove 
that, it will behave as expected.


On 3/31/2024 11:57 PM, Daniel Frey wrote:

On 3/29/24 22:38, Daniel Frey wrote:

Hi all,

I've moved a couple of machines from openrc to systemd.

I have discovered this odd problem. On openrc, distcc was quiet 
during building packages. It would obey environment variable set in 
/etc/env.d:


DISTCC_DIR=/var/distcc
DISTCC_ENABLE_DISCREPANCY_EMAIL=
DISTCC_FALLBACK=1
DISTCC_SAVE_TEMPS=0
DISTCC_SSH=
DISTCC_TCP_CORK=
DISTCC_VERBOSE=0

This currently shows up in the enviroment (checked with `set`.)

* snipped the rest *


Just an update. I have figured out it isn't systemd causing this issue.

I did upgrade several machines.

1. Upgraded the system profile.
2. Converted from split-usr to merged-usr.
3. Converted to systemd.

It turns out step 2 caused the problem. I don't know why, but it does 
- I tested this by converting an openrc machine that I hadn't upgraded 
yet from split-usr to merged-usr and the problem presented itself (no 
system on that machine yet.)


I did notice the machine I completely reinstalled from scratch (using 
systemd from the start) did not show signs of this issue.


I reinstalled the other distcc host using systemd from the start, 
installed and configured distcc and it all works as expected.


Now to reinstall the slower Celeron devices... come to think of it, I 
initially installed them in 2011. They haven't ever been reinstalled. 
Just repurposed.


Dan

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Håkon Alstadheim]

Den 31.03.2024 14:33, skrev Rich Freeman:

(moving this to gentoo-user as this is really getting off-topic for -dev)


It might also happen with commercial software, but the challenge there
is HR as you can't just pay 1 person to masquerade as 10 when they all
need to deal with payroll taxes.


For commercial entities, the government could just contact the company 
and apply pressure, no need to sneak the backdoor in. Cf. RSA .

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sun, Mar 31, 2024 at 10:59 AM Michael  wrote:
>
> On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote:
> > (moving this to gentoo-user as this is really getting off-topic for -dev)
>
> Thanks for bringing this to our attention Rich.
>
> Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are
> we meant to rebuilding any other/all packages, especially if we rebuilt our
> @world only a week ago as part of the move to profile 23.0?

It is not necessary to rebuild anything, unless you're doing something
so unusual that you'd already know the answer to the question.

-- 
Rich

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Daniel Frey]

On 3/31/24 07:59, Michael wrote:

On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote:

(moving this to gentoo-user as this is really getting off-topic for -dev)


Thanks for bringing this to our attention Rich.

Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are
we meant to rebuilding any other/all packages, especially if we rebuilt our
@world only a week ago as part of the move to profile 23.0?


I just ran `glsa-check -l affected` and it came up blank for me.

I ran `emerge --sync` and checked again and it indeed says my machine is 
affected.


I then ran `emerge -auDN world` and it automatically downgraded.

So, all we need to do sync and update world. It will downgrade xz-utils 
automatically.


If you want to make sure, run `glsa-check -l affected` after the emerge 
world, if it comes up blank you are not affected. Or run `glsa-check -l 
202403-02` and it will tell you if you are affected:


$ glsa-check -l 202403-04
[A] means this GLSA was marked as applied (injected),
[U] means the system is not affected and
[N] indicates that the system might be affected.

202403-04 [U] XZ utils: Backdoor in release tarballs ( app-arch/xz-utils )


Dan

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Michael]

On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote:
> (moving this to gentoo-user as this is really getting off-topic for -dev)

Thanks for bringing this to our attention Rich.

Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are 
we meant to rebuilding any other/all packages, especially if we rebuilt our 
@world only a week ago as part of the move to profile 23.0?


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

Re: [gentoo-user] Re: New profiles 23.0

[Walter Dnes]

  Thanks for the help. I've migrated my 3 operating Gentoo machines;
main desktop, backup desktop, and an old used Lenovo Thinkpad X201.  The
poor thing was thrashing away for over 18 hours with 657 packages on the
emerge --emptytree!!!  And that's after using a homebrew bash script to
select the max available speed on the CPU.  "time" output...

> real1086m47.440s
> user1732m29.120s
> sys 146m54.026s

> > I got the news item when I ran "emerge --sync".  My understanding is
> > that step 1 in the news item says "Please also update your system
> > fully and depclean before proceeding" so I should update world
> > first.
> 
> Yes.  And depclean.

  I ended up unmerging specific items manually.  Depclean is "rather
agressive", and wants to remove all but the latest kernel, *EVEN A
KERNEL THAT I'M CURRENTLY USING*.  I'm currently on 6.1.67...

[x8940][waltdnes][~] eselect kernel list
Available kernel symlink targets:
  [1]   linux-6.1.57-gentoo
  [2]   linux-6.1.67-gentoo *
  [3]   linux-6.6.13-gentoo
  [4]   linux-6.6.21-gentoo

  I ran into the Intel integrated graphics problem described in...
https://discussion.fedoraproject.org/t/f39-kernel-6-6-x-no-video-on-intel-integrated-graphics/98360

  His solution...

> I was filling out the details for a bug report. Under the description,
> it asked if I have tried rawhide. I installed 6.7.0-0.rc4.35.fc40
> and it fixed the issue!

  This appears to be a bug in the 6.6.x kernels, which is fixed in
6.7.x.  My 2 desktops and the Thinkpad all have integrated Intel
graphics, so I'll sit at 6.1.67 until 6.7.x, or higher, goes stable.
/var/db/repos/gentoo/sys-kernel/gentoo-kernel/gentoo-kernel-6.7.10.ebuild
is already present, but is keyworded "~amd64".

-- 
Roses are red
Roses are blue
Depending on their velocity
Relative to you

Re: [gentoo-user] Re: How to synchronise between 2 locations

[J. Roeleveld]

On Thursday, 28 March 2024 14:51:42 CET Grant Edwards wrote:
> On 2024-03-27, Mark Knecht  wrote:
> > On Wed, Mar 27, 2024 at 11:59 AM J. Roeleveld  wrote:
> >> I am looking for a way to synchronise a filesystem between 2
> >> servers.  Changes can occur on both sides which means I need to
> >> have it synchronise in both directions.
> > 
> > How synchronized? For instance, does it need to handle identicals where
> > a file is on both sides but has been moved?
> 
> Does it need to handle the case where the same file is modified
> independently on both sides?

Yes, as this is something that could happen

Re: [gentoo-user] Re: Emerge trouble with firefox and thunderbird ...

[Wols Lists]

On 10/03/2024 22:44, Carsten Hauck wrote:



The CPU of the machine in question is in deed an old AMD. It's good to
know the reason for that build-failures, thanks a lot.
I certainly will stick to "-clang" in my package.use.


Interesting. I'm not at all sure how old my CPU is, but at four cores it 
must be getting on a bit. Sounds like I should do the same ...


Cheers,
Wol