Re: udev creates wrong symlink from rule after upgrade to bookworm

evice. Details > below. > > Ideas? In the light of how Karl's bug was solved, perhaps you could improve your details. For example, writing ls -ld /dev/A* with a wildcard seems reasonable, but head -n 13 /etc/udev/rules.d/10* conceals the filename, which should be construct

Re: udev creates wrong symlink from rule after upgrade to bookworm

. = In Debian 11. root@imager:~# cat /etc/deb*ver* 11.8 root@imager:~# head -n 13 /etc/udev/rules.d/10* | tail -n 2 KERNEL=="sd?3", SUBSYSTEM=="block", ATTR{size}=="60028928", \ SYMLINK+="AY", OWNER="root", GROUP="root&q

Howto debug the boot sequence and udev because bcache is not working after a reboot in Debian 12

. I am trying to find the cause of the problem with bcache, I see no explainable errors in dmesg ou "jounalctl -b" and when I try to reattach the missing bcache I see no errors and works. No data is lost. I see too that the links /dev/bcache/by-uuid are missing, so some problem is possible

udev not on-demand-loading modules with custom kernel

x27;t work as no vfat module gets loaded (as an example). Likewise adding rules via iptables doesn't work, as the netfilter modules are missing. I have to manually load the nf* modules and _then_ I'm able to use iptables. I can load all those modules by hand via modprobe, but au

Re: systemd: udev coldplug all devices question

On Thu, Sep 15, 2022 at 01:30:11AM -0400, Chuck Zmudzinski wrote: bug report to try to fix it, except for the suggestion that a Debian kernel developer made to increase the uevent buffer size in the kernel over a year ago and another suggestion from another Debian maintainer or developer who gave

systemd: udev coldplug all devices question

d to the journal and boot logs on Fedora and also on Fedora the live and netinst images do not crash, but on Debian these negative things do happen. Finally, another workaround to make the Debian live image or the Debian netinst image bootable with the problematic device was to edit the udev s

Re: Cannot upgrade circular udev dependency

On 2/16/22 9:26 AM, Greg Wooledge wrote: On Wed, Feb 16, 2022 at 08:24:57AM -0800, David Liontooth wrote: Still, where in pool is udev? unicorn:~$ apt-get --reinstall --print-uris install udev Reading package lists... Done Building dependency tree... Done Reading state information... Done 0

Re: Cannot upgrade circular udev dependency

On 2/16/22 9:03 AM, Andy Smith wrote: On Wed, Feb 16, 2022 at 07:19:34AM -0800, David Liontooth wrote: Hi -- I have a machine, Linux ancient 2.6.36.2 #1 SMP Sun Dec 26 06:19:57 PST 2010 x86_64 GNU/Linux. […] Since release 198, udev requires support for the following features in the running

Re: Cannot upgrade circular udev dependency

On Wed, Feb 16, 2022 at 08:24:57AM -0800, David Liontooth wrote: > Still, where in pool is udev? unicorn:~$ apt-get --reinstall --print-uris install udev Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstal

Re: Cannot upgrade circular udev dependency

On Wed, Feb 16, 2022 at 07:19:34AM -0800, David Liontooth wrote: > Hi -- I have a machine, Linux ancient 2.6.36.2 #1 SMP Sun Dec 26 06:19:57 > PST 2010 x86_64 GNU/Linux. […] > Since release 198, udev requires support for the following features in > the running kernel: >

Re: Cannot upgrade circular udev dependency

not? What happens when you try to boot one of them? Are they missing whatever features you needed to build a custom kernel to support? I've only tried remotely, so I don't see what's happening. If I force it and the udev is wrong, won't the kernel fail? I also cannot upgrade ud

Re: Cannot upgrade circular udev dependency

3.16.0-6-amd64 > Found initrd image: /boot/initrd.img-3.16.0-6-amd64 > Found linux image: /boot/vmlinuz-2.6.36.2 > Found linux image: /boot/vmlinuz-2.6.36.1 Why not? What happens when you try to boot one of them? Are they missing whatever features you needed to build a custom kern

Cannot upgrade circular udev dependency

