Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1208393 > unrolled thread

Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Michael Stone <mstone@debian.org> - 2024-08-14 21:40 +0200
    Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2024-08-15 19:40 +0200
      Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Nilesh Patra <nilesh@debian.org> - 2024-08-15 19:50 +0200
        Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Colin Watson <cjwatson@debian.org> - 2024-08-16 00:30 +0200
          Bug#1064795: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Ben Hutchings <ben@decadent.org.uk> - 2024-08-22 02:20 +0200

#1208393 — Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

Package: iproute2
Version: 6.10.0-1
Severity: critical
Justification: breaks the whole system

The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that failed the network was not
configured. This meant having to boot into single user mode for diagnostics
because systemd hung forever waiting for the network.

My ideal solution would be to revert 1064795 and mark it "wontfix" as there's
no way to know how many users have locally written scripts that call ip via
what used to be a perfectly valid path (and because removing the symlink buys
exactly nothing as far as I can tell).

A less satisfactory solution would be to add a versioned Breaks and a version
of the vlan package with a different path to /sbin/ip. (And, of course, any
other package that might have broken, not including local scripts which we
can't possibly identify.)

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.87
ii  libbpf1                1:1.4.5-1
ii  libc6                  2.39-6
ii  libcap2                1:2.66-5
ii  libcap2-bin            1:2.66-5
ii  libdb5.3t64            5.3.28+dfsg2-7
ii  libelf1t64             0.191-2
ii  libmnl0                1.0.5-2+b1
ii  libselinux1            3.5-2+b4
ii  libtirpc3t64           1.3.4+ds-1.3
ii  libxtables12           1.8.10-4

iproute2 recommends no packages.

Versions of packages iproute2 suggests:
ii  python3  3.12.5-1

-- debconf information excluded

[toc] | [next] | [standalone]

#1208517

[Multipart message — attachments visible in raw view] — view raw

At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > This change was noted in NEWS.
> > 
> > I would suggest hooking your config into something that uses the
> > network-online.target target, with a timeout like network-manager
> > and networkd do, so that the boot process doesn't hang. If it's a
> > simple unit, it's enough to add RuntimeMaxSec= to it, so that it's
> > killed if it doesn't work within the configured timeout.
> 
> It's just so depressing that this is how debian works now. We used to
> try to not break things, now the answer is "you should have read the
> NEWS, and known that unrelated packages were going to break, and
> reconfigured standard debian network tools to add non-default
> timeouts". All because the aesthetic preference for not having the
> same binary appear in two different paths is a higher priority than
> keeping systems working.

"Move fast and break as much stuff as possible, or Debian will be doomed
to irrelevance.  I'll be SABDFL someday!"

The creed of the _impactful_ developer.

Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#1208519

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > This change was noted in NEWS.
> > > 
> > > I would suggest hooking your config into something that uses the
> > > network-online.target target, with a timeout like network-manager
> > > and networkd do, so that the boot process doesn't hang. If it's a
> > > simple unit, it's enough to add RuntimeMaxSec= to it, so that it's
> > > killed if it doesn't work within the configured timeout.
> > 
> > It's just so depressing that this is how debian works now. We used to
> > try to not break things, now the answer is "you should have read the
> > NEWS, and known that unrelated packages were going to break, and
> > reconfigured standard debian network tools to add non-default
> > timeouts". All because the aesthetic preference for not having the
> > same binary appear in two different paths is a higher priority than
> > keeping systems working.
> 
> "Move fast and break as much stuff as possible, or Debian will be doomed
> to irrelevance.  I'll be SABDFL someday!"
> 
> The creed of the _impactful_ developer.

It looks like a pretty pointless change - breaks several scripts for example.
It was/is common to assume /sbin/ip to be present and usable.
Michael's bug report does make sense to me. Such a change is even causing
systems to not bootup.

Best,
Nilesh

[toc] | [prev] | [next] | [standalone]

#1208551

On Thu, Aug 15, 2024 at 11:14:41PM +0530, Nilesh Patra wrote:
> On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> > At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > It's just so depressing that this is how debian works now. We used to
> > > try to not break things, now the answer is "you should have read the
> > > NEWS, and known that unrelated packages were going to break, and
> > > reconfigured standard debian network tools to add non-default
> > > timeouts". All because the aesthetic preference for not having the
> > > same binary appear in two different paths is a higher priority than
> > > keeping systems working.
> > 
> > "Move fast and break as much stuff as possible, or Debian will be doomed
> > to irrelevance.  I'll be SABDFL someday!"
> > 
> > The creed of the _impactful_ developer.
> 
> It looks like a pretty pointless change - breaks several scripts for example.
> It was/is common to assume /sbin/ip to be present and usable.
> Michael's bug report does make sense to me. Such a change is even causing
> systems to not bootup.

On 2024-07-14 (five days before the iproute2 change was made), there was
this conversation on #debian-devel:

  19:14 <petn-randall> Is there a reason why iproute2 ships a symlink
  from /sbin/ip to /bin/ip? I've looked into the packaging repo and it
  seems to predate the git log.
  ...
  19:52 <cjwatson> petn-randall:
  https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has
  a pretty non-trivial list of things that would need fixed before
  removing that (and of course some false positives)

I realize it wasn't petn-randall who made this change, but it seems a
big coincidence that the symlink was dropped a few days after this IRC
conversation; and yet it seems nobody bothered to do the most basic due
diligence that I pointed out here, which is kind of sad.  (I fixed
wireless-tools after this change caused an RC bug there.)

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#1209443 — Bug#1064795: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2024-08-16 at 16:54 +0100, Colin Watson wrote:
> On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> > I think it probably was just a coincidence, since it looks like the
> > change was made in order to fix #1064795 which was reported on
> > 25 Feb 2024.
> 
> Ah, good to know, thanks.  I didn't notice that since it wasn't
> mentioned in the iproute2 changelog.
> 
> > It just strikes me as obvious that removing any long-standing binary
> > path in Debian is pretty-much bound to break someone's system, and if
> > you want to do that you really ought to at least check, and preferably
> > try to work out a way of warning them about it, or fixing the breakage
> > first.
> 
> Quite.  If nothing else, I think the code actually in the Debian archive
> that relies on the old path ought to be changed _first_, e.g. via an
> MBF.  I see a bunch of cases that are relatively subtle and might suck a
> lot of other people's time trying to debug them from cold, such as
> AppArmor profiles and example scripts, and it's just good manners to
> give maintainers an explicit heads-up.

I've made a team upload of iproute2 (version 6.10.0-2) with this change
reverted.

Luca, please leave the symlink in place at least as long as there are
packages that rely on it.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web