Re: [arch-general] Systemd boot

On Sun Nov 29, 2020 at 1:14 PM CET, Lone_Wolf wrote: > It wasn't clear to me (and still is not) what initramfs environment your > questions were about. > > > Do you want answers based on systemd manpages OR on a systemd initramfs > as setup by mkinitcpio on archlinux ? As I conjecture below, I don'

Re: [arch-general] Systemd boot

On 28-11-2020 19:24, Riccardo Paolo Bestetti wrote: 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 o

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,

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

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 sec

Re: [arch-general] systemd-zram generator

The fact is that pushing to get some experimental software installed and, especially, configured by default in Arch is rude from my viewpoint (as an Arch user), extremely so when * There are alternatives already in the Arch repos, while this one is not even packaged * "This is a project in rust."

Re: [arch-general] systemd-zram generator

Hi Chris, > I consider your response: > 1. Disrespectful to me. I agree. > Is this sort response representative of the Arch Linux community? A minority seem to think OpenBSD's, perhaps inaccurate, reputation is a target. > Relative newcomers, and first time posters, should expect this kind of

Re: [arch-general] systemd-zram generator

El vie., 17 ene. 2020 a las 5:18, Chris Murphy () escribió: > Is this sort response representative of the Arch Linux community? > Relative newcomers, and first time posters, should expect this kind of > hostility? I think it's embarrassing. In arch-general list can write anyone. Just ignore him.

Re: [arch-general] systemd-zram generator

On Thu, Jan 16, 2020 at 4:03 AM Neven Sajko via arch-general wrote: > > > ... installed by default ... > > > ... Is it really a feature that the user needs to know about specific > > implementations? > > > ... always including it in an installation by default, just like the > > existing swap uni

Re: [arch-general] systemd-zram generator

> ... installed by default ... > ... Is it really a feature that the user needs to know about specific > implementations? > ... always including it in an installation by default, just like the existing > swap units, rather than expecting users to manually install a package. You obviously know

Re: [arch-general] systemd-zram generator

On Mon, Jan 13, 2020 at 6:45 AM Geo Kozey via arch-general wrote: > > There are many tools to configure zram available, one is even in Arch Linux > repos: > https://www.archlinux.org/packages/community/any/systemd-swap/ Right. And typically they don't co-exist, they expect they're the only one.

Re: [arch-general] systemd-zram generator

> From: Chris Murphy > Sent: Mon Jan 13 05:51:15 CET 2020 > To: > Subject: [arch-general] systemd-zram generator > > > Hi, > > swap-create@.service generator for zram devices > https://github.com/systemd/zram-generator > > zram: Compressed RAM based block devices > https://www.kernel.org/doc/

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

On 2018-06-30 13:55:18 (+0200), Tinu Weber wrote: > On Sat, Jun 30, 2018 at 13:34:11 +0200, Bjoern Franke wrote: > > > Are you truly logged in as this second user for whom it does not work, > > > or just su(1)'d, etc? > > > > Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

On Sat, Jun 30, 2018 at 13:34:11 +0200, Bjoern Franke wrote: > > Are you truly logged in as this second user for whom it does not work, > > or just su(1)'d, etc? > > Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning > an own zsh as user2 would do the right thing. -s only spa

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi Bjoern, > > Are you truly logged in as this second user for whom it does not > > work, or just su(1)'d, etc? > > Erm, just used "sudo -u user2 -s" to login as user2. I assumed > spawning an own zsh as user2 would do the right thing. It doesn't here. As UID 1000 logged into an XFCE desktop via

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi Ralph, > > Are you truly logged in as this second user for whom it does not work, > or just su(1)'d, etc? Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning an own zsh as user2 would do the right thing. > My guess is there's a user.service running for the user ID where i

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi Bjoern, > > I'm trying to create a systemd timer for a user to run duply daily. > > For one user the enabled worked fine, but another one: > > > > systemctl --user enable backup.timer > > Failed to connect to bus: No such file or directory Are you truly logged in as this second user fo

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

