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

Groups > linux.debian.devel > #116165 > unrolled thread

Improvement of headless server upgrades

Back to article view | Back to linux.debian.devel

Contents

  Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-05 03:40 +0100
    Re: Improvement of headless server upgrades Fabio Fantoni <fantonifabio@tiscali.it> - 2025-03-05 10:30 +0100
    Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-05 16:10 +0100
      Re: Improvement of headless server upgrades Michael Banck <mbanck@debian.org> - 2025-03-05 16:20 +0100
        Re: Improvement of headless server upgrades Bjørn Mork <bjorn@mork.no> - 2025-03-05 17:50 +0100
          Re: Improvement of headless server upgrades Matthias Urlichs <matthias@urlichs.de> - 2025-03-05 19:30 +0100
            Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-05 20:40 +0100
              Re: Improvement of headless server upgrades Soren Stoutner <soren@debian.org> - 2025-03-05 21:00 +0100
            Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-05 20:40 +0100
            Re: Improvement of headless server upgrades Bjørn Mork <bjorn@mork.no> - 2025-03-05 21:10 +0100
              Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-05 21:40 +0100
                Re: Improvement of headless server upgrades Matthias Urlichs <matthias@urlichs.de> - 2025-03-05 22:30 +0100
                  Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-06 09:00 +0100
              Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-05 21:40 +0100
        Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-05 20:40 +0100
          Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-06 10:10 +0100
      Re: Improvement of headless server upgrades Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-06 15:50 +0100
      Re: Improvement of headless server upgrades Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-03-07 01:50 +0100
    Re: Improvement of headless server upgrades Helmut Grohne <helmut@subdivi.de> - 2025-03-06 06:50 +0100
      Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-07 00:10 +0100
    Re: Improvement of headless server upgrades Holger Levsen <holger@layer-acht.org> - 2025-03-06 09:50 +0100
      Re: Improvement of headless server upgrades Fabio Fantoni <fantonifabio@tiscali.it> - 2025-03-06 11:30 +0100
      Re: Improvement of headless server upgrades Wookey <wookey@wookware.org> - 2025-03-06 15:20 +0100
        Re: Improvement of headless server upgrades Andrey Rakhmatullin <wrar@debian.org> - 2025-03-06 17:40 +0100
        Re: Improvement of headless server upgrades Bjørn Mork <bjorn@mork.no> - 2025-03-06 18:00 +0100
        Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-07 00:00 +0100
          Re: Improvement of headless server upgrades "Helmut K. C. Tessarek" <tessarek@evermeet.cx> - 2025-03-07 00:20 +0100

Page 1 of 2  [1] 2  Next page →

#116165 — Improvement of headless server upgrades

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

This is my first mail in a Debian mailing list and I hope I've chosen 
the correct one. There are way too many lists thus please direct me to 
the correct one, in case I messed up.

I would like to make a suggestion for release upgrades. It should not be 
a huge effort to implement and I can work with someone to make this happen.

In the last few days I ran into a serious issue when upgrading to newer 
releases on 3 headless servers: the network connection went dead.
In the first situation the interface name changed from eth0 to end0 and 
after the reboot my adapter got a link-local address.
In the second situation dhcpcd was replaced by Network Manager and once 
again the network was dead.

Please don't get me wrong, I am not against keeping up with the times 
and use new technology. Far from it.
But in both cases I had to connect my headless machines to a monitor and 
keyboard and fix the network issues. Usually this is not a problem, but 
sometimes it might be impossible.
In both cases I did not even know that these things would happen. The 
dist-upgrade made the changes without my input and I was left in the 
dark. Iamgine my surprise when I couldn't connect to my boxes anymore.

Both network "outages" could have been prevented by adding a note at the 
end of the dist-upgrade output.

e.g. something like the following (monospace font required for the 
"Attention" text):

     _  _____ _____ _____ _   _ _____ ___ ___  _   _
    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|

Network interface name changed: please update config files before reboot.

     _  _____ _____ _____ _   _ _____ ___ ___  _   _
    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|

Network subsystem changed: please add a system connection before reboot.

Is this something that makes sense? Often you have a remote console like 
an iLO or whatever cloud systems provide. But in some cases there is 
nothing. No console, no monitor, no keyboard. Only a power and a network 
cable.

