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

Groups > linux.debian.user > #239674 > unrolled thread

/usr/sbin/reboot: disabled in systemd-nspawn container

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

Contents

  /usr/sbin/reboot: disabled in systemd-nspawn container "sp007@caiway.net" <sp007@caiway.net> - 2021-09-04 15:00 +0200
    Re: /usr/sbin/reboot: disabled in systemd-nspawn container Reco <recoverym4n@enotuniq.net> - 2021-09-04 16:10 +0200
      Re: /usr/sbin/reboot: disabled in systemd-nspawn container "sp007@caiway.net" <sp007@caiway.net> - 2021-09-04 17:10 +0200
        Re: /usr/sbin/reboot: disabled in systemd-nspawn container Reco <recoverym4n@enotuniq.net> - 2021-09-04 17:40 +0200
        Re: /usr/sbin/reboot: disabled in systemd-nspawn container Greg Wooledge <greg@wooledge.org> - 2021-09-04 18:00 +0200
          Re: /usr/sbin/reboot: disabled in systemd-nspawn container Stefan Monnier <monnier@iro.umontreal.ca> - 2021-09-04 19:20 +0200
            Re: /usr/sbin/reboot: disabled in systemd-nspawn container Greg Wooledge <greg@wooledge.org> - 2021-09-04 19:40 +0200
              Re: /usr/sbin/reboot: disabled in systemd-nspawn container The Wanderer <wanderer@fastmail.fm> - 2021-09-04 21:10 +0200
                Re: /usr/sbin/reboot: disabled in systemd-nspawn container "sp007@caiway.net" <sp007@caiway.net> - 2021-09-04 22:40 +0200
      Re: /usr/sbin/reboot: disabled in systemd-nspawn container "sp007@caiway.net" <sp007@caiway.net> - 2021-09-04 17:40 +0200
    Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED "sp007@caiway.net" <sp007@caiway.net> - 2021-09-04 18:00 +0200
      Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-12 09:50 +0200

#239674 — /usr/sbin/reboot: disabled in systemd-nspawn container

Hi,

Suddenly I can no longer reboot or poweroff my up-to-date
bullseye system:

# reboot
/usr/sbin/reboot: disabled in systemd-nspawn container

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.



# poweroff
/usr/sbin/poweroff: disabled in systemd-nspawn container

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.



I am definitively NOT in a container.

I did experiment with systemd-nspawn some weeks ago and stopped using
it.
I did often reboot/poweroff this system after this, and I have no idea
where to look for the bug.

# apt purge systemd-container does not help


Now I do Alt+SysReq+...to reboot/poweroff




tia

[toc] | [next] | [standalone]

#239679

	Hi.

On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp007@caiway.net wrote:
> Suddenly I can no longer reboot or poweroff my up-to-date
> bullseye system:
> 
> # reboot
> /usr/sbin/reboot: disabled in systemd-nspawn container

Unless I'm mistaken, these messages are not generated by systemd.
In fact, there's nothing that resembles such messages in systemd
sources.

So, try this, for starters:

/bin/systemd reboot

And, what about these:

ls -al /sbin/reboot
file /sbin/reboot

Reco

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

#239680

On Sat, 4 Sep 2021 16:42:45 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp007@caiway.net wrote:
> > Suddenly I can no longer reboot or poweroff my up-to-date
> > bullseye system:
> > 
> > # reboot
> > /usr/sbin/reboot: disabled in systemd-nspawn container
> 
> Unless I'm mistaken, these messages are not generated by systemd.
> In fact, there's nothing that resembles such messages in systemd
> sources.
> 
> So, try this, for starters:
> 
> /bin/systemd reboot
> 

# /bin/systemd reboot
Excess arguments.

> And, what about these:
> 
> ls -al /sbin/reboot

# ls -al /sbin/reboot
-rwxr-xr-x 1 root root 319 Mar 24 05:22 /sbin/reboot


> file /sbin/reboot
> 

# file /sbin/reboot
/sbin/reboot: POSIX shell script, ASCII text executable

> Reco
> 

thx

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

#239681

On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
> On Sat, 4 Sep 2021 16:42:45 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > 	Hi.
> > 
> > On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp007@caiway.net wrote:
> > > Suddenly I can no longer reboot or poweroff my up-to-date
> > > bullseye system:
> > > 
> > > # reboot
> > > /usr/sbin/reboot: disabled in systemd-nspawn container
> > 
> > Unless I'm mistaken, these messages are not generated by systemd.
> > In fact, there's nothing that resembles such messages in systemd
> > sources.
> > 
> > So, try this, for starters:
> > 
> > /bin/systemd reboot
> > 
> 
> # /bin/systemd reboot
> Excess arguments.