nitrd image: /boot/initrd.img-4.9.0-16-amd64 Found linux image: /boot/vmlinuz-3.16.0-6-amd64 Found initrd image: /boot/initrd.img-3.16.0-6-amd64 Found linux image: /boot/vmlinuz-2.6.36.2 Found linux image: /boot/vmlinuz-2.6.36.1 I also cannot upgrade udev: root@ancient:~# apt --fix-broken install Re

Re: udev applied to SDHC card. Two systems compared.

On Sun 26 Dec 2021 at 21:32:20 (-0800), pe...@easthope.ca wrote: > Any ideas about why udev assigns a symlink on the desktop system and > not on the Sharp Mebius laptop? Because the slots you're pushing them into are of a different type. > Desktop machine. > Pertinent l

Re: udev applied to SDHC card. Two systems compared.

From: "Alexander V. Makartsev" Date: Wed, 29 Dec 2021 03:49:14 +0500 > My point was, you could've used better or more identifiers to > distinguish between devices, so there is no other device could ever > interfere. For example, what will happen if you plug in another drive > with the s

Re: udev applied to SDHC card. Two systems compared.

On 29.12.2021 01:59, pe...@easthope.ca wrote: From: "Alexander V. Makartsev" Date: Mon, 27 Dec 2021 22:16:04 +0500 It is always better to make udev rules to identify target devices properly. Thanks Alexander. Definitely my intention. 'KERNEL=="sd?1"'

Re: udev applied to SDHC card. Two systems compared.

From: "Alexander V. Makartsev" Date: Mon, 27 Dec 2021 22:16:04 +0500 > It is always better to make udev rules to identify target devices properly. Thanks Alexander. Definitely my intention. 'KERNEL=="sd?1"' identifies two volumes, /dev/sda1 and /dev/sd

Re: udev applied to SDHC card. Two systems compared.

On 27.12.2021 10:32, pe...@easthope.ca wrote: Any ideas about why udev assigns a symlink on the desktop system and not on the Sharp Mebius laptop? I think it is impossible to answer that question without actually looking at these systems. Perhaps it is a problem of poorly written rule that

udev applied to SDHC card. Two systems compared.

