Setting up a VPS w/ Diet Pi - GRUB Issue

Troubleshooting
1

Greetings,

I am setting up a VPS to run Diet Pi, however when attempting to install the packaged OS it also attempts to install GRUB.

The VPS uses KVM so I tried using the standard VM image and also the Native PC image - I was able to use a ‘hold package’ command for GRUB on the Native PC Image which worked, but I had to destroy that VM for other reasons and now I cannot remember how I did it. Either way, I was hoping for a better solution.

Unfortunately it’s not very easy for me to just spin-up an image that isn’t in the VPS provider’s default list of images - I have to submit a ticket to have them handle it, but they have a quick turn-around time.

So, is there any way to stop the GRUB installation on these images?

2

GRUB comes pre-installed with our x86_64 VM images. KVM does not support it? All KVM-based virtualizers we ship images for, like Proxmox, work well with it.

So the pre-installed GRUB is not an issue, but only when GRUB is updated it causes issues? In which way? I wonder whether GRUB is an issue at all, but used properly, but only the update fails. Might the only problem be that the root filesystem is not stored on /dev/sda but on a different drive naming scheme (echo "$G_ROOTFS_DEV")? This information should be automatically adjusted on first boot, but maybe it fails. In this case it needs to be entered manually on a GRUB package upgrade, for it to know whether to flash GRUB to.

3

Hmm, I am really not sure. But now that you mention the update aspect, I do recall it failing at that point. Is there a way around this?

Like I said, the VPS provider doesn’t have Diet Pi OS in their image library, but I can spin-up the latest Debian Bullseye image quickly, and as many times as I wish.

I also tried converting an instance of Debian Bullseye into Diet Pi, however I ran across the same issue.

Is there a way to stop the update (I would not prefer this solution as I assume it will pop up later) or change the command to properly match the right drive?

I will attempt to do another conversion now and post the error I get…

4

Well, now all is working. I spun-up a fresh Debian Bullseye instance and used the conversion script - I selected VM and the whole process worked perfectly. I believe I even saw the script confirm the absence of SDA and SDA1, and confirm VDA and VDA1 were present.

Weirdly, when I ran apt update and apt upgrade on the fresh instance (prior to running the Diet Pi conversion script), I received the following error (I selected VDA which seemed to work without any problem):

The GRUB boot loader was previously installed to a disk that is no longer present, or whose unique identifier has changed for some
reason. It is important to make sure that the installed GRUB core image stays in sync with GRUB modules and grub.cfg. Please check
again to make sure that GRUB is written to the appropriate boot devices.

If youre unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.

Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However,
this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.

GRUB install devices:
[*] /dev/vda (53687 MB; ???)
[ ] /dev/vda1 (53686 MB; ???)
5

Yes this was correct procedure.

6

Thanks again for the assistane - I do have one more question regarding “Fail2Ban”…

I see that the jail.conf shows the following:

[DEFAULT]
enabled = true
ignoreip = 127.0.0.1/8
ignorecommand =
backend = systemd
mode = normal
filter = %(__name__)s[mode=%(mode)s]
findtime = 600
maxretry = 3
bantime = 600
banaction = route
action = %(banaction)s[blocktype=blackhole]

[dropbear]

[sshd]
# Mode: normal (default), ddos, extra or aggressive (combines all)
# See "filter.d/sshd.conf" for details.
#mode = normal
  1. Since I am using DropBear SSH, do I need to add enable=true since it does not currently show it? The Diet Pi Docs state that both SSH software packages are enabled by default, but I just wanted to make sure.
  2. I would like to add Portainer to the jail.conf file - would the following be the correct way to do it?
[portainer]
enable = true
mode = normal
  1. If a software package has a space or dash in it (e.g.; pi-hole), would the following be correct?
[pi-hole]
enable = true
mode = normal
  1. The Diet Pi Docs show enable = true, however in the jail.conf file under [DEFAULT], it shows enabled = true. Which one should be used?

Thanks again.

7

It should be enabled already, and nothing would need to be configured.

Both configurations are available ootb. No need to change anything.

I doubted configuration for portainer can be activated that way. At least I found information that a revers proxy would be needed to check access logs. Just as an idea Harden Portainer and Apache2 Reverse Proxy with fail2ban · GitHub Probably that’s not true but at least some access log would need to be specified.

same goes to PiHole Configure fail2ban on pihole admin interface - #8 by jfb - Help - Pi-hole Userspace

8

Understood - thank you.

I will explore those articles a little later to see how difficult it will be.

9

Just search the web to get your own information. The one I found might be outdated or incorrect. :wink:

1 Like
10

All settings from the [DEFAULT] block are applied to all other blocks, so all defined blocks are enabled without adding this setting, and use the systemd backend, route ban action etc. I found it somehow unnecessary that one needs to add a new jail block as well as enable it explicitly :wink:. Why would one add a block if not to have it enabled.

2 Likes