Er, I meant /bin/systemctl reboot.
But anyway,

> > file /sbin/reboot
> 
> # file /sbin/reboot
> /sbin/reboot: POSIX shell script, ASCII text executable

That's not how it's supposed to be.
Somehow these shell scripts replaced actual halt, reboot and poweroff.

My suggestion:

ln -sf /bin/systemctl /sbin/reboot
ln -sf /bin/systemctl /sbin/halt
ln -sf /bin/systemctl /sbin/poweroff

Or, even better:

apt install --reinstall systemd-sysv

Reco

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

#239685

On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
> On Sat, 4 Sep 2021 16:42:45 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > 	Hi.
> > 
> > On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp007@caiway.net wrote:
> > > Suddenly I can no longer reboot or poweroff my up-to-date
> > > bullseye system:
> > > 
> > > # reboot
> > > /usr/sbin/reboot: disabled in systemd-nspawn container
> > 
> > Unless I'm mistaken, these messages are not generated by systemd.
> > In fact, there's nothing that resembles such messages in systemd
> > sources.
> > 
> > So, try this, for starters:
> > 
> > /bin/systemd reboot
> > 
> 
> # /bin/systemd reboot
> Excess arguments.
> 
> > And, what about these:
> > 
> > ls -al /sbin/reboot
> 
> # ls -al /sbin/reboot
> -rwxr-xr-x 1 root root 319 Mar 24 05:22 /sbin/reboot
> 
> 
> > file /sbin/reboot
> > 
> 
> # file /sbin/reboot
> /sbin/reboot: POSIX shell script, ASCII text executable

That's not normal for a bullseye system using systemd for init.

unicorn:~$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 14 Jul 13 13:29 /sbin/reboot -> /bin/systemctl*

You might need to reinstall the systemd-sysv package, maybe.  I'm
not sure what you did or how your system got into this state.

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

#239687

Greg Wooledge [2021-09-04 11:35:25] wrote:
> On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
>> # file /sbin/reboot
>> /sbin/reboot: POSIX shell script, ASCII text executable
>
> That's not normal for a bullseye system using systemd for init.

Indeed.

> I'm not sure what you did or how your system got into this state.

Maybe

    dpkg -S /sbin/reboot /usr/sbin/reboot

could give us a clue?


        Stefan
    

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

#239688

On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
> Greg Wooledge [2021-09-04 11:35:25] wrote:
> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
> >> # file /sbin/reboot
> >> /sbin/reboot: POSIX shell script, ASCII text executable
> >
> > That's not normal for a bullseye system using systemd for init.
> 
> Indeed.
> 
> > I'm not sure what you did or how your system got into this state.
> 
> Maybe
> 
>     dpkg -S /sbin/reboot /usr/sbin/reboot
> 
> could give us a clue?

>From the other part of the thread, it looks like they installed a
package from a different operating system.  One that interfered with
the Debian init system.

This is why we tell people: NEVER mix packages from different operating
systems.  Especially low-level ones like systemd.

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

#239689

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

On 2021-09-04 at 13:20, Greg Wooledge wrote:

> On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
>
>> Greg Wooledge [2021-09-04 11:35:25] wrote:
>> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
>> >> # file /sbin/reboot
>> >> /sbin/reboot: POSIX shell script, ASCII text executable
>> >
>> > That's not normal for a bullseye system using systemd for init.
>> 
>> Indeed.
>> 
>> > I'm not sure what you did or how your system got into this state.
>> 
>> Maybe
>> 
>>     dpkg -S /sbin/reboot /usr/sbin/reboot
>> 
>> could give us a clue?
> 
> From the other part of the thread, it looks like they installed a
> package from a different operating system.  One that interfered with
> the Debian init system.
> 
> This is why we tell people: NEVER mix packages from different operating
> systems.  Especially low-level ones like systemd.

Based on what I read of the thread, that package is
progress-linux-container.

$ apt-cache policy progress-linux-container
progress-linux-container:
  Installed: (none)
  Candidate: 20210101-2
  Version table:
     20210101-2 900
        800 http://ftp.us.debian.org/debian stable/main amd64 Packages
        800 http://ftp.us.debian.org/debian stable/main i386 Packages
        900 http://ftp.us.debian.org/debian testing/main amd64 Packages
        900 http://ftp.us.debian.org/debian testing/main i386 Packages