Cheers,
   K. C.

P.S.: I go by KC, trying to avoid the Spaceballs Dark Helmet mixup.


-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

[toc] | [next] | [standalone]

#116169

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

Il 05/03/2025 02:39, Helmut K. C. Tessarek ha scritto:
> This is my first mail in a Debian mailing list and I hope I've chosen 
> the correct one. There are way too many lists thus please direct me to 
> the correct one, in case I messed up.
>
> I would like to make a suggestion for release upgrades. It should not 
> be a huge effort to implement and I can work with someone to make this 
> happen.
>
> In the last few days I ran into a serious issue when upgrading to 
> newer releases on 3 headless servers: the network connection went dead.
> In the first situation the interface name changed from eth0 to end0 
> and after the reboot my adapter got a link-local address.
> In the second situation dhcpcd was replaced by Network Manager and 
> once again the network was dead.

Hi, when you do upgrade to a new major version you should before read 
release note for important changes, also read NEWS on packages upgrade 
(that contain important changes, including the one that can require 
manual changes). It is also good to test upgrade on a test server or on 
a minor one for the first time on any major version upgrade, so you can 
spot other possible unforeseen events.

These network changes are documented and well known, I have done many 
Debian server upgrades over the years and for example those network 
changes I had seen before by documenting myself and I had made sure to 
modify correctly before the upgrade and reboot to avoid unexpected 
events. Alternatively you can also modify to force the old names.

>
> Please don't get me wrong, I am not against keeping up with the times 
> and use new technology. Far from it.
> But in both cases I had to connect my headless machines to a monitor 
> and keyboard and fix the network issues. Usually this is not a 
> problem, but sometimes it might be impossible.
> In both cases I did not even know that these things would happen. The 
> dist-upgrade made the changes without my input and I was left in the 
> dark. Iamgine my surprise when I couldn't connect to my boxes anymore.
>
> Both network "outages" could have been prevented by adding a note at 
> the end of the dist-upgrade output.
>
> e.g. something like the following (monospace font required for the 
> "Attention" text):
>
>     _  _____ _____ _____ _   _ _____ ___ ___  _   _
>    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
>   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
>  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
> /_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|
>
> Network interface name changed: please update config files before reboot.
>
>     _  _____ _____ _____ _   _ _____ ___ ___  _   _
>    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
>   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
>  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
> /_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|
>
> Network subsystem changed: please add a system connection before reboot.
>
> Is this something that makes sense? Often you have a remote console 
> like an iLO or whatever cloud systems provide. But in some cases there 
> is nothing. No console, no monitor, no keyboard. Only a power and a 
> network cable.
>
> Cheers,
>   K. C.
>
> P.S.: I go by KC, trying to avoid the Spaceballs Dark Helmet mixup.
>
>

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

#116176

On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
<tessarek@evermeet.cx> wrote:
>Both network "outages" could have been prevented by adding a note at the 
>end of the dist-upgrade output.
>
>e.g. something like the following (monospace font required for the 
>"Attention" text):
>
>     _  _____ _____ _____ _   _ _____ ___ ___  _   _
>    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
>   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
>  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
>/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|
>
>Network interface name changed: please update config files before reboot.

Why would people who do not read the NEWS.Debian or the Release Notes
read that? And how would you solve the issue of people wanting more
and more of those attention banners?

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#116177

Hi,

On Wed, Mar 05, 2025 at 04:06:56PM +0100, Marc Haber wrote:
> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
> <tessarek@evermeet.cx> wrote:
> >Both network "outages" could have been prevented by adding a note at the 
> >end of the dist-upgrade output.
> >
> >e.g. something like the following (monospace font required for the 
> >"Attention" text):
> >
> >     _  _____ _____ _____ _   _ _____ ___ ___  _   _
> >    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
> >   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
> >  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
> >/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|
> >
> >Network interface name changed: please update config files before reboot.
> 
> Why would people who do not read the NEWS.Debian or the Release Notes
> read that? And how would you solve the issue of people wanting more
> and more of those attention banners?

Presumably because it will be written directly to their terminal.

Things in NEWS.Debian or the release notes probably only can caution
users to be aware of possible problems; if we are able to detect that
there will be a problem and warn the person running the command, that
sounds sensible to me, but I have not looked at the details.