On 27 June 2018 at 08:26, Bjoern Franke wrote: > Hi, > > I'm trying to create a systemd timer for a user to run duply daily. For > one user the enabled worked fine, but another one: > > systemctl --user enable backup.timer > Failed to connect to bus: No such file or directory > > I have no clue wh

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi, > Good, > > Each user + the system has his own dbus. Normally, you should have > dbus.service and dbus.socket units somewhere (/usr/lib/systemd/user > and/or /etc/systemd/user and/or .config/systemd/user) > > If it works correctly for one of the users, then probably > /usr/lib/systemd/user a

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

> systemctl --user status has the same error. How do I start dbus for the > second user? systemctl enable --user dbus fails due the same error, and > system's dbus is running. Good, Each user + the system has his own dbus. Normally, you should have dbus.service and dbus.socket units somewhere (/u

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi Ismael, thanks for your both hints. > > The two clues I have according to your error are > - Is .config/systemd/user created? (Maybe it has to be created manually) Yes, I've dropped there the timer and service file. > - Does the second user have dbus started correctly? (for instance, does >

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

Hi Bjoern, > I'm trying to create a systemd timer for a user to run duply daily. For > one user the enabled worked fine, but another one: > > systemctl --user enable backup.timer > Failed to connect to bus: No such file or directory > > I have no clue why this happens, systemctl daemon-reload (a

Re: [arch-general] systemd-suspend hangs from time to time