progress-linux-container is a package in Debian, and at least at a
glance, is apparently meant for installing on a Debian system. (Or else
it made it from the downstream distribution into upstream Debian by
mistake, somehow.)

It's just not meant for installing on a host system; it's meant for
installing only inside a container.

What resulted in it being installed in the OP's case is unclear (the OP
has said he doesn't know), but at least at a glance it doesn't look like
this is a case of mixing different operating systems, unless I'm
misunderstanding what you mean by that.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#239690

On Sat, 04 Sep 2021 14:46:21 -0400
The Wanderer <wanderer@fastmail.fm> wrote:

> On 2021-09-04 at 13:20, Greg Wooledge wrote:
> 
> > On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
> >
> >> Greg Wooledge [2021-09-04 11:35:25] wrote:
> >> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp007@caiway.net wrote:
> >> >> # file /sbin/reboot

> 
> Based on what I read of the thread, that package is
> progress-linux-container.
> 
> $ apt-cache policy progress-linux-container
> progress-linux-container:
>   Installed: (none)
>   Candidate: 20210101-2
>   Version table:
>      20210101-2 900
>         800 http://ftp.us.debian.org/debian stable/main amd64 Packages
>         800 http://ftp.us.debian.org/debian stable/main i386 Packages
>         900 http://ftp.us.debian.org/debian testing/main amd64
> Packages 900 http://ftp.us.debian.org/debian testing/main i386
> Packages
> 
> progress-linux-container is a package in Debian, and at least at a
> glance, is apparently meant for installing on a Debian system. (Or
> else it made it from the downstream distribution into upstream Debian
> by mistake, somehow.)
> 
> It's just not meant for installing on a host system; it's meant for
> installing only inside a container.
> 
> What resulted in it being installed in the OP's case is unclear (the
> OP has said he doesn't know), but at least at a glance it doesn't
> look like this is a case of mixing different operating systems,
> unless I'm misunderstanding what you mean by that.
> 

Thw Wanderer, you are absolutely right
our posts may have crossed
the case is solved
see above


# apt remove progress-linux-container
solved the issue

and in addition,
I must have installed by hand, in the wrong place
in OS not inside container

my bad


glad it is cleared
thanks

sp007

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

#239682

On Sat, 4 Sep 2021 16:42:45 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.

> /bin/systemd reboot
> 
> And, what about these:
> 
> ls -al /sbin/reboot
> file /sbin/reboot
> 
> Reco
> 

the commands poweroff and reboot are textfiles.
I have no idea

# mcedit /sbin/reboot:
#!/bin/sh

echo "${0}: disabled in systemd-nspawn container"

if [ -e /etc/open-infrastructure/container/shutdown.txt ]
then
        cat /etc/open-infrastructure/container/shutdown.txt
elif [ -e /usr/share/open-infrastructure/container/shutdown.txt ]
then
        cat /usr/share/open-infrastructure/container/shutdown.txt
fi

exit 1

#eof

# mcedit /sbin/poweroff:
#!/bin/sh

echo "${0}: disabled in systemd-nspawn container"

if [ -e /etc/open-infrastructure/container/shutdown.txt ]
then
        cat /etc/open-infrastructure/container/shutdown.txt
elif [ -e /usr/share/open-infrastructure/container/shutdown.txt ]
then
        cat /usr/share/open-infrastructure/container/shutdown.txt
fi

exit 1



# cat /usr/share/open-infrastructure/container/shutdown.txt

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.

So the reason is found, now I have to find out who/what take over these
basic commands

I have no packages with open-infrastructure installed

tia

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

#239684 — Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED

SOLVED

/usr/share/open-infrastructure/container/shutdown.txt
is from package progress-linux-container:

Progress Linux is a Debian derivative distribution focused on system
integration.

This package is a metapackage to be installed in a container
(systemd-nspawn).

# apt remove progress-linux-container

let's see if this is the problem

YES

I have no idea why it was installed.

Thanks, Reco

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

#239902 — Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED

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

On Sb, 04 sep 21, 17:35:49, sp007@caiway.net wrote:
> SOLVED
> 
> /usr/share/open-infrastructure/container/shutdown.txt
> is from package progress-linux-container:
> 
> Progress Linux is a Debian derivative distribution focused on system
> integration.
> 
> This package is a metapackage to be installed in a container
> (systemd-nspawn).
> 
> # apt remove progress-linux-container

You should probably `purge` it, `remove` can leave stuff behind.

(didn't bother to check for this particular package, but anyway, I like 
my `dpkg -l` "clean")

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

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

csiph-web