Michael

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

#116181

Michael Banck <mbanck@debian.org> writes:
> On Wed, Mar 05, 2025 at 04:06:56PM +0100, Marc Haber wrote:
>> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
>> <tessarek@evermeet.cx> wrote:
>> >Both network "outages" could have been prevented by adding a note at the 
>> >end of the dist-upgrade output.
>> >
>> >e.g. something like the following (monospace font required for the 
>> >"Attention" text):
>> >
>> >     _  _____ _____ _____ _   _ _____ ___ ___  _   _
>> >    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
>> >   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
>> >  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
>> >/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|
>> >
>> >Network interface name changed: please update config files before reboot.
>> 
>> Why would people who do not read the NEWS.Debian or the Release Notes
>> read that? And how would you solve the issue of people wanting more
>> and more of those attention banners?
>
> Presumably because it will be written directly to their terminal.

apt install apt-listchanges


Bjørn

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

#116185

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

On 05.03.25 17:16, Bjørn Mork wrote:
> apt install apt-listchanges

To be fair, apt-listchanges lists a whole lot of changes, esp. when you 
do a dist-upgrade.

Noticing the one change among the umpteen more-or-less-major NEWS 
entries that actually affects the ability of your system to safely 
reboot with the same network configuration is not a trivial task, even 
for reasonably experienced sysadmins.

-- 
-- regards
-- 
-- Matthias Urlichs

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

#116190

On Wed, Mar 05, 2025 at 06:29:26PM +0100, Matthias Urlichs wrote:
>Noticing the one change among the umpteen more-or-less-major NEWS 
>entries that actually affects the ability of your system to safely 
>reboot with the same network configuration is not a trivial task, even 
>for reasonably experienced sysadmins.

It is also a challenge for a package maintainer to judge WHEN to drop 
a higher priority NEWS entry.

I think that our release notes recommend one or another way for console 
access for upgrades for exactly this reason.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

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

#116193

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

On Wednesday, March 5, 2025 12:34:27 PM MST Marc Haber wrote:
> On Wed, Mar 05, 2025 at 06:29:26PM +0100, Matthias Urlichs wrote:
> >Noticing the one change among the umpteen more-or-less-major NEWS
> >entries that actually affects the ability of your system to safely
> >reboot with the same network configuration is not a trivial task, even
> >for reasonably experienced sysadmins.
> 
> It is also a challenge for a package maintainer to judge WHEN to drop
> a higher priority NEWS entry.
> 
> I think that our release notes recommend one or another way for console
> access for upgrades for exactly this reason.

I would not be opposed to some type of special warning that an upgrade would 
break remote access on a particular machine if it were possible to produce the 
warning reliably, but I don't think it would be that easy to implement.  
Sometimes it might be easy to detect, but I think a lot of times it isn't easy 
for Debian to know when the change will cause breakage or not, and if people 
become dependent on these warnings instead of actually reading the release 
notes and the NEWS entries, then I can see this causing more problems than it 
solves.

If you are doing an upgrade on a remote or headless system, it probably 
behooves your time to read over the release notes and the NEWS entries to 
understand how changes may affect your connectivity.  As a human you are much 
more likely to know if the change will break remote access than any automated 
check Debian can produce.

Now, if any of the breakages being discussed were not sufficiently documented in 
the release notes or NEWS entries, that is a different issue and one which 
should probably be addressed directly to the package that made the breaking 
change.

-- 
Soren Stoutner
soren@debian.org

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

#116191

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

On 2025-03-05 12:29, Matthias Urlichs wrote:
> Noticing the one change among the umpteen more-or-less-major NEWS 
> entries that actually affects the ability of your system to safely 
> reboot with the same network configuration is not a trivial task, even 
> for reasonably experienced sysadmins.

I couldn't agree more.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

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

#116194

Matthias Urlichs <matthias@urlichs.de> writes:
> On 05.03.25 17:16, Bjørn Mork wrote:
>> apt install apt-listchanges
>
> To be fair, apt-listchanges lists a whole lot of changes, esp. when
> you do a dist-upgrade.
>
> Noticing the one change among the umpteen more-or-less-major NEWS
> entries that actually affects the ability of your system to safely
> reboot with the same network configuration is not a trivial task, even
> for reasonably experienced sysadmins.

