How to suppress/handle junction points in CIFS-mounting Windows 7 shares on Linux?

[Daniel Barclay]

When mounting a Windows 7 share on Linux, how *can Windows junction points be 
suppressed* (or otherwise handled so that one that points up to a containing 
directory can't cause an endless loop)?

For example, the (standard, Windows-created) junction point at "C:\Users\someuser\Application 
Data\" links back up to "C:\Users\someuser\".

When I try to mount C: on Linux and run a command that recursively traverses 
down subdirectories (e.g., find, du) the command iterates through (the Linux 
pathnames for):

 * C:\Users\someuser\Application Data\
 * C:\Users\someuser\Application Data\Application Data\
 * C:\Users\someuser\Application Data\Application Data\Application Data\
 * etc.

until hitting some limit and then hanging.

Apparently, Linux and/or the commands see the junction point as a regular 
directory, not recognizing it as a symbolic link or other structure that can 
cause a filesystem traversal loop.

(In Windows Explorer, the junction point shows up as a folder that can't be opened 
("Access is denied"). In CygWin on Windows, the junction point seems to show up 
as a regular Unix symlink, so the find command normally skips it, and even with -follow 
specified, find can recognize and cut the traversal loop.)

So, *how can junction point be suppressed or handled?*  Is there any way to:
- Tell *Windows to suppress* reporting *junction points* as directories?
- Get *Linux*'s CIFS mounting to recognize junction points and *present them as 
symbolic links?*
- Get *Linux*'s CIFS mounting to recognize junction points and simply 
*suppr**ess them?*

(I've tried with both the administrative share for C: (C$) and a user-created 
share of C:.)

Thanks,
Daniel

Re: where does `hostname -f` derive the domainname from?

[Vincent Lefevre]

On 2022-06-26 21:07:13 +, tuxi...@posteo.de wrote:
> I checked using strace and it's appearently going through the following:
> 
> 1. uname

This is due to the call to gethostname(), as seen with "hostname"
without any option.

The following is due to the call to getaddrinfo() on the node name
and depends on the system.

> 2. /run/nscd/socket

I don't have that. You may have nscd or unscd installed.

> 3. /etc/nsswitch.conf

I suppose that this is usual.

> 4. /etc/resolv.conf
> 5. /etc/hosts

I think that both are read because getaddrinfo() does more than
what is actually needed for "hostname -f" (only /etc/hosts should
be sufficient with a usual configuration).

On my machine, there's also "/etc/host.conf".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Digikam busted on bullseye.

[gene heskett]

On 6/26/22 15:40, Brian wrote:

On Sun 26 Jun 2022 at 15:13:35 -0400, gene heskett wrote:


Greetings all;

I've run out of patience with digikams inability to see existing
albums, or to create a new one. That is disabling its importing
from the camera, making me take the card out and put it in a
reader.

Questions to this list have not been helpful.

You said it :)! How about the answers?

They were from folks who obviously were not digikam users, so not all
that helpful. suggesting script based solutions. They meant well but did
not actually address the problem.

One item of note, there's very little I can run from a console that doesn't
log these two errors:
tk-Message: 17:10:28.754: Failed to load module 
"window-decorations-gtk-module"

Gtk-Message: 17:10:28.754: Failed to load module "colorreload-gtk-module"

but goes ahead and runs ok anyway. Searching for them in synaptic isn't 
fruitfull.
But I  have the feeling that fixing that will not  fix digikam. The 
error it spits out
on a console is pointing at the old install on /media/sda5 which I can't 
find a way to
 redirect to the present copy of that dir but on my /home raid10, which 
not mounted
in this boot because both are links to this raid10. Or something like 
that, but ALL the
album related buttons are ghosted, inactive, so no way to make a new 
album exists.

What mailing list do I complain on?

https://www.digikam.org/support/

But you do not neend to moan or complain. Act out of character
and request help in a reasonable way :).
At my age, that would indeed be out of character.  I subbed to their 
list above  so we'll

