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

Groups > linux.debian.bugs.rc > #369819 > 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.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Michael Stone <mstone@debian.org> - 2024-08-15 19:30 +0200
    Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Philip Hands <phil@hands.com> - 2024-08-16 17:40 +0200
      Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Colin Watson <cjwatson@debian.org> - 2024-08-16 18:00 +0200
        Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts Michael Stone <mstone@debian.org> - 2024-08-16 22:40 +0200

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

>> 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.
>
>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.

[toc] | [next] | [standalone]

#369890

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

Colin Watson <cjwatson@debian.org> writes:

> 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.)

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.

Luka, how about temporarily reverting this change to give people a
chance to prepare for it?

BTW I'm not directly affected by this AFAIK, so I'm not asking for me.

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.

I note that neither the Changelog nor the NEWS file mentioned this as a
breaking change or issued anything like a warning about it.

  https://salsa.debian.org/kernel-team/iproute2/-/commit/c4bb148dd4ed0601ca32ee8a458007d0c348d6c3

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

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

#369893

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.

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

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

#369900

On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote:
>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.

Or, of course, leave it forever since it causes no problems...

[toc] | [prev] | [standalone]

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

csiph-web