Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
William Kenworthy wrote:
>
> On 16/6/24 07:07, Mark Knecht wrote:
>>
>> > I still don't understand the efi thing. I'm booted up tho. I'm
>> happy.
>> > Now to get temp sensors and stuff to work. I want to keep a eye on
>> > temps for a bit. I think the boot media was reporting the wrong info.
>> > Even the ambient temp was to high for this cool room. It showed like
>> > 100F or something when my A/C is set to 68F or so. Plus, the side is
>> > off the case at times. New battle. ;-)
>> >
>> > Dale
>>
>>
>> Hi Dale,
>> Congrats on getting your new machine working. I think you've received
>> a lot of good info on temperature effects but there is one thing I
>> didn't
>> see anyone talking about so I'll mention it here. (Note - my career was
>> chip design in Silicon Valley so I'm speaking from experience in both
>> chips and PCs that use them.
>>
>> First, don't worry too much about high temperatures hurting your
>> processor or the chips in the system. They can stand up to 70C
>> pretty much forever and 100C for long periods of time. Long before
>> anything would get damaged at the chip level, if it ever gets damaged,
>> you are going to have timing problems that would either cause the
>> system to crash, corrupt data, or both, so temps are important
>> but it won't be damage to the processor. (Assuming it's a good
>> chip that meets all specs and is well tested which I'm sure yours
>> is.
>>
>> The thing I think you should be aware of is that long-term high
>> temps, while they don't hurt the processor, can very possibly degrade
>> the thermal paste that is between your processor or M.2 chips
>> and their heat sinks & fans. Thermal paste can and will degrade
>> of time and high temps make it degrade faster so the temps you
>> see today may not be the same as what you see 2 or 3 years from
>> now.
>>
>> Now, the fun part. I wrote you a little Python program which on
>> my system is called Dales_Loop.py. This program has 3
>> parameters - a value to count to, the number of cores to be used,
>> and a timeout value to stop the program. Using a program like
>> this can give you repeatable results. I use btop in a second
>> terminal to watch individual core temps As provided it will
>> loop 1,000,000 on 4 cores in parallel. When it finishes the
>> count it will start another process and count again. It will
>> do this for 30 seconds and then stop. When finished it will
>> tell you how many processes it ran over the complete test.
>>
>> If you wanted to do other things inside the loop, like floating
>> point math or things that would stress the machine in other
>> ways you can add that to the subroutine.
>>
>> Anyway, you can start with 4 cores, up the time value
>> to run the test longer, up the count value to run each
>> process longer, and most fun, raise the number of cores
>> to start using more of the processor. On my Ryzen 9
>> 5950X, which is water cooled, I don't get much fan reaction
>> until I'm using 16 of the 32 threads.
>>
>> Best wishes for you and your new rig.
>>
>> Cheers,
>> Mark
>>
>>
>>
>> import multiprocessing
>> import time
>>
>> def count_to_large_number(count_value):
>> for i in range(count_value):
>> pass # Replace with your desired computation or task
>>
>> def main():
>> num_processes = 4
>> count_value = 100
>> runtime_seconds = 30
>>
>> processes = []
>> start_time = time.time()
>> total_processes_started = 0
>>
>> while time.time() - start_time < runtime_seconds:
>> for process in processes:
>> if not process.is_alive():
>> processes.remove(process)
>>
>> while len(processes) < num_processes:
>> process =
>> multiprocessing.Process(target=count_to_large_number,
>> args=(count_value,))
>> processes.append(process)
>> process.start()
>> total_processes_started += 1
>>
>> for process in processes:
>> process.join()
>>
>> print(f"Total processes started: {total_processes_started}")
>>
>> if __name__ == "__main__":
>> main()
>>
> or use app-benchmarks/stress
>
> BillK
That's the plan. I'm still installing KDE in bits. I'm going through
the meta packages right now. That gives it heating and cooling cycles
which helps heat up the thermal grease but doesn't heat it up for very
long periods. Tomorrow maybe, I'll use stress to really heat it up. 30
minutes with all cores and threads should stir up something. :/
My complaint, the temps sensors is reporting is way higher than my IR
thermometer says. Even what I think is the ambient temp is way off.
I've googled and others report the same thing. During one compile, I
pointed the IR sensor right at the base of the CPU cooler. It may not
be as hot as the CPU is but it is closer than anything else. I measured
like 80F or something while sensors was reporting above 140F or so. I
can see a little difference but not that much. Besides, for the wattage
t
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On 16/6/24 07:07, Mark Knecht wrote:
> I still don't understand the efi thing. I'm booted up tho. I'm happy.
> Now to get temp sensors and stuff to work. I want to keep a eye on
> temps for a bit. I think the boot media was reporting the wrong info.
> Even the ambient temp was to high for this cool room. It showed like
> 100F or something when my A/C is set to 68F or so. Plus, the side is
> off the case at times. New battle. ;-)
>
> Dale
Hi Dale,
Congrats on getting your new machine working. I think you've received
a lot of good info on temperature effects but there is one thing I didn't
see anyone talking about so I'll mention it here. (Note - my career was
chip design in Silicon Valley so I'm speaking from experience in both
chips and PCs that use them.
First, don't worry too much about high temperatures hurting your
processor or the chips in the system. They can stand up to 70C
pretty much forever and 100C for long periods of time. Long before
anything would get damaged at the chip level, if it ever gets damaged,
you are going to have timing problems that would either cause the
system to crash, corrupt data, or both, so temps are important
but it won't be damage to the processor. (Assuming it's a good
chip that meets all specs and is well tested which I'm sure yours
is.
The thing I think you should be aware of is that long-term high
temps, while they don't hurt the processor, can very possibly degrade
the thermal paste that is between your processor or M.2 chips
and their heat sinks & fans. Thermal paste can and will degrade
of time and high temps make it degrade faster so the temps you
see today may not be the same as what you see 2 or 3 years from
now.
Now, the fun part. I wrote you a little Python program which on
my system is called Dales_Loop.py. This program has 3
parameters - a value to count to, the number of cores to be used,
and a timeout value to stop the program. Using a program like
this can give you repeatable results. I use btop in a second
terminal to watch individual core temps As provided it will
loop 1,000,000 on 4 cores in parallel. When it finishes the
count it will start another process and count again. It will
do this for 30 seconds and then stop. When finished it will
tell you how many processes it ran over the complete test.
If you wanted to do other things inside the loop, like floating
point math or things that would stress the machine in other
ways you can add that to the subroutine.
Anyway, you can start with 4 cores, up the time value
to run the test longer, up the count value to run each
process longer, and most fun, raise the number of cores
to start using more of the processor. On my Ryzen 9
5950X, which is water cooled, I don't get much fan reaction
until I'm using 16 of the 32 threads.
Best wishes for you and your new rig.
Cheers,
Mark
import multiprocessing
import time
def count_to_large_number(count_value):
for i in range(count_value):
pass # Replace with your desired computation or task
def main():
num_processes = 4
count_value = 100
runtime_seconds = 30
processes = []
start_time = time.time()
total_processes_started = 0
while time.time() - start_time < runtime_seconds:
for process in processes:
if not process.is_alive():
processes.remove(process)
while len(processes) < num_processes:
process =
multiprocessing.Process(target=count_to_large_number, args=(count_value,))
processes.append(process)
process.start()
total_processes_started += 1
for process in processes:
process.join()
print(f"Total processes started: {total_processes_started}")
if __name__ == "__main__":
main()
or use app-benchmarks/stress
BillK
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
> I still don't understand the efi thing. I'm booted up tho. I'm happy.
> Now to get temp sensors and stuff to work. I want to keep a eye on
> temps for a bit. I think the boot media was reporting the wrong info.
> Even the ambient temp was to high for this cool room. It showed like
> 100F or something when my A/C is set to 68F or so. Plus, the side is
> off the case at times. New battle. ;-)
>
> Dale
Hi Dale,
Congrats on getting your new machine working. I think you've received
a lot of good info on temperature effects but there is one thing I didn't
see anyone talking about so I'll mention it here. (Note - my career was
chip design in Silicon Valley so I'm speaking from experience in both
chips and PCs that use them.
First, don't worry too much about high temperatures hurting your
processor or the chips in the system. They can stand up to 70C
pretty much forever and 100C for long periods of time. Long before
anything would get damaged at the chip level, if it ever gets damaged,
you are going to have timing problems that would either cause the
system to crash, corrupt data, or both, so temps are important
but it won't be damage to the processor. (Assuming it's a good
chip that meets all specs and is well tested which I'm sure yours
is.
The thing I think you should be aware of is that long-term high
temps, while they don't hurt the processor, can very possibly degrade
the thermal paste that is between your processor or M.2 chips
and their heat sinks & fans. Thermal paste can and will degrade
of time and high temps make it degrade faster so the temps you
see today may not be the same as what you see 2 or 3 years from
now.
Now, the fun part. I wrote you a little Python program which on
my system is called Dales_Loop.py. This program has 3
parameters - a value to count to, the number of cores to be used,
and a timeout value to stop the program. Using a program like
this can give you repeatable results. I use btop in a second
terminal to watch individual core temps. As provided it will
loop 1,000,000 on 4 cores in parallel. When it finishes the
count it will start another process and count again. It will
do this for 30 seconds and then stop. When finished it will
tell you how many processes it ran over the complete test.
If you wanted to do other things inside the loop, like floating
point math or things that would stress the machine in other
ways you can add that to the subroutine.
Anyway, you can start with 4 cores, up the time value
to run the test longer, up the count value to run each
process longer, and most fun, raise the number of cores
to start using more of the processor. On my Ryzen 9
5950X, which is water cooled, I don't get much fan reaction
until I'm using 16 of the 32 threads.
Best wishes for you and your new rig.
Cheers,
Mark
import multiprocessing
import time
def count_to_large_number(count_value):
for i in range(count_value):
pass # Replace with your desired computation or task
def main():
num_processes = 4
count_value = 100
runtime_seconds = 30
processes = []
start_time = time.time()
total_processes_started = 0
while time.time() - start_time < runtime_seconds:
for process in processes:
if not process.is_alive():
processes.remove(process)
while len(processes) < num_processes:
process = multiprocessing.Process(target=count_to_large_number,
args=(count_value,))
processes.append(process)
process.start()
total_processes_started += 1
for process in processes:
process.join()
print(f"Total processes started: {total_processes_started}")
if __name__ == "__main__":
main()
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
On Saturday, 15 June 2024 23:00:07 BST Jack wrote: > A bit of searching found the wiki page for dispatch-conf, which > includes: > > Before running dispatch-conf for the first time, the settings in > /etc/dispatch-conf.conf should be edited, and the archive directory > specified in /etc/dispatch-conf.conf will need to be created > (/etc/config-archive by default). > > So it appears that directory may be specific to that tool, and not > directly related to portage. I wondered if it was a systemd feature, but apparently not. Thanks for clearing that up. -- Regards, Peter.
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
On 2024.06.15 02:38, Vitaliy Perekhovy wrote: On Fri, Jun 14, 2024 at 04:54:09PM -0400, Jack wrote: > I don't have any such directory. What package does it belong to, or is > it a config setting for portage or another package? Yes, it is a configuration of portage itself. There is an env variable CONFIG_PROTECT that contains a list of directories that portage will protect from automatic modification. Please check this article: https://wiki.gentoo.org/wiki/CONFIG_PROTECT You can query that variable by `portageq envvar CONFIG_PROTECT'. /etc is the first entry in my CONFIG_PROTECT, but I still have no config-archive under /etc. I think the folders listed in that variable are treated specially by portage in terms of not silently replacing config files, but doesn't control save/archive. A bit of searching found the wiki page for dispatch-conf, which includes: Before running dispatch-conf for the first time, the settings in /etc/dispatch-conf.conf should be edited, and the archive directory specified in /etc/dispatch-conf.conf will need to be created (/etc/config-archive by default). So it appears that directory may be specific to that tool, and not directly related to portage.
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
Michael wrote: > On Saturday, 15 June 2024 12:01:26 BST Dale wrote: >> Michael wrote: >>> b) Using a bootloader: >>> >>> Mount your ESP under the /efi mountpoint. GRUB et al, will install their >>> .efi image in the /efi/EFI/ directory. You can have your /boot as a >>> directory on your / partition, or on its own separate partition with a >>> more robust fs type than ESP's FAT and your kernel images will be >>> installed in there. >> H. If I have a separate /boot, then efi gets mounted under /boot? >> Like this: >> >> /boot/efi/ > "... Mounting the ESP to /boot/efi/, as was traditionally done, is not > recommended." > > Please read: > > https://wiki.gentoo.org/wiki/EFI_System_Partition#Mount_point > >> I'd like to use Grub, it's what I'm used to mostly. That way I can >> update grub with its command and I guess update the efi thingy too when >> I add kernels. I'm not sure on that tho. I could be wrong. > You can still use GRUB. Example: > = > EFI Partition: /dev/nvme0n1p1 type ef00 > > Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system > partition) > > Mountpoint: /efi > > Filesystem: FAT32 > = > > Then you can have a separate boot partition, example: > = > Boot Partition: /dev/nvme0n1p2, type 8300 > > Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) > > Mountpoint: /boot > > Filesystem: ext2/3/4/xfs/btrfs/etc. > === > > > [snip...] >>> ~ # du -s -h /var >>> 17G /var >> Well, it is large but it should last me a long time. Who knows what >> portage will do next. When the distfiles and such moved to /var, it's a >> good thing I was on LVM. This time, I'm not using LVM so gotta plan >> further ahead. > You can use btrfs or zfs and have /root, /home, /var, /what-ever mounted in > subvolumes. This way they will use/share the free space of the single top > level partition/disk. > Update. I just followed the docs. I had little idea of what I was doing but I just did what it said. Dang thing booted, first time. Even my fresh new kernel worked. :-D :-D Since I was confused and thought /boot and efi could be the same partition, I ended up with /boot on the root partition. I may redo that later. It works tho. Plus, loads of space for other images etc. I still don't understand the efi thing. I'm booted up tho. I'm happy. Now to get temp sensors and stuff to work. I want to keep a eye on temps for a bit. I think the boot media was reporting the wrong info. Even the ambient temp was to high for this cool room. It showed like 100F or something when my A/C is set to 68F or so. Plus, the side is off the case at times. New battle. ;-) Dale :-) :-)
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
Hello, Vitaliy. On Fri, Jun 14, 2024 at 21:25:23 +0300, Vitaliy Perekhovy wrote: > On Fri, Jun 14, 2024 at 03:53:35PM +, Alan Mackenzie wrote: > > I think portage is at fault here - it should retain the older standard > > version of /etc/bash/bashrc so that users can resolve the differences > > with a 3-way diff. > Before replace your old bashrc file, portage place the old one > here: /etc/config-archive/etc/bash/bashrc Thanks, I didn't know that. It was extremely helpful. It turns out that Gentoo has reorganised the layout of /etc/bash/bashrc, fragmenting it into bashrc itself and three files in /etc/bash/bashrc.d. Knowing that I was able to sort things out without further problems. It would have been nice to have known about this change before it happened, but I suppose it's too minor a change to clog up the eselect news system with. > -- > Regards, > Vitaliy Perekhovy -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
Hello, Netfab. On Fri, Jun 14, 2024 at 19:52:32 +0200, netfab wrote: > Le 14/06/24 à 19:33, Alan Mackenzie a tapoté : > > Are these files freely available, anywhere, perhaps? > Else, everything is also available from gentoo.org : > > https://gitweb.gentoo.org/repo/gentoo.git/tree/app-shells/bash/files/bashrc > Click on plain to get the raw version. Thanks, that helped. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Keep getting LC_ALL error during install.
Michael wrote: > On Saturday, 15 June 2024 19:33:54 BST Dale wrote: > >> (chroot) livecd / # cat /etc/env.d/02locale >> # Configuration file for eselect >> # This file has been automatically generated. >> LANG="en_US.UTF8" >> #LC_ALL="en_US.UTF8" >> (chroot) livecd / # >> >> I commented out the LC_ALL thinking it might make the error go away. >> The docs mention not setting it at all. > Yes, it should not be set. You can try unsetting it: > > export LC_ALL="" > source /etc/profile > > [snip ...] That fixed it. Since I was in a chroot, I had to run the command that changes PS1 so I don't forget where I am. LOL >> I think I either missed something or set something wrong somewhere. I >> just can't figure out what it is. I was hoping another pair of eyes >> would help. If not, I may just start over. I'm still really confused >> over the efi thing and how partitions are to be set up. While I've read >> about efi, I've never understood how it works. If I could, I'd still >> use the old BIOS method. It worked just fine for me. :/ >> >> Dale >> >> :-) :-) > You can contact me off list in case I'm able to answer specific questions > with > your UEFI installation, or ask on list for a wider audience and broader > contributions. There's nothing magic about UEFI. Actually I find it rather > easier than the obscure CMOS jump code. :-/ I think I'm going to try and find a video that shows the install, one that shows it booting and maybe a couple other things. I need to understand efi better. Right now, all I know is it takes the place of the old BIOS. Beyond that, no idea. Keep in mind, I've never seen one before, haven't even seen one now either. o_- I'm not opposed to efi. I remember when the old Grub reached its end of life. Grub2 is different but it works. I don't use the eye candy part so that makes it even easier. The biggest thing, I copy my kernels and such over manually and I keep a couple older ones that I want to be available. I also plan to install memtest, a rescue image or two and those need to be available as well. I may still use Grub, I may not. Right now, I'm clueless. I'm just trying to follow the docs which given all the options available are confusing to follow. Thanks for the help. Progress. :-D Dale :-) :-)
[gentoo-user] Re: Arrow and edit keys?
On 2024-06-15, Michael wrote: > On Saturday, 15 June 2024 19:20:26 BST Alan Grimes wrote: >> A number of my softwarez requires the use of the arrow keys and can't >> use the numpad in edit mode to work around it. So who do I need to kill >> to get arrow keys to work in x11 again? > > I don't understand what is the "edit mode" you refer to. There > ought to be a NumLock key to enable/disable the numeric pad. Also, > your DE would have some config GUI for enabling/disabling the > numlock. I don't read Mr. Grimes postings, but if the question is how to control the numlock state. The Xorg config file option XkbOptions can be used to turn numlock on/off. There's also the numlockx command-line utility to do the same. Most of the options described here can be modified to turn numlock off instead of on: https://wiki.archlinux.org/title/Activating_numlock_on_bootup
Re: [gentoo-user] Arrow and edit keys?
On Saturday, 15 June 2024 19:20:26 BST Alan Grimes wrote: > A number of my softwarez requires the use of the arrow keys and can't > use the numpad in edit mode to work around it. So who do I need to kill > to get arrow keys to work in x11 again? I don't understand what is the "edit mode" you refer to. There ought to be a NumLock key to enable/disable the numeric pad. Also, your DE would have some config GUI for enabling/disabling the numlock. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On Saturday, 15 June 2024 17:55:17 BST Michael wrote: --->8 Thanks, but I'll stick to what I know if you don't mind. -- Regards, Peter.
[gentoo-user] Keyboard still...
Lets go back to square 1. The keyboard is the most fundamental device ever, it was invented about 80 years before anyone figured out how to connect it to a computer, before the computer even existed actually The fundamental AT 101 keyboard, or microsoft's gay variant the PC-104, and the increasingly faggoty variants that have come since is still basically one almost absolutely interchangable device. You would have to go to a time before roughly 1986 to find a keyboard without modern edit keys. (search PC XT 83-key ). Ok. So I am in a situation where an absolutely fundamental technology that's dead simple ( classically an 8042 microcontroller talking to another 8042 microcontroller over a really simple serial link...) Since, presumably, EVERYONE uses this device, and EVERYONE would be screwed if any part of it stopped working for any reason, and it, theoretically, should be impossible to break because nobody would ever have any reason to touch the code that should have been basically calcified for the last fifteen years, and if they did touch it, *AND* test it, then they would instantly notice problems and such a change would never be committed to github much less make it out to the repository and onto my system. Now I'm in a situation where something that couldn't possibly break, has been broken so utterly that I have no idea where even to begin. I looked at the manpage for setxkbmap and it's the normal moonspeak, talking about things that are utterly orthogonal to the problem I'm facing, and offering dozens of command line switches, all of them seem to have a 40-60% chance of being even slightly relevant. Google pulls up results from ten years ago. The keyboard is known working, the console driver works great... So why two drivers??? I know about 42% of the answer to that There are two worlds, TEXTBOOKLAND and the real world that we actually live in. In textbookland, there are two types of devices: block devices and character devices. Nothing else exists, and unix is complete and perfect with just block devices and character devices. The linux console lives mostly in textbookland. X11, however, has to work in the real world where it had to superimpose a whole new framework of event-driven devices like keyboards, mices, gamepads, etc... that operate in real time and support games and human interractions. I have not yet found /come across any textbook that acknowledges the existence of such devices. The kernel must provide some minimal, begrudging facility to allow them to exist but the workings of the entire stack is shrouded in mystery and obfuscation up to the user-level libraries such as SDL-input and such... Linux, ofcourse, provides ten thousand different things to waste time becoming an expert on. It never entered even my most fevered immaginings that I would have to become an expert on the keyboard input system after figuring out how to toggle the layout over to dvorak... -- You can't out-crazy a Democrat. #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights.
Re: [gentoo-user] Keep getting LC_ALL error during install.
On Saturday, 15 June 2024 19:33:54 BST Dale wrote: > (chroot) livecd / # cat /etc/env.d/02locale > # Configuration file for eselect > # This file has been automatically generated. > LANG="en_US.UTF8" > #LC_ALL="en_US.UTF8" > (chroot) livecd / # > > I commented out the LC_ALL thinking it might make the error go away. > The docs mention not setting it at all. Yes, it should not be set. You can try unsetting it: export LC_ALL="" source /etc/profile [snip ...] > I think I either missed something or set something wrong somewhere. I > just can't figure out what it is. I was hoping another pair of eyes > would help. If not, I may just start over. I'm still really confused > over the efi thing and how partitions are to be set up. While I've read > about efi, I've never understood how it works. If I could, I'd still > use the old BIOS method. It worked just fine for me. :/ > > Dale > > :-) :-) You can contact me off list in case I'm able to answer specific questions with your UEFI installation, or ask on list for a wider audience and broader contributions. There's nothing magic about UEFI. Actually I find it rather easier than the obscure CMOS jump code. :-/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Keep getting LC_ALL error during install.
Michael wrote:
> On Saturday, 15 June 2024 19:09:18 BST Dale wrote:
>> Michael wrote:
>>> On Saturday, 15 June 2024 18:24:27 BST Dale wrote:
Howdy,
I got down to the time zone part. When I try to run emerge --config
sys-libs/timezone-data I get this output.
(chroot) livecd / # emerge --config sys-libs/timezone-data
Configuring pkg...
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.12/emerge", line 57, in main
retval = emerge_main()
^
File "/usr/lib/python3.12/site-packages/_emerge/main.py", line 1308,
in emerge_main
return run_action(emerge_config)
^
File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line
3876, in run_action
return action_config(
^^
File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line 758,
in action_config
retval = portage.doebuild(
^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
line 1218, in doebuild
rval = _prepare_env_file(mysettings)
^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
line 1686, in _prepare_env_file
env_extractor.start()
File "/usr/lib/python3.12/site-packages/_emerge/AsynchronousTask.py",
line 34, in start
self._start()
File
"/usr/lib/python3.12/site-packages/_emerge/BinpkgEnvExtractor.py", line
43, in _start
env=self.settings.environ(),
^^^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/config.py",
line 3378, in environ
raise AssertionError(
AssertionError: LC_ALL=en_US.UTF8 for posixish locale. It seems that
split_LC_ALL was not called for phase config?
(chroot) livecd / #
The next section is locale so I skipped ahead to set the locale settings
but nothing I do gets me past this error. Did I miss a step somewhere?
I'm currently booted from the Gentoo LiveGUI USB Image and am in the
chroot. I been following the handbook with the parts that apply to me
but maybe I missed something??? This is the current setting.
(chroot) livecd / # eselect locale list
Available targets for the LANG variable:
[1] C
[2] C.utf8
[3] en_US
[4] en_US.iso88591
[5] en_US.utf8
[6] POSIX
[7] en_US.UTF8 *
[ ] (free form)
(chroot) livecd / #
I also tried setting it to #5. Same error but works on current rig.
Anyone know what I missed? I even tried copying settings from my
current rig but same error. I've also ran the following after each
setting I tried.
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
Any thoughts?
Dale
:-) :-)
>>> Please share:
>>>
>>> $ cat /etc/locale.gen
>>>
>>> $ locale -a
>>>
>>> $ locale
>> I'm going to remove most of the commented out stuff. Also separating it
>> a bit. Make it easier to read.
>>
>>
>>
>> livecd / # cat /etc/locale.gen
>>
>> en_US ISO-8859-1
>> en_US.UTF-8 UTF-8
>> (chroot) livecd / #
>>
>> livecd / # locale -a
>> C
>> C.utf8
>> en_US
>> en_US.iso88591
>> en_US.utf8
>> POSIX
>> (chroot) livecd / #
>>
>> livecd / # locale
>> LANG=en_US.utf8
>> LC_CTYPE="en_US.UTF8"
>> LC_NUMERIC="en_US.UTF8"
>> LC_TIME="en_US.UTF8"
>> LC_COLLATE="en_US.UTF8"
>> LC_MONETARY="en_US.UTF8"
>> LC_MESSAGES="en_US.UTF8"
>> LC_PAPER="en_US.UTF8"
>> LC_NAME="en_US.UTF8"
>> LC_ADDRESS="en_US.UTF8"
>> LC_TELEPHONE="en_US.UTF8"
>> LC_MEASUREMENT="en_US.UTF8"
>> LC_IDENTIFICATION="en_US.UTF8"
>> LC_ALL=en_US.UTF8
> Hmm ... how did the last entry end up in there?
>
> Can you please check your /etc/env.d/02locale and your ~/.bashrc.
>
(chroot) livecd / # cat /etc/env.d/02locale
# Configuration file for eselect
# This file has been automatically generated.
LANG="en_US.UTF8"
#LC_ALL="en_US.UTF8"
(chroot) livecd / #
I commented out the LC_ALL thinking it might make the error go away.
The docs mention not setting it at all.
There's no /root/.bashrc, yet anyway.
>> (chroot) livecd / #
>>
>>
>> I tried to copy the settings from my current rig and the docs seem to
>> agree with that still. I think I either missed something or set
>> something wrong. I just can't figure out which as it matches my current
>> rig. :/
>>
>> Where did I go wrong?
> Re-use, it saves time, but check first what it is you are re-using. You
>
[gentoo-user] Arrow and edit keys?
A number of my softwarez requires the use of the arrow keys and can't use the numpad in edit mode to work around it. So who do I need to kill to get arrow keys to work in x11 again? -- You can't out-crazy a Democrat. #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights.
Re: [gentoo-user] Keep getting LC_ALL error during install.
On Saturday, 15 June 2024 19:09:18 BST Dale wrote:
> Michael wrote:
> > On Saturday, 15 June 2024 18:24:27 BST Dale wrote:
> >> Howdy,
> >>
> >> I got down to the time zone part. When I try to run emerge --config
> >> sys-libs/timezone-data I get this output.
> >>
> >>
> >>
> >> (chroot) livecd / # emerge --config sys-libs/timezone-data
> >>
> >>
> >> Configuring pkg...
> >>
> >> Traceback (most recent call last):
> >> File "/usr/lib/python-exec/python3.12/emerge", line 57, in main
> >>
> >> retval = emerge_main()
> >>
> >> ^
> >>
> >> File "/usr/lib/python3.12/site-packages/_emerge/main.py", line 1308,
> >>
> >> in emerge_main
> >>
> >> return run_action(emerge_config)
> >>
> >>^
> >>
> >> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line
> >>
> >> 3876, in run_action
> >>
> >> return action_config(
> >>
> >>^^
> >>
> >> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line 758,
> >>
> >> in action_config
> >>
> >> retval = portage.doebuild(
> >>
> >> ^
> >>
> >> File
> >>
> >> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
> >> line 1218, in doebuild
> >>
> >> rval = _prepare_env_file(mysettings)
> >>
> >>^
> >>
> >> File
> >>
> >> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
> >> line 1686, in _prepare_env_file
> >>
> >> env_extractor.start()
> >>
> >> File "/usr/lib/python3.12/site-packages/_emerge/AsynchronousTask.py",
> >>
> >> line 34, in start
> >>
> >> self._start()
> >>
> >> File
> >>
> >> "/usr/lib/python3.12/site-packages/_emerge/BinpkgEnvExtractor.py", line
> >> 43, in _start
> >>
> >> env=self.settings.environ(),
> >>
> >> ^^^
> >>
> >> File
> >>
> >> "/usr/lib/python3.12/site-packages/portage/package/ebuild/config.py",
> >> line 3378, in environ
> >>
> >> raise AssertionError(
> >>
> >> AssertionError: LC_ALL=en_US.UTF8 for posixish locale. It seems that
> >> split_LC_ALL was not called for phase config?
> >> (chroot) livecd / #
> >>
> >>
> >>
> >> The next section is locale so I skipped ahead to set the locale settings
> >> but nothing I do gets me past this error. Did I miss a step somewhere?
> >> I'm currently booted from the Gentoo LiveGUI USB Image and am in the
> >> chroot. I been following the handbook with the parts that apply to me
> >> but maybe I missed something??? This is the current setting.
> >>
> >>
> >> (chroot) livecd / # eselect locale list
> >>
> >> Available targets for the LANG variable:
> >> [1] C
> >> [2] C.utf8
> >> [3] en_US
> >> [4] en_US.iso88591
> >> [5] en_US.utf8
> >> [6] POSIX
> >> [7] en_US.UTF8 *
> >> [ ] (free form)
> >>
> >> (chroot) livecd / #
> >>
> >>
> >> I also tried setting it to #5. Same error but works on current rig.
> >> Anyone know what I missed? I even tried copying settings from my
> >> current rig but same error. I've also ran the following after each
> >> setting I tried.
> >>
> >>
> >> env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
> >>
> >>
> >> Any thoughts?
> >>
> >> Dale
> >>
> >> :-) :-)
> >
> > Please share:
> >
> > $ cat /etc/locale.gen
> >
> > $ locale -a
> >
> > $ locale
>
> I'm going to remove most of the commented out stuff. Also separating it
> a bit. Make it easier to read.
>
>
>
> livecd / # cat /etc/locale.gen
>
> en_US ISO-8859-1
> en_US.UTF-8 UTF-8
> (chroot) livecd / #
>
> livecd / # locale -a
> C
> C.utf8
> en_US
> en_US.iso88591
> en_US.utf8
> POSIX
> (chroot) livecd / #
>
> livecd / # locale
> LANG=en_US.utf8
> LC_CTYPE="en_US.UTF8"
> LC_NUMERIC="en_US.UTF8"
> LC_TIME="en_US.UTF8"
> LC_COLLATE="en_US.UTF8"
> LC_MONETARY="en_US.UTF8"
> LC_MESSAGES="en_US.UTF8"
> LC_PAPER="en_US.UTF8"
> LC_NAME="en_US.UTF8"
> LC_ADDRESS="en_US.UTF8"
> LC_TELEPHONE="en_US.UTF8"
> LC_MEASUREMENT="en_US.UTF8"
> LC_IDENTIFICATION="en_US.UTF8"
> LC_ALL=en_US.UTF8
Hmm ... how did the last entry end up in there?
Can you please check your /etc/env.d/02locale and your ~/.bashrc.
> (chroot) livecd / #
>
>
> I tried to copy the settings from my current rig and the docs seem to
> agree with that still. I think I either missed something or set
> something wrong. I just can't figure out which as it matches my current
> rig. :/
>
> Where did I go wrong?
Re-use, it saves time, but check first what it is you are re-using. You could
end up falling behind, because the world of code moves on and you may also end
up copying over previous latent mistakes.
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Keep getting LC_ALL error during install.
Michael wrote:
> On Saturday, 15 June 2024 18:24:27 BST Dale wrote:
>> Howdy,
>>
>> I got down to the time zone part. When I try to run emerge --config
>> sys-libs/timezone-data I get this output.
>>
>>
>>
>> (chroot) livecd / # emerge --config sys-libs/timezone-data
>>
>>
>> Configuring pkg...
>>
>> Traceback (most recent call last):
>> File "/usr/lib/python-exec/python3.12/emerge", line 57, in main
>> retval = emerge_main()
>> ^
>> File "/usr/lib/python3.12/site-packages/_emerge/main.py", line 1308,
>> in emerge_main
>> return run_action(emerge_config)
>>^
>> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line
>> 3876, in run_action
>> return action_config(
>>^^
>> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line 758,
>> in action_config
>> retval = portage.doebuild(
>> ^
>> File
>> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
>> line 1218, in doebuild
>> rval = _prepare_env_file(mysettings)
>>^
>> File
>> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
>> line 1686, in _prepare_env_file
>> env_extractor.start()
>> File "/usr/lib/python3.12/site-packages/_emerge/AsynchronousTask.py",
>> line 34, in start
>> self._start()
>> File
>> "/usr/lib/python3.12/site-packages/_emerge/BinpkgEnvExtractor.py", line
>> 43, in _start
>> env=self.settings.environ(),
>> ^^^
>> File
>> "/usr/lib/python3.12/site-packages/portage/package/ebuild/config.py",
>> line 3378, in environ
>> raise AssertionError(
>> AssertionError: LC_ALL=en_US.UTF8 for posixish locale. It seems that
>> split_LC_ALL was not called for phase config?
>> (chroot) livecd / #
>>
>>
>>
>> The next section is locale so I skipped ahead to set the locale settings
>> but nothing I do gets me past this error. Did I miss a step somewhere?
>> I'm currently booted from the Gentoo LiveGUI USB Image and am in the
>> chroot. I been following the handbook with the parts that apply to me
>> but maybe I missed something??? This is the current setting.
>>
>>
>> (chroot) livecd / # eselect locale list
>> Available targets for the LANG variable:
>> [1] C
>> [2] C.utf8
>> [3] en_US
>> [4] en_US.iso88591
>> [5] en_US.utf8
>> [6] POSIX
>> [7] en_US.UTF8 *
>> [ ] (free form)
>> (chroot) livecd / #
>>
>>
>> I also tried setting it to #5. Same error but works on current rig.
>> Anyone know what I missed? I even tried copying settings from my
>> current rig but same error. I've also ran the following after each
>> setting I tried.
>>
>>
>> env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
>>
>>
>> Any thoughts?
>>
>> Dale
>>
>> :-) :-)
> Please share:
>
> $ cat /etc/locale.gen
>
> $ locale -a
>
> $ locale
I'm going to remove most of the commented out stuff. Also separating it
a bit. Make it easier to read.
livecd / # cat /etc/locale.gen
en_US ISO-8859-1
en_US.UTF-8 UTF-8
(chroot) livecd / #
livecd / # locale -a
C
C.utf8
en_US
en_US.iso88591
en_US.utf8
POSIX
(chroot) livecd / #
livecd / # locale
LANG=en_US.utf8
LC_CTYPE="en_US.UTF8"
LC_NUMERIC="en_US.UTF8"
LC_TIME="en_US.UTF8"
LC_COLLATE="en_US.UTF8"
LC_MONETARY="en_US.UTF8"
LC_MESSAGES="en_US.UTF8"
LC_PAPER="en_US.UTF8"
LC_NAME="en_US.UTF8"
LC_ADDRESS="en_US.UTF8"
LC_TELEPHONE="en_US.UTF8"
LC_MEASUREMENT="en_US.UTF8"
LC_IDENTIFICATION="en_US.UTF8"
LC_ALL=en_US.UTF8
(chroot) livecd / #
I tried to copy the settings from my current rig and the docs seem to
agree with that still. I think I either missed something or set
something wrong. I just can't figure out which as it matches my current
rig. :/
Where did I go wrong?
Dale
:-) :-)
Re: [gentoo-user] Keep getting LC_ALL error during install.
On Saturday, 15 June 2024 18:24:27 BST Dale wrote:
> Howdy,
>
> I got down to the time zone part. When I try to run emerge --config
> sys-libs/timezone-data I get this output.
>
>
>
> (chroot) livecd / # emerge --config sys-libs/timezone-data
>
>
> Configuring pkg...
>
> Traceback (most recent call last):
> File "/usr/lib/python-exec/python3.12/emerge", line 57, in main
> retval = emerge_main()
> ^
> File "/usr/lib/python3.12/site-packages/_emerge/main.py", line 1308,
> in emerge_main
> return run_action(emerge_config)
>^
> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line
> 3876, in run_action
> return action_config(
>^^
> File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line 758,
> in action_config
> retval = portage.doebuild(
> ^
> File
> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
> line 1218, in doebuild
> rval = _prepare_env_file(mysettings)
>^
> File
> "/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
> line 1686, in _prepare_env_file
> env_extractor.start()
> File "/usr/lib/python3.12/site-packages/_emerge/AsynchronousTask.py",
> line 34, in start
> self._start()
> File
> "/usr/lib/python3.12/site-packages/_emerge/BinpkgEnvExtractor.py", line
> 43, in _start
> env=self.settings.environ(),
> ^^^
> File
> "/usr/lib/python3.12/site-packages/portage/package/ebuild/config.py",
> line 3378, in environ
> raise AssertionError(
> AssertionError: LC_ALL=en_US.UTF8 for posixish locale. It seems that
> split_LC_ALL was not called for phase config?
> (chroot) livecd / #
>
>
>
> The next section is locale so I skipped ahead to set the locale settings
> but nothing I do gets me past this error. Did I miss a step somewhere?
> I'm currently booted from the Gentoo LiveGUI USB Image and am in the
> chroot. I been following the handbook with the parts that apply to me
> but maybe I missed something??? This is the current setting.
>
>
> (chroot) livecd / # eselect locale list
> Available targets for the LANG variable:
> [1] C
> [2] C.utf8
> [3] en_US
> [4] en_US.iso88591
> [5] en_US.utf8
> [6] POSIX
> [7] en_US.UTF8 *
> [ ] (free form)
> (chroot) livecd / #
>
>
> I also tried setting it to #5. Same error but works on current rig.
> Anyone know what I missed? I even tried copying settings from my
> current rig but same error. I've also ran the following after each
> setting I tried.
>
>
> env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
>
>
> Any thoughts?
>
> Dale
>
> :-) :-)
Please share:
$ cat /etc/locale.gen
$ locale -a
$ locale
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] CPU frequency governors and temperatures
On Saturday, 15 June 2024 18:24:04 BST Walter Dnes wrote: > On Sat, Jun 15, 2024 at 12:39:09PM +0100, Michael wrote > > > The maximum temperature at which your CPU die with its 65W TDP starts > > throttling to keep its temperatures safe is 100°C TjMax. Look at the > > TJunction number here: > > > > https://www.intel.com/content/www/us/en/products/sku/199271/intel-core-i51 > > 0400-processor-12m-cache-up-to-4-30-ghz/specifications.html > > > > According to Intel anything below 100°C is 'normal'. If this were > > my CPU I would not worry with temperatures ~70-85°C. Above that > > I would install a better CPU cooler. > > Thanks. I wasn't aware of the two different versions of "Max > Temperature". I have had laptops which throttled on hot days and when there wasn't enough airflow around/underneath them. You'll see dmesg filling up with warnings about max temp reached or some such and any heavy lifting compilation taking forever to finish, since the CPU is throttling and cutting out. If the overheating was extreme due to a race condition, then the laptop would just shutdown. Since you have not observed this kind of rather concerning symptoms, I think you can continue using the schedutil governor which is quite intelligent in juggling and optimising tasks. Check the documentation for your kernel in: /usr/src/linux-6.6.30-gentoo/Documentation/scheduler/schedutil.rst signature.asc Description: This is a digitally signed message part.
[gentoo-user] Keep getting LC_ALL error during install.
Howdy,
I got down to the time zone part. When I try to run emerge --config
sys-libs/timezone-data I get this output.
(chroot) livecd / # emerge --config sys-libs/timezone-data
Configuring pkg...
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.12/emerge", line 57, in main
retval = emerge_main()
^
File "/usr/lib/python3.12/site-packages/_emerge/main.py", line 1308,
in emerge_main
return run_action(emerge_config)
^
File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line
3876, in run_action
return action_config(
^^
File "/usr/lib/python3.12/site-packages/_emerge/actions.py", line 758,
in action_config
retval = portage.doebuild(
^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
line 1218, in doebuild
rval = _prepare_env_file(mysettings)
^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/doebuild.py",
line 1686, in _prepare_env_file
env_extractor.start()
File "/usr/lib/python3.12/site-packages/_emerge/AsynchronousTask.py",
line 34, in start
self._start()
File
"/usr/lib/python3.12/site-packages/_emerge/BinpkgEnvExtractor.py", line
43, in _start
env=self.settings.environ(),
^^^
File
"/usr/lib/python3.12/site-packages/portage/package/ebuild/config.py",
line 3378, in environ
raise AssertionError(
AssertionError: LC_ALL=en_US.UTF8 for posixish locale. It seems that
split_LC_ALL was not called for phase config?
(chroot) livecd / #
The next section is locale so I skipped ahead to set the locale settings
but nothing I do gets me past this error. Did I miss a step somewhere?
I'm currently booted from the Gentoo LiveGUI USB Image and am in the
chroot. I been following the handbook with the parts that apply to me
but maybe I missed something??? This is the current setting.
(chroot) livecd / # eselect locale list
Available targets for the LANG variable:
[1] C
[2] C.utf8
[3] en_US
[4] en_US.iso88591
[5] en_US.utf8
[6] POSIX
[7] en_US.UTF8 *
[ ] (free form)
(chroot) livecd / #
I also tried setting it to #5. Same error but works on current rig.
Anyone know what I missed? I even tried copying settings from my
current rig but same error. I've also ran the following after each
setting I tried.
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
Any thoughts?
Dale
:-) :-)
Re: [gentoo-user] CPU frequency governors and temperatures
On Sat, Jun 15, 2024 at 12:39:09PM +0100, Michael wrote > The maximum temperature at which your CPU die with its 65W TDP starts > throttling to keep its temperatures safe is 100°C TjMax. Look at the > TJunction number here: > > https://www.intel.com/content/www/us/en/products/sku/199271/intel-core-i510400-processor-12m-cache-up-to-4-30-ghz/specifications.html > According to Intel anything below 100°C is 'normal'. If this were > my CPU I would not worry with temperatures ~70-85°C. Above that > I would install a better CPU cooler. Thanks. I wasn't aware of the two different versions of "Max Temperature". -- Roses are red Roses are blue Depending on their velocity Relative to you
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
On 14/06/2024 18:39, Alan Mackenzie wrote: Does etc-update or dispatch-conf not give you the option to selectively update and/or to diff the file? In theory, yes. In practice, dispatch-conf just offers a single ~130-line long hunk, which is useless for distinguishing wanted pieces of code from old superseded code. As I say, what's missing is the old repository version, which would allow a diff3. etc-update certainly, and I would be surprised if dispatch-conf didn't, does offer you a diff. The (faulty) assumption here is that the user actually knows how to make use of a diff! Certainly true for me, and quite likely for a sizeable minority, I predate both Linux and Windows by quite a large margin, and have never been part of the Unix eco-system. I use linux because it's better than Windows, I use gentoo because I want to learn, but I'm not comfortable with pretty much the entire development ecosystem including things like diff. I so rarely use diff, that I find it simplest to run a diff (which tells me *what* has changed, then I open both old and new in kate, and manually investigate. It may be more work than using diff properly, but once I factor in the cost of working out how to use diff it's not worth it. It's doubly not worth it because I'll have forgotten all that hard work next time I need it! Cheers, Wol
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On Saturday, 15 June 2024 16:28:29 BST Peter Humphrey wrote: > On Saturday, 15 June 2024 13:01:33 BST Dale wrote: > > Could you share the boot screen again? > > New version attached... > > > I used lilo ages ago then switched to Grub. Grub is massive but it works > > well enough. > > ...as long as you only want to specify one kernel image. Not really. You can add as many kernel image versions as you like and in addition customise the GRUB configuration to add kernel command-line parameters of choice. > > Thing is, seeing your screen may help me to understand how > > certain options work. It may make me use the bootloader you use, which is > > what by the way? > > I use bootctl from sys-apps/systemd-utils* with USE="acl boot kernel-install > kmod tmpfiles udev -secureboot (-selinux) (-split-usr) -sysusers -test > -ukify" > > Sys-kernel/kernelinstall has USE="-dracut (-efistub) -grub -refind -systemd > -systemd-boot -uki -ukify" > > Notice the -systemd -systemd-boot flags. The wiki and some news items say to > set those, but then I'd end up with the unintelligible file and directory > names I mentioned - I'm not well versed in mental 32-digit hex > number-juggling. :) > > --->8 I thought the 'title' for any systemd-boot listed kernel can be edited to suit user preferences, as described here: https://forums.gentoo.org/viewtopic-p-8826048.html > > Like you, I keep old kernels around too. Eventually, I clean out old > > ones but I like to keep at least a couple around just in case one goes > > wonky. At least I can boot a older kernel to fix things. I also do > > things the manual way. I copy my kernels over with names I like, copy > > the config file over with a matching name as well. > > That's all automatic here; kernelinstall does it when I call 'make install'. > All but two of the files shown in 'ls -1 /boot', below, are as 'make > install' set them. The exceptions to that are early_ucode.cpio and > intel-uc.img. You can build these in-kernel, by adding their path/name in your kernel config, e.g.: CONFIG_FW_LOADER=y CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3c-03" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" See here: https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs. 2Fdisk_.28efistub_compatible.29 > The only files I maintain myself are those under /boot/loader/entries; they > define the menu items in the attachment here: > > 06-gentoo-rescue-6.6.30.conf > 07-gentoo-rescue-6.6.30.nonet.conf > 08-gentoo-rescue-6.6.21.conf > 09-gentoo-rescue-6.6.21.nonet.conf > 30-gentoo-6.6.30.conf > 32-gentoo-6.6.30.nox.conf > 34-gentoo-6.6.30.nonet.conf > 40-gentoo-6.6.21.conf > 42-gentoo-6.6.21.nox.conf > 44-gentoo-6.6.21.nonet.conf > > E.g: $ cat /boot/loader/entries/34-gentoo-6.6.30.nonet.conf > title Gentoo 6.6.30 (No network) > version 6.6.30-gentoo > linux vmlinuz-6.6.30-gentoo > options root=/dev/nvme0n1p5 net.ifnames=0 raid=noautodetect \ > softlevel=nonetwork > > > I do let dracut build the init thingy. I do edit the name to match the > > kernel so that grub sees it. So, you not alone doing it the manual way, > > as > > much as I can anyway. > > I don't need an initramfs, other than early_ucode.cpio and intel-uc.img, > because I don't want the complications of a separate /usr partition. > > $ ls -1 /boot > config-6.6.21-gentoo > config-6.6.21-gentoo-rescue > config-6.6.30-gentoo > config-6.6.30-gentoo-rescue > early_ucode.cpio > EFI > intel-uc.img > loader > System.map-6.6.21-gentoo > System.map-6.6.21-gentoo-rescue > System.map-6.6.30-gentoo > System.map-6.6.30-gentoo-rescue > vmlinuz-6.6.21-gentoo > vmlinuz-6.6.21-gentoo-rescue > vmlinuz-6.6.30-gentoo > vmlinuz-6.6.30-gentoo-rescue > > > Thanks much. > > * The handbook says to use efibootmgr to create boot entries, but that > again assumes you only want a single bootable image. It is occasionally > useful, though, to clear up any mess I may have made. With the efibootmgr you can have more than one bootable image, set your own preferred label for it and you can hardcode any kernel command-line parameters in each kernel image; e.g.: CONFIG_CMDLINE="root=PARTUUID=--XXX-- snd-hda- intel.index=1,0" signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
On 14/06/2024 16:53, Alan Mackenzie wrote: I think portage is at fault here - it should retain the older standard version of /etc/bash/bashrc so that users can resolve the differences with a 3-way diff. Is it portage itself that DID the update, or it did it tell you to do the update with etc-update, or dispatch-conf, or any one of those programs. Ime portage leaves the new version as ._something so you should have both the old and new versions until you mess it up yourself :-) And as I keep moaning, you can't blame portage for other software being stupid. Doesn't bash have a ~/.bashrc you can edit? I know - all too often the DE gets in the way ... Imho dovecot gets it perfectly right (as does systemd, actually, both of them thought this through properly) because it has a configuration in the default file that tells it to read a local file. So the package manager updates the standard file, and the standard file reads the local configuration to update it with the local settings. Cheers, Wol
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On Saturday, 15 June 2024 12:01:26 BST Dale wrote: > Michael wrote: > > b) Using a bootloader: > > > > Mount your ESP under the /efi mountpoint. GRUB et al, will install their > > .efi image in the /efi/EFI/ directory. You can have your /boot as a > > directory on your / partition, or on its own separate partition with a > > more robust fs type than ESP's FAT and your kernel images will be > > installed in there. > > H. If I have a separate /boot, then efi gets mounted under /boot? > Like this: > > /boot/efi/ "... Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended." Please read: https://wiki.gentoo.org/wiki/EFI_System_Partition#Mount_point > I'd like to use Grub, it's what I'm used to mostly. That way I can > update grub with its command and I guess update the efi thingy too when > I add kernels. I'm not sure on that tho. I could be wrong. You can still use GRUB. Example: = EFI Partition: /dev/nvme0n1p1 type ef00 Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition) Mountpoint: /efi Filesystem: FAT32 = Then you can have a separate boot partition, example: = Boot Partition: /dev/nvme0n1p2, type 8300 Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) Mountpoint: /boot Filesystem: ext2/3/4/xfs/btrfs/etc. === [snip...] > > ~ # du -s -h /var > > 17G /var > > Well, it is large but it should last me a long time. Who knows what > portage will do next. When the distfiles and such moved to /var, it's a > good thing I was on LVM. This time, I'm not using LVM so gotta plan > further ahead. You can use btrfs or zfs and have /root, /home, /var, /what-ever mounted in subvolumes. This way they will use/share the free space of the single top level partition/disk. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: CPU frequency governors and temperatures
On 14/06/2024 14:53, Walter Dnes wrote: On Thu, Jun 13, 2024 at 10:49:57PM -0500, Dale wrote model name : Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz Specs for your CPU are here: https://ark.intel.com/content/www/us/en/ark/products/199271/intel-core-i5-10400-processor-12m-cache-up-to-4-30-ghz.html 2.9GHz is the base clock, it goes up to 4.3GHz and max temperature is 100 C (212 F.) Anything below 80 C is perfectly fine. The only reason really to prevent your CPU from reaching its max clocks is of you're using a cooler that makes too much noise.
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
Peter Humphrey wrote:
> On Saturday, 15 June 2024 07:53:06 BST Dale wrote:
>> Peter Humphrey wrote:
>>> Here's the output of parted -l on my main NVMe disk in case it helps:
>>>
>>> Model: Samsung SSD 970 EVO Plus 250GB (nvme)
>>> Disk /dev/nvme1n1: 250GB
>>> Sector size (logical/physical): 512B/512B
>>> Partition Table: gpt
>>> Disk Flags:
>>>
>>> Number Start End SizeFile system Name Flags
>>>
>>> 1 1049kB 135MB 134MB
>>> 2 135MB 4296MB 4161MB fat32 boot boot, esp
>>> 3 4296MB 12.9GB 8590MB linux-swap(v1) swap1 swap
>>> 4 12.9GB 34.4GB 21.5GB ext4rescue
>>> 5 34.4GB 60.1GB 25.8GB ext4root
>>> 6 60.1GB 112GB 51.5GB ext4var
>>> 7 112GB 114GB 2147MB ext4local
>>> 8 114GB 140GB 25.8GB ext4home
>>> 9 140GB 183GB 42.9GB ext4common
>>>
>> I'm starting the process here. I'm trying to follow the install guide
>> but this is still not clear to me and the guide is not helping. In your
>> list above, is #2 where /boot is mounted? Is that where I put kernels,
>> init thingys, memtest and other images to boot from?
> Yes, and yes ('tree -L 3 /boot' below). I've had no success with the layout
> recommended in the wiki, because I want a choice of kernels to boot; I've
> shown my boot-time screen here before. In fact, gparted shows the unformatted
> first partition as bios_grub. I don't know why parted didn't show the same
> (it
> does show it now) Gparted screen shot attached.
>
> Thus, I have an unused bios_grub partition, then a FAT32 EFI system
> partition,
> then the rest as usual.
Could you share the boot screen again? I used lilo ages ago then
switched to Grub. Grub is massive but it works well enough. Thing is,
seeing your screen may help me to understand how certain options work.
It may make me use the bootloader you use, which is what by the way?
>> My current layout for a 1TB m.2 stick, typing by hand:
>>
>> 18GBEFI System
>> 2400GBLinux file system for root or /.
>> 3180GBLinux file system for /var.
>>
>> I'll have /home and such on other drives, spinning rust. I'm just
>> wanting to be sure if my #1 and your #2 is where boot files go, Grub,
>> kernels, init thingys etc. I've always had kernels and such on ext2 but
>> understand efi requires fat32.
> Yes. I believe the EFI spec requires a file system that any OS can access,
> and
> FAT is it, FAT32 usually being recommended.
>
> Then, when it comes to bootctl and installkernel, I ignore the Gentoo advice
> on USE flags because it results in illegible file names and impenetrable
> directories. My version is far simpler to manage, which I do by hand. I don't
> suppose anyone else would use my approach, but I started it long before the
> days of EFI, and it still works for me.
>
> Also, as I've said here before, I dislike the all-things-to-all-men grub, so
> I
> don't use it.
>
> Incidentally, do you really need so much space in root and /var? Mine are
> just
> 40GB each, and not even half full. I don't run a lot of media apps though.
> Still, space is cheap. :)
>
> $ tree -L 3 /boot
> /boot
> ├── config-6.1.67-gentoo-rescue
> ├── config-6.6.21-gentoo
> ├── config-6.6.21-gentoo-rescue
> ├── config-6.6.30-gentoo
> ├── config-6.6.30-gentoo-rescue
> ├── config-6.7.9-gentoo
> ├── config-6.8.5-gentoo-r1
> ├── early_ucode.cpio
> ├── EFI
> │ ├── BOOT
> │ │ └── BOOTX64.EFI
> │ ├── Linux
> │ └── systemd
> │ └── systemd-bootx64.efi
> ├── intel-uc.img
> ├── loader
> │ ├── entries
> │ │ ├── 06-gentoo-rescue-6.6.30.conf
> │ │ ├── 07-gentoo-rescue-6.6.30.nonet.conf
> │ │ ├── 08-gentoo-rescue-6.6.21.conf
> │ │ ├── 09-gentoo-rescue-6.6.21.nonet.conf
> │ │ ├── 30-gentoo-6.6.30.conf
> │ │ ├── 32-gentoo-6.6.30.conf
> │ │ ├── 34-gentoo-6.6.30.conf
> │ │ ├── 40-gentoo-6.6.21.conf
> │ │ ├── 42-gentoo-6.6.21.conf
> │ │ └── 44-gentoo-6.6.21.conf
> │ ├── entries.srel
> │ ├── loader.conf
> │ └── random-seed
> ├── System.map-6.6.21-gentoo
> ├── System.map-6.6.21-gentoo-rescue
> ├── System.map-6.6.30-gentoo
> ├── System.map-6.6.30-gentoo-rescue
> ├── System.map-6.7.9-gentoo
> ├── System.map-6.8.5-gentoo-r1
> ├── vmlinuz-6.1.67-gentoo-rescue
> ├── vmlinuz-6.6.21-gentoo
> ├── vmlinuz-6.6.21-gentoo-rescue
> ├── vmlinuz-6.6.30-gentoo
> ├── vmlinuz-6.6.30-gentoo-rescue
> ├── vmlinuz-6.7.9-gentoo
> └── vmlinuz-6.8.5-gentoo-r1
>
OK. So, I mount /boot and put my kernels, config files and all the
things I usually put there as usual. Then I have a efi directory under
/boot that the efi tools use. I only created one partition so I assume
when I boot it will find the efi directory within /boot??? If this is
the case, I don't need to redo my partitions. I already started a OS
backup but oh well. ;-)
Like you, I keep old kernels around too. Eventually, I clean out old
o
Re: [gentoo-user] CPU frequency governors and temperatures
On Friday, 14 June 2024 20:53:04 BST Walter Dnes wrote: > On Fri, Jun 14, 2024 at 11:54:52AM +0100, Michael wrote > > > I would think 46-48°C is refreshingly cool, but it very much depends > > on the CPU chip, the MoBo and its BIOS/microcode settings. > > I looked up my CPU (see my reply to Dale). The max temp allowed is > 71.3 C. A short kernel compile is one thing. I tried schedutil during > an emerge world update, and the temp was hitting 70 C. Ouch! schedutil > has to go. Not so fast! :-) The maximum temperature at which your CPU die with its 65W TDP starts throttling to keep its temperatures safe is 100°C TjMax. Look at the TJunction number here: https://www.intel.com/content/www/us/en/products/sku/199271/intel-core-i510400-processor-12m-cache-up-to-4-30-ghz/specifications.html As I understand it 72°C is the TCase temperature. sys-apps/lm-sensors are meant to report TjMax, the core temperature of the CPU. The TCase can be measured (approximately) with an infrared thermometer, or by hacking the cover of the CPU (seriously NOT recommended!). Assuming you have enough RAM and you use all your CPU threads, a big package compile (e.g. chromium) will indicate typical max temperatures your particular installation achieves. Something like MAKEOPTS="-j13 -l12.8" ought to squeeze the juice out of it. The TjMax is controlled by the MoBo firmware and any updates to it. Aftermarket CPU coolers and thermal paste will give you an edge here over stock options for desktops, especially when ambient temperatures hit higher numbers in the summer months. For a laptop there are limited things to try, e.g. better thermal pads/paste and a cooling pad with external fans. However, such measures may only be necessary if the stock cooler does not keep temperatures within normal operating range. According to Intel anything below 100°C is 'normal'. If this were my CPU I would not worry with temperatures ~70-85°C. Above that I would install a better CPU cooler. > > I recall an early i7 CPU laptop would not go above 2,400MHz when > > 4core/8threads were running, but on single core processes I would > > see it on i7z jumping up to 4,200MHz. > > Speaking of cores+threads... I had always thought my cpu had 12 > cores. i.e. /proc/cpuinfo showed 12 "cpus" as did directory > /sys/devices/system/cpu/ But I was wrong. The specs show 6 real cores, > plus hyperthreading. You can use lscpu. It shows threads and cores. > See Greg Kroah-Hartman's presentation about the > security issue called "hyperthreading"... > https://events19.linuxfoundation.org/wp-content/uploads/2018/07/gregkh_mds.p > df Read it and weep. Page 6 summarizes it succinctly... > > == > OpenBSD was right > * Guessed more problems would be in this area > * Disabled SMT for Intel chips in June 2018 > * Repeated the plea to disable this in August 2018 > * Prevented almost all MDS issues automatically > * Security over performance > * Huge respect! > == > > I immediately went into the BIOS and disabled hyperthreading... and > adjusted makeopts in make.conf In June 2018 and for 2019 the idea to disable hyperthreading would be a security precaution, especially for datacenters and systems running VM installations. I am not sure this is either necessary or even recommended anymore. More knowledgeable contributors should chime in here. As far as I know, OEM MoBo firmware updates, CPU microcode releases, OS kernels, compilers and applications have implemented a lot of fixes and patches to cover the litany of CPU bugs and vulnerabilities discovered since then. If you run lscpu and also check your dmesg output, you'll see what known vulnerabilities your CPU may be still be exposed to - if any. Sadly Intel are not very charitable toward their older retail market CPUs and did not release needed microcode updates. This steered me away from their CPUs since then. You could also take a look at the spectre-meltdown-checker if you want a more detailed report on the latest revealed vulnerabilities: https://github.com/speed47/spectre-meltdown-checker signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc
On Friday, 14 June 2024 18:33:57 BST Alan Mackenzie wrote: > Are these files freely available, anywhere, perhaps? Your backup from last week? :) -- Regards, Peter.
Re: [gentoo-user] CPU frequency governors and temperatures
On Friday, 14 June 2024 16:16:09 BST Michael wrote: > Liquid cooling would have made it as quiet as a church mouse. ;-) I have a machine here with liquid cooling, and over its few years it's become deafening under full load (24 simultaneous floating-point physics applications). It is quiet when idling, though - of course. Perhaps I should get busy cleaning... -- Regards, Peter.
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On Saturday, 15 June 2024 07:53:06 BST Dale wrote:
> Peter Humphrey wrote:
> > Here's the output of parted -l on my main NVMe disk in case it helps:
> >
> > Model: Samsung SSD 970 EVO Plus 250GB (nvme)
> > Disk /dev/nvme1n1: 250GB
> > Sector size (logical/physical): 512B/512B
> > Partition Table: gpt
> > Disk Flags:
> >
> > Number Start End SizeFile system Name Flags
> >
> > 1 1049kB 135MB 134MB
> > 2 135MB 4296MB 4161MB fat32 boot boot, esp
> > 3 4296MB 12.9GB 8590MB linux-swap(v1) swap1 swap
> > 4 12.9GB 34.4GB 21.5GB ext4rescue
> > 5 34.4GB 60.1GB 25.8GB ext4root
> > 6 60.1GB 112GB 51.5GB ext4var
> > 7 112GB 114GB 2147MB ext4local
> > 8 114GB 140GB 25.8GB ext4home
> > 9 140GB 183GB 42.9GB ext4common
> >
> I'm starting the process here. I'm trying to follow the install guide
> but this is still not clear to me and the guide is not helping. In your
> list above, is #2 where /boot is mounted? Is that where I put kernels,
> init thingys, memtest and other images to boot from?
Yes, and yes ('tree -L 3 /boot' below). I've had no success with the layout
recommended in the wiki, because I want a choice of kernels to boot; I've
shown my boot-time screen here before. In fact, gparted shows the unformatted
first partition as bios_grub. I don't know why parted didn't show the same (it
does show it now) Gparted screen shot attached.
Thus, I have an unused bios_grub partition, then a FAT32 EFI system partition,
then the rest as usual.
> My current layout for a 1TB m.2 stick, typing by hand:
>
> 18GBEFI System
> 2400GBLinux file system for root or /.
> 3180GBLinux file system for /var.
>
> I'll have /home and such on other drives, spinning rust. I'm just
> wanting to be sure if my #1 and your #2 is where boot files go, Grub,
> kernels, init thingys etc. I've always had kernels and such on ext2 but
> understand efi requires fat32.
Yes. I believe the EFI spec requires a file system that any OS can access, and
FAT is it, FAT32 usually being recommended.
Then, when it comes to bootctl and installkernel, I ignore the Gentoo advice
on USE flags because it results in illegible file names and impenetrable
directories. My version is far simpler to manage, which I do by hand. I don't
suppose anyone else would use my approach, but I started it long before the
days of EFI, and it still works for me.
Also, as I've said here before, I dislike the all-things-to-all-men grub, so I
don't use it.
Incidentally, do you really need so much space in root and /var? Mine are just
40GB each, and not even half full. I don't run a lot of media apps though.
Still, space is cheap. :)
$ tree -L 3 /boot
/boot
├── config-6.1.67-gentoo-rescue
├── config-6.6.21-gentoo
├── config-6.6.21-gentoo-rescue
├── config-6.6.30-gentoo
├── config-6.6.30-gentoo-rescue
├── config-6.7.9-gentoo
├── config-6.8.5-gentoo-r1
├── early_ucode.cpio
├── EFI
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
├── intel-uc.img
├── loader
│ ├── entries
│ │ ├── 06-gentoo-rescue-6.6.30.conf
│ │ ├── 07-gentoo-rescue-6.6.30.nonet.conf
│ │ ├── 08-gentoo-rescue-6.6.21.conf
│ │ ├── 09-gentoo-rescue-6.6.21.nonet.conf
│ │ ├── 30-gentoo-6.6.30.conf
│ │ ├── 32-gentoo-6.6.30.conf
│ │ ├── 34-gentoo-6.6.30.conf
│ │ ├── 40-gentoo-6.6.21.conf
│ │ ├── 42-gentoo-6.6.21.conf
│ │ └── 44-gentoo-6.6.21.conf
│ ├── entries.srel
│ ├── loader.conf
│ └── random-seed
├── System.map-6.6.21-gentoo
├── System.map-6.6.21-gentoo-rescue
├── System.map-6.6.30-gentoo
├── System.map-6.6.30-gentoo-rescue
├── System.map-6.7.9-gentoo
├── System.map-6.8.5-gentoo-r1
├── vmlinuz-6.1.67-gentoo-rescue
├── vmlinuz-6.6.21-gentoo
├── vmlinuz-6.6.21-gentoo-rescue
├── vmlinuz-6.6.30-gentoo
├── vmlinuz-6.6.30-gentoo-rescue
├── vmlinuz-6.7.9-gentoo
└── vmlinuz-6.8.5-gentoo-r1
--
Regards,
Peter.
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
Michael wrote: > On Saturday, 15 June 2024 07:53:06 BST Dale wrote: >> Peter Humphrey wrote: >>> On Sunday, 2 June 2024 16:11:38 BST Dale wrote: My plan, given it is a 1TB, use maybe 300GBs of it. Leave the rest blank. Have the /boot, EFI directory, root and maybe put /var on a separate partition. I figure for the boot stuff, 3GBs would be plenty for all combined. Make them large so they can grow. Make root, which would include /usr, say 150GBs. /var can be around 10GBs. My current OS is on a 160GB drive. I wish I could get the nerve up to use LVM on everything except the boot stuff, /boot and the EFI stuff. If I make them like above, I should be good for a long time. Could go much larger tho. Could use maybe 700GBs of it. I assume it would use the unused part if needed. I still don't know a lot about those things. Mostly what I see posted on this list really. >>> Doesn't everyone mount /tmp and /var/tmp/portage on tmpfs these days? I >>> use >>> hard disk for a few large packages, but I'm not convinced it's needed - >>> except when running an emerge -e, that is, when they can get in the way >>> of lots of others. That's why, some months ago, I suggested introducing >>> an ability to mark some packages for compilation solitarily. (Is that a >>> word?) >>> >>> Here's the output of parted -l on my main NVMe disk in case it helps: >>> >>> Model: Samsung SSD 970 EVO Plus 250GB (nvme) >>> Disk /dev/nvme1n1: 250GB >>> Sector size (logical/physical): 512B/512B >>> Partition Table: gpt >>> Disk Flags: >>> >>> Number Start End SizeFile system Name Flags >>> >>> 1 1049kB 135MB 134MB >>> 2 135MB 4296MB 4161MB fat32 boot boot, esp >>> 3 4296MB 12.9GB 8590MB linux-swap(v1) swap1 swap >>> 4 12.9GB 34.4GB 21.5GB ext4rescue >>> 5 34.4GB 60.1GB 25.8GB ext4root >>> 6 60.1GB 112GB 51.5GB ext4var >>> 7 112GB 114GB 2147MB ext4local >>> 8 114GB 140GB 25.8GB ext4home >>> 9 140GB 183GB 42.9GB ext4common >>> >>> The common partition is mounted under my home directory, to keep >>> everything >>> I'd want to preserve if I made myself a new user account. It's v. useful, >>> too. >> I'm starting the process here. I'm trying to follow the install guide >> but this is still not clear to me and the guide is not helping. In your >> list above, is #2 where /boot is mounted? Is that where I put kernels, >> init thingys, memtest and other images to boot from? > I'm simplifying this to keep it short, but you can understand the UEFI MoBo > firmware to be no different than the legacy CMOS code on your old MoBo, > except > upgraded, much larger and more powerful in its capabilities. In particular, > it can access, load and execute directly specially structured executables, > stored as *.efi files on a GPT formatted disk, in the EFI System Partition > (ESP). The ESP should be formatted as FAT32 and contain a directory named > EFI > in its top level, where any .EFI executables should be stored. The ESP does > not have to be the first partition on the disk, the UEFI firmware will scan > and find .efi files in whichever FAT32 partition they are stored. > > NOTES: > > 1. Some MoBo's UEFI firmware offer a 'Compatibility Support Module' (CSM) > setting, which if enabled will allow disks with a DOS partition table and a > boot loader in the MBR to be booted by the UEFI MoBo. Since you are starting > from scratch and you're not installing Windows 98 there is no reason to have > this feature enabled. I suggest you follow the handbook and use a GPT > partitioned disk with an ESP installed boot loader. Left CSM cut off, didn't know what it was anyway. LOL Using GPT, prefer to use GPT on everything just to be consistent. > 2. The UEFI firmware is capable of loading Linux kernels directly without a > 3rd party boot loader, as long as the kernels have been created to include > the > 'EFI stub'. This makes the kernel image executable by the UEFI firmware, > without the intervention of a boot loader/manager like GRUB: > > https://wiki.gentoo.org/wiki/EFI_stub > > Multibooting of different OSs or kernels can be managed thereafter by using > the CLI tool efibootmgr, or the UEFI boot menu (by pressing F2, DEL, or some > such key during POST). > > https://wiki.gentoo.org/wiki/Efibootmgr > > Given the above you broadly have the following choices: > > a) Simplest, direct, without a 3rd party bootloader: > > Mount your ESP under the /boot mountpoint and drop your kernel .efi images in > there, under the /boot/EFI/ directory, then boot them directly using the UEFI > firmware or efibootmgr to switch between them. > > b) Using a bootloader: > > Mount your ESP under the /efi mountpoint. GRUB et al, will install their > .efi > image in the /efi/EFI/ directory. You can
Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?
On Saturday, 15 June 2024 07:53:06 BST Dale wrote: > Peter Humphrey wrote: > > On Sunday, 2 June 2024 16:11:38 BST Dale wrote: > >> My plan, given it is a 1TB, use maybe 300GBs of it. Leave the rest > >> blank. Have the /boot, EFI directory, root and maybe put /var on a > >> separate partition. I figure for the boot stuff, 3GBs would be plenty > >> for all combined. Make them large so they can grow. Make root, which > >> would include /usr, say 150GBs. /var can be around 10GBs. My current > >> OS is on a 160GB drive. I wish I could get the nerve up to use LVM on > >> everything except the boot stuff, /boot and the EFI stuff. If I make > >> them like above, I should be good for a long time. Could go much larger > >> tho. Could use maybe 700GBs of it. I assume it would use the unused > >> part if needed. I still don't know a lot about those things. Mostly > >> what I see posted on this list really. > > > > Doesn't everyone mount /tmp and /var/tmp/portage on tmpfs these days? I > > use > > hard disk for a few large packages, but I'm not convinced it's needed - > > except when running an emerge -e, that is, when they can get in the way > > of lots of others. That's why, some months ago, I suggested introducing > > an ability to mark some packages for compilation solitarily. (Is that a > > word?) > > > > Here's the output of parted -l on my main NVMe disk in case it helps: > > > > Model: Samsung SSD 970 EVO Plus 250GB (nvme) > > Disk /dev/nvme1n1: 250GB > > Sector size (logical/physical): 512B/512B > > Partition Table: gpt > > Disk Flags: > > > > Number Start End SizeFile system Name Flags > > > > 1 1049kB 135MB 134MB > > 2 135MB 4296MB 4161MB fat32 boot boot, esp > > 3 4296MB 12.9GB 8590MB linux-swap(v1) swap1 swap > > 4 12.9GB 34.4GB 21.5GB ext4rescue > > 5 34.4GB 60.1GB 25.8GB ext4root > > 6 60.1GB 112GB 51.5GB ext4var > > 7 112GB 114GB 2147MB ext4local > > 8 114GB 140GB 25.8GB ext4home > > 9 140GB 183GB 42.9GB ext4common > > > > The common partition is mounted under my home directory, to keep > > everything > > I'd want to preserve if I made myself a new user account. It's v. useful, > > too. > I'm starting the process here. I'm trying to follow the install guide > but this is still not clear to me and the guide is not helping. In your > list above, is #2 where /boot is mounted? Is that where I put kernels, > init thingys, memtest and other images to boot from? I'm simplifying this to keep it short, but you can understand the UEFI MoBo firmware to be no different than the legacy CMOS code on your old MoBo, except upgraded, much larger and more powerful in its capabilities. In particular, it can access, load and execute directly specially structured executables, stored as *.efi files on a GPT formatted disk, in the EFI System Partition (ESP). The ESP should be formatted as FAT32 and contain a directory named EFI in its top level, where any .EFI executables should be stored. The ESP does not have to be the first partition on the disk, the UEFI firmware will scan and find .efi files in whichever FAT32 partition they are stored. NOTES: 1. Some MoBo's UEFI firmware offer a 'Compatibility Support Module' (CSM) setting, which if enabled will allow disks with a DOS partition table and a boot loader in the MBR to be booted by the UEFI MoBo. Since you are starting from scratch and you're not installing Windows 98 there is no reason to have this feature enabled. I suggest you follow the handbook and use a GPT partitioned disk with an ESP installed boot loader. 2. The UEFI firmware is capable of loading Linux kernels directly without a 3rd party boot loader, as long as the kernels have been created to include the 'EFI stub'. This makes the kernel image executable by the UEFI firmware, without the intervention of a boot loader/manager like GRUB: https://wiki.gentoo.org/wiki/EFI_stub Multibooting of different OSs or kernels can be managed thereafter by using the CLI tool efibootmgr, or the UEFI boot menu (by pressing F2, DEL, or some such key during POST). https://wiki.gentoo.org/wiki/Efibootmgr Given the above you broadly have the following choices: a) Simplest, direct, without a 3rd party bootloader: Mount your ESP under the /boot mountpoint and drop your kernel .efi images in there, under the /boot/EFI/ directory, then boot them directly using the UEFI firmware or efibootmgr to switch between them. b) Using a bootloader: Mount your ESP under the /efi mountpoint. GRUB et al, will install their .efi image in the /efi/EFI/ directory. You can have your /boot as a directory on your / partition, or on its own separate partition with a more robust fs type than ESP's FAT and your kernel images will be installed in there. c) For systemd you can mount your ESP un
Re[2]: [gentoo-user] Difficulty with updating /etc/basb/bashrc
-- Original Message -- From "Paul Colquhoun" To gentoo-user@lists.gentoo.org Date 15.06.2024 01:43:22 Subject Re: [gentoo-user] Difficulty with updating /etc/basb/bashrc You edited the old file, not portage. Why didn't you keep a copy of the old file? I have this in the crontabs of my servers: # fcrontab -l | grep git 2024-06-15 10:26:22 INFO listing root's fcrontab %hourly,mail(no) 35 cd /etc && git add --all . && git commit -m "autocommit" One server recorded 147 commits during the last 12 months, another one reports 1509 commits during the last 12 years. Set it up and forget about it until you run into this problem the next time. s.
