Re: [gentoo-user] motherboard BIOS vs CPU microcode

2021-04-12 Thread Michael
On Monday, 12 April 2021 11:56:40 BST Adam Carter wrote:
> Do these largely overlap?

Yes.

> So if your motherboard manufacturer is diligent with releasing updates and
> you've applied them, you generally won't expect a 'microcode updated early
> to new patch_level' message from dmesg?

>From what I've come across so far, it's been the case MoBo manufacturers 
release BIOS/UEFI code upgrades for a few years only.  Dekstop MoBos up to 5 
years after product launch, laptops up to 2 years if you're lucky.  Thereafter 
CPU microcode patching becomes an exercise for the OS.  However, the CPU 
manufacturer may not bother releasing updates for your CPU model, in which 
case the result is the same.  :(

The signature of the microcode will change after an OEM BIOS/UEFI code upgrade 
has been flashed into the MoBo, so you'll be able to tell if the upgrade had 
anything to do with the CPU.

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


Re: [gentoo-user] Can't install a new system

2021-04-12 Thread Peter Humphrey
On Thursday, 8 April 2021 16:47:05 BST Neil Bothwick wrote:
> On Thu, 08 Apr 2021 13:27:51 +0100, Peter Humphrey wrote:
> > Untarring the latest stage-3 onto /mnt/gentoo, /mnt/gentoo/var and /mnt/
> > gentoo/usr/local gets me started. Then I chroot /mnt/gentoo /bin/bash,
> > and that works too. Then I leave the profile at the default vanilla
> > amd64 and emerge-webrsync. So far so good. Then when I try emerge
> > -uaDvN @world I get a circular dependency involving elt-patches and
> > xz-utils. No amount of unsetting of USE flags makes any difference. Nor
> > does --excluding one of them, because portage just refuses to do that.
> 
> Try omitting -D and -N to reduce the number of packages being rebuilt. If
> that doesn't help, post the output here.

Okay, step by step. First I chose the basic make.profile, number 1, and 
installed my base system set - everything that doesn't need a GUI. Then I 
switched to the basic desktop profile, number 5 and ran a -uav @world. So far 
so good, but then I attempted to install a basic set of GUI packages - 
everything but a DE. The command was 'emerge -uav @xorg'. I got this:

--->8
>>> Preparing source in /var/tmp/portage/dev-ruby/net-telnet-0.2.0/work ...
 * Running prepare phase for all ...
 * Running prepare phase for all ...
 * Running source copy phase for ruby27 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-ruby/net-telnet-0.2.0/work ...
 * Running configure phase for ruby27 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-ruby/net-telnet-0.2.0/work ...
 * Running compile phase for ruby27 ...
 * Running compile phase for all ...
>>> Source compiled.
 * Skipping make test/check due to ebuild restriction.
>>> Test phase [disabled because of RESTRICT=test]: dev-ruby/net-telnet-0.2.0

>>> Install dev-ruby/net-telnet-0.2.0 into /var/tmp/portage/dev-ruby/net-
telnet-0.2.0/image/
 * Running install phase for ruby27 ...
Traceback (most recent call last):
3: from :1:in `'
2: from :1:in `require'
1: from /usr/lib64/ruby/2.7.0/rubygems.rb:16:in `'
/usr/lib64/ruby/2.7.0/rubygems.rb:16:in `require': cannot load such file -- 
rubygems/compatibility (LoadError)
 * Unable to find the gems dir
 * ERROR: dev-ruby/net-telnet-0.2.0::gentoo failed (install phase):
 *   Unable to find the gems dir
--->8

There seems to be an inconsistency in the ruby packaging. Is there anything I 
can do to evade it? I've attached the package-set files I use when building a 
new system, for info.

-- 
Regards,
Peter.
app-emulation/virtualbox-additions
app-emulation/virtualbox-extpack-oracle
app-emulation/virtualbox-modules
app-office/libreoffice
kde-apps/kwrite
kde-apps/okular
media-gfx/gimp
net-analyzer/nmap
net-misc/netkit-telnetd
net-print/cups
net-print/cups-pdf
sci-misc/boinc
sys-apps/gptfdisk
sys-block/gparted
www-client/firefox

app-admin/hddtemp
app-admin/lib_users
app-admin/logrotate
app-admin/sudo
app-admin/syslog-ng
app-editors/joe
app-editors/nano
app-misc/colordiff
app-misc/mmv
app-portage/eix
app-portage/elogv
app-portage/euses
app-portage/genlop
app-portage/gentoolkit
net-analyzer/iptraf-ng
net-analyzer/tcpdump
net-analyzer/traceroute
net-firewall/shorewall
net-fs/nfs-utils
net-misc/chrony
net-misc/whois
sys-apps/lshw
sys-apps/portage
sys-apps/smartmontools
sys-apps/usbutils
sys-fs/dosfstools
sys-fs/ntfs3g
sys-power/acpid
sys-process/cronie
sys-process/iotop
sys-process/lsof
www-client/links


core
Description: application/core
dev-lang/rust-bin
gui-libs/display-manager-init
kde-apps/ark
kde-apps/filelight
kde-apps/k3b
#kde-apps/kcharselect
kde-apps/kdeadmin-meta
kde-apps/kdecore-meta
kde-apps/kdegraphics-meta
kde-apps/kdepim-meta
kde-apps/konsole
kde-apps/krfb
kde-apps/kwalletmanager
kde-apps/print-manager
kde-misc/kio-gdrive
kde-plasma/plasma-meta
kde-misc/kio-gdrive
mail-filter/spamassassin
media-fonts/dejavu

## Added to replace kde-plasma/plasma-meta
#kde-plasma/breeze-gtk
#kde-plasma/plasma-browser-integration
#kde-plasma/kde-gtk-config
#kde-plasma/kdeplasma-addons
#kde-plasma/khotkeys
#kde-plasma/kwallet-pam
#kde-plasma/oxygen
#kde-plasma/plasma-desktop
#kde-plasma/sddm-kcm
#kde-plasma/systemsettings
#x11-misc/sddm
app-misc/radeontop
app-portage/cpuid2cpuflags
net-dns/bind-tools
sys-apps/hwinfo
sys-fs/extundelete
dev-libs/amdgpu-pro-opencl
media-fonts/corefonts
media-fonts/freefont
media-fonts/intlfonts
media-fonts/unifont
x11-apps/mesa-progs
x11-base/xorg-server
x11-drivers/xf86-video-amdgpu
x11-plugins/gkrellm-gkfreq
x11-plugins/gkrellmoon
x11-plugins/gkrellsun
x11-plugins/gkrelltop
x11-themes/gkrellm-themes


[gentoo-user] motherboard BIOS vs CPU microcode

2021-04-12 Thread Adam Carter
Do these largely overlap?

So if your motherboard manufacturer is diligent with releasing updates and
you've applied them, you generally won't expect a 'microcode updated early
to new patch_level' message from dmesg?


Re: [gentoo-user] Can't install a new system

2021-04-12 Thread Peter Humphrey
On Sunday, 11 April 2021 12:02:27 BST Rich Freeman wrote:
> On Sun, Apr 11, 2021 at 6:33 AM Peter Humphrey  
wrote:
> > I think I must have had a bad stage tarball. At any rate, that problem
> > doesn't occur now.
> 
> Possible, though it seems more likely that it was a bad repo that you
> synced.  The problem would go away the next time you ran emerge --sync
> (whether on the same stage3 or with a new one).

It could also have been damaged in transit. I'm afraid I've got out of the 
habit of checking the downloads. Anyway, I've fetched it again and checked it 
this time.

-- 
Regards,
Peter.