Finding how a Linux system was booted

I have a remote server, running Linux 5.19.0-41-generic x86_64, I am trying to find out how it was booted.

Apparently, it does not use systemd :

PID 1 process is bash.

ps -p 1 -o comm=
bash

Apparently, there is no GRUB, at least there is none in /usr/sbin , and

grub-install --version
-bash: grub-install: command not found

I guess, GRUB was not used at startup.

It does not seem to be a virtual machine. I checked some files. It seems to be running on bare metal. But the configuration is minimal: top shows just a handful of processes and on ssh I am prompted to "unminimize", if I need fuller functionality.

I was inclined to think that SysV was used:

ls /etc/init.d
apport          bluetooth  hwclock.sh  network-manager  procps                       rsync  udev
avahi-daemon    dbus       iwpmd       nfs-common       pulseaudio-enable-autospawn  saned  unattended-upgrades
binfmt-support  gdm3       kmod        pppd-dns         rpcbind                      ssh    x11-common

But:

runlevel
unknown

and /etc/inittab does not exist.

Q1: how to diagnose with what the thing was booted.

Q2: how to reboot it? Ideally, using systemd.

sudo reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to talk to init daemon.

sudo init 6
Couldn't find an alternative telinit implementation to spawn.

sudo shutdown -r now
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to talk to init daemon.

Thanks.

You cannot conclusively determine this without asking the person managing the system.

Linux does not record what, exactly, handed off execution to the kernel, because there’s no way to reliably determine this from the kernel itself (any mechanism that could be used is dependent on the bootloader cooperating). And there’s actually a whole slew of exotic possibilities that most people never even think about, such as UML (kernel runs as a user process in another Linux environment, kind of a weird hybrid between a VM and a container) or QEMU’s direct-kernel-boot functionality (instead of regular firmware, QEMU just initializes the VM and then loads the kernel itself from the host system and hands off execution directly to the kernel).

That all said, given that PID 1 is bash and there is no fstab it’s probably a container.

A couple of other quick notes:

• /etc/init.d is not reliably indicative of sysvinit. It actually has almost nothing to do with sysvinit aside from happening to be used by Debian-derived systems that are using sysvinit. It’s also used by some other LSB-compliant service management systems, and by OpenRC, and at least on some systemd systems it actually includes stub scripts that just call the appropriate systemctl commands.
• ‘unminimize’ is an Ubuntu thing. Ubuntu Server edition has the option of installing a super-minimal system that lacks things normally only needed for interactive sessions, as a way to provide a more secure base for systems that are managed by tools like Terraform, Cockpit, or MAAS instead of via remote shell sessions. Notably, many Ubuntu containers are set up using this base, because size matters (a lot) for container images and it’s much smaller than a normal Ubuntu root filesystem would be.

PID 1 process is bash....there is no GRUB

Most likely a container.

It does not seem to be a virtual machine. I checked some files

But you're not going to tell us which ones. I do love a guessing game.

on ssh I am prompted to "unminimize", if I need fuller functionality

It's difficult to upgrade bare metal from software.

I was inclined to think that SysV was used

pid 1 on SysV is init.

You can check if you are running in a container by looking for 'lxc' or 'docker' in /proc/self/mountinfo

how to reboot it?

If shutdown -r is not working, speak to the people who built the host.

1. cat /proc/cmdline should reveal how it happened to not run the init service; however, this is not definitive. Simple cases will have something like init=/bin/bash in the kernel command line, but in general case this is impossible to determine. For example, if some interaction happened within initramfs, you'd not be able to find which one, but you'll be still able to find out there was debug flag in use so there was non-standard initramfs path used. Also, examining init script in the initramfs image might be helpful in this case.

2. Stop all services, unmount all filesystems possible, remount everything else as read-only, sync and then reboot -f; look here.

Note that if bash is run like that, it is running already as root; you can do anything to the system even without sudo. Check with whoami.