View previous topic :: View next topic |
Author |
Message |
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Mon May 17, 2021 5:37 pm Post subject: |
|
|
There is something buggy here at the forum: it indicates there are comments in another page but wont let me access them... |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Mon May 17, 2021 6:46 pm Post subject: |
|
|
I deleted the 5.10 kernel, unmerged it, reemerged it and reestart the compilation. Now I have warnings also in "sudo make", in the beginning of the compilation:
Code: |
linux> sudo make menuconfig
Password:
HOSTCC scripts/kconfig/preprocess.o
HOSTLD scripts/kconfig/mconf
WARNING: unmet direct dependencies detected for ADI_AXI_ADC
Depends on [n]: IIO [=m] && HAS_IOMEM [=y] && OF [=n]
Selected by [m]:
- AD9467 [=m] && IIO [=m] && SPI [=y]
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
linux> sudo make
SYNC include/config/auto.conf.cmd
HOSTLD scripts/kconfig/conf
WARNING: unmet direct dependencies detected for ADI_AXI_ADC
Depends on [n]: IIO [=m] && HAS_IOMEM [=y] && OF [=n]
Selected by [m]:
- AD9467 [=m] && IIO [=m] && SPI [=y]
WARNING: unmet direct dependencies detected for ADI_AXI_ADC
Depends on [n]: IIO [=m] && HAS_IOMEM [=y] && OF [=n]
Selected by [m]:
- AD9467 [=m] && IIO [=m] && SPI [=y]
WARNING: unmet direct dependencies detected for ADI_AXI_ADC
Depends on [n]: IIO [=m] && HAS_IOMEM [=y] && OF [=n]
Selected by [m]:
- AD9467 [=m] && IIO [=m] && SPI [=y]
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
.
.
.
|
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Mon May 17, 2021 7:01 pm Post subject: |
|
|
vcmota,
Run
Use the search to find ADI_AXI_ADC and turn it off if you don't need it or turn on OF if you do need ADI_AXI_ADC.
Either will fix the warning.
Even if the kernel compiles as is, ADI_AXI_ADC won't work.
There are a number of bugs in the forums but we are going to move to phpBB3 'real soon', so they won't be fixed. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Mon May 17, 2021 7:16 pm Post subject: |
|
|
Thank you NeddySeagoon. I removed anything remotely related with the keyword and the compilation restarted without issue. I will now see if this solves the other difficulties I am having. As soon as the compilation finishes I will reboot and check.
Thank you again! |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 3:51 am Post subject: |
|
|
It did not work. The kernel took much longer to compile but I still can't use the keyboard after login in with the new kernel.
However, I am starting to think this issue has no direct relation to the kernel, but with the way I start the X session after login.
First, In one of the times I rebooted the system with the new kernel the keyboard simply worked. I then restarted the computer to check to see if it was permanent but it wasn't. For some reason it simply worked, but this seems to prove that it wont be a kernel issue, otherwise it would never work.
Second, if instead of login in with the user I do it with root, which has no X session attached to it, the keyboard works.
This is how I start my X session, which occurs without using a display manager:
Code: |
~> cat .xinitrc
#!/bin/bash
barM &
setxkbmap br
feh --bg-scale /home/vinicius/Downloads/337033.jpg &
exec dbus-launch --exit-with-session dwm
~> cat .bash_profile
# /etc/skel/.bash_profile
# This file is sourced by bash for login shells. The following line
# runs your .bashrc and is recommended by the bash info pages.
if [[ -f ~/.bashrc ]] ; then
. ~/.bashrc
fi
export PATH=$PATH:/sbin
xinit .xinitrc -- /etc/X11/xinit/xserverrc
~>
|
|
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 1:22 pm Post subject: |
|
|
I find out this thread in the arch forums. It seems related, but I cant say what is wrong with my locales, if there is anything wrong:
Code: |
~> locale
LANG=
LC_CTYPE=pt_BR.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
~> locale -a
C
C.utf8
POSIX
pt_BR.utf8
~> eselect locale list
Available targets for the LANG variable:
[1] C
[2] C.utf8
[3] POSIX
[4] pt_BR.utf8
[ ] (free form)
~> cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-march=native -O2"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE and USE_EXPAND flags that were used for
# buidling in addition to what is provided by the profile.
USE="X policykit dbus elogind -consolekit alsa acl udev savedconfig udisks fortran lapack threads unicode symlink crypt"
MAKEOPTS="-j5"
CPU_FLAGS_X86="mmx sse sse2 mmxext"
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
VIDEO_CARDS="nouveau radeon"
INPUT_DEVICES="libinput wacom"
FEATURES="nostrip"
POLICY_TYPES="strict"
LINGUAS="en pt pt_BR zh zn_CN"
L10N="en pt pt-BR zh zh-CN"
GENTOO_MIRRORS="https://gentoo.c3sl.ufpr.br/ http://gentoo.c3sl.ufpr.br/ rsync://gentoo.c3sl.ufpr.br/gentoo/"
~>
|
|
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 3:44 pm Post subject: |
|
|
I managed to save the outputs of .local/share/xorg/Xorg.0.log which are generated immediately upon login for both the 4.19 and 5.10 kernels, and they are completely different. Here is the output for 4.19, and here for 5.10. It seems that after calling X upon login with the 5.10 kernel the systems scrambles harshly with the driver for the graphic card (RADEON is mentioned multiple times in this file), while for 4.19 (where everything works fine) the word RADEON doesn't even appears. The funny thing is that both kernels have been compiled locally (obviously, since this is gentoo) and with the exact same options in make.conf, which I will repeat below:
Code: |
~> cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-march=native -O2"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE and USE_EXPAND flags that were used for
# buidling in addition to what is provided by the profile.
USE="X policykit dbus elogind -consolekit alsa acl udev savedconfig udisks fortran lapack threads unicode symlink crypt"
MAKEOPTS="-j5"
CPU_FLAGS_X86="mmx sse sse2 mmxext"
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
VIDEO_CARDS="nouveau radeon"
INPUT_DEVICES="libinput wacom"
FEATURES="nostrip"
POLICY_TYPES="strict"
LINGUAS="en pt pt_BR zh zn_CN"
L10N="en pt pt-BR zh zh-CN"
GENTOO_MIRRORS="https://gentoo.c3sl.ufpr.br/ http://gentoo.c3sl.ufpr.br/ rsync://gentoo.c3sl.ufpr.br/gentoo/"
~>
|
Also, if I understand correctly, since I start the kernel update with "make menuconfig", the kernel options for 5.10 should be the same as those for 4.19. |
|
Back to top |
|
|
Ralphred Guru
Joined: 31 Dec 2013 Posts: 494
|
Posted: Tue May 18, 2021 6:32 pm Post subject: |
|
|
vcmota wrote: | Also, if I understand correctly, since I start the kernel update with "make menuconfig", the kernel options for 5.10 should be the same as those for 4.19. |
Not quite, it'll start with no config that way, and only fix conflicts in the config file it generates.
If you have the old config (in ../linux-4.19.x/.config , or /boot/config-4.19.x-gentoo, or from "zcat /proc/config.gz") copy it into your new kernels base directory, then run from there.
It will rationalise your old config in the context of the new kernel, and present you with a command line [y/n/m] for each of the new options not available in the old kernel. Unless there is something specific you wanted in the new kernel, for testing purposes you can just hold down the enter button and accept the defaults, once it's working go in and take out the unneeded stuff later on (either by copying the old config again and paying attention to the "make oldconfig" questions, or by hand with "make menuconfig").
If you start messing around with config options and the kernel starts to fail to build, you can force it to start from scratch with "make clean".
You also have the option to "make mrproper" which will clear out any configs you have set as well, making the kernel source tree as if it had just been installed (In theory).
If I do start tinkering with my .config, for new hardware or whatever, I always cp .config ../config-5.x.x-working-[date] before I start, it's always good to have a backup
You also mentioned nvidia, which I think requires some kind of update to build the modules for your new kernel, but someone else will have to fill you in on that, sorry.
For the locale issue, your eselect locale list doesn't show a * for the selected locale.
Seems like you need to run "eselect locale set 4" but I suggest you follow this guide carefully and try not to miss any steps.
Last edited by Ralphred on Tue May 18, 2021 6:42 pm; edited 1 time in total |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 6:42 pm Post subject: |
|
|
Ralphred wrote: | vcmota wrote: | Also, if I understand correctly, since I start the kernel update with "make menuconfig", the kernel options for 5.10 should be the same as those for 4.19. |
Not quite, it'll start with no config that way, and only fix conflicts in the config file it generates.
If you have the old config (in ../linux-4.19.x/.config , or /boot/config-4.19.x-gentoo, or from "zcat /proc/config.gz") copy it into your new kernels base directory, then run from there.
It will rationalise your old config in the context of the new kernel, and present you with a command line [y/n/m] for each of the new options not available in the old kernel. Unless there is something specific you wanted in the new kernel, for testing purposes you can just hold down the enter button and accept the defaults, once it's working go in and take out the unneeded stuff later on (either by copying the old config again and paying attention to the make oldcofig questions, or by hand with make menuconfig).
If you start messing around with config options and the kernel starts to fail to build, you can force it to start from scratch with "make clean".
You also have the option to "make mrproper" which will clear out any configs you have set as well, making the kernel source tree as if it had just been installed (In theory).
If I do start tinkering with my .config, for new hardware or whatever, I always cp .config ../config-5.x.x-working-[date] before I start, it's always good to have a backup
You also mentioned nvidia, which I think requires some kind of update to build the modules for your new kernel, but someone else will have to fill you in on that, sorry. |
Thank you Ralphred for your reply. I did it and the kernel is now compiling. This is what I did exactly:
Code: |
~> ls /boot
System.map-4.19.37-gentoo System.map-5.10.27-gentoo-x86_64.old config-5.10.27-gentoo-x86_64 grub initramfs-5.10.27-gentoo-x86_64.img.old lost+found vmlinuz-5.10.27-gentoo-x86_64
System.map-5.10.27-gentoo-x86_64 config-4.19.37-gentoo config-5.10.27-gentoo-x86_64.old initramfs-5.10.27-gentoo-x86_64.img initramfs-genkernel-x86_64-4.19.37-gentoo vmlinuz-4.19.37-gentoo vmlinuz-5.10.27-gentoo-x86_64.old
~> ls /boot/*5.10*
/boot/System.map-5.10.27-gentoo-x86_64 /boot/config-5.10.27-gentoo-x86_64 /boot/initramfs-5.10.27-gentoo-x86_64.img /boot/vmlinuz-5.10.27-gentoo-x86_64
/boot/System.map-5.10.27-gentoo-x86_64.old /boot/config-5.10.27-gentoo-x86_64.old /boot/initramfs-5.10.27-gentoo-x86_64.img.old /boot/vmlinuz-5.10.27-gentoo-x86_64.old
~> sudo rm /boot/*5.10*
~> cd /usr/src/linux
linux> sudo make oldconfig
#
# No change to .config
#
linux> ls /boot
System.map-4.19.37-gentoo config-4.19.37-gentoo grub initramfs-genkernel-x86_64-4.19.37-gentoo lost+found vmlinuz-4.19.37-gentoo
linux> sudo make
.
.
.
|
|
|
Back to top |
|
|
Ralphred Guru
Joined: 31 Dec 2013 Posts: 494
|
Posted: Tue May 18, 2021 6:50 pm Post subject: |
|
|
OK, you missed a step, not to worry, I have enough info to write it all so you can cut and paste
make sure that linux points to linux-5.10.27-gentoo at this point, like this Code: | lrwxrwxrwx 1 root root 19 Mar 6 01:15 linux -> linux-5.10.27-gentoo |
We'll assume it does, so continue with Code: | cd linux
cp .config ../config-5.10.27.backup
cp /boot/config-4.19.37-gentoo .config
make oldconfig |
Then you will get your list of new options. And run eselect locale set (see edit to previous post) ^^
Oh, and from your make.conf you can doto speed up the compile in line with your cpu cores.
May as well finish, lol, then Code: | sudo make modules_install
sudo make install
sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg-4.19.37.bak
sudo grub-mkconfig >/boot/grub/grub.cfg
emerge [something for the nvidia driver] | then reboot.
Once it's working Code: | emerge --noreplace gentoo-sources:5.10.27 | will put 5.10.27 specifically in your world file, so it won't ask to get uninstalled if you emerge --depclean at a later date when a new 5.10.x kernel is installed in /usr/src, but you may not have started using it yet. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 7:26 pm Post subject: |
|
|
Thank you Ralphred for your reply. I did it as you said and the kernel is being compiled. Just a note: my graphic card is ati radeon, not nvidia.
Thank you again! |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Tue May 18, 2021 7:28 pm Post subject: |
|
|
vcmota,
Code: | sudo make install
sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg-4.19.37.bak |
/boot needs to be mounted before you run make install. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Ralphred Guru
Joined: 31 Dec 2013 Posts: 494
|
Posted: Tue May 18, 2021 7:55 pm Post subject: |
|
|
vcmota wrote: | my graphic card is ati radeon, not nvidia. | I read some nvidia stuff in the xorg.0.log, so just mentioned it. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 8:48 pm Post subject: |
|
|
It did not work. Here is the new output of .local/share/xorg/Xorg.0.log, which changed completely, but neither keyboard nor usb mouse are working. I also set the locale, following the localization guide, as you can see here:
Code: |
~> eselect locale list
Available targets for the LANG variable:
[1] C
[2] C.utf8
[3] POSIX
[4] pt_BR.utf8 *
[ ] (free form)
~>
|
But it also had no effect on the issue. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Tue May 18, 2021 8:53 pm Post subject: |
|
|
vcmota,
What time and date appear in
That's the build time and date of the running kernel.
Does it look right for your most recent kernel build? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 9:06 pm Post subject: |
|
|
For the kernel that works this is the output:
Code: |
Linux mossadegh 4.19.37-gentoo #1 SMP Fri May 10 09:52:56 UTC 2019 x86_64 Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz GenuineIntel GNU/Linux
|
and for the kernel where the issue appears this is it:
Code: |
Linux mossadegh 5.10.27-gentoo #5 SMP Tue May 18 17:17:26 UTC 2021 x86_64 Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz GenuineIntel GNU/Linux
|
In both cases the information is correct. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Tue May 18, 2021 9:23 pm Post subject: |
|
|
At this stage it looks more likely to be some option that should have been set in the new kernels due to the fact that the hardware is ver old. Although he computer is 9 years old, we are surely talking about a 10 year old configuration, at least. And something changed between kernels 4.19 and 5.10 that I have missed, i. e., this issue very likely would have appeared last year after a kernel update that I never made. But how to find out? |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue May 18, 2021 9:42 pm Post subject: |
|
|
Just a thought, but maybe use a 5.4 kernel as an intermediate? Leaping from 4.17 to 5.10 seems like jumping a chasm to me.
No expert, just a thought. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Wed May 19, 2021 4:04 am Post subject: |
|
|
Just a small update. I keep myself suspicious of the fact that there is something missing from the kernel, some option that should have been set. Therefore I recompiled the kernel adding support for anything that seemed even remotely plausible to be relevant for the keyboard and USB devices. It was useless regarding the main issue. This is the config for the 5.10 kernel where neither mouse nor keyboard works, and this is for the 4.19 kernel where everything works.
I have also removed the keywod "nouveau" from VIDEO_CARDS in make.conf, since my video card is radeon, and made the proper updates (emerge @world, @preserved-rebuild and depclean), also without any success whatsoever regarding the persistent issue. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Wed May 19, 2021 2:19 pm Post subject: |
|
|
Tony0945 wrote: | Just a thought, but maybe use a 5.4 kernel as an intermediate? Leaping from 4.17 to 5.10 seems like jumping a chasm to me.
No expert, just a thought. |
What I think is that, if this is really due to some misterious option that should have being set in the kernel, than this would certainly not solve the issue. Meaning that the only thing that this should give me is when the problem occurred, i. e., in which version of the kernel my keyboard and perifericals were no longer working out of the box, and I would have to try all the kernels starting from 4.19.
BUT... What do I have to lose? I am completely stuck, cant use my computer properly and the new one I bought would only arrive in 25 working days (!!!!!). Also, there are no guaranties that the issue is with an option at the kernel configuration, this is just what it seems to me now, but it might be something else entirely. So, my question is: how to do it? Just emerging the specific version would be enough for it to be targeted by the compilation?
Thank you tony0945 for your reply. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Wed May 19, 2021 2:58 pm Post subject: |
|
|
"eselect kernel list" followed by eselect kernel set"
example: Code: | Casti ~ # eselect kernel list
Available kernel symlink targets:
[1] linux-4.17.19-gentoo
[2] linux-5.4.72-gentoo
[3] linux-5.4.92-gentoo
[4] linux-5.4.97-gentoo
[5] linux-5.10.27-gentoo *
Casti ~ # eselect kernel set 4
Casti ~ # eselect kernel list
Available kernel symlink targets:
[1] linux-4.17.19-gentoo
[2] linux-5.4.72-gentoo
[3] linux-5.4.92-gentoo
[4] linux-5.4.97-gentoo *
[5] linux-5.10.27-gentoo
| list showed that 5.10.27 was currently set, set changed it to 5.4.97. You have to do the list first to get the index numbers because they are different on every install. "eselect n set" automagically sets the symlink.
I have to mention that I maintain xf86-input-mouse and xf86-input-keyboard in a local overlay because when they were replaced by xf86-input-libinput, I lost the keyboard and mouse! I'm using an old Microsoft USB keyboard and an old Microsoft USB mouse. I had to ssh in and reverse the change. That's why I'm following your thread with great interest. The news item says libinput should work, but it doesn't.
No need to unmerge any kernels unless you are really cramped for space. As you can see I have five and only inadvertently lost 4.19.x. At some point 4.4 gave me problems, so I let it give up the ghost. IIRC, I still have it on really really old 32-bit hardware.
The reason I suggested an intermediate is that many CONFIG items are set by the kernel based on what the user has selected. An intermediate may work. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Wed May 19, 2021 3:06 pm Post subject: |
|
|
Ah! I raced over this tidbit from the news item (emphasis by me_
Quote: | The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.
| I use an old version eudev as do some others while still others do not run udev or eudev preferring to maintain a hard /dev per the wiki olde gentoo item.
So, maybe the problem lies there, although that doesn't explain why the old kernel works. |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Wed May 19, 2021 4:29 pm Post subject: |
|
|
Tony0945 wrote: | Ah! I raced over this tidbit from the news item (emphasis by me_
Quote: | The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.
| I use an old version eudev as do some others while still others do not run udev or eudev preferring to maintain a hard /dev per the wiki olde gentoo item.
So, maybe the problem lies there, although that doesn't explain why the old kernel works. |
Thank you Tony0945 for your reply. If I correctly understood I already have this set. In make.conf I have as use flag udev, and also the flag INPUT_DEVICES="libinput wacom", as you can see:
Code: |
~> cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-march=native -O2"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE and USE_EXPAND flags that were used for
# buidling in addition to what is provided by the profile.
USE="X policykit dbus elogind -consolekit alsa acl udev savedconfig udisks fortran lapack threads unicode symlink crypt"
MAKEOPTS="-j5"
CPU_FLAGS_X86="mmx sse sse2 mmxext"
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
VIDEO_CARDS="radeon"
INPUT_DEVICES="libinput wacom"
FEATURES="nostrip"
POLICY_TYPES="strict"
LINGUAS="en pt pt_BR zh zn_CN"
L10N="en pt pt-BR zh zh-CN"
GENTOO_MIRRORS="https://gentoo.c3sl.ufpr.br/ http://gentoo.c3sl.ufpr.br/ rsync://gentoo.c3sl.ufpr.br/gentoo/"
|
Also libinput is in use:
Code: |
~> grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log
[ 43.488] (II) Using input driver 'libinput' for 'Power Button'
[ 43.592] (II) Using input driver 'libinput' for 'Video Bus'
[ 43.595] (II) Using input driver 'libinput' for 'Power Button'
[ 43.597] (II) Using input driver 'libinput' for 'Video Bus'
[ 43.600] (II) Using input driver 'libinput' for 'Logitech HID-compliant mouse'
[ 43.655] (II) Using input driver 'libinput' for 'Logitech HID-compliant mouse Consumer Control'
[ 43.659] (II) Using input driver 'libinput' for 'AT Translated Set 2 keyboard'
[ 43.662] (II) Using input driver 'libinput' for 'PS/2 Logitech Wheel Mouse'
[ 43.675] (II) Using input driver 'libinput' for 'Logitech HID-compliant mouse Consumer Control'
~>
|
and there are no deprecated xorg packages installed:
Code: |
~> equery list xf86-input-*
* Searching for xf86-input-* ...
[IP-] [ ] x11-drivers/xf86-input-libinput-0.30.0:0
[IP-] [ ] x11-drivers/xf86-input-wacom-0.39.0:0
~>
|
|
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Wed May 19, 2021 4:41 pm Post subject: |
|
|
I'm out of ideas. Try sys-kernel/gentoo-kernel-bin ? At least it might get you up and running? |
|
Back to top |
|
|
vcmota Guru
Joined: 19 Jun 2017 Posts: 363
|
Posted: Wed May 19, 2021 4:48 pm Post subject: |
|
|
One question: do I need the /run partition mounted for keyboard/usb mouse to work? Because whenever I boot with the 5.10 kernel there is this warning about mounting /run, while when loading the 4.19 kernel on boot everything is fine.
Also, I said in an early comment that my fstab was empty. It turned out it is not empty, and I sulery wrote it a long time ago and erased it from my memory:
Code: |
~> cat /etc/fstab
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed); notail increases performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail / tail freely.
#
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# See the manpage fstab(5) for more information.
#
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
#
# NOTE: Even though we list ext4 as the type here, it will work with ext2/ext3
# filesystems. This just tells the kernel to use the ext4 driver.
#
# NOTE: You can use full paths to devices like /dev/sda3, but it is often
# more reliable to use filesystem labels or UUIDs. See your filesystem
# documentation for details on setting a label. To obtain the UUID, use
# the blkid(8) command.
/dev/sda2 /boot ext2 noauto,noatime 0 2
UUID=daee6e13-8503-4b7b-bda9-c379d64c17ce / ext4 noatime 0 1
UUID=ad282bec-4a30-43da-ae72-e611d5feb9e1 none swap sw 0 0
#/dev/cdrom /mnt/cdrom auto noauto,ro 0 0
tmpfs /tmp tmpfs defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t 0 0
tmpfs /run tmpfs mode=0755,nosuid,nodev,rootcontext=system_u:object_r:var_run_t 0 0
~>
|
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|