I agree. But I don't see what makes the proposal any better.

We can (and do, AFAIK) discuss which items belong in NEWS.  But there
are many more-or-less-major changes which might require attention when
you do a dist-upgrade. Filtering this list down to one or two items is
not realistic. And prefixing the list with ATTENTION won't make the job
any easier.


Bjørn

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

#116195

On Wed, Mar 05, 2025 at 03:32:51PM -0500, Helmut K. C. Tessarek wrote:
>I doubt there are more than one or at max two items that would break 
>network connectivity.

And which of the millions of changes would that be that would break YOUR 
system?


-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

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

#116197

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

On 05.03.25 21:35, Marc Haber wrote:
> And which of the millions of changes would that be that would break 
> YOUR system? 

The number of changes that can adversely impact your ability to boot 
*or* your network connectivity (but which won't fail the upgrade!) can 
safely be assumed to be smaller than five or so.

Anything else can be fixed post-upgrade.

-- 
-- regards
-- 
-- Matthias Urlichs

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

#116206

On Wed, Mar 05, 2025 at 10:12:05PM +0100, Matthias Urlichs wrote:
>On 05.03.25 21:35, Marc Haber wrote:
>>And which of the millions of changes would that be that would break 
>>YOUR system?
>
>The number of changes that can adversely impact your ability to boot 
>*or* your network connectivity (but which won't fail the upgrade!) can 
>safely be assumed to be smaller than five or so.

And which of the millions are those five? Any small number of "false 
alerts" already will cause users to stop reading.

Maybe we could introduce a new header field where a package might create 
itself as "probably harmful to the reboot" (like grub, initramfs-tools, 
network-manager, systemd etc) and have their NEWS entries sorted first 
by apt-listchanges.

But I think that it is unrealistic to expect maintainers to classify 
their changes whether they might affect reboot.

Running a headless server without console access is a challenge. You 
_really_ need to know your way to debug such a situation. I don't think 
that we as a distribtion can change that.

In the current case, it's only a matter of hooking up a display and 
keyboard to a physically accessible system. It could be a housing server 
in a datacenter next time (been there, done that).

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

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

#116196

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

On 2025-03-05 14:51, Bjørn Mork wrote:
> We can (and do, AFAIK) discuss which items belong in NEWS.  But there
> are many more-or-less-major changes which might require attention when
> you do a dist-upgrade. Filtering this list down to one or two items is
> not realistic. And prefixing the list with ATTENTION won't make the job
> any easier.

I doubt there are more than one or at max two items that would break 
network connectivity.

In both cases it was only one item that broke my ability to connect to 
the rebooted machine.
After the dist-upgrade finishes, people would usually type reboot and 
hit enter.
If above the current prompt (where you enter 'reboot'), something like

     _  _____ _____ _____ _   _ _____ ___ ___  _   _
    / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |
   / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
  / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
/_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|

or

  ____ _____ ___  ____      ____ _____ ___  ____
/ ___|_   _/ _ \|  _ \    / ___|_   _/ _ \|  _ \
\___ \ | || | | | |_) |   \___ \ | || | | | |_) |
  ___) || || |_| |  __/     ___) || || |_| |  __/
|____/ |_| \___/|_|       |____/ |_| \___/|_|

shows up, I am pretty sure it catches your attention.

Cheers,
   K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

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

#116192

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

Hello,

Thaank you for all the replies so far.

On 2025-03-05 10:15, Michael Banck wrote:
> Presumably because it will be written directly to their terminal.

Yes, this is one of the reasons. During a dist-upgrade you receive the 
changes, but it's many, many pages long and spotting the entry that 
renders your system dead is not easy.

I am not asking to create multiple ATTENTION banners at the end. All 
issues can be fixed as long as I can connect to the machine.
Thus anything that would prevent the machine from booting (e.g. if it's 
known that the machine would not boot unless a grub-install is done) or 
having a functioning network connection, should be mentioned explicitly 
at the end.

The subject specifically points out an improvement for headless server 
upgrades. Chances are that these "special" notifications only happen now 
and then.

But it would certainly make the upgrade experience better.