Hi, > > from time to time, systemd-suspend hangs on my Thinkpad X140e. After > starting a suspend (through e.g. closing the lid), the following happens: > > For the record: The issue was caused by setting any other alpm policy than "max_performance" (Redhat has a bugreport for it: https://bugzi

Re: [arch-general] systemd permissions on run?

Related bug: https://bugs.archlinux.org/task/56828 The issue is caused because systemd assumes that nobody user have the UID 65534, but in Arch Linux it have the UID 99. Temporally fix is do a `chown 65534` to the file. And take note that the `ls -l` command shows nobody with UID 99 and 65534 (ye

Re: [arch-general] systemd permissions on run?

I will be out of the office from January until March. If you need immediate assistance please contact the office. Kind Regards,

Re: [arch-general] systemd permissions on run?

On Fri, Feb 02, 2018 at 11:23:34AM +0800, Oon-Ee Ng via arch-general wrote: > On Fri, Feb 2, 2018 at 9:40 AM, Oon-Ee Ng wrote: > > > Did something change recently w.r.t this? I have smbd, postgresql, and > > squid all failing on me with the following error:- > > > > systemd[1]: smbd.service: Perm

Re: [arch-general] systemd permissions on run?

Hi, I'm enjoying a holiday at sea and will be off the grid until the end of month! I'll get back to you that week. You could also reach out to my colleagues via the support mail. Thanks for your patience and talk to you then! Best regards,

Re: [arch-general] systemd permissions on run?

On Fri, Feb 2, 2018 at 9:40 AM, Oon-Ee Ng wrote: > Did something change recently w.r.t this? I have smbd, postgresql, and > squid all failing on me with the following error:- > > systemd[1]: smbd.service: Permission denied while opening PID file or > unsafe symlink chain: /var/run/smbd.pid > syst

Re: [arch-general] systemd permissions on run?

Hello, Thank you for your mail. I will answer as fast as possible.

Re: [arch-general] systemd - move to base group and expect it to be installed?

On 09/19/2017 09:36 PM, Marc Boocha via arch-general wrote: > I am unable to send to arch-dev-public for some reason so i am send my > reply to arch general. You need to be whitelisted to post on arch-dev-public, since its purpose is to offer a publicly *readable* medium for the Developers, Truste

Re: [arch-general] systemd - move to base group and expect it to be installed?

I am unable to send to arch-dev-public for some reason so i am send my reply to arch general. I think the filesystem can be split, the sysuser/tempfile will be in the independent package. I do believe we seriously need a meta package for some parts of base. Systemd, Glibc, PAM, Filesystem, Coreuti

Re: [arch-general] systemd on bios computer

It turns out that package was installed, thanks for the info and help. On Wed, 5 Jul 2017, Jude DaShiell wrote: Date: Wed, 5 Jul 2017 21:36:37 From: Jude DaShiell Reply-To: General Discussion about Arch Linux To: Eli Schwartz via arch-general Subject: Re: [arch-general] systemd on bios

Re: [arch-general] systemd on bios computer

i Schwartz via arch-general >> To: arch-general@archlinux.org >> Cc: Eli Schwartz >> Subject: Re: [arch-general] systemd on bios computer >> >> On 07/04/2017 02:52 PM, Jude DaShiell wrote: >>> When doing a systemd upgrade I get: >>> (3/7) Upgrading sys

Re: [arch-general] systemd on bios computer

To: arch-general@archlinux.org Cc: Eli Schwartz Subject: Re: [arch-general] systemd on bios computer On 07/04/2017 02:52 PM, Jude DaShiell wrote: When doing a systemd upgrade I get: (3/7) Upgrading systemd-boot... Couldn't find EFI system partition. It is recommended to mount it to /boot

Re: [arch-general] systemd on bios computer

On 07/04/2017 02:52 PM, Jude DaShiell wrote: > When doing a systemd upgrade I get: > (3/7) Upgrading systemd-boot... > Couldn't find EFI system partition. It is recommended to mount it to > /boot. Alternatively, use --path= to specify path to mount point. > error: command failed to execute correct

Re: [arch-general] systemd on bios computer

Jude DaShiell on Tue, 2017/07/04 14:52: > When doing a systemd upgrade I get: > (3/7) Upgrading systemd-boot... > Couldn't find EFI system partition. It is recommended to mount it to > /boot. Alternatively, use --path= to specify path to mount point. > error: command failed to execute correctly >

Re: [arch-general] systemd on bios computer

On 07/04/2017 01:52 PM, Jude DaShiell wrote: > When doing a systemd upgrade I get: > (3/7) Upgrading systemd-boot... > Couldn't find EFI system partition. It is recommended to mount it to > /boot. Alternatively, use --path= to specify path to mount point. > error: command failed to execute correctl

Re: [arch-general] systemd on bios computer

Just ignore this error, as it is irrelevant to your machine. W dniu 04.07.2017 o 20:52, Jude DaShiell pisze: > When doing a systemd upgrade I get: > (3/7) Upgrading systemd-boot... > Couldn't find EFI system partition. It is recommended to mount it to > /boot. Alternatively, use --path= to specify

Re: [arch-general] systemd latest upgrade

about Arch Linux To: General Discussion about Arch Linux Subject: Re: [arch-general] systemd latest upgrade On 01/31/17 at 04:18pm, Jude DaShiell wrote: For the last several systemd upgrades an error complaining about a missing uefi directory has come out when those upgrades were being inst

Re: [arch-general] systemd latest upgrade

On 01-02-17 10:12, Jelle van der Waa wrote: On 01/31/17 at 04:18pm, Jude DaShiell wrote: However any package install now finishes with the message: Arming ConditionNeedsUpdate That's just a pacman hook to touch /var, for the recent CVE issue in systemd [1] [2] [1] https://git.archlinux

Re: [arch-general] systemd latest upgrade

On 01/31/17 at 04:18pm, Jude DaShiell wrote: > For the last several systemd upgrades an error complaining about a missing > uefi directory has come out when those upgrades were being installed. Today > that happened too. No clue > However any package install now finishes with the > message: > Arm

Re: [arch-general] Systemd services start by default

Op 8 dec. 2016 02:53 schreef "sivmu" : > > Am 08.12.2016 um 02:01 schrieb Leonid Isaev: > > On Wed, Dec 07, 2016 at 11:56:25PM +0100, sivmu wrote: > >> [...] Systemd happened! > >> Or rather systemd-resolved and the systemd time sync daemon. [...] > Thats concerning... > Maybe someone else has not

Re: [arch-general] Systemd services start by default

On 2016-12-07 23:56, sivmu wrote: > Today I noticed there were network services running on my system. > I DON'T have have permanently running network services. > WTF happened? Systemd happened! > Or rather systemd-resolved and the systemd time sync daemon. > > It seems that a recent update set tho

Re: [arch-general] Systemd services start by default

Am 08.12.2016 um 02:01 schrieb Leonid Isaev: > On Wed, Dec 07, 2016 at 11:56:25PM +0100, sivmu wrote: >> Today I noticed there were network services running on my system. >> I DON'T have have permanently running network services. >> WTF happened? Systemd happened! >> Or rather systemd-resolved an

Re: [arch-general] Systemd services start by default

On Wed, 7 Dec 2016 18:01:59 -0700, Leonid Isaev wrote: >resolved and timesyncd are not enabled in systemd 232-6 Neither in 232-4 from core.

Re: [arch-general] Systemd services start by default

On Wed, Dec 07, 2016 at 11:56:25PM +0100, sivmu wrote: > Today I noticed there were network services running on my system. > I DON'T have have permanently running network services. > WTF happened? Systemd happened! > Or rather systemd-resolved and the systemd time sync daemon. > > It seems that a

Re: [arch-general] Systemd services start by default

On Wed, 7 Dec 2016 23:56:25 +0100, sivmu wrote: >Today I noticed there were network services running on my system. What network services? How could I check this? [rocketmouse@archlinux ~]$ grep systemd /var/log/pacman.log | tail -4 [2016-12-01 12:53] [ALPM] upgraded libsystemd (231-4 -> 232-4) [2

Re: [arch-general] Systemd services start by default

On Wed, 7 Dec 2016 23:56:25 +0100 sivmu wrote: > Today I noticed there were network services running on my system. > I DON'T have have permanently running network services. > WTF happened? Systemd happened! > Or rather systemd-resolved and the systemd time sync daemon. > > It seems that a recent

Re: [arch-general] systemd-boot ignores loader.conf

On Mon, 14 Nov 2016 23:25:45 +0100 Tung Anh Vu via arch-general wrote: > I managed to make the boot menu screen not appear by holding the minus key > down to 0 second timeout in the boot menu itself. > Thanks everyone, especially David Thurstenson. > > PS: I still have no idea, why does systemd-

Re: [arch-general] systemd-boot ignores loader.conf

I managed to make the boot menu screen not appear by holding the minus key down to 0 second timeout in the boot menu itself. Thanks everyone, especially David Thurstenson. PS: I still have no idea, why does systemd-boot ignore the timeout setting from loader.conf, but obeys the rest. On Mon, Nov

Re: [arch-general] systemd-boot ignores loader.conf

timeout 0 <-- in loader.conf 1st line default arch <-- in loader.conf 2nd line On 11/14/2016 12:58 PM, David Thurstenson via arch-general wrote: On Mon, Nov 14, 2016 at 12:55 PM, Tung Anh Vu via arch-general wrote: Exactly. I'm successfully booting, so the /boot/loader/entries/arch.conf is pre

Re: [arch-general] systemd-boot ignores loader.conf

I just tried and it didn't help. Just in case, is the location /boot/loader/loader.conf correct? Also, do I need to explicitly reload the conf file using some bootctl command? On Mon, Nov 14, 2016 at 7:58 PM, David Thurstenson via arch-general < arch-general@archlinux.org> wrote: > Try setting "t

Re: [arch-general] systemd-boot ignores loader.conf

On Mon, Nov 14, 2016 at 12:55 PM, Tung Anh Vu via arch-general wrote: > Exactly. I'm successfully booting, so the /boot/loader/entries/arch.conf is > present and appears to be correct. > My problem is, that I'm trying to make the boot menu to *not* appear, but > without any success. Try setting "

Re: [arch-general] systemd-boot ignores loader.conf

Exactly. I'm successfully booting, so the /boot/loader/entries/arch.conf is present and appears to be correct. My problem is, that I'm trying to make the boot menu to *not* appear, but without any success. On Mon, Nov 14, 2016 at 7:47 PM, David Thurstenson via arch-general < arch-general@archlinux

Re: [arch-general] systemd-boot ignores loader.conf

On Mon, Nov 14, 2016 at 12:39 PM, Zachary Kline wrote: > Hello, > > I think the boot menu will still appear, because the default boot entry just > indicates which OS will be booted after the timeout. It doesn’t stop the menu > from appearing, or you couldn’t pick another OS easily. > Best, > Zac

Re: [arch-general] systemd-boot ignores loader.conf

Hello, I think the boot menu will still appear, because the default boot entry just indicates which OS will be booted after the timeout. It doesn’t stop the menu from appearing, or you couldn’t pick another OS easily. Best, Zack. > On Nov 14, 2016, at 10:02 AM, Tung Anh Vu via arch-general > w

Re: [arch-general] systemd-boot ignores loader.conf

https://wiki.archlinux.org/index.php/systemd-boot#Adding_boot_entries Probably missing /boot/loader/entries/arch.conf -Original Message- From: arch-general [mailto:arch-general-boun...@archlinux.org] On Behalf Of Tung Anh Vu via arch-general Sent: Monday, November 14, 2016 12:03 PM To: a

Re: [arch-general] systemd problems

Hello David, Am 13.10.2016 um 14:51 schrieb David Runge: Hello Peter, [...] blueman-applet doesn't show any bluetooth devices and doesn't even search for those. Hm, does it show your builtin hardware in the "Adapter" menu? If so, you're all set to go, just have to make your computer visible

Re: [arch-general] systemd problems

Hello Peter, On 2016-10-13 13:33:27 (+0200), Peter Nabbefeld wrote: > Okt 13 05:05:47 tuchola systemd[1]: Starting Bluetooth service... > Okt 13 05:05:48 tuchola bluetoothd[485]: Bluetooth daemon 5.41 > Okt 13 05:05:48 tuchola systemd[1]: Started Bluetooth service. > Okt 13 05:05:48 tuchola blueto

Re: [arch-general] systemd problems

Hello David, Am 13.10.2016 um 13:04 schrieb David Runge: Hey again, On 2016-10-13 12:01:42 (+0200), Peter Nabbefeld wrote: I've got problems with bluetooth (service does not start), which seem to be caused by systemd problems, as several services are "dead". you might want to check the log ou

Re: [arch-general] systemd problems

Hey again, On 2016-10-13 12:01:42 (+0200), Peter Nabbefeld wrote: > > > I've got problems with bluetooth (service does not start), which seem to > > > be > > > caused by systemd problems, as several services are "dead". > > you might want to check the log output of those services then. What does

Re: [arch-general] systemd problems

Hi David, Am 13.10.2016 um 11:35 schrieb David Runge: Hi Peter, On 2016-10-13 08:37:13 (+0200), Peter Nabbefeld wrote: Hello, I've got problems with bluetooth (service does not start), which seem to be caused by systemd problems, as several services are "dead". you might want to check the l

Re: [arch-general] systemd problems

Hi Peter, On 2016-10-13 08:37:13 (+0200), Peter Nabbefeld wrote: > > Hello, > > I've got problems with bluetooth (service does not start), which seem to be > caused by systemd problems, as several services are "dead". you might want to check the log output of those services then. > > Output of

Re: [arch-general] systemd user accounts are created in a inconsistent way

Op 2 feb. 2016 22:24 schreef "Damjan Georgievski" : > it's better to let `systemd-sysusers` create all users, /etc/passwd > should probably not be included in any package > since it changes in the lifetime of the distro and updates are hard to merge. Agreed. And while we're at it, stop packaging /

Re: [arch-general] systemd user accounts are created in a inconsistent way

On 2 February 2016 at 21:28, Daniel Milewski wrote: > Most systemd user accounts are present in the /etc/passwd file provided > by the filesystem package. This is not the case for only two of them, > namely systemd-journal-upload and systemd-journal-remote, which are set > up by systemd-sysusers,

Re: [arch-general] systemd user unit files from custom directory

On Sat, Jan 30, 2016 at 2:22 PM, Andre "Osku" Schmidt wrote: > On Sat, Jan 30, 2016 at 1:41 PM, Damjan Georgievski wrote: >> On 30 January 2016 at 12:48, Andre "Osku" Schmidt >> wrote: >>> hello, >>> >>> thought i'd ask here first, in case it's a distro problem. >>> >>> was wondering if we can u

Re: [arch-general] systemd user unit files from custom directory

On Sat, Jan 30, 2016 at 1:41 PM, Damjan Georgievski wrote: > On 30 January 2016 at 12:48, Andre "Osku" Schmidt > wrote: >> hello, >> >> thought i'd ask here first, in case it's a distro problem. >> >> was wondering if we can use systemd to start and stop a daemon for >> testing purposes during de

Re: [arch-general] systemd user unit files from custom directory

On 30 January 2016 at 12:48, Andre "Osku" Schmidt wrote: > hello, > > thought i'd ask here first, in case it's a distro problem. > > was wondering if we can use systemd to start and stop a daemon for > testing purposes during development. meaning, i would like to not have > to "install" my daemon

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On Thu, Nov 12, 2015 at 07:52:20PM +0100, Bennett Piater wrote: > > I mostly just use LAN when I need to download a lot of stuff at home, > because WIFI is much slower even at 54 Mb/s, especially since my home > network is 1 Gbps. So I could just turn WIFI off in those cases, that > would be an ac

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

> Well, it depends on whether wlan0 and eth0 are on different networks. If > they are, then the answer is yes, and you are screwed. > > If both interfaces get the same ip, then you can maintain persistent > connection. For example, let's assume that you constantly switch between > different interf

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On Thu, Nov 12, 2015 at 12:30:36PM +0100, Bennett Piater wrote: > > Say you start out on wifi, and open an ssh connection. Then you plug in > > ethernet. The ssh session will remain on the wifi route until it is > > closed. There's no way* to make an existing connection "jump ship" from > > one rou

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

> Say you start out on wifi, and open an ssh connection. Then you plug in > ethernet. The ssh session will remain on the wifi route until it is > closed. There's no way* to make an existing connection "jump ship" from > one route to another. If you were to disable the wifi connection as soon > as t

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On Wed, Nov 11, 2015 at 09:47:25AM +0100, Bennett Piater wrote: > Hello! > I installed Arch on my new Thinkpad T450s over the weekend. > Everything works well, but I have a question: > > I use systemd-networkd to manage my network interfaces and netctl for > the connections. I set everything up ac

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On Wed, Nov 11, 2015 at 16:06:18 +0100, Bennett Piater wrote: > They have different metrics as per the example from the wiki. > > However, no wiki article or manpage that I encountered explained what > exactly the metric does. Could you explain that to me? > > Cheers, > Bennett > > > If there ar

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

ip route get 8.8.8.8 ip route get 7.7.7.7 will show the routes for those ip addresses. you can check several to see where they go (in case the 2 default routes have the same metric) On 11 November 2015 at 14:38, Andrew Von Stein <16vo...@gmail.com> wrote: > Expanding on the ip route command, you

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

Expanding on the ip route command, you can you see what interface is used to reach the Internet by looking at the default route. The entry that has the destination as 0.0.0.0 and the subnet mask as 0.0.0.0 is the default route. If your LAN is shown above your wifi interface I'm going to assume that

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

> I don't use netctl, but you can usually see what default route it uses with > > ip route Thanks for that, I didn't know that command. The LAN is shown above WIFI, which (I assume) means that it takes precedence. > > I have made the experience that newly configured interfaces "steal" the

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On Wed, Nov 11, 2015 at 09:35:05 +, Ben Oliver wrote: > On 11 November 2015 at 09:18, Ludwig Zins wrote: > > > On 11/11/15 09:47, Bennett Piater wrote: > > > Hello! > > > I installed Arch on my new Thinkpad T450s over the weekend. > > > Everything works well, but I have a question: > > > > >

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On 11 November 2015 at 09:18, Ludwig Zins wrote: > On 11/11/15 09:47, Bennett Piater wrote: > > Hello! > > I installed Arch on my new Thinkpad T450s over the weekend. > > Everything works well, but I have a question: > > > > I use systemd-networkd to manage my network interfaces and netctl for >

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

On 11/11/15 09:47, Bennett Piater wrote: > Hello! > I installed Arch on my new Thinkpad T450s over the weekend. > Everything works well, but I have a question: > > I use systemd-networkd to manage my network interfaces and netctl for > the connections. I set everything up according to (this)[0] an

Re: [arch-general] systemd-logind: failed to get session

Wed, 23 Sep 2015 09:09:06 +0200 Ralf Mardorf : > What could be the reason? It's Xorg, run from the login manager, of course it doesn't belong to any session. Same here with sddm. --byte pgphG4mvcGxv_.pgp Description: Digitale Signatur von OpenPGP

Re: [arch-general] systemd-networkd 226 in virtual machines

or maybe net.ifnames=0 on the kernel command line to completely disable network interface renaming. W dniu 09.09.2015 o 17:34, Damjan Georgievski pisze: in 226, systemd-networkd now supports predictable interface names for virtio devices.[1] For people running Arch in KVM with virtio-net (as I

Re: [arch-general] systemd new dependencies impede using OpenRC

> I interpreted this thread as a bug report with 'The Arch Way' page on > the wiki so it hasn't been for naught. That page has been rewritten to > better reflect what has always been the development philosophy instead > of being a vague advertisement for the distribution with questionable > claims.

Re: [arch-general] systemd new dependencies impede using OpenRC

While technical debate can be productive when it's not simply rehasing the same things over and over again, simply voicing opinions is not. I don't think it would be a good idea to develop any distribution based upon the opinions of whoever shouts the loudest. Decisions are made based on consensus

Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 18:46 GMT-03:00 Daniel Micay : > > Now, it would be technically possible to replace *systemd* in base with a > > generic "init-system" which could be provided by both *systemd* and > *openrc*, > > but that would make things much more complicated and *much* more effort > to > > maintain.

Re: [arch-general] systemd new dependencies impede using OpenRC

On Fri, Jul 3, 2015 at 4:10 PM, Geoff wrote: > On Fri, 3 Jul 2015 16:51:21 +0200 > Bardur Arantsson wrote: > > > > STOP! > > Although I find the discussion interesting, I have watched with growing > amazement. As I recall, this list became moderated due to the furore when > systemd was introdu

Re: [arch-general] systemd new dependencies impede using OpenRC

On Fri, 3 Jul 2015 16:51:21 +0200 Bardur Arantsson wrote: > STOP! Although I find the discussion interesting, I have watched with growing amazement. As I recall, this list became moderated due to the furore when systemd was introduced, and I doubt that Lennart himself could have got a post on

Re: [arch-general] systemd new dependencies impede using OpenRC

On 07/03/2015 04:31 PM, Tobias Hunger wrote: > To be fair: There is more to here than "Unix philosophy" and "I hate Lennart". > STOP! Can we please end this discussion now? This no longer has anything to do with Arch Linux and is just spam (for this list) at this point. I'm sure people who are

Re: [arch-general] systemd new dependencies impede using OpenRC

To be fair: There is more to here than "Unix philosophy" and "I hate Lennart". Number 1 is "systemd is a monolithic mess" and reveals a glaring misunderstanding of layered architectures. He is basically claiming that kernel/xorg/browser is one mess since the browser won't start without the kernel

Re: [arch-general] systemd new dependencies impede using OpenRC

I can't overtly fault the logic in that blog post for the most part. However he does still basically toe the "Unix philosophy" line (Talking about modularity and such.) The thing that bothers me most about this document though is how he dismisses systemd's legitimate, if not unique, features as "p

Re: [arch-general] systemd new dependencies impede using OpenRC

On Fri, Jul 3, 2015 at 1:10 PM, LoneVVolf wrote: > This blog post gives the best description of systemd flaws i am aware of : > http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html That is one of the worst descriptions of problems in systemd that I am aware of:-) The author comp

Re: [arch-general] systemd new dependencies impede using OpenRC

On Jul 3, 2015 6:10 AM, "LoneVVolf" wrote: > > Some general comments : > > - Openrc is a replacement for sysv init, not an addition. > OpenRC runs on SysV Init last I checked, as OpenRC is just highly polished initscripts. How is that a replacement instead of an addition? > - openrc has it's own

Re: [arch-general] systemd new dependencies impede using OpenRC

Some general comments : - Openrc is a replacement for sysv init, not an addition. - openrc has it's own equivalent of .service files, they are simpler then systemd servicefiles - my personal opinion about openrc is that it's not mature enough yet for majority of linux users to replace system

Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 6:45 GMT+02:00 Yaro Kasear : > > I wouldn't mind some spiritual successor to systemd where its entire > purpose is to be init, without sacrificing some of the more useful/powerful > features like cgroups, concurrency, and the like. Systemd went wrong when > it started going into stuff th

Re: [arch-general] systemd new dependencies impede using OpenRC

I personally prefer systemd over the alternatives. I grant there's considerable feature creep, but the people who complain a lot either don't offer an alternative, or the one alternative they offer is the frankly broken system Linux had been using since the dawn of time. I wouldn't mind some spiri

Re: [arch-general] systemd new dependencies impede using OpenRC

On 07/03/2015 12:19 AM, Daniel Micay wrote: >> WHAT? The opinion of users has no weight here ?!?!?! > [--snip--] Just to add a little bit to what Daniel said: Can we please calm down a bit here? It's not like there's no overlap between what developers want and what ordinary users want -- in fact

Re: [arch-general] systemd new dependencies impede using OpenRC

> WHAT? The opinion of users has no weight here ?!?!?! Popular opinion has no weight. Zero. Technical arguments have weight but most of them have already been debated for ages. There's a strong consensus among the developers (and trusted users / other people who contribute, but that's less importa

Re: [arch-general] systemd new dependencies impede using OpenRC

> Now, it would be technically possible to replace *systemd* in base with a > generic "init-system" which could be provided by both *systemd* and *openrc*, > but that would make things much more complicated and *much* more effort to > maintain. Packages don't have a dependency on systemd because t

Re: [arch-general] systemd new dependencies impede using OpenRC

On 02/07/15 02:34 PM, Neven Sajko wrote: > Daniel Micay dixit: >> The package isn't going to be split so it doesn't make much sense to >> refer to libsystemd. > > It is split: > https://www.archlinux.org/packages/core/x86_64/libsystemd/ I know it's split into systemd, libsystemd and systemd-sysvc

Re: [arch-general] systemd new dependencies impede using OpenRC

It is very simple. The bare minimum Arch install consist of the base group. The user *must* install this group. If they don't, they no longer have a minimal Arch install, so developers cannot help them. It is the *base* and everything else builds on

  1   2   3   4   5   6   7   >