see what that might provide.

Thank you.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Has anybody replaced pulseaudio with pipewire on Debian 11...

[Vincent Lefevre]

On 2022-06-25 09:55:00 +0100, Ottavio Caruso wrote:
> I have some BT headphones (Anker Soundcore Q30) which work beautifully on
> Android devices but are an absolute pain on Debian 11.
> 
> I have to constantly "reinstall -- purge" the whole bluethooth/pulseaudio
> stack to make it work and I have tried all other tricks in the book.
> 
> It looks like completely replacing pa with pipewire makes sense on Ubuntu. I
> wonder if anybody has anecdotal experience of nuking pulseaudio and
> installing pipewire on Debian Stable and if that makes things better with
> regards to bluetooth audio.

Last year, pulseaudio was automatically replaced by pipewire for a few
days, and my BT headphones no longer worked correctly due to

  https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/267

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Digikam busted on bullseye.

[Andrew M.A. Cater]

On Sun, Jun 26, 2022 at 03:13:35PM -0400, gene heskett wrote:
> Greetings all;
> 
> I've run out of patience with digikams inability to see existing
> albums, or to create a new one. That is disabling its importing
> from the camera, making me take the card out and put it in a
> reader.
> 

If digikam is punching your buttons - apt-get remove it and purge it.
There are always other applications to try. I know you prefer TDE
but you've had the issues with installing TDE.

Complaining about digikam to upstream developers may or may not be
helpful.

> Questions to this list have not been helpful.
> 
> What mailing list do I complain on?
> 

This one, sometimes :)

> Thanks all.
> 
> Cheers, Gene Heskett.
> 
All the very best, as ever,

Andy Cater

> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
> 

Re: where does `hostname -f` derive the domainname from?

[tuxifan]

On Sonntag, 26. Juni 2022 22:32:38 CEST Jim Popovitch wrote:
> where does `hostname -f` derive the domainname from?
> 
> I have 2 systems, the first was buster --> bullseye with /etc/hostname
> containing "oscar" and `hostname -f` returning "oscar.domain.tld".
> 
> The second system is a clean install of bullseye with /etc/hostname
> containing "felix".  On this system `hostname -f` returns "felix".
> 
> DNS for both systems have FQDN entries.  Where should the domainname be
> set in a clean fresh install of bullseye?
> 
> tia,
> 
> -Jim P.

I checked using strace and it's appearently going through the following:

1. uname
2. /run/nscd/socket
3. /etc/nsswitch.conf
4. /etc/resolv.conf
5. /etc/hosts

Tuxifan

Re: where does `hostname -f` derive the domainname from?

[Jim Popovitch]

On Sun, 2022-06-26 at 16:52 -0400, Greg Wooledge wrote:
> Both sections are vague and murky about what happens if you *don't* have
> an entry for your hostname in /etc/hosts.
> 
> Fortunately, Debian adds a line exactly like this in /etc/hosts, for
> your hostname with your "DNS domain name" (the one you specified during
> installation) attached.  So you rarely ever have to worry about what
> happens if this entry is missing.

That was the problem.  The bullseye-only system had an /etc/hosts entry
without a FQDN.  I removed that and it uses the one in DNS.  


Thanks for the very thoughtful and detailed insight Greg.

-Jim P.

Re: where does `hostname -f` derive the domainname from?

[Greg Wooledge]

On Sun, Jun 26, 2022 at 04:32:38PM -0400, Jim Popovitch wrote:
> where does `hostname -f` derive the domainname from?

Start with the man page, always.

   -f, --fqdn, --long
  Display  the FQDN (Fully Qualified Domain Name). A FQDN consists
  of a short host name and the DNS domain name. Unless you are us‐
  ing bind or NIS for host lookups you can change the FQDN and the
  DNS domain name (which is part of the FQDN)  in  the  /etc/hosts
  file.  See  the warnings in section THE FQDN above und use host‐
  name --all-fqdns instead wherever possible.