Any ideas about why udev assigns a symlink on the desktop system and not on the Sharp Mebius laptop? Thx,... P. Desktop machine. peter@joule:/home/peter$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 11 (bullseye

Re: How to avoid systemd/udev unpredictable NIC names

On Ma, 31 aug 21, 16:33:49, Reco wrote: > On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote: > > > > Another completely different approach is to use some other tool to > > configure your network that can match on MAC address and just ignore the > > names completely. > > Surely you

Re: How to avoid systemd/udev unpredictable NIC names

On Mon, 2021-08-30 at 20:26 -0400, Greg Wooledge wrote: > On Tue, Aug 31, 2021 at 01:44:09AM +0200, Steve Keller wrote: [...] > > Actually, I don't know this. When I wrote unpredictable new naming > > scheme I meant systemd's enps scheme, since it's > > unpredictable for me as long as I don't lear

Re: How to avoid systemd/udev unpredictable NIC names

is a PCI card. If the kernel should really change the > enumeration of the cards in some future, I will do something about > that. By which time, of course, the consequences of this mistake might well have already happened, eg, juggling your internal network, dmz, and external internet. But

Re: How to avoid systemd/udev unpredictable NIC names

On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote: > On Lu, 30 aug 21, 16:41:39, Greg Wooledge wrote: > > On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote: > > > I plan to upgrade a server from Debian stretch to buster. Having read > > > the release notes I wonder what's

Re: How to avoid systemd/udev unpredictable NIC names

want to keep it that way. The Debian wiki on this shows several ways involving kernel cmdline, udev, and systemd. I've read it, I've also read some of the sparse and incomplete systemd documentation for almost an hour. Still I don't know when and what software component (kernel,

Re: How to avoid systemd/udev unpredictable NIC names

On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote: > Another completely different approach is to use some other tool to > configure your network that can match on MAC address and just ignore the > names completely. > > For systemd-networkd > > /etc/systemd/network/my.network > > [

Re: How to avoid systemd/udev unpredictable NIC names

On Lu, 30 aug 21, 16:41:39, Greg Wooledge wrote: > On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote: > > I plan to upgrade a server from Debian stretch to buster. Having read > > the release notes I wonder what's the best way to avoid the new scheme > > of unpredictable network int

Re: How to avoid systemd/udev unpredictable NIC names

On Ma, 31 aug 21, 01:11:33, Steve Keller wrote: > > I still don't understand, why eth in > a systemd.link file would be a problem, since in the udev .rules this > has worked for years. Greg already explained what problems might show up if you try

Re: How to avoid systemd/udev unpredictable NIC names

s a PCI card. If the kernel should really change the > enumeration of the cards in some future, I will do something about > that. A good alternative in your scenario above would be to take control of udev rules yourself and rename your NICs based on their MAC address (or on some other tidbi

Re: How to avoid systemd/udev unpredictable NIC names

table" because they're based on the PCI slot number, which is not stable. > Well, this is exactly what I dislike with systemd > & co. I've read lots of docs & man pages, still I don't know the > exact process of how the interfaces are renamed after the kernel names

Re: How to avoid systemd/udev unpredictable NIC names

Roberto C. Sánchez writes: > Since nobody else has mentioned this link, here is where I recommend you > start: https://wiki.debian.org/NetworkInterfaceNames Oh, that's what I meant by "wiki" in my posts. Sorry, I should have given the URL. It's linked from the buster release-notes in section 5

Re: How to avoid systemd/udev unpredictable NIC names

his is exactly what I dislike with systemd & co. I've read lots of docs & man pages, still I don't know the exact process of how the interfaces are renamed after the kernel names the eth. Does udevd run first, does systemd call udev, does systemd do the renaming itself or is it d

Re: How to avoid systemd/udev unpredictable NIC names

Since I almost never change hardware configurations this is probably OK even with my two NICs, one on the mainboard, the second is a PCI card. If the kernel should really change the enumeration of the cards in some future, I will do something about that. In buster I still need to disable t

Re: How to avoid systemd/udev unpredictable NIC names

> my external network to the DSL router. That's easy and I want to keep > it that way. > > The Debian wiki on this shows several ways involving kernel cmdline, > udev, and systemd. I've read it, I've also read some of the sparse > and incomplete syst

Re: How to avoid systemd/udev unpredictable NIC names

IL Ka schrieb: > > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs. > > Isn't that what the topic starter asked about?:) I don't think so: | I simply have eth0 for the internal network and eth1 for | my external network to the DSL router. That looks like two ethernet NICs.

Re: How to avoid systemd/udev unpredictable NIC names

> > > > Isn't that what the topic starter asked about?:) I sincerely hope that the OP will tell us how many ethernet interfaces their "server" has, so we can stop the hypothetical tennis match. > To make names predictable one can either leave everything as-is an

Re: How to avoid systemd/udev unpredictable NIC names

ictable one can either leave everything as-is and let `systemd-udev` do its job, or create custom naming scheme using "link" files: https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html https://systemd.io/PREDICTABLE_INTERFACE_NAMES/ https://www.freedesktop.org/software/systemd/man/systemd.link.html

Re: How to avoid systemd/udev unpredictable NIC names

Dan Ritter wrote: > Steve Keller wrote: > > I plan to upgrade a server from Debian stretch to buster. Having read > > the release notes I wonder what's the best way to avoid the new scheme > > of unpredictable network interface names. > > In /etc/default/grub, assuming that you are booting

Re: How to avoid systemd/udev unpredictable NIC names

On Mon, Aug 30, 2021 at 11:36 PM Steve Keller wrote: > So I'm still confused what to do after the upgrade to buster to keep > my network names. > > > in /etc/default/grub add "net.ifnames=0" to GRUB_CMDLINE_LINUX and execute "update-grub" This service: https://www.freedesktop.org/software/system

Re: How to avoid systemd/udev unpredictable NIC names

On Mon, Aug 30, 2021 at 04:41:55PM -0400, Dan Ritter wrote: > Steve Keller wrote: > > I plan to upgrade a server from Debian stretch to buster. Having read > > the release notes I wonder what's the best way to avoid the new scheme > > of unpredictable network interface names. > > In /etc/def

Re: How to avoid systemd/udev unpredictable NIC names

Steve Keller wrote: > I plan to upgrade a server from Debian stretch to buster. Having read > the release notes I wonder what's the best way to avoid the new scheme > of unpredictable network interface names. In /etc/default/grub, assuming that you are booting with grub, GRUB_CMDLINE_LIN

Re: How to avoid systemd/udev unpredictable NIC names

On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote: > I plan to upgrade a server from Debian stretch to buster. Having read > the release notes I wonder what's the best way to avoid the new scheme > of unpredictable network interface names. You say "server", so I'm guessing it has

How to avoid systemd/udev unpredictable NIC names

s shows several ways involving kernel cmdline, udev, and systemd. I've read it, I've also read some of the sparse and incomplete systemd documentation for almost an hour. Still I don't know when and what software component (kernel, udev, systemd) decides the NIC names and whether a

Re: Logitech C310 rule in /etc/udev/rules.d/25-webcam.rules?

ot;video4linux" > DRIVER=="" > ATTR{index}=="0" > ATTR{dev_debug}=="0" > ATTR{name}=="UVC Camera (046d:081b)" > > /etc/udev/rules.d/25-webcam.rules: > > KERNEL=="video[0-9]*", \ > SUBSYSTEM=

Logitech C310 rule in /etc/udev/rules.d/25-webcam.rules?

ATTR{index}=="0" ATTR{dev_debug}=="0" ATTR{name}=="UVC Camera (046d:081b)" /etc/udev/rules.d/25-webcam.rules: KERNEL=="video[0-9]*", \ SUBSYSTEM=="video4linux", \ SUBSYSTEMS=="usb", \ ATTRS{idVendor}=="046d",

Re: udev alzheimers

23:55AM -0400, Gene Heskett wrote: > > > > > > > > > > Since updating to stretch, udev has been randomly swapping ttyUSB0 > > > > > and ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of > > > > > heyu, a trs-80-coco3, and occasionally e

Re: udev alzheimers

On Thu 21 May 2020 at 13:26:03 (-0400), Gene Heskett wrote: > On Thursday 21 May 2020 12:11:42 David Wright wrote: > > On Thu 21 May 2020 at 08:23:55 (-0400), Gene Heskett wrote: > > > Since updating to stretch, udev has been randomly swapping ttyUSB0 > > > and ttyUSB1 a

Re: udev alzheimers

rote: > > > > > Since updating to stretch, udev has been randomly swapping > > > > > ttyUSB0 and ttyUSB1 and sometimes ttyUSB2 around, confusing > > > > > the hell out of heyu, a trs-80-coco3, and occasionally even > > > > > nut. Nut (apc

Re: udev alzheimers

David Wright writes: > On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote: > > On Thursday 21 May 2020 10:10:10 to...@tuxteam.de wrote: > > > On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote: > > > > > > > > Since updating to stretc

Re: udev alzheimers

On Thursday 21 May 2020 14:13:29 David Wright wrote: > On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote: > > On Thursday 21 May 2020 10:10:10 to...@tuxteam.de wrote: > > > On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote: > > > > Since upda

Re: udev alzheimers

On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote: > On Thursday 21 May 2020 10:10:10 to...@tuxteam.de wrote: > > On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote: > > > > > > Since updating to stretch, udev has been randomly swapping ttyUSB0 >

Re: udev alzheimers

On Thursday 21 May 2020 12:11:42 David Wright wrote: > On Thu 21 May 2020 at 08:23:55 (-0400), Gene Heskett wrote: > > Since updating to stretch, udev has been randomly swapping ttyUSB0 > > and ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of > > heyu

Re: udev alzheimers

On Thursday 21 May 2020 10:10:10 to...@tuxteam.de wrote: > On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote: > > greetings all; > > > > Since updating to stretch, udev has been randomly swapping ttyUSB0 > > and ttyUSB1 and sometimes ttyUSB2 around, confusi

Re: udev alzheimers

On Thu 21 May 2020 at 08:23:55 (-0400), Gene Heskett wrote: > > Since updating to stretch, udev has been randomly swapping ttyUSB0 and > ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of heyu, a > trs-80-coco3, and occasionally even nut. Nut (apc ups) is not on a

Re: udev alzheimers

On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote: > greetings all; > > Since updating to stretch, udev has been randomly swapping ttyUSB0 and > ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of heyu, a > trs-80-coco3, and occasionally even nut. Nut (apc

Re: udev alzheimers

Gene Heskett wrote: > greetings all; > > Since updating to stretch, udev has been randomly swapping ttyUSB0 and > ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of heyu, a > trs-80-coco3, and occasionally even nut. Nut (apc ups) is not on a > usb-serial adap

udev alzheimers

greetings all; Since updating to stretch, udev has been randomly swapping ttyUSB0 and ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of heyu, a trs-80-coco3, and occasionally even nut. Nut (apc ups) is not on a usb-serial adapter, it just a usb cable but the other 2 are on

Re: Success of udev rule depends on if user has local or NIS account

Hi, On 2020-01-09 18:23, Greg Wooledge wrote: On Thu, Jan 09, 2020 at 05:56:53PM +0100, Christoph Pleger wrote: Does anybody know what happened in newer kernels that makes OWNER="$result" fail for NIS accounts? At a guess, it's bug #878625 again. Does it start working again if you install ns

Re: Success of udev rule depends on if user has local or NIS account

On Thu, Jan 09, 2020 at 05:56:53PM +0100, Christoph Pleger wrote: > Does anybody know what happened in newer kernels that makes OWNER="$result" > fail for NIS accounts? At a guess, it's bug #878625 again. Does it start working again if you install nscd, or one of its alternatives? Or if you over

Success of udev rule depends on if user has local or NIS account

Hello, I wrote the following udev rule: ACTION=="add", SUBSYSTEM=="block", ATTRS{removable}=="1", PROGRAM="/lib/udev/foreground-user", RESULT!="root",MODE="0600", OWNER="$result" The goal of this rule is to give

Re: udev being an ass

attitude. You have, I assume the same clothes to get glad in > > that you got mad in. Use them. > > In your defense I'll say that your negativity is infrequently, if ever, > *ad hominem*, and udev, brltty et. al. are all inanimate things, not > animate beings, the forme

Re: udev being an ass

On Thu, Aug 29, 2019 at 9:51 PM Felix Miata wrote: > > David Wright composed on 2019-08-29 19:49 (UTC-0500): > > > Unfortunately, virtually every conversation about any of your systems > > begins with a tirade about how Debian is completely broken, whether > > it's the... > > I'm guessing most of

Re: udev being an ass

e, I assume the same clothes to > > get glad in that you got mad in. Use them. > > In your defense I'll say that your negativity is infrequently, if > ever, *ad hominem*, and udev, brltty et. al. are all inanimate things, > not animate beings, the former being incapable of ta

Re: udev being an ass

got mad in. Use them. In your defense I'll say that your negativity is infrequently, if ever, *ad hominem*, and udev, brltty et. al. are all inanimate things, not animate beings, the former being incapable of taking umbrage at being the target of diverse epithets, as they are, like rocks, lacki

Re: udev being an ass

On Thursday 29 August 2019 21:34:33 Felix Miata wrote: > David Wright composed on 2019-08-29 19:49 (UTC-0500): > > Unfortunately, virtually every conversation about any of your > > systems begins with a tirade about how Debian is completely broken, > > whether it's the... > > I'm guessing most of

Re: udev being an ass

David Wright composed on 2019-08-29 19:49 (UTC-0500): > Unfortunately, virtually every conversation about any of your systems > begins with a tirade about how Debian is completely broken, whether > it's the... I'm guessing most of it would be curtailed if he could install the current stable rele

Re: udev being an ass

On Wed 28 Aug 2019 at 20:19:29 (-0400), Gene Heskett wrote: > On Wednesday 28 August 2019 16:04:48 Greg Wooledge wrote: > > On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote: > > > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > > > I've resorted to the chattr on more than one occ

Re: udev being an ass

On Wed 28 Aug 2019 at 19:59:53 (-0400), Gene Heskett wrote: > On Wednesday 28 August 2019 15:42:56 Brian wrote: > > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > > I've resorted to the chattr on more than one occasion. Works well > > > if you can get it all done before before the t

Re: udev being an ass, SOLVED

On Thursday 29 August 2019 15:23:42 Greg Wooledge wrote: > > > and yet you can't actually describe what you DO want to happen. > > > > I just did, in a step by step description, Greg. How you choose to > > understand it is up to you. > > I just reviewed >

Re: udev being an ass

> > and yet you can't actually describe what you DO want to happen. > > I just did, in a step by step description, Greg. How you choose to > understand it is up to you. I just reviewed again. There is nothing in it about how you want

Re: udev being an ass

On Thursday 29 August 2019 12:55:10 Greg Wooledge wrote: > On Thu, Aug 29, 2019 at 11:41:55AM -0400, Gene Heskett wrote: > > Its all hosts file based, no dhcp involved this side of the router. > > If the desired fqdn is not in the /etc/hosts file, which is > > identical on all machines (so is the

Re: udev being an ass

On Thu, Aug 29, 2019 at 11:41:55AM -0400, Gene Heskett wrote: > Its all hosts file based, no dhcp involved this side of the router. If > the desired fqdn is not in the /etc/hosts file, which is identical on > all machines (so is the /etc/resolv.conf file, which assigns the router [...] None of

Re: udev being an ass

On Thu 29 Aug 2019 at 12:03:22 -0400, Gene Heskett wrote: > On Thursday 29 August 2019 09:26:25 mick crane wrote: > > > On 2019-08-29 13:45, Greg Wooledge wrote: > > > On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote: > > >> Thats a miss-statement. I do want persistent interface names

Re: udev being an ass

On Thursday 29 August 2019 09:26:25 mick crane wrote: > On 2019-08-29 13:45, Greg Wooledge wrote: > > On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote: > >> Thats a miss-statement. I do want persistent interface names EVEN > >> if I move this boot drive to a whole new box. > >> > >> Th

Re: udev being an ass

On Thursday 29 August 2019 08:45:47 Greg Wooledge wrote: > On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote: > > Thats a miss-statement. I do want persistent interface names EVEN if > > I move this boot drive to a whole new box. > > > > This machine does in fact have 2 nic's. And I ha

Re: udev being an ass

On 2019-08-29 13:45, Greg Wooledge wrote: On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote: Thats a miss-statement. I do want persistent interface names EVEN if I move this boot drive to a whole new box. This machine does in fact have 2 nic's. And I have indeed used both at the

Re: udev being an ass

On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote: > Thats a miss-statement. I do want persistent interface names EVEN if I > move this boot drive to a whole new box. > This machine does in fact have 2 nic's. And I have indeed used both at > the same time but haven't mastered "consis

Re: udev being an ass

On Wed 28 Aug 2019 at 19:59:53 -0400, Gene Heskett wrote: > If you can't say something constructive Brian, please just stfu. I won't > claim to speak for the rest of the list, but I am damned tired of your > negative attitude. You have, I assume the same clothes to get glad in > that you got ma

Re: udev being an ass, SOLVED

urprise in IRC for a totally unrelated issue, but it > appears to be relevant to Gene's wish set: > > In squeeze, wheezy, and jessie, and *possibly* stretch, the persistent > interface names that are stored in > /etc/udev/rules.d/70-persistent-net.rules are created by > /lib

Re: udev being an ass

On Wednesday 28 August 2019 16:04:48 Greg Wooledge wrote: > On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote: > > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > > I've resorted to the chattr on more than one occasion. Works well > > > if you can get it all done before before t

Re: udev being an ass

On Wednesday 28 August 2019 15:42:56 Brian wrote: > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > I've resorted to the chattr on more than one occasion. Works well > > if you can get it all done before before the timer runs the N-M > > script again. > > Users (particularly new use

Re: udev being an ass

On Wed 28 Aug 2019 at 03:18:59 -0400, Gene Heskett wrote: > On Wednesday 28 August 2019 02:10:02 Andrei POPESCU wrote: > > > On Ma, 27 aug 19, 14:27:02, Gene Heskett wrote: > > > What, in wheezy > > > > Do you mean Debian 7? > > > > > /lib/

Re: udev being an ass

On Wed 28 Aug 2019 at 16:04:48 -0400, Greg Wooledge wrote: > On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote: > > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > > > > I've resorted to the chattr on more than one occasion. Works well if you > > > can get it all done before b

Re: udev being an ass

eezy, and jessie, and *possibly* stretch, the persistent interface names that are stored in /etc/udev/rules.d/70-persistent-net.rules are created by /lib/udev/rules.d/75-persistent-net-generator.rules. If for some reason one wishes to AVOID having udev's persistent interface names in these old

Re: udev being an ass

On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote: > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > > > I've resorted to the chattr on more than one occasion. Works well if you > > can get it all done before before the timer runs the N-M script again. > > Users (particularly ne

Re: udev being an ass

On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote: > I've resorted to the chattr on more than one occasion. Works well if you > can get it all done before before the timer runs the N-M script again. Users (particularly new users) who read chattr(1), and who think getting their own way wi

Re: udev being an ass

On Wednesday 28 August 2019 12:53:15 Greg Wooledge wrote: > On Wed, Aug 28, 2019 at 12:26:05PM -0400, Gene Heskett wrote: > > So: delete /etc/udev/rules.d/70-persistent-net.rules AND edit /e/n/i > > to put it back on eth0 where it belongs and it should work. > > Only

Re: udev being an ass

> > > > > > > > > > > > But udevs UN-persistent rules have apparently run out > > > > > > > > > of eth0 names, renaming the only ethernet port it has > > > > > > > > > to eth2. So I either

Re: udev being an ass

On Wed, Aug 28, 2019 at 12:26:05PM -0400, Gene Heskett wrote: > So: delete /etc/udev/rules.d/70-persistent-net.rules AND edit /e/n/i to > put it back on eth0 where it belongs and it should work. Only on machines that have precisely ONE (1) network interface. On any machine with more th

Re: udev being an ass

On Wednesday 28 August 2019 10:54:56 Curt wrote: > On 2019-08-28, Gene Heskett wrote: > > It may, looks as if it could, but by itself lacks sufficient > > context to ring any bells. > > https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.ht >ml >

Re: udev being an ass

rently run out of > > > > > > > > eth0 names, renaming the only ethernet port it has to > > > > > > > > eth2. So I either rename it to eth2 in /e/n/i, or kill > > > > > > > > the rule that advances the name. Since those

Re: udev being an ass

On 2019-08-28, Gene Heskett wrote: > > It may, looks as if it could, but by itself lacks sufficient context to > ring any bells. https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.html Drop Revert-udev-network-device-renaming-immediately-give.patch. ... In case yo

Re: udev being an ass

2019 at 16:13:25 (-0400), Greg Wooledge wrote: > > > > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote: > > > > > > I'll do it, but the date on it is today, so I suspect > > > > > > something in /lib/udev/rules.d is behind the

Re: udev being an ass

On Wednesday 28 August 2019 08:34:17 Curt wrote: > On 2019-08-28, Gene Heskett wrote: > >> in Bullseye it appears that > >> '/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort > >> of maybe work in specifically unspecified cases (if

Re: udev being an ass

On 2019-08-28, Gene Heskett wrote: > >> in Bullseye it appears that >> '/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort of >> maybe work in specifically unspecified cases (if I understood a recent >> announcement here correctly). &

Re: udev being an ass

On Wednesday 28 August 2019 05:58:09 Curt wrote: > On 2019-08-27, Gene Heskett wrote: > >> In spite of posts about it in -user, you are just about clueless > >> about status of /etc/udev/rules.d/70-persistent-net.rules, aren't > >> you? > > > >

Re: udev being an ass

On 2019-08-27, Gene Heskett wrote: >> >> In spite of posts about it in -user, you are just about clueless about >> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you? >> > I can read them just fine. But when written in swahili, they aren't that

Re: udev being an ass

On Wednesday 28 August 2019 02:35:51 Felix Miata wrote: > Andrei POPESCU composed on 2019-08-28 09:10 (UTC+0300): > > Gene Heskett wrote: > >> What, in wheezy > > > > Do you mean Debian 7? > > > >> /lib/udev/rules.d rule do I nuke so eth0 remains eth0

Re: udev being an ass

On Wednesday 28 August 2019 02:10:02 Andrei POPESCU wrote: > On Ma, 27 aug 19, 14:27:02, Gene Heskett wrote: > > What, in wheezy > > Do you mean Debian 7? > > > /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of > >which box I put that drive in? >

Re: udev being an ass

On Wednesday 28 August 2019 01:45:04 Felmon Davis wrote: > On Tue, 27 Aug 2019, Gene Heskett wrote: > > On Tuesday 27 August 2019 16:01:30 Brian wrote: > >> (P.S. > >> Could we have posts without medical details. They make me feel > >> quesy). > > > > Life, fully lived, can and will have its queas

Re: udev being an ass

; > > except for the HD. > > > > > > > > > > > > > > But udevs UN-persistent rules have apparently run out of > > > > > > > eth0 names, renaming the only ethernet port it has to > > > > > > > eth2. So I either

  1   2   3   4   5   6   7   8   9   10   >