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 11/28/20 3:01 PM, SET via arch-general 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 can't speak to this NIC specifically. But in my experience, the r8169, which is part of the kernel, automagically works with most Realtek devices. I'd recommend trying that before installing a separate device. DR
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] Systemd boot
"Riccardo Paolo Bestetti" wrote: > I2'm trying to fully make sense of the boot process with systemd. > > I've read various pages from the manual, including bootup(7). There are > two points I don't fully understand. > > * Filesystem mounts during initrd > The man page, under the initrd section, says: "systemd detects that it > is run within an initrd [...]. The bootup process begins identical to > the system manager bootup (see above) until it reaches basic.target. > [...] Before any file systems are mounted, it must be determined > whether the system will resume from hibernation or proceed with normal > boot." > > In my mind, that part self-contradicts when both saying that 1) the > bootup proceeds identical to the system manager bootup and 2) a > determination on whether to mount file systems is made /after/ > basic.target. This is because some file systems (including, in most > cases, the root file systems) would have been mounted before > local-fs.target, which is ordered before basic.target. > > So either the process is not really identical until basic.target, or I'm > getting something wrong. > > * Instances > I gather that the systemd which runs inside the initrd is a completely > separate instance from the one which then runs in the booted system. > Which implies - as discussed above - that the system initialization > sequence from beginning to basic.target actually happens twice. > > Does this means than any initialization units which could potentially be > run twice - once in the initrd and once in the booted system - should be > instrumented to avoid running their logic twice (in the cases where > that's not needed or even harmful)? > > Let's consider for example an hypothetical service with > "WantedBy=cryptsetup-pre.target", which decrypts a keyfile using an > hardware token. This keyfile is then consumed by > systemd-cryptsetup-generator with keyfile-erase=on. What happens if the > service is run twice, but the key is consumed only the first time? A > decrypted keyfile remains in the system. > > What's the correct approach to avoid such a scenario? > > Riccardo I am confused my self about the exact booting procedures. Yet I do believe that you are missing the important issue of chroot. In a simplistic decription, the system boots into an initrd. Then it shutoff. CHROOT. And now it will reboot into a working system. Do examine the journal of a boot process. In particular, look for the chroot line: systemd[1]: Switching root. And examine carefully what happen before that line. And after it. -- u34
Re: [arch-general] Systemd boot
On Sat Nov 28, 2020 at 1:58 PM CET, Lone_Wolf wrote: > Archlinux has its own boot process, described at [1] > > Check the initramfs section and you'll see a reference to mkinitcpio [2] > . > > On the mkinitcpio page look at the Common Hooks section. > > Basically there are 2 systems that archlinux can use in initramfs : > busybox and systemd . > > > Check the hooks in your mkinitcpio.conf : are you using the systemd hook > or any of the sd-* hooks ? > > If yes, mkinitpio sd-encrypt hook is what handles your encrypted drives. > see [3] for details > > If no, busybox encrypt hook is responsible, see [4]. I'm informed on what the supported boot processed for Arch are, and I very well known which one I'm running, as I configured it. :) I'm grateful for your help, but you didn't really answer any of my questions, which are about some specifics of the systemd boot process that I'd like to better understand. Riccardo
Re: [arch-general] Systemd boot
On 28-11-2020 10:22, Riccardo Paolo Bestetti wrote: I2'm trying to fully make sense of the boot process with systemd. I've read various pages from the manual, including bootup(7). There are two points I don't fully understand. * Filesystem mounts during initrd The man page, under the initrd section, says: "systemd detects that it is run within an initrd [...]. The bootup process begins identical to the system manager bootup (see above) until it reaches basic.target. [...] Before any file systems are mounted, it must be determined whether the system will resume from hibernation or proceed with normal boot." In my mind, that part self-contradicts when both saying that 1) the bootup proceeds identical to the system manager bootup and 2) a determination on whether to mount file systems is made /after/ basic.target. This is because some file systems (including, in most cases, the root file systems) would have been mounted before local-fs.target, which is ordered before basic.target. So either the process is not really identical until basic.target, or I'm getting something wrong. * Instances I gather that the systemd which runs inside the initrd is a completely separate instance from the one which then runs in the booted system. Which implies - as discussed above - that the system initialization sequence from beginning to basic.target actually happens twice. Does this means than any initialization units which could potentially be run twice - once in the initrd and once in the booted system - should be instrumented to avoid running their logic twice (in the cases where that's not needed or even harmful)? Let's consider for example an hypothetical service with "WantedBy=cryptsetup-pre.target", which decrypts a keyfile using an hardware token. This keyfile is then consumed by systemd-cryptsetup-generator with keyfile-erase=on. What happens if the service is run twice, but the key is consumed only the first time? A decrypted keyfile remains in the system. What's the correct approach to avoid such a scenario? Riccardo Archlinux has its own boot process, described at [1] Check the initramfs section and you'll see a reference to mkinitcpio [2] . On the mkinitcpio page look at the Common Hooks section. Basically there are 2 systems that archlinux can use in initramfs : busybox and systemd . Check the hooks in your mkinitcpio.conf : are you using the systemd hook or any of the sd-* hooks ? If yes, mkinitpio sd-encrypt hook is what handles your encrypted drives. see [3] for details If no, busybox encrypt hook is responsible, see [4]. Lone_Wolf [1] https://wiki.archlinux.org/index.php/Arch_boot_process [2] https://wiki.archlinux.org/index.php/Mkinitcpio [3] https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Using_sd-encrypt_hook [4] https://wiki.archlinux.org/index.php/Mkinitcpio#Runtime_customization
[arch-general] Systemd boot
I2'm trying to fully make sense of the boot process with systemd. I've read various pages from the manual, including bootup(7). There are two points I don't fully understand. * Filesystem mounts during initrd The man page, under the initrd section, says: "systemd detects that it is run within an initrd [...]. The bootup process begins identical to the system manager bootup (see above) until it reaches basic.target. [...] Before any file systems are mounted, it must be determined whether the system will resume from hibernation or proceed with normal boot." In my mind, that part self-contradicts when both saying that 1) the bootup proceeds identical to the system manager bootup and 2) a determination on whether to mount file systems is made /after/ basic.target. This is because some file systems (including, in most cases, the root file systems) would have been mounted before local-fs.target, which is ordered before basic.target. So either the process is not really identical until basic.target, or I'm getting something wrong. * Instances I gather that the systemd which runs inside the initrd is a completely separate instance from the one which then runs in the booted system. Which implies - as discussed above - that the system initialization sequence from beginning to basic.target actually happens twice. Does this means than any initialization units which could potentially be run twice - once in the initrd and once in the booted system - should be instrumented to avoid running their logic twice (in the cases where that's not needed or even harmful)? Let's consider for example an hypothetical service with "WantedBy=cryptsetup-pre.target", which decrypts a keyfile using an hardware token. This keyfile is then consumed by systemd-cryptsetup-generator with keyfile-erase=on. What happens if the service is run twice, but the key is consumed only the first time? A decrypted keyfile remains in the system. What's the correct approach to avoid such a scenario? Riccardo
Re: [arch-general] Thunderbird 78
Thunderbird asks me to migrate my keys, and I am not sure, if I should not wait a few more days. Whatever you choose, a warning: set a strong master password for Thunderbird before doing the migration. Otherwise Thunderbird stores your private key unencrypted and there is no warning about the situation during migration.⁽¹⁾ ⁽¹⁾ https://bugzilla.mozilla.org/show_bug.cgi?id=1662272 OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-general] Thunderbird 78
Hello Nico, You cannot use gpg for public key operations but for secret key ops. Please follow the instructions for smartcards (no smartcard daemon needed obviously): https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards Then you can use the external gpg with your ~/.gnupg for decryption and signing. Best wishes, NTS On 28 Nov 2020 9:36 a.m., "NicoHood" wrote: Thunderbird 78 is in the repos for quite some time now. Can anyone please explain me what is the best way to use GPG now for email encryption? I read that Archlinux aims to use the system wide gpg keyring instead of thunderbirds builtin store. Is that still the case and is that implemented yet? Thunderbird asks me to migrate my keys, and I am not sure, if I should not wait a few more days. Having the private key in multiple places is really not the best idea in my opinion. Depending on the current state we could also add a news on the archlinux website or at least update the wiki: https://wiki.archlinux.org/index.php/Thunderbird/Enigmail Cheers Nico
Re: [arch-general] Thunderbird 78
Thunderbird 78 is in the repos for quite some time now. Can anyone please explain me what is the best way to use GPG now for email encryption? I read that Archlinux aims to use the system wide gpg keyring instead of thunderbirds builtin store. Is that still the case and is that implemented yet? Thunderbird asks me to migrate my keys, and I am not sure, if I should not wait a few more days. Having the private key in multiple places is really not the best idea in my opinion. Depending on the current state we could also add a news on the archlinux website or at least update the wiki: https://wiki.archlinux.org/index.php/Thunderbird/Enigmail Cheers Nico