So, the initial point is /etc/hosts (as it says in the text).  Now let's
check out the warnings it told us to heed.

   THE FQDN
   [...]
   The  recommended  method of setting the FQDN is to make the hostname be
   an alias for the fully qualified name using /etc/hosts,  DNS,  or  NIS.
   For  example,  if  the  hostname was "ursula", one might have a line in
   /etc/hosts which reads

  127.0.1.1ursula.example.com ursula
   [...]

Both sections are vague and murky about what happens if you *don't* have
an entry for your hostname in /etc/hosts.

Fortunately, Debian adds a line exactly like this in /etc/hosts, for
your hostname with your "DNS domain name" (the one you specified during
installation) attached.  So you rarely ever have to worry about what
happens if this entry is missing.

My understanding is that if you mangle your /etc/hosts file so that there
is no entry of this form, it'll move on to a DNS lookup next (following
the steps outlined in /etc/nsswitch.conf).  A DNS lookup of your short-form
hostname (with no dots in it) would typically apply the domain names
that are specified in /etc/resolv.conf in the "search" entry -- or if there
is no search entry, then the legacy "domain" entry.

If you have also mangled the /etc/nsswitch.conf file so that name lookups
are performed using alternative sources, then you would be the sole person
who knows where to look.

Re: where does `hostname -f` derive the domainname from?

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256





--- Original Message ---
On Sunday, June 26th, 2022 at 2:32 PM, Jim Popovitch  wrote:

> where does `hostname -f` derive the domainname from?

/etc/hosts, I think.

--
Glenn English

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJiuMYUACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDKncAgAsgx3ge8Dz9wuDlENti8KrX0Lktua1pTZVs68v9XKIsLwhna3
HJFYacGh3ykvC7BHdZjzboU+6jRpAdWLWYFKhLk1UsvqRrFR0EAkj77FG+Dm
7ac24b8K0QlmDHZd8Zi+2Wzx+LqZYaph2YVdrrOp0xamWeOa9uVC9VbnP+8R
xGos0+XraP6RNz0A2ZOqBS+uZh/SW7j4FYJLcmq9iICSGqkPi9eQQJz45E7b
533D+KTV+OkVigputRpcUFYB2UpnaFYKm8yjLUBUqSN1NABlWxyVSThClntO
RYtKpidGI6UrWyVp/LPiUV7yP9CepQ+vVNLqM5fb5Ean2nZ0hRXheg==
=XYP/
-END PGP SIGNATURE-

where does `hostname -f` derive the domainname from?

[Jim Popovitch]

where does `hostname -f` derive the domainname from?

I have 2 systems, the first was buster --> bullseye with /etc/hostname
containing "oscar" and `hostname -f` returning "oscar.domain.tld".

The second system is a clean install of bullseye with /etc/hostname
containing "felix".  On this system `hostname -f` returns "felix".

DNS for both systems have FQDN entries.  Where should the domainname be
set in a clean fresh install of bullseye?

tia,

-Jim P.

Re: Digikam busted on bullseye.

[Brian]

On Sun 26 Jun 2022 at 15:13:35 -0400, gene heskett wrote:

> Greetings all;
> 
> I've run out of patience with digikams inability to see existing
> albums, or to create a new one. That is disabling its importing
> from the camera, making me take the card out and put it in a
> reader.
> 
> Questions to this list have not been helpful.

You said it :)! How about the answers?

> What mailing list do I complain on?

https://www.digikam.org/support/

But you do not neend to moan or complain. Act out of character
and request help in a reasonable way :).

-- 
Brian.

Digikam busted on bullseye.

[gene heskett]

Greetings all;

I've run out of patience with digikams inability to see existing
albums, or to create a new one. That is disabling its importing
from the camera, making me take the card out and put it in a
reader.

Questions to this list have not been helpful.

