Re: [arch-general] efibootmgr doesn't change boot order!
Hey,
On 28-12-2020 12:12, Peter K Haokip wrote:
thanks for the reply,
I am able to change the boot order from the BIOS menu. It works
A-okay from there, I am trying to accomplish that with efibootmgr.
If you're unlucky, maybe the motherboard firmware prevents you from
doing that. You could fall back to adding chain-load entries for grub in
that case, to have grub start the next bootloader.
could you cite any link where I could read about it in details ? where
the bootx64.efi file will be stored if I install it in NOT IN PORTABLE
mode(?)? cuz that would help me know whether the grub is installed in
portable or none portable mode.
You can add boot entries for any EFI executable on the EFI system
partition, regardless of the name. These boot entries are stored on
non-volatile storage on the motherboard. Normally, grub-install takes
care of this, and the binary is installed as `efi/grub/grub.efi`. All
you need to do is not pass `--removable` to grub-install.
You would install a bootloader as `efi/boot/bootx64.efi` only if you
want to create a bootable USB stick, or if your motherboards UEFI
implementation is so broken that that's the only thing that works.
Also, would be nice if you could provide any source where I can read
about how I make my motherboard detect regular boot entries (instead
of the /Efi/boot/bootx64.efi)
You can find everything in the specifications if you dig deep enough:
https://uefi.org/specifications
See in particular section 3.5.1.1 on "Removable Media Boot Behavior" of
the "UEFI Specification Version 2.8":
https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf
Regards,
-- Maarten
thanks,
On Mon, 28 Dec 2020, 15:45 Maarten de Vries, <mailto:maar...@de-vri.es>> wrote:
On 28-12-2020 10:42, Peter K Haokip via arch-general wrote:
> I read an forum entry from nearly 6 years ago about am
efibootmgr bug that
> Doesn't let you change the boot order on a multi OS system if
you have arch
> linux as the default OS. Had some users report this as well in
other
> forums.
> Now i am facing the that problem in my system with arch ubuntu
and windows.
>
> when i change the boot order , it shows the change 'temporarily'
but when i
> restart it boots the default (Arch linux Grub ) and the change
disappears.
>
> I faced this issue last month and gave up on it since I couldn't
find any
> detailed resource on this on the net.
> This list may be my last hope.
>
> If anybody could give some direction , would be much appreciated.
>
> regards,
> khaithang39
Hey,
It could be a motherboard problem. Sadly I've seen more motherboards
with weird bugs in their UEFI implementation than without. You
could try
to change the boot order through the motherboard firmware interface
(often called "the BIOS" even if that isn't technically correct
anymore)
and see if that helps.
Another thing that may have happened is that you installed grub as
portable bootloader. It will be called `efi/boot/bootx64.efi` on
the EFI
system partition if that happened. A bootloader under that name is
auto-detected by the motherboard, even if you didn't add a boot entry
for it manually. Perhaps your motherboard always favors such
bootloaders
over the normal boot entries.
If this is the case, you could install grub as non-portable
bootloader
by not passing `--removable` to `grub-install`, and then delete
`efi/boot/bootx64.efi`. Alternatively, you might also be able to
configure your motherboard to prefer regular boot entries before
running
`bootx64.efi` from that partition.
I hope this helps,
-- Maarten
Re: [arch-general] efibootmgr doesn't change boot order!
thanks for the reply, I am able to change the boot order from the BIOS menu. It works A-okay from there, I am trying to accomplish that with efibootmgr. could you cite any link where I could read about it in details ? where the bootx64.efi file will be stored if I install it in NOT IN PORTABLE mode(?)? cuz that would help me know whether the grub is installed in portable or none portable mode. Also, would be nice if you could provide any source where I can read about how I make my motherboard detect regular boot entries (instead of the /Efi/boot/bootx64.efi) thanks, On Mon, 28 Dec 2020, 15:45 Maarten de Vries, wrote: > On 28-12-2020 10:42, Peter K Haokip via arch-general wrote: > > I read an forum entry from nearly 6 years ago about am efibootmgr bug > that > > Doesn't let you change the boot order on a multi OS system if you have > arch > > linux as the default OS. Had some users report this as well in other > > forums. > > Now i am facing the that problem in my system with arch ubuntu and > windows. > > > > when i change the boot order , it shows the change 'temporarily' but > when i > > restart it boots the default (Arch linux Grub ) and the change > disappears. > > > > I faced this issue last month and gave up on it since I couldn't find any > > detailed resource on this on the net. > > This list may be my last hope. > > > > If anybody could give some direction , would be much appreciated. > > > > regards, > > khaithang39 > > Hey, > > It could be a motherboard problem. Sadly I've seen more motherboards > with weird bugs in their UEFI implementation than without. You could try > to change the boot order through the motherboard firmware interface > (often called "the BIOS" even if that isn't technically correct anymore) > and see if that helps. > > Another thing that may have happened is that you installed grub as > portable bootloader. It will be called `efi/boot/bootx64.efi` on the EFI > system partition if that happened. A bootloader under that name is > auto-detected by the motherboard, even if you didn't add a boot entry > for it manually. Perhaps your motherboard always favors such bootloaders > over the normal boot entries. > > If this is the case, you could install grub as non-portable bootloader > by not passing `--removable` to `grub-install`, and then delete > `efi/boot/bootx64.efi`. Alternatively, you might also be able to > configure your motherboard to prefer regular boot entries before running > `bootx64.efi` from that partition. > > I hope this helps, > > -- Maarten > >
Re: [arch-general] efibootmgr doesn't change boot order!
On 28-12-2020 10:42, Peter K Haokip via arch-general wrote: I read an forum entry from nearly 6 years ago about am efibootmgr bug that Doesn't let you change the boot order on a multi OS system if you have arch linux as the default OS. Had some users report this as well in other forums. Now i am facing the that problem in my system with arch ubuntu and windows. when i change the boot order , it shows the change 'temporarily' but when i restart it boots the default (Arch linux Grub ) and the change disappears. I faced this issue last month and gave up on it since I couldn't find any detailed resource on this on the net. This list may be my last hope. If anybody could give some direction , would be much appreciated. regards, khaithang39 Hey, It could be a motherboard problem. Sadly I've seen more motherboards with weird bugs in their UEFI implementation than without. You could try to change the boot order through the motherboard firmware interface (often called "the BIOS" even if that isn't technically correct anymore) and see if that helps. Another thing that may have happened is that you installed grub as portable bootloader. It will be called `efi/boot/bootx64.efi` on the EFI system partition if that happened. A bootloader under that name is auto-detected by the motherboard, even if you didn't add a boot entry for it manually. Perhaps your motherboard always favors such bootloaders over the normal boot entries. If this is the case, you could install grub as non-portable bootloader by not passing `--removable` to `grub-install`, and then delete `efi/boot/bootx64.efi`. Alternatively, you might also be able to configure your motherboard to prefer regular boot entries before running `bootx64.efi` from that partition. I hope this helps, -- Maarten
[arch-general] efibootmgr doesn't change boot order!
I read an forum entry from nearly 6 years ago about am efibootmgr bug that Doesn't let you change the boot order on a multi OS system if you have arch linux as the default OS. Had some users report this as well in other forums. Now i am facing the that problem in my system with arch ubuntu and windows. when i change the boot order , it shows the change 'temporarily' but when i restart it boots the default (Arch linux Grub ) and the change disappears. I faced this issue last month and gave up on it since I couldn't find any detailed resource on this on the net. This list may be my last hope. If anybody could give some direction , would be much appreciated. regards, khaithang39
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Em dezembro 22, 2020 13:33 Emil Velikov escreveu: Is there any interest in the bugs opened, or the gvt regression is a must for those to move forward? My systems lack gvt support (nor do I have Windows license) to reproduce the bug(s), yet I'm willing to help to get this moving. Yes. I haven't got time to proper look at them, but I will. I'm not using bumblebee atm as well. Regards, Giancarlo Razzolini pgp2_ApyB5E0g.pgp Description: PGP signature
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
On Fri, 11 Dec 2020 at 11:43, Emil Velikov wrote: > > On Mon, 7 Dec 2020 at 18:47, Giancarlo Razzolini > wrote: > > > > Em dezembro 7, 2020 14:24 Emil Velikov escreveu: > > > > > > Doing GL (primus+bumblebee) as a start, trimmed only to the bare > > > minimum changes: > > > https://bugs.archlinux.org/task/68882 > > > https://bugs.archlinux.org/task/68883 > > > > > > > Thanks. > > > > > Do you have details or a bug report about these? I haven't used intel > > > gvt-g and on the occasion of skimming through the code - quality was > > > below i915. > > > > > > > There is a nasty bug where nvidia prime render offload causes the VM to > > simply segfault [0]. > > But intel gvt-g is better than using virgl for 3D stuff on a VM. > > > If I have to choose - segfault or slower rendering (via virgl) - I'd > choose the latter :-P > Nevertheless added a few comments which should help you move forward. > > I would suggest opting for virgl, until all the relevant bugs are > fixed. This way we can proceed with the package cleanup quicker. > Is there any interest in the bugs opened, or the gvt regression is a must for those to move forward? My systems lack gvt support (nor do I have Windows license) to reproduce the bug(s), yet I'm willing to help to get this moving. Thanks Emil
Re: [arch-general] darktable libavif libyuv update and undefined symbol
It’s a bug in libyuv-r2212+dfaf7534-1, fixed in libyuv-r2212+dfaf7534-2. Regards, Archange Le 22 décembre 2020 16:38:25 GMT+01:00, Genes Lists via arch-general a écrit : >Todays update[1] of darktable along with libavif / libavif led to this >message: > >(5/7) Probing GDK-Pixbuf loader modules... >g_module_open() failed for >/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-avif.so: >/usr/lib/libyuv.so: undefined symbol: jpeg_read_raw_data > >I have libjpeg-turbo installed and confirme that the function is >available in the library: > >% objdump -T /usr/lib/libjpeg.so |egrep read_raw_data >00017950 gDF .text 00df LIBJPEG_8.0 >jpeg_read_raw_data > >Anyone have ideas how to resolve this? Is it benig, or a problem on my end? > >thanks. > >[1] Updated to: >darktable 2:3.2.1-3 >libavif-0.8.3-1 >libyuv-r2212+dfaf7534-1
Re: [arch-general] darktable libavif libyuv update and undefined symbol
On 12/22/20 10:55 AM, Juergen Werner via arch-general wrote: ... Try libyuv-r2212+dfaf7534-2. Looks like that might fix your problem. Yes indeed I just got it - thanks - and all looks fine now. gene
Re: [arch-general] darktable libavif libyuv update and undefined symbol
On 22.12.2020 16:38, Genes Lists via arch-general wrote: Todays update[1] of darktable along with libavif / libavif led to this message: (5/7) Probing GDK-Pixbuf loader modules... g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-avif.so: /usr/lib/libyuv.so: undefined symbol: jpeg_read_raw_data I have libjpeg-turbo installed and confirme that the function is available in the library: % objdump -T /usr/lib/libjpeg.so |egrep read_raw_data 00017950 g DF .text 00df LIBJPEG_8.0 jpeg_read_raw_data Anyone have ideas how to resolve this? Is it benig, or a problem on my end? thanks. [1] Updated to: darktable 2:3.2.1-3 libavif-0.8.3-1 libyuv-r2212+dfaf7534-1 Try libyuv-r2212+dfaf7534-2. Looks like that might fix your problem.
[arch-general] darktable libavif libyuv update and undefined symbol
Todays update[1] of darktable along with libavif / libavif led to this message: (5/7) Probing GDK-Pixbuf loader modules... g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-avif.so: /usr/lib/libyuv.so: undefined symbol: jpeg_read_raw_data I have libjpeg-turbo installed and confirme that the function is available in the library: % objdump -T /usr/lib/libjpeg.so |egrep read_raw_data 00017950 gDF .text 00df LIBJPEG_8.0 jpeg_read_raw_data Anyone have ideas how to resolve this? Is it benig, or a problem on my end? thanks. [1] Updated to: darktable 2:3.2.1-3 libavif-0.8.3-1 libyuv-r2212+dfaf7534-1
Re: [arch-general] https://git.archlinux.org/svntogit obsolete?
On Sun, Dec 20, 2020 at 05:33:05PM +0100, Erich Eckner via arch-general wrote: > Hi, Yo! > I was surprised to find git.archlinux.org/svntogit/packages.git/ and > git.archlinux.org/svntogit/community.git/ being no longer updated since a > few days. I know, there was a github mirror of the repositories set up some > time ago - did I miss some deprecation notice for the old locations or is > this some oversight on the arch end? There was some devops work on the server and the timer/services synching the repositories where probably not enabled. Thus they died after a reboot. The services are enabled and started so you should see the repo synching again. > regards, > Erich Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-general] https://git.archlinux.org/svntogit obsolete?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I was surprised to find git.archlinux.org/svntogit/packages.git/ and git.archlinux.org/svntogit/community.git/ being no longer updated since a few days. I know, there was a github mirror of the repositories set up some time ago - did I miss some deprecation notice for the old locations or is this some oversight on the arch end? regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/ffMIACgkQCu7JB1Xa e1qskg//T0HkTdj33ygNCpDNwvDf2H6V1zOBkjadlHrXph4/WkQIyYa7QJxmWXfV d0CWioelIJM4qkBpXrwTa4xMvowW7HLgvpUnCfnXSSaiCODEbJDXC/b0OokHSS9c K+9rGdMgVwfmsMevc/k919ifzmNIUkmX3tOd4lRc1CO6A2EHxFELndY3MbBhpz12 gP599BPvopC+AlYg0MEu1l0/1wAq5p0zSJvneyh2R8LIo8RW/8N7JWnmt0CJf8sM iNiBHvj7byk1Y8uXghibaN9LqLAtRTodhb++Fm5NKdHmlVAnGxrdA3aKlYJYYXsL Q/OYBSTwuhNvxXJnewLtErWjcVu7IL29gPX2Hh7Yhyf+XHScond/Z6WWza3dBYMx rEC9sknS9aSQeuvJqAyfq0mCDQJxbDFAs2p2zh0LG65pbY04yZstmDo/Al+xZV5D wwqedpiTAUVI23m9IePMfxEUnWuRaF5GYeJIa/EFmYn5OXPWMuUO/Y5p2G54QLvX Zwbxu08NDzf+jznhVw2CiP/V7SDMtdLa0hMblvD63z+ywZql0KGIjhiyA9EtXMZm NGQexY5yHyb2R5gKx8e4a7o8ZRJP/n/85laRj3dBYA1ulr5Sp7FCNdYFOLs9xz64 IygVzAJG6Og4kDD7trPl++OwLzaKZ//Qodm3w/+egG3HY75/KvM= =vYL+ -END PGP SIGNATURE-
Re: [arch-general] Bug with CIFS mount
On Thu, 17 Dec 2020 at 00:12, Maarten de Vries wrote: > > On 16-12-2020 14:09, Tasnad Kernetzky via arch-general wrote: > > Hi All, > Hi, > > > > I suppose I hit this bug: https://bugs.archlinux.org/task/68963 and it > > seems it is not fully resolved. I didn't request to reopen the bug, > > because I'm not 100% sure it is really the same thing. > > > The bug you're linking is marked as duplicate of this one: > https://bugs.archlinux.org/task/68666 > > That one has been re-opened yesterday, so it seems likely that the > problem is not solved yet. But you also shouldn't re-open the duplicate > issue. Judging from the comments on the re-opened issue, an additional > patch has been sent upstream already. > > I hope this helps :) > > -- Maarten > > Oh well, it literally says "sorry for the duplicate", how could I miss that. Thank you very much and also thanks to/for the patche[r]s! Best, Tasnad
Re: [arch-general] Bug with CIFS mount
On 16-12-2020 14:09, Tasnad Kernetzky via arch-general wrote: Hi All, Hi, I suppose I hit this bug: https://bugs.archlinux.org/task/68963 and it seems it is not fully resolved. I didn't request to reopen the bug, because I'm not 100% sure it is really the same thing. The bug you're linking is marked as duplicate of this one: https://bugs.archlinux.org/task/68666 That one has been re-opened yesterday, so it seems likely that the problem is not solved yet. But you also shouldn't re-open the duplicate issue. Judging from the comments on the re-opened issue, an additional patch has been sent upstream already. I hope this helps :) -- Maarten
[arch-general] Bug with CIFS mount
Hi All,
I suppose I hit this bug: https://bugs.archlinux.org/task/68963 and it
seems it is not fully resolved. I didn't request to reopen the bug,
because I'm not 100% sure it is really the same thing.
I have a setup with kerberos/sssd/pam/autofs, authenticating with an
active directory, and cifs mounts stopped working.
Login and nfs with kerberos work fine, to the issue is quite likely with
cifs.
Mounting the cifs share works with libcap-ng-0.8-1, but not with
libcap-ng-0.8.2-1.
I have cifs-utils 6.11-2, sssd 2.4.0-2 and krb5 1.18.2-1.
Did I miss something or am I hitting something special due to the setup?
Does anybody have a clue what could be the issue?
I include lots of details about the config and logs, but tl;dr:
"mount -t cifs -o
domain=DOM,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0
//nas.example.com/theUser /nas/home/theUser"
fails with
"cifs.upcall[532824]: drop_all_capabilities: Unable to apply capability
set: Success"
Best,
Tasnad
Substituted values
==
* myMachine: the client's hostname (not fqdn)
* theUser: the nonroot user trying to mount via autofs
* 1234567: uid of theUser (from Active directory)
* DOM: the AD domain
* DOM.EXAMPLE.COM: domain, fqdn
/etc/krb5.conf
==
[libdefaults]
default_realm = DOM.EXAMPLE.COM
udp_preference_limit = 0
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 10h
renew_lifetime = 7d
forwardable = true
sssd.conf
=
[sssd]
config_file_version = 2
domains = DOM.EXAMPLE.COM
services = nss, pam
[nss]
default_shell = /bin/bash
shell_fallback = /bin/bash
filter_groups = root
filter_users = root
[domain/DOM.EXAMPLE.COM]
id_provider = ad
auth_provider = ad
access_provider = simple
ldap_schema = ad
sudo_provider = none
cache_credentials = false
krb5_store_password_if_offline = false
dyndns_update = false
ldap_id_mapping = false
use_fully_qualified_names = false
enumerate = false
ignore_group_members = true
case_sensitive = preserving
ad_enable_gc = false
ad_hostname = myMachine
ldap_search_base = [...]
ldap_user_search_base = [...]
ldap_user_search_scope = [...]
ldap_group_search_base = [...]
ldap_group_search_scope = [...]
nsswitch.conf
=
passwd: files sss
group: files sss
shadow: files sss
gshadow: files sss
publickey: files
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
networks: files
protocols: files
services: files sss
ethers: files
rpc: files
netgroup: files sss
automount: sss
homes.autofs
/nas/home /etc/autofs/auto.master.d/home.map
-domain=DOM,fstype=cifs,sec=krb5,soft,noserverino,cifsacl
home.map
* -username=$USER,cruid=$UID,vers=3.0 ://nas.example.com/&
cifs idmap plugin
/etc/cifs_utils/idmap-plugin -> /usr/lib/cifs-utils/cifs_idmap_sss.so
klist
=
Ticket cache: FILE:/tmp/krb5cc_
Default principal: theu...@dom.example.com
Valid starting Expires Service principal
12/16/2020 11:31:48 12/16/2020 21:25:18
krbtgt/dom.example@dom.example.com
renew until 12/23/2020 11:25:18
automount -fd
=
handle_packet: type = 3
handle_packet_missing_indirect: token 727, name theUser, request pid 532818
attempting to mount entry /nas/home/theUser
lookup_mount: lookup(file): looking up theUser
lookup_mount: lookup(file): theUser ->
-username=$USER,cruid=$UID,vers=3.0 ://nas.example.com/&
parse_mount: parse(sun): expanded entry:
-username=theUser,cruid=1234567,vers=3.0 ://nas.example.com/theUser
parse_mount: parse(sun): gathered options:
domain=DOM,fstype=cifs,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0
parse_mount: parse(sun): dequote("://nas.example.com/theUser") ->
://nas.example.com/theUser
parse_mount: parse(sun): core of entry:
options=domain=DOM,fstype=cifs,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0,
loc=://nas.example.com/theUser
sun_mount: parse(sun): mounting root /nas/home, mountpoint theUser, what
//nas.example.com/theUser, fstype cifs, options
domain=DOM,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0
do_mount: //nas.example.com/theUser /nas/home/theUser type cifs options
domain=DOM,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0
using module generic
mount_mount: mount(generic): calling mkdir_path /nas/home/theUser
mount(generic): calling mount -t cifs -o
domain=DOM,sec=krb5,soft,noserverino,cifsacl,username=theUser,cruid=1234567,vers=3.0
//nas.example.com/theUser /nas/home/theUser
>> mount error(126): Required key not available
>> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and
kernel log messages (dmesg)
mount(generic): failed to mount //nas.example.com/theUser (type cifs) on
/nas/home/theUser
dev_ioctl_send_fail: token = 727
failed to mount /nas/home/theUser
journalctl
==
kernel: CIFS: fs/cifs/cifsfs.c:
[arch-general] [aur] Could anybody help with Meshroom installation?
Hello, I tried to install alice-vision-git together with meshroom, but it seems sth. isn't found: Meshroom-2020.1.1]$ Meshroom WARNING:root:== The following "submitters" plugins could not be loaded == * simpleFarmSubmitter: No module named 'simpleFarm' Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/cx_Freeze/initscripts/__startup__.py", line 40, in run module.run() File "/home/peter/.cache/pacaur/meshroom/src/meshroom/setupInitScriptUnix.py", line 39, in run File "meshroom/ui/__main__.py", line 10, in File "/home/peter/.cache/pacaur/meshroom/src/meshroom/meshroom/ui/app.py", line 18, in File "shibokensupport/__feature__.py", line 142, in _import File "/home/peter/.cache/pacaur/meshroom/src/meshroom/meshroom/ui/reconstruction.py", line 169, in File "/home/peter/.cache/pacaur/meshroom/src/meshroom/meshroom/ui/reconstruction.py", line 253, in ViewpointWrapper TypeError: A constant property cannot have a WRITE method or a NOTIFY signal. The strange point for me here is that Meshroom tries to find sth. using my cache - I don't think that's the way Meshroom (or any other application) should work ... Kind regards Peter
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
On Mon, 7 Dec 2020 at 18:47, Giancarlo Razzolini wrote: > > Em dezembro 7, 2020 14:24 Emil Velikov escreveu: > > > > Doing GL (primus+bumblebee) as a start, trimmed only to the bare > > minimum changes: > > https://bugs.archlinux.org/task/68882 > > https://bugs.archlinux.org/task/68883 > > > > Thanks. > > > Do you have details or a bug report about these? I haven't used intel > > gvt-g and on the occasion of skimming through the code - quality was > > below i915. > > > > There is a nasty bug where nvidia prime render offload causes the VM to > simply segfault [0]. > But intel gvt-g is better than using virgl for 3D stuff on a VM. > If I have to choose - segfault or slower rendering (via virgl) - I'd choose the latter :-P Nevertheless added a few comments which should help you move forward. I would suggest opting for virgl, until all the relevant bugs are fixed. This way we can proceed with the package cleanup quicker. -Emil
[arch-general] PA over JACK: excessive work?
Hi, I'm using PulseAudio over JACK and noticed in htop that while not doing nothing PA works much more than when idle alone, is this normal/right? This is what I do: Close everything that uses audio. Start JACK through qjackctl. $ pulseaudio --kill $ pulseaudio --start (So, PA now works as some kind of bridge redirecting audio through JACK.) $ pactl load-module module-jack-sink $ pactl load-module module-jack-source (So I have general sink/source ports to make connections.) But then I check htop and PA is working all the time. Is this normal? Am I doing something wrong? Thanks a lot in advance.
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Em dezembro 7, 2020 14:24 Emil Velikov escreveu: Doing GL (primus+bumblebee) as a start, trimmed only to the bare minimum changes: https://bugs.archlinux.org/task/68882 https://bugs.archlinux.org/task/68883 Thanks. Do you have details or a bug report about these? I haven't used intel gvt-g and on the occasion of skimming through the code - quality was below i915. There is a nasty bug where nvidia prime render offload causes the VM to simply segfault [0]. But intel gvt-g is better than using virgl for 3D stuff on a VM. Regards, Giancarlo Razzolini [0] https://github.com/intel/gvt-linux/issues/162 pgp1FXwOcDdVx.pgp Description: PGP signature
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
On Fri, 4 Dec 2020 at 14:11, Giancarlo Razzolini wrote: > > Em dezembro 4, 2020 10:04 Emil Velikov escreveu: > > On Fri, 4 Dec 2020 at 12:50, Giancarlo Razzolini > > wrote: > >> > >> Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: > >> > I would love to hear the input from the respective maintainers and the > >> > overall Arch developer base as a whole. > >> > > >> > >> As the maintainer for both bumblebee and prime-run, I don't see the need > >> for deprecation, yet. > >> Bumblebee still has some uses and also, the it has the appeal of keeping > >> the card completely powered > >> off, something that doesn't happen with prime render offload. > >> > > Thanks for maintaining these Giancarlo. > > > > The power management side of Bumblebee will be untouched - my email > > explicitly covers only the file side of things. > > > > I've seen far too many reports of people using primus, on top of GLVND > > enabled nvidia/mesa causing all sorts of problems. Since tracking > > individual reports does not scale - I've put this proposal. > > > > Note: having a compat primusrun/optirun/pvkrun makes sense - setting > > the respective environment variables is annoying. > > > > -Emil > > > > Put your proposal changes and reasoning on flyspray tickets for each package > and I'll take a look. Doing GL (primus+bumblebee) as a start, trimmed only to the bare minimum changes: https://bugs.archlinux.org/task/68882 https://bugs.archlinux.org/task/68883 > I'm not sure all the changes are needed. And, it turns out that, due to some > limitations/issues > related to intel gvt-g and nvidia with prime render offload, I'm using > bumblebee currently. > Do you have details or a bug report about these? I haven't used intel gvt-g and on the occasion of skimming through the code - quality was below i915. > Only issue I had recently was the xorg autodetection issue that they > reverted, other than that, it > works fine here. > Again, a bug report with details would be appreciated. Thanks Emil
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Em dezembro 4, 2020 10:04 Emil Velikov escreveu: On Fri, 4 Dec 2020 at 12:50, Giancarlo Razzolini wrote: Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: > I would love to hear the input from the respective maintainers and the > overall Arch developer base as a whole. > As the maintainer for both bumblebee and prime-run, I don't see the need for deprecation, yet. Bumblebee still has some uses and also, the it has the appeal of keeping the card completely powered off, something that doesn't happen with prime render offload. Thanks for maintaining these Giancarlo. The power management side of Bumblebee will be untouched - my email explicitly covers only the file side of things. I've seen far too many reports of people using primus, on top of GLVND enabled nvidia/mesa causing all sorts of problems. Since tracking individual reports does not scale - I've put this proposal. Note: having a compat primusrun/optirun/pvkrun makes sense - setting the respective environment variables is annoying. -Emil Put your proposal changes and reasoning on flyspray tickets for each package and I'll take a look. I'm not sure all the changes are needed. And, it turns out that, due to some limitations/issues related to intel gvt-g and nvidia with prime render offload, I'm using bumblebee currently. Only issue I had recently was the xorg autodetection issue that they reverted, other than that, it works fine here. Regards, Giancarlo Razzolini pgpE4IxU3PPan.pgp Description: PGP signature
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
On Fri, 4 Dec 2020 at 12:55, Lone_Wolf wrote: > > > On 04-12-2020 13:50, Giancarlo Razzolini via arch-general wrote: > > Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: > >> I would love to hear the input from the respective maintainers and the > >> overall Arch developer base as a whole. > >> > > > > As the maintainer for both bumblebee and prime-run, I don't see the > > need for deprecation, yet. > > Bumblebee still has some uses and also, the it has the appeal of > > keeping the card completely powered > > off, something that doesn't happen with prime render offload. > > > > Having said that, I do think bumblebee/primus/primus_vk days are > > numbered. > > > > Regards, > > Giancarlo Razzolini > > > For clarity : > > Does this affect people without an nvidia card ? > > Are users with an nvidia card that only use nouveau kernel module affected ? > There should be no user visible changes with my proposal - both GL and VK should work as normal. The power management side of things is completely unchanged. -Emil
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
On Fri, 4 Dec 2020 at 12:50, Giancarlo Razzolini wrote: > > Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: > > I would love to hear the input from the respective maintainers and the > > overall Arch developer base as a whole. > > > > As the maintainer for both bumblebee and prime-run, I don't see the need for > deprecation, yet. > Bumblebee still has some uses and also, the it has the appeal of keeping the > card completely powered > off, something that doesn't happen with prime render offload. > Thanks for maintaining these Giancarlo. The power management side of Bumblebee will be untouched - my email explicitly covers only the file side of things. I've seen far too many reports of people using primus, on top of GLVND enabled nvidia/mesa causing all sorts of problems. Since tracking individual reports does not scale - I've put this proposal. Note: having a compat primusrun/optirun/pvkrun makes sense - setting the respective environment variables is annoying. -Emil
Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: I would love to hear the input from the respective maintainers and the overall Arch developer base as a whole. As the maintainer for both bumblebee and prime-run, I don't see the need for deprecation, yet. Bumblebee still has some uses and also, the it has the appeal of keeping the card completely powered off, something that doesn't happen with prime render offload. Having said that, I do think bumblebee/primus/primus_vk days are numbered. Regards, Giancarlo Razzolini pgpYQ_QXLRvfi.pgp Description: PGP signature
[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Hello all, As some of you may know, I have been an Arch user for over 5 years and a Linux graphics developer working on the whole stack from the kernel DRM all the way up-to Mesa and X. I would like to propose, partially deprecating and potentially removing some of the said packages in light of the development that has been happening over the last few years. tl;dr: these solutions have been partially or completely obsolete, for a while now ## OpenGL/GLX/etc # Background As you know, in the early days we would have both Mesa and vendors provide their own libGL.so.1 and in some cases libglx.so (xorg module). Alongside that drivers lacked dynPM, allowing you to powering off the GPU, when it's not used. To address those primus and bumblebee came about. Note: dynPM is mentioned for completeness, it won't be covered any more. # Since then Nvidia and open source drivers support client - Mesa drivers - since v17.2.0 (at least), packaged 7 Sep 2017 - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 ... and server-side glvnd: - xorg-xserver - since v1.20.6, packaged 23 Nov 2019 - Nvidia drivers - since v435.21, packaged 30 Aug 2019 ## Vulkan # Background On the Vulkan side the drivers are clearly separated from the start - libvulkan_$vendor.so. Yet very few applications would bother selecting the GPU, plus server-side (when using WSI_X11) wasn't complete. GL Vulkan interop was also tricky, with libGL.so.1 being provided by vendors. This resulted in primus_vk. # Since then - Mesa drivers - since 20.1.0, packaged 28 May 2020 Driver selection layer was added, falling back to DRI_PRIME [1] - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 Vulkan implicit layer was added - see [2] ## My proposal: Cleanup the packages, as outlined below and update the wiki. Please check out the Extra notes below. I will be more than happy to tackle this although maintainers will have to push/rebuild the packages for obvious reasons. - primus: replace with a simple compat script primusrun, which a) finds the ID_PATH_TAG for the Nvidia GPU and sets DRI_PRIME=$tag $@ - bumblebee: optirun - replace with script calling primusrun xorg config - should not be needed, double-check and drop bumblebeed - (optionally) remove no longer applicable code, config etc bumblebee - remove no longer applicable group - virtual GL: move to AUR, since it has no more users - primus_vk: replace with a simple compat script pvkrun akin to primusrun, making use of [1] and [2] ## Extra notes: - primus/bumblebee - seemingly been abandoned upstream for 4+ years. Arch maintainers having to carry fixes locally. - primus/virtualgl/primus_vk performance is worse than natively - compat primusrun/optirun/pvkrun are to minimise breakage - some legacy Nvidia drivers may lack support - those drivers live in the AUR, thus a solution for them should also be packaged there. ## Feedback I would love to hear the input from the respective maintainers and the overall Arch developer base as a whole. Is there a particular use-case that I've missed? How would you like this handled - as mentioned above, I'm happy to submit patches be that via Flyspray, email, MR or otherwise. Looking forward to your input -Emil [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766 [2] http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/primerenderoffload.html
Re: [arch-general] Softphone
Hi, Le 03/12/2020 à 22:58, Jörg Jellissen a écrit : Hello, i am currently searching for another software solution for a SIP Softphone on Gnome in ArchLinux. I didn't found a good solution. In AUR there is linphone available but i think this is terrible for me. Have you tried Jami? It used to be a SIP Softphone software originally, and still offer this feature (though I have never tried it myself). Regards, Archange
Re: [arch-general] gnupg version
02.12.2020 00:31, mpan пишет: hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but arch only has Version 2.2.24-1 in testing. my question is why it haven't been updated? if the maintainer simply does not have time yet, then I understand, but maybe there is another reason? There is only one bug fixed between 2.2.24 and 2.2.25, and it introduces 3 lines of code: DIFF -- diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 6245a5331..ec60db2e6 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -4392,10 +4392,15 @@ check_keyidstr (app_t app, const char *keyidstr, int keyno, int *r_use_auth) const char *s; int n; const char *fpr = NULL; + int i; if (r_use_auth) *r_use_auth = 0; + /* Make sure we have load the public keys. */ + for (i = 0; i < 3; i++) + get_public_key (app, i); + if (strlen (keyidstr) < 32) return gpg_error (GPG_ERR_INV_ID); else - /DIFF Aside from what SET said, about building the whole 2.2.25, if that’s the bug affecting you you may just apply a patch over 2.2.24 and build it. thanks. i built it. -- Sincerely, Alexander.
Re: [arch-general] gnupg version
Le mardi 1 décembre 2020 15:57:53 CET Alexander Epaneshnikov via arch-general a écrit : > hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but > arch only has Version 2.2.24-1 in testing. my question is why it haven't > been updated? if the maintainer simply does not have time yet, then I > understand, but maybe there is another reason? GnuPG 2.2.24 is now available. If you badly need GnuPG 2.2.25, you may customize the PKGBUILD and build it.
Re: [arch-general] gnupg version
01.12.2020 18:22, karx via arch-general пишет: On Tue, Dec 1, 2020, 8:58 AM Alexander Epaneshnikov via arch-general < arch-general@archlinux.org> wrote: hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but arch only has Version 2.2.24-1 in testing. my question is why it haven't been updated? if the maintainer simply does not have time yet, then I understand, but maybe there is another reason? -- Sincerely, Alexander. How new is the new version? If it's very new, it might not have had enough time to get packaged. release was announced at Mon Nov 23 19:00:22 CET 2020 -- Yash -- Sincerely, Alexander.
Re: [arch-general] gnupg version
On Tue, Dec 1, 2020, 8:58 AM Alexander Epaneshnikov via arch-general < arch-general@archlinux.org> wrote: > hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but > arch only has Version 2.2.24-1 in testing. my question is why it haven't > been updated? if the maintainer simply does not have time yet, then I > understand, but maybe there is another reason? > -- > Sincerely, Alexander. > How new is the new version? If it's very new, it might not have had enough time to get packaged. -- Yash >
[arch-general] gnupg version
hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but arch only has Version 2.2.24-1 in testing. my question is why it haven't been updated? if the maintainer simply does not have time yet, then I understand, but maybe there is another reason? -- Sincerely, Alexander.
Re: [arch-general] Translation not fully working with gnome and gdm
Hi, you didn't provide the information how you tried to enable the translations. Could the following be the culprit? "If you are using a desktop environment, such as GNOME, its language settings may be overriding the settings in locale.conf." - https://wiki.archlinux.org/index.php/locale#My_system_is_still_using_wrong_language Regards, Ralf
Re: [arch-general] Realtek RTL8111H NIC : does it just work?
Thank you all. I can now choose this board definitely.
Re: [arch-general] Realtek RTL8111H NIC : does it just work?
On Sat, Nov 28, 2020 at 3:09 PM SET via arch-general < arch-general@archlinux.org> wrote: > Hello, > > I 'm planning to buy a PC with an MSI MPG X570 GAMING EDGE WIFI mother > board, having a Realtek RTL8111H ethernet device, and install Arch of > course. > > I 've seen many web pages about the need to install the r8168 package for > it to work. Some pages hint that the r8169 driver should work too. Almost > all of these sources are many years old. > > I wish some forum members could share their experience with this NIC on > current kernel. Does it just work? Is the r8168 package mandatory? Can > complex tweak be avoided? > > Thank you. > > > -- > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma > brièveté. > I recently purchased an ASRock B550 Phantom Gaming 4 with Realtek RTL8111H for ethernet (shows up in lspci as '08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)'). It 'just worked' for me, without any extra package. I'm currently on kernel 5.9.8-arch1-1 (haven't gotten around to the latest update yet).
[arch-general] Realtek RTL8111H NIC : does it just work?
Hello, I 'm planning to buy a PC with an MSI MPG X570 GAMING EDGE WIFI mother board, having a Realtek RTL8111H ethernet device, and install Arch of course. I 've seen many web pages about the need to install the r8168 package for it to work. Some pages hint that the r8169 driver should work too. Almost all of these sources are many years old. I wish some forum members could share their experience with this NIC on current kernel. Does it just work? Is the r8168 package mandatory? Can complex tweak be avoided? Thank you. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [arch-general] pacman reset procedure
Yeah, this sounds more like a mirror problem than a database problem. On Fri, Nov 27, 2020, 9:16 AM LuKaRo wrote: > On 27.11.20 15:37, Jude DaShiell wrote: > > Failed to synchronize all error failed to update each database and > > finally error failed to synchronize all data bases. > Are you sure that this is really an error in your database and not just an > error of your mirror? I've had similar errors multiple times, and every > time it was the mirror I used that had some error. Just using a different > mirror in /etc/pacman/mirrorlist fixed it, I never had to intervene > manually. >
Re: [arch-general] pacman reset procedure
On Fri, 27 Nov 2020 09:37:53 -0500 Jude DaShiell wrote: > Failed to synchronize all error failed to update each database and > finally error failed to synchronize all data bases. > > On Fri, 27 Nov 2020, Nate DeMare via arch-general wrote: > > > Date: Fri, 27 Nov 2020 09:23:55 > > From: Nate DeMare via arch-general > > To: General Discussion about Arch Linux > > Cc: Nate DeMare > > Subject: Re: [arch-general] pacman reset procedure > > > > "The pacman data bases I have apparently got broken and will not update." > > > > > > What specifically does the pacman error say? > Specific, exact errors. And don't top post.
Re: [arch-general] pacman reset procedure
"The pacman data bases I have apparently got broken and will not update." What specifically does the pacman error say?
Re: [arch-general] Wine package broken
Hi, > > Should I file a bug, email the maintainer of the package, email the > latest package uploader, etc.? What's the quickest way to get this > resolved? > Writing an mail to arch-general is much more better than using the bug tracker. Bug trackers, what are they used for? Regards Bjoern
[arch-general] gn package, could you please add the emacs gn-mode.el ?
Hi, Evangelos in the source tree of 'gn' package, the emacs mode scripts has been added in misc/emacs/gn-mode.el Could you please add that mode into the gn release package in ArchLinux ?
Re: [arch-general] busted system after update
Many of use have been there! Earlier this year I overwrote /etc/shadow with pacnew in a moment of madness.
Re: [arch-general] root login @ console
Nov 14 13:35:28 yoda audit[2683212]: USER_AUTH pid=2683212 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/bin/login" hostname=yoda addr=? terminal=tty2 res=failed' Nov 14 13:35:28 yoda kernel: audit: type=1100 audit(1605378928.928:6994): pid=2683212 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/bin/login" hostname=yoda addr=? terminal=tty2 res=failed' Nov 14 13:35:31 yoda login[2683212]: FAILED LOGIN 1 FROM tty2 FOR root, Authentication failure I read somewhere that I could tell pam to use debug output. I will see if I can find that. Thanks for the tip. On Sat, Nov 14, 2020 at 11:15 AM Guus Snijders via arch-general wrote: > > Op za 14 nov. 2020 03:50 schreef Jack Frost via arch-general < > arch-general@archlinux.org>: > > > Thanks for the tip. There were no pam.d/ files that had pam_tally and > > now pacnew files. I am digging through pam man pages to see if I can > > figure it out. Someone had to disable root access. I commented out > > pam_securetty.so in all the files but still no luck. > > > > You could also try reading the logs... (probably journald). > > When the authentication fails, there is surely some message somewhere > stating /why/ it failed. > > > > Mvg, Guus
Re: [arch-general] root login @ console
Op za 14 nov. 2020 03:50 schreef Jack Frost via arch-general < arch-general@archlinux.org>: > Thanks for the tip. There were no pam.d/ files that had pam_tally and > now pacnew files. I am digging through pam man pages to see if I can > figure it out. Someone had to disable root access. I commented out > pam_securetty.so in all the files but still no luck. > You could also try reading the logs... (probably journald). When the authentication fails, there is surely some message somewhere stating /why/ it failed. Mvg, Guus
Re: [arch-general] root login @ console
Thanks for the tip. There were no pam.d/ files that had pam_tally and now pacnew files. I am digging through pam man pages to see if I can figure it out. Someone had to disable root access. I commented out pam_securetty.so in all the files but still no luck. Thanks. On Fri, Nov 13, 2020 at 5:04 PM SET via arch-general wrote: > > Le vendredi 13 novembre 2020 17:06:08 CET Jack Frost via arch-general a écrit > : > > So I foo-bared my /home partition, no big deal, done it before, and I > >... > > Had a somehow similar problem yesterday. > > After removing all lines with 'pam_tally' in /etc/pam.d/login via ssh > (fortunately worked), I could login as root at console. This module is > reportedly deprecated. > > If there's a login.pacnew file, just replace the current login file with the > pacnew one, unless you have custom settings in your login file. > > Regards.
Re: [arch-general] root login @ console
Le vendredi 13 novembre 2020 17:06:08 CET Jack Frost via arch-general a écrit : > So I foo-bared my /home partition, no big deal, done it before, and I >... Had a somehow similar problem yesterday. After removing all lines with 'pam_tally' in /etc/pam.d/login via ssh (fortunately worked), I could login as root at console. This module is reportedly deprecated. If there's a login.pacnew file, just replace the current login file with the pacnew one, unless you have custom settings in your login file. Regards.
[arch-general] postgres 12
‐‐‐ Original Message ‐‐‐ On Friday, November 13, 2020 9:36 AM, ente wrote: > Hi, > > since the upgrade of postgress from 11.9 to 12.5 I am having issues > starting up using the systemd service file. > > When I do: > > > su postgres > > postgress -D data > > it works great. When I do > > > systemctl start postgresql > > I get: An old version of the database format was found. > > Checking the database version shows it is on 12. So obviously the > systemd unit file seems to point postgres to an unexpected location. > > My system file is pointing to a non-standard location according to the > arch wiki: > [Service] > Environment=PGROOT=/pathto/pgroot > PIDFile=/pathto/pgroot/data/postmaster.pid > > Anyone else facing the same issue? Any suggestions? Yes, there is a bug. It cost me my local database.
Re: [arch-general] root login @ console
Yes, that works fine. I am still left not being able to login as root though. What setting is causing that in Arch? On Fri, Nov 13, 2020 at 11:09 AM Yash Karandikar via arch-general wrote: > > > On 11/13/20 10:06 AM, Jack Frost via arch-general wrote: > > So I foo-bared my /home partition, no big deal, done it before, and I > > keep good backups. I boot to single mode and get to a prompt. My > > regular user is gone so I try to just login at the console (no X) as > > root. It doesn't work. I know I set the root password. > > > > What setting is preventing root from being able to authenticate. I > > noticed when I went to cups on localhost:631 and tried to do an admin > > task and needed to authenticate. Root couldn't login. > > > > How do I allow root logins under Arch/Arco linux at a console??? > > > Can you try chroot-ing in using a live USB? >
Re: [arch-general] root login @ console
On Fri Nov 13, 2020 at 11:06 AM EST, Jack Frost via arch-general wrote: > What setting is preventing root from being able to authenticate. I > noticed when I went to cups on localhost:631 and tried to do an admin > task and needed to authenticate. Root couldn't login. Perhaps the root account is locked with `passwd -l root`? You can try and check by looking through the `/etc/passwd` file. If after `root:` is an `!` or a `*`, then you won't be able to login. > How do I allow root logins under Arch/Arco linux at a console??? Assuming you have access to the bootloader, you can try "Using bash as init"[1] or the other options on the Wiki page. [1]: https://wiki.archlinux.org/index.php/Reset_lost_root_password#Using_bash_as_init - Steven
Re: [arch-general] root login @ console
On 11/13/20 10:06 AM, Jack Frost via arch-general wrote: > So I foo-bared my /home partition, no big deal, done it before, and I > keep good backups. I boot to single mode and get to a prompt. My > regular user is gone so I try to just login at the console (no X) as > root. It doesn't work. I know I set the root password. > > What setting is preventing root from being able to authenticate. I > noticed when I went to cups on localhost:631 and tried to do an admin > task and needed to authenticate. Root couldn't login. > > How do I allow root logins under Arch/Arco linux at a console??? Can you try chroot-ing in using a live USB? signature.asc Description: OpenPGP digital signature
[arch-general] root login @ console
So I foo-bared my /home partition, no big deal, done it before, and I keep good backups. I boot to single mode and get to a prompt. My regular user is gone so I try to just login at the console (no X) as root. It doesn't work. I know I set the root password. What setting is preventing root from being able to authenticate. I noticed when I went to cups on localhost:631 and tried to do an admin task and needed to authenticate. Root couldn't login. How do I allow root logins under Arch/Arco linux at a console???
Re: [arch-general] postgres 12
Checking the bug tracker should be the first spot to look for an answer https://bugs.archlinux.org/task/68601 Local files got mixed after the test build as the tree contained a rebuild bump. Just wait for -3 hitting the repos and upgrade to it. Cheers
Re: [arch-general] Firefox slowness
On 11/12/20 6:46 PM, David Rosenstrauch wrote: On 11/12/20 12:36 PM, riveravaldez via arch-general wrote: On 11/12/20, David Rosenstrauch wrote: Perhaps this is just me, but it feels like Firefox has gotten super slow / hogging lots of CPU recently. Anyone else seeing this? And/or know what might be causing it? (Some recent upgrade to the package perhaps?) Just in case, if you're using the Sync function, it takes some time and CPU work at start up, I usually open Firefox and check until that syncing is done. Best regards. I don't use sync'ing. I'm guessing this must be something having to do with Firefox 82 though. DR FWIW I am experiencing the same, slowness of firefox especially when starting up. I have also firefox version 82.0.3 but the apparent slowness was also present in earlier versions. I am using firefox under windows 10. If cleaning the profile did help please notify us on the list. ~Z
Re: [arch-general] Firefox slowness
On 11/12/20, David Rosenstrauch wrote: > Perhaps this is just me, but it feels like Firefox has gotten super slow > / hogging lots of CPU recently. Anyone else seeing this? And/or know > what might be causing it? (Some recent upgrade to the package perhaps?) Just in case, if you're using the Sync function, it takes some time and CPU work at start up, I usually open Firefox and check until that syncing is done. Best regards.
Re: [arch-general] Thunderbird package version
On Tue Nov 10, 2020 at 6:44 PM EST, karx via arch-general wrote: > There is already a quite lengthy discussion about this issue going on on > the mailing list. Apologies. I looked at the wrong archive.
Re: [arch-general] Thunderbird package version
On Tue, Nov 10, 2020, 5:02 PM Steven Guikal via arch-general < arch-general@archlinux.org> wrote: > Hi, > > I'm looking at the thunderbird package, and the reported version is > 68.12.0-1 which is rather outdated. Trying to install the package also > installs the outdated version. However, looking at the PKGBUILD it's > 78.4.1. Why is this the case? > There is already a quite lengthy discussion about this issue going on on the mailing list. -- Yash >
[arch-general] Thunderbird package version
Hi, I'm looking at the thunderbird package, and the reported version is 68.12.0-1 which is rather outdated. Trying to install the package also installs the outdated version. However, looking at the PKGBUILD it's 78.4.1. Why is this the case?
[arch-general] PSA: OpenVPN no longer runs scripts as root
OpenVPN now runs scripts as the user `openvpn`, not as root. This tripped me up recently, because I use the `update-systemd-resolved` script, but it can't do its thing without root. Just thought I'd put this out there in case anyone else was having issues.
[arch-general] Thunderbird 78
Hello, Thunderbird allows you to use GnuPG for private key operations if you can’t/don’t want to import your private key into Thunderbird. This is a feature lot of us need, because if you use a smartcard-like hardware solution (Yubikey, Nitrokey, any PGP smartcard…) that’s the only solution (since you cannot import your private key into Thunderbird). Thunderbird calls this the “external GnuPG feature”: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards Thank you for the information. Alright! Thunderbird does have a fallback for GnuPG. Please correct me if I'm wrong: currently everybody that uses Thunderbird, whether they have a need for GnuPG or not, is stuck with an out-of-date version 68.12.0. I'm using Archlinux for many years and normally Archlinux updates packages as they are released. If some people cannot use the latest version for whatever reason, they are free to add the package to IgnorePkg in their /etc/pacman.conf. Now, I understand that it must be sour if the package maintainer himself/herself has to do that, but it does not seem right what is happening now. To avoid that the discussion goes about whether there are "a lot" or "a few" or how many there are that have a need for GnuPG, please consider whether it is worth to avoid shipping (security) updates. Peter.
Re: [arch-general] Thunderbird 78
On 11/8/20 2:12 PM, Archange via arch-general wrote: > Hi, > > On 09/11/2020 00:05, Peter via arch-general wrote: >> Hello, >> >>> anthraxx did update the PKGBUILD and we are testing the build but currently >>> for instance I’m unable to decrypt messages using the external GnuPG >>> feature (reported upstream), and there is also a build issue with system >>> bzip2 (I used the vendored one instead, but that’s not what we want for the >>> final build). >>> >>> So for now this remain WIP. >> I couldn't find the ticket in Bugzilla. Can you please post the ticket >> number of the bug that was reported upstream? > > Sure: https://bugzilla.mozilla.org/show_bug.cgi?id=1675939 > >> GnuPG was replaced by OpenPGP. What are you referring to when you say >> "decrypt messages using the external GnuPG feature"? > > Thunderbird allows you to use GnuPG for private key operations if you > can’t/don’t want to import your private key into Thunderbird. This is a > feature lot of us need, because if you use a smartcard-like hardware solution > (Yubikey, Nitrokey, any PGP smartcard…) that’s the only solution (since you > cannot import your private key into Thunderbird). Thunderbird calls this the > “external GnuPG feature”: > https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards > > Regards, > Bruno/Archange It's not only required for hardware private key keeping, also for opting to use GnuPG for managing private keys, which is what I'm hoping to use. -- Javier signature.asc Description: OpenPGP digital signature
Re: [arch-general] Thunderbird 78
Hi, On 09/11/2020 00:05, Peter via arch-general wrote: Hello, anthraxx did update the PKGBUILD and we are testing the build but currently for instance I’m unable to decrypt messages using the external GnuPG feature (reported upstream), and there is also a build issue with system bzip2 (I used the vendored one instead, but that’s not what we want for the final build). So for now this remain WIP. I couldn't find the ticket in Bugzilla. Can you please post the ticket number of the bug that was reported upstream? Sure: https://bugzilla.mozilla.org/show_bug.cgi?id=1675939 GnuPG was replaced by OpenPGP. What are you referring to when you say "decrypt messages using the external GnuPG feature"? Thunderbird allows you to use GnuPG for private key operations if you can’t/don’t want to import your private key into Thunderbird. This is a feature lot of us need, because if you use a smartcard-like hardware solution (Yubikey, Nitrokey, any PGP smartcard…) that’s the only solution (since you cannot import your private key into Thunderbird). Thunderbird calls this the “external GnuPG feature”: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards Regards, Bruno/Archange
[arch-general] Thunderbird 78
Hello, anthraxx did update the PKGBUILD and we are testing the build but currently for instance I’m unable to decrypt messages using the external GnuPG feature (reported upstream), and there is also a build issue with system bzip2 (I used the vendored one instead, but that’s not what we want for the final build). So for now this remain WIP. I couldn't find the ticket in Bugzilla. Can you please post the ticket number of the bug that was reported upstream? GnuPG was replaced by OpenPGP. What are you referring to when you say "decrypt messages using the external GnuPG feature"? Peter.
Re: [arch-general] Thunderbird 78
Hi, Le 8 novembre 2020 01:59:07 GMT+04:00, Bjoern Franke via arch-general a écrit : >Hi, > >> I have not thoroughly tested through things on the build yet, though. >> I have never used thunderbird much, so I'm not sure I would be the best >> person to test and ensure all of it's features work right. I do want >> to however verify that removing the newly unsupported flags isn't >> breaking anything. >> >> Let me know if you'd like the PKGBUILD, or if I can do anything to help >> you guys with this update. I've got time to do extra things for now. > >I have used the 78.x betas and they had bugs like error messages about >broken keys though I didn't want to encrypt or sign a message. > >78.4.1 is out now, so maybe Levente or Jan could find some time to >update it :) > >Best Regards >Bjoern anthraxx did update the PKGBUILD and we are testing the build but currently for instance I’m unable to decrypt messages using the external GnuPG feature (reported upstream), and there is also a build issue with system bzip2 (I used the vendored one instead, but that’s not what we want for the final build). So for now this remain WIP. Regards, Bruno/Archange
Re: [arch-general] Thunderbird 78
Hi, > I have not thoroughly tested through things on the build yet, though. > I have never used thunderbird much, so I'm not sure I would be the best > person to test and ensure all of it's features work right. I do want > to however verify that removing the newly unsupported flags isn't > breaking anything. > > Let me know if you'd like the PKGBUILD, or if I can do anything to help > you guys with this update. I've got time to do extra things for now. I have used the 78.x betas and they had bugs like error messages about broken keys though I didn't want to encrypt or sign a message. 78.4.1 is out now, so maybe Levente or Jan could find some time to update it :) Best Regards Bjoern
Re: [arch-general] locked out
6 de nov. de 2020 14:43 por f...@linuxaudio.org: > Hello all, > > After a full upgrade it seems I'm locked out :-( > > The system boots normally, and shows the xdm login screen. > But my password is not accepted. Same in a tty, also for > root. > > I can boot using an installation stick, mount all partitions > under /mnt as during installation, and do an arch-chroot /mnt > > I reset my password and the root password in that environment, > but that didn't help. After a normal boot I'm still locked out. > > Any hints to solve this will be much appreciated ! > > -- > FA > It looks like a PAM lockout [1]. [1] https://wiki.archlinux.org/index.php/Security#Lock_out_user_after_three_failed_login_attempts -- Regards, flipee
Re: [arch-general] locked out
I've had suffered something similar with passwords having special characters in. If the keyboard language is somehow changed, the way to type them is no longer what we think it is, and so the password input doesn't match. Encryption keys are also not fully friendly with special characters. Or maybe they are, but using these in the terminal sometimes leads to unthought commands / instructions. Regards, Nicolás Adamo On Fri, Nov 6, 2020, 14:45 Konnor Klercke wrote: > Do you have multiple keyboard layouts set up? Or do you use a layout other > than US-QWERTY? I've had issues with that before. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, November 6th, 2020 at 12:43, Fons Adriaensen < > f...@linuxaudio.org> wrote: > > > Hello all, > > > > After a full upgrade it seems I'm locked out :-( > > > > The system boots normally, and shows the xdm login screen. > > > > But my password is not accepted. Same in a tty, also for > > > > root. > > > > I can boot using an installation stick, mount all partitions > > > > under /mnt as during installation, and do an arch-chroot /mnt > > > > I reset my password and the root password in that environment, > > > > but that didn't help. After a normal boot I'm still locked out. > > > > Any hints to solve this will be much appreciated ! > > > > > -- > > > > FA >
Re: [arch-general] locked out
Nov 6 2020, Fons Adriaensen has written: Hello all, After a full upgrade it seems I'm locked out :-( Do you have free space on your root partition and/or whereever /tmp is mounted on? I had a few issues a couple of times, especially with the extra storage of new package files. Though even then, I think, I could log into the system in emergency one-terminal mode. HTH. Best wishes, Jeanette The system boots normally, and shows the xdm login screen. But my password is not accepted. Same in a tty, also for root. I can boot using an installation stick, mount all partitions under /mnt as during installation, and do an arch-chroot /mnt I reset my password and the root password in that environment, but that didn't help. After a normal boot I'm still locked out. Any hints to solve this will be much appreciated ! -- FA -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c 'Cause living in a dream of you and me Is not the way my life should be... <3 (Britney Spears)
Re: [arch-general] Dual Boot with Windows 10 20H2
Hi, I'm an artist who was forced to learn (analog) photography, but isn't interested in photography. However, since a few month I'm using a Sony α6400. I'm not aware off any professional Linux software for artwork, at best software with all professional features does exist, but gets way to often broken, so that it's not wise to depend on it. To some extend you probably could use extra/digikam 7.1.0-2 An advanced digital photo management application as well as the usual suspects extra/gimp 2.10.22-1 GNU Image Manipulation Program in my experiences way to unstable for serious usage, or extra/krita 4.4.1-1 Edit and paint images quite good, if you don't need reliable colour profiles. I experienced the available colour profiles as utterly broken. I'm running Windows 10 in Virtualbox, using the package virtualbox-bin from AUR (+ guest additions and + the extension pack from Oracle) and my experiences are quite good. My experiences with the package virtualbox from community aren't that good. However, I do not use art software for Windows, I only want to point out that virtualbox is not that bad, to run Windows 10. Some software that can't be used with virtualbox, due to hardware issues, works when running it under wine-staging. I'm using wine-staging for a MIDI guitar synth editor. To some extend I'm using Linux software for artwork, but mostly an iPadPro for photo development and painting, let alone pro-audio. Regards, Ralf
Re: [arch-general] Dual Boot with Windows 10 20H2
Hi, > Or, you can run Windows as a VM. I don't see any reason (taking into > account your hardware and windows software needs) why this might be a > problem for you. AFAIK you have to use the virtualbox extensions from AUR to use USB passthrough with an virtual USB 2.0 Controller, otherwise only 1.1 is possible and I would assume the mentioned devices could refuse to work with 1.1. Best Regards Bjoern
Re: [arch-general] Dual Boot with Windows 10 20H2
Hi! El jue., 5 nov. 2020 a las 23:02, escribió: > [...] > CPU: AMD FX(tm)-4100 Quad-Core Processor 3.60 GHz > RAM: 18 GB > SSD: Samsung 250GB 840 Pro Series for my OS > HDD: WD 2TB as my primary data drive First for all, I have a similar setup. In my case I have a 250GB SSD and two data drives, first is 2TB and second 1TB. > Is it a good choice to install two OS on my system? Yes. I explain. I'm an Arch Linux user since ¿maybe 10 or 15 years ago? I don't remember... Always have dual boot for Windows and Linux. The reason is simple, I'm a "gamer" (no, I don't do Twich videos or have a YouTube channel, only like play computer games). For this reason I need a "video game console", that is Windows. :-D For everything else I use Linux, for work, for browsing Internet, for whatever. With dual-boot I don't have any problem. If I need use my computer, boots Arch, and if i want game, boots Windows. In my case I have this: - In SSD disk (250GB), the first 150GB is for Windows (with the 3 partitions that Windows 10 need), the remaining 100GB for Arch Linux. - The 2TB disk is for Windows data (games need space). - The 1TB disk is for Linux with two partitions, first one (smaller) is for swap and secon one (much bigger) for data (I have several mounts of this disk, for downloads folder, for virtual machines, etc). The installation process is very simple. First for all install Windows reserving the 100GB in SSD for a Linux partition and when you have Windows running install Arch Linux in the reseved partition. If your computer have UEFI you can use systemd-boot for menu choices, if not, GRUB. And there is all. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Re: [arch-general] Dual Boot with Windows 10 20H2
I'd consider dual-booting the best option and personally I use this when Windows is a requirement. Everything works (just follow the wiki steps) EXCEPT when you try to use a TPM, which is painful to say the least. If you use normal (or no) disk encryption, then go for it. TL;DR- Pros: - Everything works flawlessly (I mean, as flawless as running only linux) Cons: - Secure boot/disk encryption with a TPM is going to be painful. Without a TPM, there's no issue, though. - If you are new, there's always a chance you'd mess up the first time (I remember, during my first Arch installation, I accidentally deleted the Windows bootloader). Although I agree, VirtualBox really sucks. If you want to use Arch on Windows, I'd say try out either Hyper-V (requires Win Pro version) or VMWare (good features are behind a paywall). If I use Arch on Windows, I do it without GUI using Hyper-V (although I've never tried Hyper-V's RDP-like thing), and if I need GUI I just run an X-server on Windows. Or, you can run Windows as a VM. I don't see any reason (taking into account your hardware and windows software needs) why this might be a problem for you. On Fri, Nov 6, 2020 at 3:32 AM wrote: > > Hello, > > > > i have a problem. > > I would like to go back to ArchLInux, but i must use windows for most > software like a DocumentScanner (Fujitsu Siemens ScanSnap IX500) with OCR > Software, ABBY Fine Reader and so on, i have a LabelPrinter (Brother QL800) > > My Hobby is Photography with my CANON EOS 80D. I use Luminar 4 to edit my > pictures. I found another solution called darktable. But only for this. > > > > I have a PC created by myself in 2015 with specs > > > > CPU: AMD FX(tm)-4100 Quad-Core Processor 3.60 GHz > > RAM: 18 GB > > SSD: Samsung 250GB 840 Pro Series for my OS > > HDD: WD 2TB as my primary data drive > > > > Is it a good choice to install two OS on my system? > > I like Linux, so i began to learn with Debian 5, with Linux Mint, a little > bit Manjaro and for few months ArchLinux. > > > > I like ArchLInux. > > Is it a good choice to do this or is there another option to use both OS. > > > > A Windows VM with VirtualBox and Boxes doesn’t work fine ☹ i don’t know why > > So this is not an option > > > > > > Please can you help me by my brain storming. > > Many thanks > > >
Re: [arch-general] ibus has been out-of-date for over a month
On Mon, Nov 2, 2020 at 12:02 AM Felix Yan wrote: > > ibus 1.5.23+1+gdd4cc5b0-1 has been pushed into [testing]. Sorry for the > delay. Excellent, thank you! I just installed ibus 1.5.23 from [testing] and it is working great. -Alex
Re: [arch-general] "npm" package issues
Eli, > The files should definitely be owned, though... I suspect your issue > is due to upgrading the pacman version, resulting in some files that > could not be deleted due to not existing, but were not part of the new > package and therefore did not exist afterward either. thanks. in theory (modulo fat fingers), the only files i *removed* were ones that [pacman -Qo] said were unowned. and, *those* files were unowned post [pacman -Syu]. a time machine would help. absent that, again, i guess we'll "let that mystery be". thanks again. cheers, Greg
Re: [arch-general] "npm" package issues
Yash, i (according to the pacman log) explicitly installed npm-check-updates. (i've just now removed it; i think i installed it when i was initially flailing around, trying to understand the npm-verse.) in terms of arch packages, the arch package page https://www.archlinux.org/packages/community/any/npm-check-updates/ says the arch package npm-check-updates depends on the arch npm and semver packages. in addition, npm-check-updates depends on a large number of *npm* packages, including the one you mention, rc-config-loader. in addition, the arch *npm* package includes (the npm package) "rc". it's a convoluted it world out there. cheers, Greg ps -- that every web site i build has its own local copies of all the npm packages used for that site is both a (simplification) boon and a (disk usage) shame. but, i digress.
Re: [arch-general] "npm" package issues
On 11/4/20 1:03 PM, Greg Minshall via arch-general wrote: > this is just a status update, mostly for anyone in the future who might > find this useful for their problem. but, if anyone in the near-present > has any comment, i'm happy. (and, i appreciate all the help up to now!) > > presumably this is all fallout from some historic "npm update -g". > > way too many details follow. > > i removed all files from /usr/lib/node_modules/npm/node_modules *not* > owned by the npm package. > > then, [pacman -Syu] (without '--overwrite', as the offending files have > been removed)succeeded. > > but, in the output, immediately after > > (192/192) checking available disk space > > (and some trailing ###...) > > there were a number of lines like > > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/meant/.npmignore > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/meant/.travis.yml > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/ > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/ > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/.travis.yml > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/LICENSE > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/example/ > > [pacman -Qo] says they are all owned by no package. if that is so, what > is causing the upgrade process to look for them? This pacman warning indicates that while deleting the files from the old copy of the package, it could not find some files to delete, before installing the new copy of the package. The files should definitely be owned, though... I suspect your issue is due to upgrading the pacman version, resulting in some files that could not be deleted due to not existing, but were not part of the new package and therefore did not exist afterward either. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] "npm" package issues
On 11/4/20 12:03 PM, Greg Minshall via arch-general wrote: > (145/192) upgrading npm-check-updates > Did you explicitly install npm-check-updates or was it a dependency of something else? > > .../rc/package.json shows a dependency on minimist. Looks like npm-check-updates depends on something else called rc-load-config, which doesn't depend on anything called "rc", which makes me think that "rc" is built into npm or nodejs. I'm not a NodeJS expert, though, so don't take my word for it. -- Yash Karandikar signature.asc Description: OpenPGP digital signature
Re: [arch-general] "npm" package issues
this is just a status update, mostly for anyone in the future who might find this useful for their problem. but, if anyone in the near-present has any comment, i'm happy. (and, i appreciate all the help up to now!) presumably this is all fallout from some historic "npm update -g". way too many details follow. i removed all files from /usr/lib/node_modules/npm/node_modules *not* owned by the npm package. then, [pacman -Syu] (without '--overwrite', as the offending files have been removed)succeeded. but, in the output, immediately after (192/192) checking available disk space (and some trailing ###...) there were a number of lines like warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.npmignore warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/LICENSE warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/example/ [pacman -Qo] says they are all owned by no package. if that is so, what is causing the upgrade process to look for them? then, after those warnings (in case context is of use) :: Running pre-transaction hooks... (1/2) Removing linux initcpios... (2/2) Unregistering Haskell modules... :: Processing package changes... ( 1/192) upgrading alsa-card-profiles ( 2/192) upgrading alsa-firmware (with some trailing ###... on the last two lines). and, after a bit (144/192) upgrading npm (145/192) upgrading npm-check-updates (ditto) .../rc/package.json shows a dependency on minimist. [pacman -Qo] doesn't seem to know any of the warned-about files; and [pacman -Qkk npm] says "0 altered files" (ditto for [pacman -Qkk npm-check-updates]). (and, everything under /usr/lib/node_modules/npm/node_modules is owned by (the new) "npm 6.14.8-2". unfortunately, i did *not* run [pacman -Qkk npm] *before* doing [pacman -Syu]. cheers, again thanks, sorry for all the detail, Greg
Re: [arch-general] "npm" package issues
thanks, Nick and Maarten. i guess all paths include some trepidation on my part. Nick -- i think it's a good assumption i *did* do some sort of "npm ... -g" action. i've often wondered how distributions (arch and others) deal with users of R, (now) npm, etc., doing a system-wide install of (sub-)packages. (and, in my right mind, i try to avoid doing such system-wide installs.) cheers, Greg
Re: [arch-general] "npm" package issues
On Wed, 4 Nov 2020 at 15:17, Nick Shvelidze via arch-general < arch-general@archlinux.org> wrote: > I think running `pacman -Syu --overwrite '/usr/lib/node_modules/*'` is > safe. > I have no idea how those files would end up there without using `sudo > npm install -g` > It would be good to also explicitly delete everything not owned by pacman in /usr/lib/node_modules. Otherwise you run the risk that some old (deleted upstream) files stick around and possibly cause weird issues. -- Maarten
Re: [arch-general] "npm" package issues
I think running `pacman -Syu --overwrite '/usr/lib/node_modules/*'` is safe.
I have no idea how those files would end up there without using `sudo
npm install -g`
On Wed, Nov 4, 2020 at 11:56 AM Greg Minshall via arch-general
wrote:
>
> hi. [hope all are well, etc.]
>
> i use the npm package (for managing javascript packages).
>
> today i tried "pacman -Syu", and i got a number of errors about files
> under /usr/lib/node_modules/npm/node_modules that "exists in
> filesystem":
>
> (182/182) checking for file conflicts
> error: failed to commit transaction (conflicting files)
> npm: /usr/lib/node_modules/npm/node_modules/meant/.github/workflows/ci.yml
> exists in filesystem
> npm: /usr/lib/node_modules/npm/node_modules/minimist/.travis.yml exists in
> filesystem
> ... (about minimist)
>
>
> these are files that are not owned by the npm package. the relevant
> find command
>
> : find /usr/lib/node_modules/npm/node_modules/ -exec pacman -Qo {} \; |
> :grep -v 'is owned by npm 6.14.8-1'
>
> shows two files in some sort of ./.bin/ directory
>
> error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/node-gyp
> error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/semver
>
>
> and then a number in a small number of npm packages, namely in
> - meant (the .github subdirectory)
> - minimist (the whole directory, i think)
> - node-gyp (the whole directory)
> - semver (the whole directory)
> that are also in the "No package owns" state.
>
> note that [pacman -Syu] only complains about meant and minimist, not
> node-gyp or semver.
>
> first off, i wonder if anyone has ideas of how i ended up in this
> situation? i know that occasionally npm will exclaim, with enthusiasm,
> that a new, updated version, is available, and offer me a chance to
> update it. normally i don't run as root. but, if i had, in the past,
> sudo'd npm, and let it update itself, might *that* have produced this?
>
> then, second, i'm ignorant enough to not be sure what to do and am
> looking for advice. i can do [pacman --overwrite]. i could, i suppose
> (at what consequence?:) [pacman -R npm], then re-install. (though i
> assume i'd have the same problem, as pacman would presumably leave
> untouched the files not owned by npm.) i could just delete the
> offending files pacman complains about (meant/.github/..., and
> minimist/...).
>
> okay, thanks in advance for any thoughts.
>
> cheers, Greg
Re: [arch-general] "npm" package issues
hi, Toni, thanks for the question. actually, i don't know, but if i bothered to sudo, it would have been to do -g (global). do you know (maybe it's a stupid, "well, duh!", question...) if, in that case, my system would become "un-pacman'able"? especially, in such as way as i've described. cheers, Greg
[arch-general] "npm" package issues
hi. [hope all are well, etc.]
i use the npm package (for managing javascript packages).
today i tried "pacman -Syu", and i got a number of errors about files
under /usr/lib/node_modules/npm/node_modules that "exists in
filesystem":
(182/182) checking for file conflicts
error: failed to commit transaction (conflicting files)
npm: /usr/lib/node_modules/npm/node_modules/meant/.github/workflows/ci.yml
exists in filesystem
npm: /usr/lib/node_modules/npm/node_modules/minimist/.travis.yml exists in
filesystem
... (about minimist)
these are files that are not owned by the npm package. the relevant
find command
: find /usr/lib/node_modules/npm/node_modules/ -exec pacman -Qo {} \; |
:grep -v 'is owned by npm 6.14.8-1'
shows two files in some sort of ./.bin/ directory
error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/node-gyp
error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/semver
and then a number in a small number of npm packages, namely in
- meant (the .github subdirectory)
- minimist (the whole directory, i think)
- node-gyp (the whole directory)
- semver (the whole directory)
that are also in the "No package owns" state.
note that [pacman -Syu] only complains about meant and minimist, not
node-gyp or semver.
first off, i wonder if anyone has ideas of how i ended up in this
situation? i know that occasionally npm will exclaim, with enthusiasm,
that a new, updated version, is available, and offer me a chance to
update it. normally i don't run as root. but, if i had, in the past,
sudo'd npm, and let it update itself, might *that* have produced this?
then, second, i'm ignorant enough to not be sure what to do and am
looking for advice. i can do [pacman --overwrite]. i could, i suppose
(at what consequence?:) [pacman -R npm], then re-install. (though i
assume i'd have the same problem, as pacman would presumably leave
untouched the files not owned by npm.) i could just delete the
offending files pacman complains about (meant/.github/..., and
minimist/...).
okay, thanks in advance for any thoughts.
cheers, Greg
Re: [arch-general] USB flash installation medium in BIOS machines
On 03.11.2020 15:15, u...@net9.ga wrote: I have 2 options for that during POST. Press F2 or Del to go into BIOS configuration and see and reorder the boot devices. This list is a classical BIOS boot device list. The other option is press F12 and Don't F2, or Del show more complex screens, other than just reorder boot devices? Yes of course. I just didn't want to describe my whole BIOS settings menu, because I thought your question was aimed the boot device selection. There is some unrelated stuff, but like with most consumer laptops it is very rudimentary and narrow, like disable USB or disable Camera or disable Micorphone or ASF configuration... Perhaps the problem is that itthe dirmware is looking for an ESP, which can not be found? Shouldn't the ESP be on the Live medium? I never had one on my hard drive, which is a plain MBR partitioned one with no fancy firmware loading stuff... plain old BIOS GRUB setup. Always been. I came to the conclusion, that my hardware is faulty. Somehow it is capable to start the systemd-boot loader but not the actual UEFI image. And all while not mentioning any EFI capabilities in BIOS settings. Well, if it boots systemd-boot, have you tried to configure systemd-boot? Are you aware to the fact that there used to be 32 bits variant of the efi firmware? What do you mean by configure? It is the unchanged archlinux-2020.11.01-x86_64.iso I dd'ed on a stick. Just out of curiosit, does anyone know a way to "ask" the hardware about EFI capabilities, without actually booting through EFI? I think that if you can start the installation, you might query hardware capabilities. I am referring to https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Checking_the_firmware_bitness . I am aware of /sys/firmware/efi, but it only shows up when you actually boot through the EFI, which, as stated, I was never able to. I worked around the problem, so I am good for now. If someone is interested in investigating the problem with that dated hardware I am more than willing to do whatever you need for that. Just mail directly, no need to spam the list any further.
Re: [arch-general] Fail2Ban is not adding iptables rules
El mar., 3 nov. 2020 a las 15:21, escribió: > > Maykel Franco via arch-general wrote: > > > El mar., 3 nov. 2020 a las 10:45, escribi??: > > > > > > Maykel Franco via arch-general wrote: > > > > > > > El mar., 3 nov. 2020 a las 9:48, escribi??: > > > > > > > > > > Maykel Franco via arch-general wrote: > > > > > > > > > > > Hi, I have this script for iptables for my archlinux desktop: > > > > > > > > > > > > https://pastebin.com/SafhsKFt > > > > > > > > > > > > And when received external request access SSH error, fail2ban add > > > > > > rule > > > > > > but the rule not working. > > > > > > > > > > > > I think it has to do with the iptables script, but the fail2ban > > > > > > blocking rules add fine but don't ban. That could be happening? > > > > > > > > > > It could be that the banning fail2ban rule doesn't ban. > > > > > 1. Can you show the iptables state before, and after, fail2ban added > > > > >its rule? That is, issue an iptables -s command? I do hope I got > > > > >the iptables command right. > > > > > 2. Can you show fail2ban configuration? > > > > > > > > > > -- > > > > > u34 > > > > > > > > The problem is not fail2ban. The problem is the script iptables rules > > > > because after exec script iptables: > > > > > > > > https://pastebin.com/SafhsKFt > > > > > > > > I try drop ip: > > > > > > > > iptables -A INPUT -p tcp -s 192.168.0.33 --dport 22 -j DROP > > > > > > > > Not block ip 192.168.0.33 on port 22. > > > > > > Possibly because that line is added as the last lines of the iptables. > > > The accept lines of the script already accepted the 192.168.0.33 > > > connection. You > > > probably want to issue an Insert, or a Replace, command. -I or -R, if I > > > remmeber > > > correcly. > > > What is the output of iptables -s, if I remember correctly, > > > after you issued > > > the 192.168.0.33 related command? > > > > > > As an aside, I think you should revert to nft (nftables). > > > > > > -- > > > u34 > > > > Thanks for your response. With -I works well with: > > > > iptables -I INPUT -p tcp -s 192.168.0.33 --dport -j DROP > > > > And now, for iptables works well, How it solved? I need iptables add > > rules on first place. > > I didn't follow. iptables doesn't add rules by itself. Someone, or something, > tells it what rules it should use. Whom do want to tell iptables to add > rules on first place? > > -- > u34 Maybe I have explained myself wrong. With that script that I have put from iptables, I can add rules first with the -I parameter and it works. Thanks for the help of colleagues. Now what I want is that iptables when I block some IP, it also ping it first to make it work.
Re: [arch-general] USB flash installation medium in BIOS machines
On 03/11/2020 10.23, u...@net9.ga wrote:> Have you entered the firmware configuration, or the bios configuration, whatever that is, to see its options? I have 2 options for that during POST. Press F2 or Del to go into BIOS configuration and see and reorder the boot devices. This list is a classical BIOS boot device list. The other option is press F12 and select a boot device, without the need to permanently reorder stuff. This is very plain and leaves not much room for interpretation and I tried both. Since there is no (known) option to force the boot mode of the flash drive, I went with Óscars suggestion and created a BIOS-GRUB flash drive to load the ISO as loop device, which went really smooth. I used that method before, when I originally installed Arch on it, but just for the reason that I could have multiple ISOs on a stick without reflashing all the time. That is probably the reason, why I never ran into this problem with the Arch ISO. I came to the conclusion, that my hardware is faulty. Somehow it is capable to start the systemd-boot loader but not the actual UEFI image. And all while not mentioning any EFI capabilities in BIOS settings. Just out of curiosit, does anyone know a way to "ask" the hardware about EFI capabilities, without actually booting through EFI?
Re: [arch-general] Arch Linux Support for Station P1, Station M1?
03.11.2020 14:51, Morne Ross via arch-general пишет: Hi Firefly is looking for some developers to add Linux OS support for their devices and can give some free samples. They have the Station P1 RK3399 and Station M1 RK3328 and plan to also release a RK3568 device in a couple of weeks. http://stationpc.com/portal.php?mod=topic=2 http://stationpc.com/portal.php?mod=topic=7 as i understand. this computers works on ARM architecture. so that topic would be appropriate for arch linux arm folks. archlinux only supports amd64 architecture. Will it be possible for someone to build Arch Linux for it perhaps? The source code is also available for the devices and they already have Linux booting with 5.9 kernels. For further cooperation or help you can contact T-Chip, manufacturer of the Firefly devices. s...@t-chip.com.cn You can send me the contact and shipping details then I can forward it to them for where the samples can be shipped too. If more than one person needs samples than I can also ask them. Regards Morne -- Sincerely, Alexander.
[arch-general] Arch Linux Support for Station P1, Station M1?
Hi Firefly is looking for some developers to add Linux OS support for their devices and can give some free samples. They have the Station P1 RK3399 and Station M1 RK3328 and plan to also release a RK3568 device in a couple of weeks. http://stationpc.com/portal.php?mod=topic=2 http://stationpc.com/portal.php?mod=topic=7 Will it be possible for someone to build Arch Linux for it perhaps? The source code is also available for the devices and they already have Linux booting with 5.9 kernels. For further cooperation or help you can contact T-Chip, manufacturer of the Firefly devices. s...@t-chip.com.cn You can send me the contact and shipping details then I can forward it to them for where the samples can be shipped too. If more than one person needs samples than I can also ask them. Regards Morne
Re: [arch-general] Fail2Ban is not adding iptables rules
El mar., 3 nov. 2020 a las 10:45, escribió: > > Maykel Franco via arch-general wrote: > > > El mar., 3 nov. 2020 a las 9:48, escribi??: > > > > > > Maykel Franco via arch-general wrote: > > > > > > > Hi, I have this script for iptables for my archlinux desktop: > > > > > > > > https://pastebin.com/SafhsKFt > > > > > > > > And when received external request access SSH error, fail2ban add rule > > > > but the rule not working. > > > > > > > > I think it has to do with the iptables script, but the fail2ban > > > > blocking rules add fine but don't ban. That could be happening? > > > > > > It could be that the banning fail2ban rule doesn't ban. > > > 1. Can you show the iptables state before, and after, fail2ban added > > >its rule? That is, issue an iptables -s command? I do hope I got > > >the iptables command right. > > > 2. Can you show fail2ban configuration? > > > > > > -- > > > u34 > > > > The problem is not fail2ban. The problem is the script iptables rules > > because after exec script iptables: > > > > https://pastebin.com/SafhsKFt > > > > I try drop ip: > > > > iptables -A INPUT -p tcp -s 192.168.0.33 --dport 22 -j DROP > > > > Not block ip 192.168.0.33 on port 22. > > Possibly because that line is added as the last lines of the iptables. > The accept lines of the script already accepted the 192.168.0.33 connection. > You > probably want to issue an Insert, or a Replace, command. -I or -R, if I > remmeber > correcly. > What is the output of iptables -s, if I remember correctly, > after you issued > the 192.168.0.33 related command? > > As an aside, I think you should revert to nft (nftables). > > -- > u34 Thanks for your response. With -I works well with: iptables -I INPUT -p tcp -s 192.168.0.33 --dport -j DROP And now, for iptables works well, How it solved? I need iptables add rules on first place.
Re: [arch-general] Fail2Ban is not adding iptables rules
On 03.11.20 09:54, Maykel Franco via arch-general wrote: El mar., 3 nov. 2020 a las 9:48, escribió: Maykel Franco via arch-general wrote: Hi, I have this script for iptables for my archlinux desktop: https://pastebin.com/SafhsKFt And when received external request access SSH error, fail2ban add rule but the rule not working. I think it has to do with the iptables script, but the fail2ban blocking rules add fine but don't ban. That could be happening? It could be that the banning fail2ban rule doesn't ban. 1. Can you show the iptables state before, and after, fail2ban added its rule? That is, issue an iptables -s command? I do hope I got the iptables command right. 2. Can you show fail2ban configuration? -- u34 The problem is not fail2ban. The problem is the script iptables rules because after exec script iptables: https://pastebin.com/SafhsKFt I try drop ip: iptables -A INPUT -p tcp -s 192.168.0.33 --dport 22 -j DROP Not block ip 192.168.0.33 on port 22. Thats the expected behavior. With -A you append a rule to the already existing rules. The problem is that you have already allowed port 22 in your script and this rule match for all incoming packets on port 22. Other rules will not be executed. I'm not an expert in fail2ban but when you use the following rule after the script is executed port 22 will be blocked iptables -I INPUT -p tcp -s 192.168.0.33 --dport 22 -j DROP -I means that the rule is insert on the first place in the chain. With "iptables -vL INPUT" you can see the order of the rule. First matching rule will be used and no other rules in the INPUT chain will be executed.
Re: [arch-general] Fail2Ban is not adding iptables rules
El mar., 3 nov. 2020 a las 9:48, escribió: > > Maykel Franco via arch-general wrote: > > > Hi, I have this script for iptables for my archlinux desktop: > > > > https://pastebin.com/SafhsKFt > > > > And when received external request access SSH error, fail2ban add rule > > but the rule not working. > > > > I think it has to do with the iptables script, but the fail2ban > > blocking rules add fine but don't ban. That could be happening? > > It could be that the banning fail2ban rule doesn't ban. > 1. Can you show the iptables state before, and after, fail2ban added >its rule? That is, issue an iptables -s command? I do hope I got >the iptables command right. > 2. Can you show fail2ban configuration? > > -- > u34 The problem is not fail2ban. The problem is the script iptables rules because after exec script iptables: https://pastebin.com/SafhsKFt I try drop ip: iptables -A INPUT -p tcp -s 192.168.0.33 --dport 22 -j DROP Not block ip 192.168.0.33 on port 22.
[arch-general] Fail2Ban is not adding iptables rules
Hi, I have this script for iptables for my archlinux desktop: https://pastebin.com/SafhsKFt And when received external request access SSH error, fail2ban add rule but the rule not working. I think it has to do with the iptables script, but the fail2ban blocking rules add fine but don't ban. That could be happening?
Re: [arch-general] Makepkg: Incremental builds
On 11/2/20 1:39 PM, LuKaRo wrote: > Hi everyone, > > I'm currently building ungoogled-chromium from AUR, which is running for > 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm > thinking about what happens when the next version will be released. From > my understanding, when running git pull to fetch the latest version from > AUR and afterwards makepkg -sri, the old binaries will be deleted prior > to starting the build, which will probably require to build everything > from scratch. Am I right? > > However, I'm sure that only parts of the source change between versions. > Therefore, only parts of the binary files would need to be built again, > which would dramatically decrease build time. Correct? How can I make > use of incremental builds using makepkg? I'm aware of the -e switch, but > that would skip the prepare function, which might be required as e.g. > new patch files from AUR would need to be applied. makepkg --noextract will continue a build you have interrupted using CTRL+C, it does not perform "incremental" builds for the next version of the software. > Furthermore, the timestamps of the source files all seem to be set to > the archival date. This would probably also require a full build, even > if only parts of the source changed. Correct? If yes, is there a way to > fix that? The source extraction naturally overwrites every single file in the current source archive, and updates timestamps in the process. Otherwise, how would you get the new source code? ;) Using bsdtar to unpack a tarball doesn't exactly know which files should be skipped due to not changing... > Having to spend 6-7 hrs of build time on each new release would make > frequent updating impractical. You have two options: - use ccache to cache compiler results, for unchanged source files and unchanged recursive includes you often won't need to recompile and ccache's gcc wrapper will instead output the file from the cache for significant speedup - use git+https:// based sources, since git *can* (and does) figure out which files need to be modified on disk in order to be updated to the desired revision. makepkg -sri for git-based source code does indeed play quite nicely with incremental builds -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Makepkg: Incremental builds
On Mon, Nov 2, 2020, 12:40 PM LuKaRo wrote: > Hi everyone, > > I'm currently building ungoogled-chromium from AUR, which is running for > 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm > thinking about what happens when the next version will be released. From > my understanding, when running git pull to fetch the latest version from > AUR and afterwards makepkg -sri, the old binaries will be deleted prior > to starting the build, which will probably require to build everything > from scratch. Am I right? > However, I'm sure that only parts of the source change between versions. > Therefore, only parts of the binary files would need to be built again, > which would dramatically decrease build time. Correct? How can I make > use of incremental builds using makepkg? I'm aware of the -e switch, but > that would skip the prepare function, which might be required as e.g. > new patch files from AUR would need to be applied. > > Furthermore, the timestamps of the source files all seem to be set to > the archival date. This would probably also require a full build, even > if only parts of the source changed. Correct? If yes, is there a way to > fix that? Having to spend 6-7 hrs of build time on each new release would make > frequent updating impractical. There are binary packages available on the ungoogled-chromium-archlinux GitHub page[1], however, downloading binaries from untrusted sources is usually frowned upon. [1]: https://github.com/ungoogled-software/ungoogled-chromium-archlinux -- Yash Thanks in advance! LuKaRo
Re: [arch-general] USB flash installation medium in BIOS machines
> There are only my 2 installed hard drives plus a "USB HDD: ..." option. > I am very positive that this laptop is legacy BIOS only and that it is > somehow wrongly identified as UEFI? It can't be "wrongly identified as UEFI". If the laptop didn't support UEFI, then you wouldn't even see the systemd-boot menu, because there wouldn't be anything to *load* systemd-boot, or support it running. systemd-boot is designed to exclusively run in the UEFI environment, and it just can not work at all in a BIOS environment. >>> I see the boot menu (which looks like systemd-boot menu) with only options >>> for UEFI boot and EFI shell option. -- damjan
Re: [arch-general] USB flash installation medium in BIOS machines
El lun., 2 nov. 2020 a las 10:57, Juergen Werner via arch-general
() escribió:
> I tried 2 different USB drives and different USB ports. Am I missing
> something?
Hi jotz. I tell you a method to have a Live USB that boots directly
from ISO and that can have several ISOs.
Let's assume that your USB is /dev/sdX
1. Partition It:
sudo fdisk /dev/sdX
One DOS partition, press o to new table, n to new partition a enter to
end to pick full disk. Set the partition type with t command to c (W95
FAT32 (LBA)) and use a to activate partition.
2. Format as FAT:
sudo mkfs.fat -F32 -n MULTIBOOT /dev/sdX1
3. Mount it in /usb (or in any site that you like, in my sample I'm using /usb).
sudo mkdir /usb
sudo mount /dev/sdX1 /usb
4. Make a boot dir in USB
sudo mkdir /usb/boot
5. Install GRUB for BIOS and UEFI (First line is for BIOS and second
one for UEFI)
sudo grub-install --target=i386-pc --recheck --boot-directory=/usb/boot /dev/sdX
sudo grub-install --target x86_64-efi --removable
--boot-directory=/usb/boot --efi-directory=/usb
6. Edit grub menu file (/usb/boot/grub/grub.cfg) writ this into it:
insmod all_video
set gfxpayload=keep
submenu "Arch Linux --->" {
set isover="2020.11.01"
set isoarch="x86_64"
set isofile="/iso/archlinux-${isover}-${isoarch}.iso"
loopback loop ${isofile}
menuentry "Arch Linux ${isover} ${isoarch}" {
echo "Using ${isofile}..."
probe -u ${root} --set=rootuuid
linux (loop)/arch/boot/${isoarch}/vmlinuz-linux
img_dev=/dev/disk/by-uuid/${rootuuid} img_loop=${isofile}
initrd (loop)/arch/boot/intel-ucode.img
(loop)/arch/boot/amd-ucode.img
(loop)/arch/boot/${isoarch}/initramfs-linux.img
}
menuentry "Run Memtest86+ (RAM test)" {
echo "Using ${isofile}..."
linux16 (loop)/arch/boot/memtest
}
}
7. Create a /usb/iso directory and copy archlinux-2020.11.01-x86_64.iso into it.
8. Sync and umount
sync
umount /usb
Reboot and enjoy. If you want more entries for the grub menu or have
other ISOs in your USB you can see my article about it[1] (it's in
Spanish but Google translate makes miracles).
Greetings.
[1]: https://blog.ogarcia.me/crear-un-usb-multiboot/
--
Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Re: [arch-general] USB flash installation medium in BIOS machines
On 02.11.20 15:17, Łukasz Michalski wrote: There should be two separate entries in boot menu for booting in UEFI mode and Legacy BIOS mode. What choices do you have if you open boot device menu? There are only my 2 installed hard drives plus a "USB HDD: ..." option. I am very positive that this laptop is legacy BIOS only and that it is somehow wrongly identified as UEFI? I forgot to mention, that once I confirm one of the UEFI boot options in the systemd-boot menu, the screen goes black, the fan speed increases and then stays constant. Nothing happens afterwards and no reaction on (multiple) ctrl-alt-del. Only a long press of the power button releases it from its pain.
Re: [arch-general] USB flash installation medium in BIOS machines
On 02.11.20 11:22, David Runge wrote: It seems that your hardware does support UEFI, otherwise systemd-boot would not be started. You can check in your BIOS/Firmware. Many older models have both BIOS and UEFI capabilities and usually you can select which should be used. I just double checked and I don't see any mentioning of UEFI or CSM in the BIOS settings. I always used legacy BIOS instructions and setup before and it always worked on this machine (Acer Travelmate TM8473T). But I can imagine, that this BIOS is somewhat tainted with EFI, because at that time it was just getting introduced to the general public. I found a Linux Mint forum entry where they describe a similar problem with a relatively recent installation medium on this laptop. [1] Syslinux will only be used if the hardware does not provide UEFI. Can I force it somehow? Like by manipulating the image on the flash drive? [1] https://forums.linuxmint.com/viewtopic.php?t=302868
[arch-general] USB flash installation medium in BIOS machines
Hi, I started working on my old Laptop again, which is a pre-EFI model and needed a live USB medium to do some repartitioning. I copied the current installation ISO to a USB flash. When I try to boot with it, I see the boot menu (which looks like systemd-boot menu) with only options for UEFI boot and EFI shell option. In the wiki it is mentioned, that BIOS boots are available throug syslinux: Tip: The installation image uses systemd-boot for booting in UEFI mode and syslinux for booting in BIOS mode. [...] I tried 2 different USB drives and different USB ports. Am I missing something? Cheers, jotz
Re: [arch-general] ibus has been out-of-date for over a month
On Thu, 2020-10-29 at 14:55 -0600, Alex Henrie wrote: > Dear Arch maintainers, > > ibus 1.5.23 was released at the end of last month,[1] but Arch is > still on 1.5.22.[2] Could you please update the package? ibus 1.5.23+1+gdd4cc5b0-1 has been pushed into [testing]. Sorry for the delay. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part
Re: [arch-general] suspend to RAM with home on NFS
Do you have _netdev option set for /home in fstab? I can't think of any reasons this would be a problem. It certainly wouldn't prevent you from suspending, if anything you'd just encounter trouble when resuming. Check your systemd config perhaps? >From the wiki here: https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate If the swap file is in /home/, systemd-logind will not be able to determine its size and thus will prevent hibernation. See systemd issue 15354 for a workaround. On Sun, Nov 1, 2020, 1:22 PM hw wrote: > > Hi, > > how do you get suspend to RAM to work with home directories on NFS? > Since I have /home mounted over NFS, suspending just freezes and I > can only hold down the power button to turn the computer off. >
Re: [arch-general] [arch-dev-public] archlinux/base docker image will no longer be updated
On Sun, 1 Nov 2020 11:28:29 +0100 Óscar García Amor via arch-general wrote: > I take this opportunity to comment that I maintain a clean Arch Linux > image[1] (base and base-devel) We are now providing base and base-devel in the official Docker Hub Library on a weekly basis [1]. Please feel free to contribute! [1] https://gitlab.archlinux.org/archlinux/archlinux-docker -- hashworks Webhttps://hashworks.net Public Key 0x4FE7F4FEAC8EBE67 pgpN7DBA9wtKV.pgp Description: OpenPGP digital signature
