Bug#1051401: general: PATH variable definition in debian 12
On 9/7/23 14:59, robin hodges wrote: Had a problem when I installed debian 12 onto my PC. As root the reboot and shutdown commands wouldnt work. I have solved this on my PC by including the following into the root .bashrc file export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin Did you login as root by typing "su" instead of "su --login"? If yes, this is normal behavior, check "man su": "It is recommended to always use the --login option" -Timo
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
On 5/24/22 21:34, Paul Gevers wrote: https://bugs.debian.org/1011268 (but apparently my first assumption was wrong and it's another bug, most likely Simon was right. Thanks for the link. I was quite puzzled this morning when I saw several removals messages. I guess I should just wait and hope that the removals don't actually happen. -Timo
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
Hi, On Fri, 3 Dec 2021, Florian Weimer wrote: No objects to /usr/bin/ld.so then? Just a random thought: If you have configured a restricted shell (e.g. rbash) that only lets you execute commands in PATH, will this make it possible to bypass the restriction with "ld.so /tmp/some-random-binary"? This is not necessary an argument to not do this, I'm just wondering what the implications could be. -Timo
Re: Making Debian available
On Mon, 18 Jan 2021, Marc Haber wrote: My understanding is that the live images are primarily intended for the typical "live system" use-case descended from things like Knoppix (boot machine from USB stick or optical media; use machine with OS from RAM, USB stick or optical media; shut down machine; no trace is left), with permanent installation via Calamares being considered somewhat experimental. Ah indeed. My comment was a more abstract observation: if you can run the installer in a more familiar environment it is easier for users. I did not intend to say anything about the current state of any package or team. I remember installing Debian once from a live image because the only network I had available was using 802.1x. Must have been a rather painless experience, since I don't remember much trouble about it. I've also used it a couple of times. The only worry I have is that I end up with an installation that is different from d-i installations in some subtle way that will cause me to hit some weird bug in the future. I had similar problems with virt-install. I had to add all sorts of extra hacks to produce installations that were as identical to manual installations as possible. https://lindi.iki.fi/lindi/debian10/server has my notes on how to do this with a server and https://lindi.iki.fi/lindi/debian10/ is an attempt to do it for desktop as well. Basically I first installed debian manually. Then I automated it and tweaked preseed and a custom shell script until the filesystem difference was minimal.
Re: Making Debian available
On Sun, 17 Jan 2021, Marc Haber wrote: Absolutely. The Installation Experience is one of the first contacts with the distribution for most people¹, and since we all know that the Yep. I think using the live environment for installation could be more user-friendly as the user is already familiar with how to use e.g. USB drive or browser during the installation if they need to search for help or copy some additional firmware files. The number of people who know how to do this in the current d-i images is much lower since you'd need to use the command-line with a really restricted set of tools.
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On Sun, 28 Jun 2020, Jaime wrote: Given that this is guaranteed to fail, isn't it worth "not doing"? Is there anyway that I can get dhclient to wait for a successful connection *before* sending out any DHCPDISCOVERs? (In the wired world, it doesn't make sense to issue a DHCPDISCOVER before plugging the cable in.) NetworkManager should be at least one such way. When the funciton supplicant_iface_state_cb is called with state NM_SUPPLICANT_INTERFACE_STATE_COMPLETED it will call nm_device_activate_schedule_stage3_ip_config_start that will end up starting dhclient only when wpa_supplicant has done its job. At least last time I tried using ifupdown for wifi I hit all sorts of odd race conditions that probably still exist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587634
Re: Is an init required to obey policy-rc.d during boot ?
On Thu, 23 Apr 2020, Thomas Goirand wrote: doesn't exist but will proceed) - apt install foo (shipping a foo.service) → foo.service will not be started Good to know, thanks! Is https://www.freedesktop.org/software/systemd/man/systemd.preset.html perhaps something that could help here? -Timo
Re: default firewall utility changes for Debian 11 bullseye
On Wed, 31 Jul 2019, Adam Borowski wrote: A network firewall is useful. But why would someone want a _host_ firewall for on any sane operating system? If a daemon is not supposed to listen on Are libvirt and network-manager using firewalld to setup network sharing and virtual networks? Or do the still invoke iptables directly?