What mailing list do I complain on?

Thanks all.

Cheers, Gene Heskett.

--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Grub Problem

[Stephen P. Molnar]

On 06/25/2022 09:37 AM, Stephen P. Molnar wrote:


I have four hard drives ion my Bullseye platform; Three SSD's and one 
HDD. My current copy of Bullseye is on /dev/sdd1. I have installed a 
pristine copy of Bullsye on /dev/sda.


The installer found the copy of Bullseye on /dev/ssd1 and I installed 
grub on /dev/sda1. At the end of the installation process I removed 
the installationm media from the cdrom drive, rebooted the computer 
and selected /dev/sda1. I got an error message that /dev/sda couldn't 
be found. The good news is that if I hit the reset button on the 
platform the old grub menu comes up and the system boots into the version

on sdd1.

Now, this ROF (retired old fool, althought other terms might be 
aplicable) from the long gone days of punched cards and tape drives 
has been using computers sine the early 1960's, google was not my 
frient in trying to find a solution to the problem.


Assistanc will be mucn appeciated.

Thanks in advance.

-- Stephen P. Molnar, Ph.D. Molecular Modeling 614.312.7528 (c) Skype: 
smolnar1




After much trepidation, sudo update-grub solved the problem

Thanks to those who answered my request.

-- Stephen P. Molnar, Ph.D. Molecular-Modeling 614.312.7528 (c) Skype: 
smolnar1

Re: Proprietary WiFi drivers for live mode

[tomas]

On Sun, Jun 26, 2022 at 11:29:32AM -0500, David Wright wrote:
> I've reinserted the opening line of the post I replied to.
> 
> On Sun 26 Jun 2022 at 17:14:23 (+0200), to...@tuxteam.de wrote:
> > On Sun, Jun 26, 2022 at 09:28:21AM -0500, David Wright wrote:
> > > On Sun 26 Jun 2022 at 09:07:11 (+0200), Hans wrote:
> > > > 
> > > > In your case I would suggest to build your own lifefile system with 
> > > > live-
> > > > build.
> > > > 
> > > > [...]
> > > > 
> > > > I am doing all this, when building kali-linux live-system, which 
> > > > building is 
> > > > almost the same as a debian-live system.
> > > > 
> > > > Give it a try, maybe it helps.
> > > 
> > > Sorry, but I can't see the attraction of a live system, as opposed to
> > > just building the Debian system on a stick. Care to explain?
> > 
> > If I understand correctly, a live system

[...]

> That was my point—we know what the target system is
> here: /the/ old Dell laptop, to be used by a
> non-programming/configuring/commandline-user person.

[...]

> > Both have their uses.
> 
> Agreed, in different circumstances.

I just misunderstood: I took your statement above as absolute,
not relative to the current situation. That way around I totally
agree.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Proprietary WiFi drivers for live mode

[David Wright]

I've reinserted the opening line of the post I replied to.

On Sun 26 Jun 2022 at 17:14:23 (+0200), to...@tuxteam.de wrote:
> On Sun, Jun 26, 2022 at 09:28:21AM -0500, David Wright wrote:
> > On Sun 26 Jun 2022 at 09:07:11 (+0200), Hans wrote:
> > > 
> > > In your case I would suggest to build your own lifefile system with live-
> > > build.
> > > 
> > > [...]
> > > 
> > > I am doing all this, when building kali-linux live-system, which building 
> > > is 
> > > almost the same as a debian-live system.
> > > 
> > > Give it a try, maybe it helps.
> > 
> > Sorry, but I can't see the attraction of a live system, as opposed to
> > just building the Debian system on a stick. Care to explain?
> 
> If I understand correctly, a live system
> 
>  - is thought to cope with a broader range of hardware (meaning: it
>doesn't know exactly which hardware it's going to wake up on next)

That was my point—we know what the target system is
here: /the/ old Dell laptop, to be used by a
non-programming/configuring/commandline-user person.