Cheers,
   K. C.

P.S.: I admit that reading NEWS/UPGRADE files and articles is also 
important and that doing test migrations is best practices. On the other 
hand, it's not always possible to have a test bed for every single setup.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

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

#116212

On Wed, 5 Mar 2025 14:36:20 -0500, "Helmut K. C. Tessarek"
<tessarek@evermeet.cx> wrote:
>On the other 
>hand, it's not always possible to have a test bed for every single setup.

It is way easier to have a test bed or to arrange for console access
than even trying to cater for every situation that might happen. Rest
assured that package maintainers already try to avoid situations like
that to the best of their knowledge.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#116231

On Thu, 6 Mar 2025 14:00:46 +0100, Lee Garrett <debian@rocketjump.eu>
wrote:
>P.S.: This failure mode isn't even documented in the release notes.

But they do, don't they, recommend to have console access available
during an upgrade right?

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#116250

Lee Garrett <debian@rocketjump.eu> writes:

>> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
>> <tessarek@evermeet.cx> wrote:

>>>Network interface name changed: please update config files before reboot.

> P.S.: This failure mode isn't even documented in the release notes.

This does seem to be correct given that the OP was upgrading from buster
to bullseye. however i dont recall seeing any bugs about this in those
releases, and it seems unlikely such a big issue was missed?

changes to network naming were documented in previous release-notes including:
- buster release notes at 4.1.6 (https://www.debian.org/releases/buster/amd64/release-notes.en.txt)
- the stretch release notes at 2.2.9. (https://www.debian.org/releases/stretch/amd64/release-notes.en.txt)

so i wonder if this is perhaps fall-out from not following the
instructions on earlier upgrades?

Every version of the release notes also has sections advising on how to
upgrade over ssh (4.1.4) and probably other places in part 4 (which i
always find harder to read than expected, but the advice is quite good)

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

#116202

On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote:
> This is my first mail in a Debian mailing list and I hope I've chosen the
> correct one. There are way too many lists thus please direct me to the
> correct one, in case I messed up.

As the matter is intersecting multiple packages, it isn't the worst
choice.

> In the last few days I ran into a serious issue when upgrading to newer
> releases on 3 headless servers: the network connection went dead.
> In the first situation the interface name changed from eth0 to end0 and
> after the reboot my adapter got a link-local address.

I am surprised to see this happen. Back in older times, interfaces used
to be named like eth0, but that should not be happening since quite a
number of stable releases. Those old systems that still use eth0 today
tend to do it due to a file /etc/udev/rules.d/70-persistent-net.rules.
Does that exist and list your interface on the affected system? If not,
can you try figuring out why it was still named eth0 before upgrading?

In principle, I expect that this is an unusual circumstance and
therefore do not think it is worth mitigating.

> In the second situation dhcpcd was replaced by Network Manager and once
> again the network was dead.

Can you try figuring out what dependency caused Network Manager to be
installed? Your apt or dpkg logs may be helpful here.

> Both network "outages" could have been prevented by adding a note at the end
> of the dist-upgrade output.

There are two difficulties in this proposal. One is finding a
responsible package for printing this note and the other is properly
detecting the changed network interface name before doing the reboot
that actually changes it.

As a result of these, I suggest investing time into making the described
situations less likely rather than printing a warning.

Helmut

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

#116247

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

On 2025-03-05 07:38, Helmut Grohne wrote:
> I am surprised to see this happen. Back in older times, interfaces used
> to be named like eth0, but that should not be happening since quite a
> number of stable releases. Those old systems that still use eth0 today
> tend to do it due to a file /etc/udev/rules.d/70-persistent-net.rules.
> Does that exist and list your interface on the affected system? If not,
> can you try figuring out why it was still named eth0 before upgrading?

It was buster to bullseye. A machine I had forgotten since it was 
running perfectly.
It was my fault that I didn't read the 3000 lines of NEWS for the 
upgrade, but I have done buster upgrades before and I didn't lose 
network connectivity then. I forgot that the ifname would change.

> Can you try figuring out what dependency caused Network Manager to be
> installed? Your apt or dpkg logs may be helpful here.

I am looking into it.

Cheers,
   K. C.


-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.devel

csiph-web