ive to be ready before it orders it to
become unready.
Note that
cdrskin -eject
without dev= argument will first grope all optical drives of the
computer in order to get a list of them and then chose the first one,
which is most probably /dev/sr0 on a Linux system. This may last some
time even if there
On Feb 17, 2025, Thomas Schmitt wrote:
> Hi,
>
> Dan Purgert wrote:
> > You "may" need to wait for the drive to finish reading the disc metadata
> > (i.e. drive light stops flashing) before mount(1) will not complain
> > about the lack of media. Not 100% sure if it's a generic problem, or
> > jus
In my experience, `cdrskin -eject` works more reliable than `eject`.
Regards,
Jörg.
On Feb 17, 2025, mick.crane wrote:
> On 2025-02-17 01:09, Dan Purgert wrote:
> > On Feb 16, 2025, William Torrez Corea wrote:
> > > *eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject:
> > > /dev/sr0: is whole-disk deviceeject: /dev/sr0: tr
Hi,
William Torrez Corea wrote:
> eject: device name is `/dev/sr0'
> ...
> eject: CD-ROM eject command succeeded
>
> I can't eject the optical drive
That was with: eject -v /dev/sr0 ?
What do you get from this program run
xorriso -outdev /dev/sr0 -eject all
On 2025-02-17 01:09, Dan Purgert wrote:
On Feb 16, 2025, William Torrez Corea wrote:
*eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject:
/dev/sr0: is whole-disk deviceeject: /dev/sr0: trying to eject using
CD-ROM
eject commandeject: CD-ROM eject command succeeded*
I
On Feb 16, 2025, William Torrez Corea wrote:
> *eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject:
> /dev/sr0: is whole-disk deviceeject: /dev/sr0: trying to eject using CD-ROM
> eject commandeject: CD-ROM eject command succeeded*
>
> I can't eject the o
*eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject:
/dev/sr0: is whole-disk deviceeject: /dev/sr0: trying to eject using CD-ROM
eject commandeject: CD-ROM eject command succeeded*
I can't eject the optical drive, i try mount the device:
*sudo mount -t iso9660 /dev/sr0
On 1/10/25 04:50, Dan Purgert wrote:
On Jan 09, 2025, Timothy M Butterworth wrote:
On Thu, Jan 9, 2025 at 6:45 PM Michael Stone wrote:
On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote:
For the people who need exact figures, on the other hand, binary units
are much more conven
On Jan 09, 2025, Timothy M Butterworth wrote:
> On Thu, Jan 9, 2025 at 6:45 PM Michael Stone wrote:
>
> > On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote:
> > >For the people who need exact figures, on the other hand, binary units
> > >are much more convenient, not just to measure
On Thu, Jan 09, 2025 at 06:44:30PM -0500, Michael Stone wrote:
[...]
> Baloney [...]
"Baloney" == "things I don't like"
(FWIW I'd prefer binaries in the computer context, but hey).
Human communication is messy. Both multipliers come from different
sources which were well established at the mom
On Thu 09 Jan 2025 at 02:29:37 (-0500), Jeffrey Walton wrote:
> On Tue, Jan 7, 2025 at 10:07 AM Stefan Monnier
> wrote:
> >
> > > 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> > > only though! After fromating it with ext4 it only had 15TB of usuable
> > > space.
> >
>
On Thu, Jan 9, 2025 at 6:45 PM Michael Stone wrote:
> On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote:
> >For the people who need exact figures, on the other hand, binary units
> >are much more convenient, not just to measure the size of memory
> >modules: alignment requirements, m
I agree it is important, may be a precision on the more general idea is
helpful:
"Communication of numbers between ordinary people generally happens in base
10."
It turns out that the diversity of the notion of numerosity among *homo
sapiens* is way far richer than the base-10. See
https://wals.in
On Thu, Jan 9, 2025 at 6:45 PM Michael Stone wrote:
>
> On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote:
> >For the people who need exact figures, on the other hand, binary units
> >are much more convenient, not just to measure the size of memory
> >modules: alignment requirements,
On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote:
For the people who need exact figures, on the other hand, binary units
are much more convenient, not just to measure the size of memory
modules: alignment requirements, maximum sizes of files and devices,
size of stripes, they are al
Michael Stone (12025-01-08):
> For example...let's take the 18B drive discussed earlier. That's
> 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. And
> it's 1800MB or 17166137MiB. So if you have a display in MB and you want
> to know the value in TB you move t
On Tue, Jan 7, 2025 at 10:07 AM Stefan Monnier wrote:
>
> > 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> > only though! After fromating it with ext4 it only had 15TB of usuable
> > space.
>
> 18TB "on paper" is usually 18 * 1000^4 bytes, so if you convert this
> into
On Wed, Jan 08, 2025 at 09:04:09PM -0600, Nicholas Geovanis wrote:
> TB is about 10% larger. One of the worst crimes in computer history
> was ever talking about storage in powers of 2, I really wish it would
> just go away. It has properties that nobody wants and has been the
> sourc
On Tue, Jan 7, 2025, 1:27 PM Dan Purgert wrote:
>
> > TB is about 10% larger. One of the worst crimes in computer history
> > was ever talking about storage in powers of 2, I really wish it would
> > just go away. It has properties that nobody wants and has been the
> > source of endless confusio
Max Nikulin writes:
> Gene, my congratulations. You have managed to derail the discussion
> another time.
And you have managed to clutter the list with yet another pointless rant
against Gene. Please put him in your killfile and move on.
--
John Hasler
j...@sugarbit.com
Elmwood, WI USA
luck, suffer from /dev/serial/by-id trouble with pleasure since mm
vs. in is more important to you.
Stop blaming developers if your system is improperly configured. Every
time you accuse those who do not deserve it, you decrease a chance to
get help. Do fact check before spreading rumors.
On 1/7/25 06:01, Timothy M Butterworth wrote:
I also ran into the Orca and brltty Hell problem Gene described
Just a reminder: this thread started as "new computer arriving soon".
Gene hijacked it and Orca is off-topic even in this subthread. Read the
subject.
Gene does not remember what he
On Jan 07, 2025, Michael Stone wrote:
> On Tue, Jan 07, 2025 at 10:44:00AM -0500, Dan Purgert wrote:
> > On Jan 07, 2025, Stefan Monnier wrote:
> > > > 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> > > > only though! After fromating it with ext4 it only had 15TB of usua
On Tue, Jan 07, 2025 at 11:05:11AM -0500, Michael Stone wrote:
TB is about 10% larger.
Hmm. Even talking about this is hard. The unit TiB is 1099511627776
bytes while the unit TB is 1 bytes. That is, when talking
about a drive, expressing it in TB is about a 10% larger number beca
On Tue, Jan 07, 2025 at 10:44:00AM -0500, Dan Purgert wrote:
On Jan 07, 2025, Stefan Monnier wrote:
> 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> only though! After fromating it with ext4 it only had 15TB of usuable
> space.
18TB "on paper" is usually 18 * 1000^4
On Jan 07, 2025, Stefan Monnier wrote:
> > 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> > only though! After fromating it with ext4 it only had 15TB of usuable
> > space.
>
> 18TB "on paper" is usually 18 * 1000^4 bytes, so if you convert this
> into "computer units"
> 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name
> only though! After fromating it with ext4 it only had 15TB of usuable
> space.
18TB "on paper" is usually 18 * 1000^4 bytes, so if you convert this
into "computer units" is ~16.37 * 1024^4 bytes. If you then make an
ext4
with all this?
Finally request to update the topic with the outcome.
Searching (you need rights) for udev bugs should find it if some dev
hasn't erased it. I don't know how and have long since lost the pw. I
ask for a pw reset but don't get it. Several times. I'm apparent
;> all done years ago. Get it from a pinned post on discord/klipper for
>> 3d printers forum. Restores the missing /dev/serial/by-id entries.
>
> Some post may be pinned in various forums specific to some devices or
> applications, but has the issue been reported to Debian? Is there a
uld I bother, years later, with all this?
Finally request to update the topic with the outcome.
Searching (you need rights) for udev bugs should find it if some dev
hasn't erased it. I don't know how and have long since lost the pw. I
ask for a pw reset but don't get it. Several t
On 06/01/2025 14:09, gene heskett wrote:
On 1/5/25 21:21, Max Nikulin wrote:
On 05/01/2025 23:28, gene heskett wrote:
As for bug number, I'm not the OP, just a canary.
Then ask the author to add the bug number. Tell them that without a
link you were not be able to check current state of affa
On 1/5/25 21:21, Max Nikulin wrote:
On 05/01/2025 23:28, gene heskett wrote:
As for bug number, I'm not the OP, just a canary.
Then ask the author to add the bug number. Tell them that without a
link you were not be able to check current state of affairs and, as a
result, you have secured
On 05/01/2025 23:28, gene heskett wrote:
As for bug number, I'm not the OP, just a canary.
Then ask the author to add the bug number. Tell them that without a link
you were not be able to check current state of affairs and, as a result,
you have secured your reputation as a liar.
. Get it from a pinned post on discord/klipper for 3d
printers forum. Restores the missing /dev/serial/by-id entries.
Some post may be pinned in various forums specific to some devices or
applications, but has the issue been reported to Debian? Is there a
Debian bug number?
Its been reported
scord/klipper for 3d printers forum.
Restores the missing /dev/serial/by-id entries.
Some post may be pinned in various forums specific to some devices or
applications, but has the issue been reported to Debian? Is there a
Debian bug number?
Patrice Duroux (12024-10-17):
> That is not clear to me why certain -dev depends on pkconf whereas (a
> lot of) others with a .pc file don't.
I guess it would depend on whether the only supported and documented
way to link with the library in the package is to use pkg-config or
whet
Hi,
For instance, libfontconfig-dev depends on pkgconf.
It makes me hesitate to add a(n explicit) dependency on pkgconf in the
control file of a packaging that depends libfontconfig-dev. but not on
pkgconf. It seems to require the pkg-config command regarding the
folllowing extract of its .build
current as of May 31 2024.
The current version of lynx is 2.9.2
It's available at
https://lynx.invisible-island.net/
https://invisible-island.net/archives/lynx/
Development & patches:
https://lynx.invisible-island.net/current/index.html
Files:
https://invisible-isla
On Tue, Mar 26, 2024 at 7:12 PM Björn Persson wrote:
>
> Jeffrey Walton wrote:
> > For what you want to do, and if I am parsing it correctly... I would
> > write a daemon in C [...]
>
> Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
> somehow. Writing and compiling a daem
Jeffrey Walton wrote:
> For what you want to do, and if I am parsing it correctly... I would
> write a daemon in C [...]
Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
somehow. Writing and compiling a daemon is no less work than compiling
an already written daemon.
> The
e used with devices it supports even if there are some
> other devices it doesn't support – but it looks like I'd have to build
> it from source myself.
Yeah, I've had to do that in the past. You will also (probably) need
to write a systemd unit file or two.
> > OpenSSL an
figure it can be used with devices it supports even if there are some
other devices it doesn't support – but it looks like I'd have to build
it from source myself.
> OpenSSL and GnuPG should be
> able to extract the entropy from the card, and then use it to seed
> /dev/{u}random.
Thi
On Mon, Mar 25, 2024 at 4:33 PM Björn Persson wrote:
>
> In a quest to acquire hardware random number generators for seeding
> /dev/random on servers that lack a built-in entropy source, I'm
> investigating how random data can be obtained from a security key such
> as a Ni
because the
shop didn't like my card number.
> On their mailing list however, there
> is a recent discussion about whether there any point. The conclusion
> seems to be "not really". Thread starts here:
>
> http://lists.ourshack.com/pipermail/discuss/2024-March/00
On Mon, Mar 25, 2024 at 06:09:02PM -0400, e...@gmx.us wrote:
> On 3/25/24 17:27, Andy Smith wrote:
> > The thread covers how to make rngd feed /dev/random from a OneRNG in
> > Debian 12, but it is no longer possible to tell if that does
> > anything useful.
>
> If not f
On 3/25/24 17:27, Andy Smith wrote:
The thread covers how to make rngd feed /dev/random from a OneRNG in
Debian 12, but it is no longer possible to tell if that does
anything useful.
If not from devices like this, from where does Debian get its randomness?
--
For is it not written
Hi,
On Mon, Mar 25, 2024 at 09:24:23PM +0100, Björn Persson wrote:
> Does anyone know of another way to obtain random data from devices of
> this kind?
I have some EntropyKeys and some OneRNGs. I have the rngd packaged
in Debian feeding /dev/random from them.
This had an actual noti
Hello!
In a quest to acquire hardware random number generators for seeding
/dev/random on servers that lack a built-in entropy source, I'm
investigating how random data can be obtained from a security key such
as a Nitrokey, Yubikey or a similar device.
RNGD version 6 from https://githu
Joe Pfeiffer writes:
> I have a laptop with a recent Debian install, which seems to have
> incorrect permissions on /dev/tty
>
> crw--w 1 root tty 5, 0 Feb 16 08:51 /dev/tty
Ah, found it. I somehow had a
/etc/systemd/system/getty.target.wants/getty@tty.service
file.
Foun
I have a laptop with a recent Debian install, which seems to have
incorrect permissions on /dev/tty
crw--w 1 root tty 5, 0 Feb 16 08:51 /dev/tty
/lib/udev/rules.d/50-udev-default.rules contains the usual
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="
On Mon, Jan 15, 2024, 8:32 PM Karen Lewellen
wrote:
> As of today, current edition of lynx.
> Announcement below.
> Kare
>
>
> On Tue, 16 Jan 2024, Thomas Dickey wrote:
>
> > The current version of lynx is 2.9.0
> >
> > It's available at
> > https://lynx.invisible-island.net/
> > http
As of today, current edition of lynx.
Announcement below.
Kare
On Tue, 16 Jan 2024, Thomas Dickey wrote:
The current version of lynx is 2.9.0
It's available at
https://lynx.invisible-island.net/
https://invisible-island.net/archives/lynx/
Development & patches:
https:
Hello,
I have set up 40 identical systems with Debian 12.0: same SBC, same OS
version, same preseed file. These systems use a touchscreen monitor with an
eGalax USB controller. eGalax driver was installed on all of the 40 systems
and everything works fine except for 2 systems that are connected to
Am Fri, Mar 03, 2023 at 10:09:42PM +0700 schrieb Max Nikulin:
> On 02/03/2023 22:27, Christoph Brinkhaus wrote:
> > Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> > > On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > > > I will just inform about the status. Everything is fine now
On 02/03/2023 22:27, Christoph Brinkhaus wrote:
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
h
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > I will just inform about the status. Everything is fine now. A word
> > about systemd-networkd-wait-online: With this service running there
> > has been even a delay of 1-2 seconds wh
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
has been even a delay of 1-2 seconds when switching from one console
to a different one (the consoles when X is n
Am Sun, Feb 26, 2023 at 01:21:07PM -0600 schrieb David Wright:
Hello David and Max,
> On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> > Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > > Now there are no
Hi.
On Mon, Feb 27, 2023 at 10:53:24PM +0100, Geert Stappers wrote:
> (Meanwhile solved with denyinterface in /etc/dhcpcd.conf)
>
>
> > Long story short, consider running "systemctl mask dhcpcd" unless you
> > need dhcpcd to work in a way described above.
>
> The laptop does need to ha
These have nothing to do with your problem.
> dhcpcd is the source of your problem, in a way.
OK, so I checked. And yes, it is true that adding
'denyinterfaces ovs-system ovsbr0' to /etc/dhcpcd.conf
does prevent "route 169.254.0.0/16 dev ovs-system"
and "route 169.254.0.0/16
On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > Now there are no messages reported by journald as above.
> >
> > I am curious if fixing unbound and so networ
Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > Now there are no messages reported by journald as above.
>
> I am curious if fixing unbound and so network-online.target helped to avoid
> 169.254.x.y address in your case. Can fetch
Reached target Login Prompts.
(man 5 systemd.network) and:
$ ip r
default via 192.168.1.1 dev wlp2s4 proto dhcp src 192.168.1.10 metric 20
192.168.1.0/24 dev wlp2s4 proto kernel scope link src 192.168.1.10
192.168.1.1 dev wlp2s4 proto dhcp scope link src 192.168.1.10 metric 20
$
&
Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > Now there are no messages reported by journald as above.
>
> I am curious if fixing unbound and so network-online.target helped to avoid
> 169.254.x.y address in your case.
I am no
On 25/02/2023 19:49, Christoph Brinkhaus wrote:
Now there are no messages reported by journald as above.
I am curious if fixing unbound and so network-online.target helped to
avoid 169.254.x.y address in your case. Can fetchmail work without a
kludge you added to achieve some delay? My expect
On 26/02/2023 18:18, Geert Stappers wrote:
AIUI is systemd-networkd the main player, dhcpcd some helper
and NetworkManager for contact with user.
First of all, I would not touch dhcpcd.conf for a while.
Is it assumed that ovs-system should get its IP address from DHCP?
If I understand it corr
Hi.
On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote:
> Hi.
>
> On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote:
> > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
> > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
> > > Feb 24 22
Hi.
On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote:
> On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
> > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
> > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
> > Feb 24 22:24:15 trancilo d
Hi.
On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address
> fe80::56b2:
On Sat, Feb 25, 2023 at 09:42:49AM +0700, Max Nikulin wrote:
> On 25/02/2023 04:43, Geert Stappers wrote:
> > Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
> >
> > Ideas how to avoid it are welcome.
>
> Have you checked "journalctl --boot" for logs which component assigns
>
Am Fri, Feb 24, 2023 at 07:41:26PM +0100 schrieb Christoph Brinkhaus:
I reply to myself thanking Max.
> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On
On Fri, Feb 24, 2023 at 9:51 PM David Wright wrote:
>
> On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote:
> > [...]
> I see you rebooted, and you get the same address. It's ambiguous as
> to why: it could have been stored, which makes things more efficient
> when a number of machines
gt; Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==--====-
On 25/02/2023 04:43, Geert Stappers wrote:
Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
Ideas how to avoid it are welcome.
Have you checked "journalctl --boot" for logs which component assigns
169.254.x.y address and for various errors related to network?
I am not fam
Architecture Description
+++-==---=
un avahi-autoipd(no description available)
$ uptime
22:45:25 up 1 min, 1 user, load average: 0.02, 0.04, 0.05
$ ip route | grep system
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
$
Groeten
Geert Stappers
--
Silence is hard to parse
On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On 22/02/2023 01:26, Christoph Brinkhaus
Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > [Unit]
> > > > Description=A remote mail retrieval and forw
On 22/02/2023 23:45, Christoph Brinkhaus wrote:
Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
On 22/02/2023 01:26, Christoph Brinkhaus wrote:
[Unit]
Description=A remote mail retrieval and forwarding utility
After=network-online.target opensmtpd.service unbound.service
Requires=
On 22/02/2023 19:40, Greg Wooledge wrote:
On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:
Maybe the 'w' is not matching anything.
I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
Consistent Network Device Names and biosdevname, the name will begin
with a
On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:
> Maybe the 'w' is not matching anything.
>
> I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
> Consistent Network Device Names and biosdevname, the name will begin
> with a 'p' or 'em', not a 'w', and based on
On Wed, Feb 22, 2023 at 1:43 PM David Wright wrote:
>
> On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote:
> > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> > wrote:
> > > [...]
> > > > But backing up... I suspect there's something wrong with your static
> > > > ip address assi
On Wed 22 Feb 2023 at 17:45:40 (+0100), Christoph Brinkhaus wrote:
> Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > > I have no idea if it is possible to estimate a DHCP response
> > > > > time.
> >
> > Since static IP addr
etworkd from systemd-networking, and (b) purged of avahi
packages to eliminate 169.254.x.y addresses. So I'm not sure what
there is to fix here.
But (a) raises the question of what systemd was running /before/,
which was presumably what was giving rise to 169.254.x.y addresses.
And, while I ca
Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > I have no idea if it is possible to estimate a DHCP response
> > > > time.
>
> Since static IP address is assigned, it does not matter. I expected DHCP
> configuration and that d
On 22/02/2023 01:26, Christoph Brinkhaus wrote:
I have no idea if it is possible to estimate a DHCP response
time.
Since static IP address is assigned, it does not matter. I expected DHCP
configuration and that delay may be noticed in `journalctl -b 0` logs.
[Unit]
Description=A remote mail
On Tue, Feb 21, 2023 at 01:48:58PM -0500, Jeffrey Walton wrote:
> On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> wrote:
> > [...]
> > > But backing up... I suspect there's something wrong with your static
> > > ip address assignment. The address is already taken, the netmask is
> > > wrong,
On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
wrote:
> [...]
> > But backing up... I suspect there's something wrong with your static
> > ip address assignment. The address is already taken, the netmask is
> > wrong, or the gateway is wrong.
> >
> > Looking back through this thread, I did no
Am Tue, Feb 21, 2023 at 01:06:01PM -0500 schrieb Jeffrey Walton:
> On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
> wrote:
> > Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > > On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700
Hi.
On Tue, Feb 21, 2023 at 06:44:38PM +0100, Christoph Brinkhaus wrote:
> I have no idea if it is possible to estimate a DHCP response time.
sudo nmap --script broadcast-dhcp-discover
Reco
On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
wrote:
> Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to
> > > get rid of 169.254.x.y addresses, it
Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Hello Max,
> > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> > > configure network interfac
On 20/02/2023 21:44, Christoph Brinkhaus wrote:
Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
configure network interface, either to ensure that DHCP server is available
or to assign a static address. After tha
On 2023-02-19 at 11:21, Geert Stappers wrote:
> Hi,
>
> Having installed package openvswitch-switch and doing `ip route` I do get
>
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
>
> What can be done to prevent that "zeroconf"
On Mon, Feb 20, 2023 at 9:28 AM wrote:
>[...]
> --
> rhk
>
> (sig revised 20221206)
>
> If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
> avoid top posting; and keep it "on list". (Oxford comma (and semi-colon)
> included at no charge.) If you revise the topic, change t
Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Hi Max,
> On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> > Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
> > > Having installed package openvswitch-switch and doing `ip route` I do get
> >
On Monday, February 20, 2023 04:05:19 AM to...@tuxteam.de wrote:
> On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote:
> > On Mon, Feb 20, 2023 at 2:27 AM wrote:
> [...]
>
> > > That's what Microsoft calls them. I prefer the RFC's IP4LL.
> >
> > And Wireshark (https://wiki.wireshark.
On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote:
> On Mon, Feb 20, 2023 at 2:27 AM wrote:
[...]
> > That's what Microsoft calls them. I prefer the RFC's IP4LL.
>
> And Wireshark (https://wiki.wireshark.org/APIPA.md) and Cisco
> (https://study-ccna.com/apipa-automatic-private-ip-a
On Mon, Feb 20, 2023 at 2:27 AM wrote:
>
> On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote:
> > On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers
> > wrote:
> > >
> > > Having installed package openvswitch-switch and doing `ip route` I do get
On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote:
> On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers wrote:
> >
> > Having installed package openvswitch-switch and doing `ip route` I do get
> >
> > 169.254.0.0/16 dev ovs-system scope link src 169.254.2
1 - 100 of 4290 matches
Mail list logo