>  - is not supposed to touch the host system persistent storage (aka
>disks)

That's something we apparently don't have to worry about, as it has no
hard drive, so it can only touch what is deliberately inserted into it
at the time.

>  - is not supposed to scribble on its own medium (unless you've set
>aside a partition for that)

Presumably, the OP will occasionally upgrade the OS-on-the-stick;
perhaps when they notice a point-release on their own machine.

> Perhaps it just has a tmpfs overlaid on its file system, so any change
> is only ephemeral.
> 
> so it is a slightly different usage profile than tailor-fitting a USB
> stick for a given target system.
> 
> Both have their uses.

Agreed, in different circumstances.

On Sun 26 Jun 2022 at 11:47:46 (-0400), Stefan Monnier wrote:
> > Sorry, but I can't see the attraction of a live system, as opposed to
> > just building the Debian system on a stick. Care to explain?
> 
> Speaking as someone who's used such a "Debian system on a stick" as
> a kind of replacement for a Debian live (mostly as a rescue
> environment, really): I suspect the attraction is that Debian Live has
> already been tuned for that use case (I had to make various minor
> changes to fix annoyances when "moving" the stick between systems), and

As above, the stick is for running on just the one, old Dell, laptop.

> more importantly that it shouldn't get corrupted just because you
> unplugged the stick at an "unfavorable" time.
> 
> I've had to "redo" my stick a few times and I strongly suspect it was
> because USB sticks aren't very reliable when it gets to unplugging them
> while in the middle of a write (and a normal Debian install can write
> to your stick without your explicit prompting, of course).

With careful partitioning, the damage can be limited, by making /usr
and /etc readonly, with /var separate, /tmp and any swap in memory, etc.

> Note: this was my experience almost 10 years ago.  Not sure it's
> still relevant.  And technically, I still think a normal Debian install
> tweaked to be more like Debian Live should be superior.

Cheers,
David.

Atomic update failure

[Gunther Furtado]

Bom dia a todos,

Faz bastante tempo que não acompanho as discussões por aqui.

Voltei por que estou com um problema para o qual não achei muitas
referências (só achei um bug report que menciona o erro - 921046):

i915 :00:02.0: [drm] *ERROR* Atomic update failure on pipe (AB),,,

Uso um itautec W7425 com Debian 11 com dois monitores (tenho fixação por
não jogar coisas fora).

As poucas referências que eu li por aí me deram algumas dicas, algumas
diminuíram acentuadamente a freque desse erro no journalctl (de quinze a
vinte por dia, para cinco ou seis). O computador congela por até quinze
segundos, mas raramente tenho que apelar para o Power Button, nesses casos,
não há como entrar na máquina por ssh.

Apliquei as dicas sem muito conhecimento de causa, mantive as que deram
bons resultados:

---
#/usr/share/X11/xorg.conf.d/20-intel.conf
Section "Device"
   Identifier  "Intel Graphics"
   Driver  "intel"
   Option  "AccelMethod"  "sna"
EndSection



GRUB_CMDLINE_LINUX_DEFAULT="... i915.enable_psr=0 i915.modeset=1
i915.enable_dc=0 intel_idle.max_cstate=1 ..."

---

desliguei o touchpad (dica do bug 921046, vai que)

---

O AccelMethod SNA dá muito menos erros que o UXA)

--

O bug deveria ser contra o xserver-xorg-video-intel, certo?

Saudações,


"Mas, afinal, só as criaturas que nunca
escreveram cartas de amor é que são ridículas." Fernando Pessoa

Gunther Furtado
Curitiba - Paraná - Brasil
gunfurt...@gmail.com
sip:furta...@ekiga.net

Re: Proprietary WiFi drivers for live mode

[tomas]

On Sun, Jun 26, 2022 at 09:28:21AM -0500, David Wright wrote:

[...]

> > I am doing all this, when building kali-linux live-system, which building 
> > is 
> > almost the same as a debian-live system.
> > 
> > Give it a try, maybe it helps.
> 
> Sorry, but I can't see the attraction of a live system, as opposed to
> just building the Debian system on a stick. Care to explain?

If I understand correctly, a live system

 - is thought to cope with a broader range of hardware (meaning: it
   doesn't know exactly which hardware it's going to wake up on next)
 - is not supposed to touch the host system persistent storage (aka
   disks)
 - is not supposed to scribble on its own medium (unless you've set
   aside a partition for that)

Perhaps it just has a tmpfs overlaid on its file system, so any change
is only ephemeral.

so it is a slightly different usage profile than tailor-fitting a USB
stick for a given target system.

Both have their uses.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Proprietary WiFi drivers for live mode

[David Wright]

On Sun 26 Jun 2022 at 09:07:11 (+0200), Hans wrote:
> Am Sonntag, 26. Juni 2022, 08:46:02 CEST schrieb Sven Joachim:
> > On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:
> > > I have an old Dell laptop with Broadcom BCM43142 WiFi device
> > > (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
> > > sometimes boot Debian from USB Memory Stick in live mode.
> > > The problem is that WiFi doesn't work because of the proprietary drivers
> > > it needs.
> > 
> > Probably you do not need proprietary drivers for your card, but it
> > requires non-free firmware.  Which on these old Broadcom devices is a
> > PITA, because Broadcom did not make it easily available.
> > 
> > > I tried booting it from live+nonfree image
> > > (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmw
> > > are/11.3.0-live+nonfree/amd64/iso-hybrid/), but still no luck (WiFi
> > > doesn't work). As I understand, the needed drivers would load when
> > > installing the system, but they do not load in live mode.
> > 
> > There is a misunderstanding here.  Debian's non-free images do not
> > contain proprietary drivers, but they provide firmware for the devices,
> > so that the in-kernel drivers can actually work.
> > 
> > If the non-free image does not work, the firmware for your device is
> > missing because of licensing reasons.  There is a package named
> > firmware-b43-installer in contrib which downloads Broadcom's old drivers
> > and extracts the firmware from them. Obviously you need a network
> > connection for that, so you might have to use it on another system.
> > 
> > 1. https://packages.debian.org/bullseye/firmware-b43-installer
> 
> In your case I would suggest to build your own lifefile system with live-
> build.
> 
> Thus you have the opportunity, to add any package you want to it and build in 
> your language, and you can also add packages not availabe in the debian repo.
> 
> If you get your Dell laptop running with some additionally package from the 
> debian repo, then you can add them in your own live-build.
> 
> The original debian livefile does sometimes not include, what you need.
> 
> You might (but this does not always work!), packages fro,m Ubuntu, which are 
> not available in debian. But take care of compabilties, Ubunto sometimes do 
> their own things and packages from Ubuntu might break debian.
> 
> I am doing all this, when building kali-linux live-system, which building is 
> almost the same as a debian-live system.
> 
> Give it a try, maybe it helps.

Sorry, but I can't see the attraction of a live system, as opposed to
just building the Debian system on a stick. Care to explain?

Cheers,
David.

Re: haproxy service retry

[Dan Ritter]

Jeremy Ardley wrote: 
> I have noticed a problem with haproxy on an edge router after a power
> outage.
> 
> The service is configured to start automatically, but usually it takes a bit
> of time for the internet connection to be established and an IP assigned to
> the WAN interface.
> 
> haproxy seems to keep trying for 5 times, but then stops when it still
> hasn't got a properly configured interface to bind with.
> 
> I'm interested in strategies or configuration options to get it to keep
> retrying, perhaps at an extended interval?
> 
> My WAN interface is configured using systemd-networkd (as is my LAN
> interface)

Your start requirement is not "the network is up" but "we can
talk to the Internet".

What's a good proof of that? Perhaps it is being able to contact
something that is so reliable, you expect it always to be
available.

If I were doing this casually, I might decide that one of the
DNS services run by a massively-distributed BGP anycast should
be up all the time, and that getting a good result from 3
consecutive pings is enough to establish that.

The first time I got that after starting, I would call that a
success and start haproxy. If I didn't get that, I would loop
back to pinging three times, not starting haproxy.

Implementation is up to you -- I know how to do this with
sysvinit or daemontools, but not systemd.

-dsr-

haproxy service retry

[Jeremy Ardley]

I have noticed a problem with haproxy on an edge router after a power 
outage.


The service is configured to start automatically, but usually it takes a 
bit of time for the internet connection to be established and an IP 
assigned to the WAN interface.


haproxy seems to keep trying for 5 times, but then stops when it still 
hasn't got a properly configured interface to bind with.


I'm interested in strategies or configuration options to get it to keep 
retrying, perhaps at an extended interval?


My WAN interface is configured using systemd-networkd (as is my LAN 
interface)


--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: Proprietary WiFi drivers for live mode

[didier gaumet]

Le dimanche 26 juin 2022 à 06:27 +0200, Kamil Jońca a écrit :
> piorunz  writes:
> 
> > On 25/06/2022 22:41, Charles Curley wrote:
> > 
> > > There are also USB WiFi adapters, but I cannot recommend any. 
> > > I actually use many of them and they are just fine. Many models
> > > are 100% compatible with Linux and work out of the box without
> > > installing extra drivers.
> 
> Would you be so kind and give us some links?
> 
> KJ

https://linux-hardware.org/?view=search=net%2Fwireless=usb#list

Re: Proprietary WiFi drivers for live mode

[Hans]

Am Sonntag, 26. Juni 2022, 08:46:02 CEST schrieb Sven Joachim:
In your case I would suggest to build your own lifefile system with live-
build.

Thus you have the opportunity, to add any package you want to it and build in 
your language, and you can also add packages not availabe in the debian repo.

If you get your Dell laptop running with some additionally package from the 
debian repo, then you can add them in your own live-build.

The original debian livefile does sometimes not include, what you need.

You might (but this does not always work!), packages fro,m Ubuntu, which are 
not available in debian. But take care of compabilties, Ubunto sometimes do 
their own things and packages from Ubuntu might break debian.

I am doing all this, when building kali-linux live-system, which building is 
almost the same as a debian-live system.

Give it a try, maybe it helps.

Best regards

Hans  

> On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:
> > I have an old Dell laptop with Broadcom BCM43142 WiFi device
> > (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
> > sometimes boot Debian from USB Memory Stick in live mode.
> > The problem is that WiFi doesn't work because of the proprietary drivers
> > it needs.
> 
> Probably you do not need proprietary drivers for your card, but it
> requires non-free firmware.  Which on these old Broadcom devices is a
> PITA, because Broadcom did not make it easily available.
> 
> > I tried booting it from live+nonfree image
> > (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmw
> > are/11.3.0-live+nonfree/amd64/iso-hybrid/), but still no luck (WiFi
> > doesn't work). As I understand, the needed drivers would load when
> > installing the system, but they do not load in live mode.
> 
> There is a misunderstanding here.  Debian's non-free images do not
> contain proprietary drivers, but they provide firmware for the devices,
> so that the in-kernel drivers can actually work.
> 
> If the non-free image does not work, the firmware for your device is
> missing because of licensing reasons.  There is a package named
> firmware-b43-installer in contrib which downloads Broadcom's old drivers
> and extracts the firmware from them. Obviously you need a network
> connection for that, so you might have to use it on another system.
> 
> Good luck,
> Sven
> 
> 
> 1. https://packages.debian.org/bullseye/firmware-b43-installer

Re: Proprietary WiFi drivers for live mode

[tomas]

On Sun, Jun 26, 2022 at 07:29:47AM -, Curt wrote:
> On 2022-06-26, Sven Joachim  wrote:
> > On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:
> >
> >> I have an old Dell laptop with Broadcom BCM43142 WiFi device
> >> (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
> >> sometimes boot Debian from USB Memory Stick in live mode.
> >> The problem is that WiFi doesn't work because of the proprietary drivers
> >> it needs.
> >
> > Probably you do not need proprietary drivers for your card, but it
> > requires non-free firmware.  Which on these old Broadcom devices is a
> > PITA, because Broadcom did not make it easily available.
> >
> 
> I'm reading he needs to build the driver from source using
> 'broadcom-sta-dkms'.

That was my take too. I chalked that up to the inherently
ambiguous "driver" term. Perhaps we should try to be more
specific and actually say "kernel module" (that's what goes
into your kernel) or "firmware" (that's what goes into your
network card hardware).

In the current case we seem to be dealing with a kernel
module whose license isn't compatible to the kernel's, so
it can't be distributed as part of it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Proprietary WiFi drivers for live mode

[Curt]

On 2022-06-26, Sven Joachim  wrote:
> On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:
>
>> I have an old Dell laptop with Broadcom BCM43142 WiFi device
>> (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
>> sometimes boot Debian from USB Memory Stick in live mode.
>> The problem is that WiFi doesn't work because of the proprietary drivers
>> it needs.
>
> Probably you do not need proprietary drivers for your card, but it
> requires non-free firmware.  Which on these old Broadcom devices is a
> PITA, because Broadcom did not make it easily available.
>

I'm reading he needs to build the driver from source using
'broadcom-sta-dkms'.
  
curty@einstein:~$ apt-cache show broadcom-sta-dkms
Package: broadcom-sta-dkms
Source: broadcom-sta
Version: 6.30.223.271-5
Installed-Size: 14140
Maintainer: Eduard Bloch 
Architecture: all
Provides: broadcom-sta-modules
Depends: dkms (>= 2.1.0.0)
Recommends: wireless-tools
Conflicts: broadcom-sta-modules
Description-en: dkms source for the Broadcom STA Wireless driver
 Broadcom STA is a binary-only device driver to support the following IEEE
 802.11a/b/g/n wireless network cards: BCM4311-, BCM4312-, BCM4313-,
 BCM4321-, BCM4322-, BCM43142-, BCM43224-, BCM43225-, BCM43227-, BCM43228-,
 BCM4331-, BCM4360-, and BCM4352-based hardware.
 .
 This package provides the source code for the wl kernel modules and makes use
 of the DKMS build utility to install them for the running kernel. The
 alternative package broadcom-sta-source can be used instead in case of build
 problems.
 .
 The wireless-tools package is also required in order to make use of these

Re: Proprietary WiFi drivers for live mode

[Sven Joachim]

On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:

> I have an old Dell laptop with Broadcom BCM43142 WiFi device
> (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
> sometimes boot Debian from USB Memory Stick in live mode.
> The problem is that WiFi doesn't work because of the proprietary drivers
> it needs.

Probably you do not need proprietary drivers for your card, but it
requires non-free firmware.  Which on these old Broadcom devices is a
PITA, because Broadcom did not make it easily available.

> I tried booting it from live+nonfree image
> (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.3.0-live+nonfree/amd64/iso-hybrid/),
> but still no luck (WiFi doesn't work). As I understand, the needed
> drivers would load when installing the system, but they do not load in
> live mode.

There is a misunderstanding here.  Debian's non-free images do not
contain proprietary drivers, but they provide firmware for the devices,
so that the in-kernel drivers can actually work.

If the non-free image does not work, the firmware for your device is
missing because of licensing reasons.  There is a package named
firmware-b43-installer in contrib which downloads Broadcom's old drivers
and extracts the firmware from them. Obviously you need a network
connection for that, so you might have to use it on another system.

Good luck,
Sven


1. https://packages.debian.org/bullseye/firmware-b43-installer