Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion

Fixes and tweaks to default installs
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Fixes and tweaks to default installs

Over time I've run into some things I've had to tune or fix from default or template installs. I thought I would share in the hope it helps someone. I'd be see what others might add or alter with this list.

Note, my examples are all based on some version of Debian. There are also some networking and dedicated server-specific things I might have included, but those tend to apply only to me.

Not all of the disk is in use.

Sometimes the default install does not use the entire physical disk space allocated. You can see the discrepancy by comparing the output of lsblk with df -h. I've seen a few cases where the root partition is only a fraction of what it could be. You can easily resize it. For ext4 for example you'd run something like sudo resize2fs /dev/vda1 (replace vda1 with whatever the block device is for root). For xfs it might be sudo xfs_growfs /.

Unreachable after OS dist-upgrade (net interface name change)

After Debian 8 an upgrade may change the default network interface name. Traditionally it was eth0, but in many environments may now be ens3. Unless you're expecting it, this can render your system unreachable after an upgrade and reboot. All providers should have some console-based means with which you can access your system for times just like this. In Debian this usually means replacing the interface name wherever it appears in the /etc/network/interfaces files then rebooting.

No VNC, but there is a rescue disk

This isn't a fix or tweak per se, but for that rare provider that doesn't have VNC, they may have a rescue disk option and this will allow you to do most things you'd need VNC for. It is far less convenient, but you should know how to use it. You set your system to boot into rescue. Disable the original host key(s) in your ~/.ssh/known_hosts file. SSH in with the rescue creds. Use lsblk to see what your original root partition is. mkdir /mnt/root then mount /dev/[root]. Work in mounted partition and edit files as necessary.

cloud-init systems want control

Many cloud-based provisioning systems rewrite, if necessary, config settings at each reboot. The one that bugs me the most is when they insist on managing /etc/resolv.conf. Many setups have a way to disable that functionality, but often times it is just as easy to chattr +i /etc/resolv.conf to prevent your changes from being overwritten.

/run partition is too small

Later versions of Debian require at least 20MB for the the /run partition, but if you have a system with about 256MB RAM or less, you'll find services won't start and upgrades to the most current version won't work. You can get to minimal Debian 10 on about 256MB of RAM, but you will need to install something like this into /etc/fstab first: tmpfs /run tmpfs nosuid,noexec,size=20M,nr_inodes=4096 0 0

Validate passwd, sshd_config, and repo sources

The passwd file should go without saying. The SSH config may have multiple entries for PasswordAuthentication yes or PermitRootLogin yes. If you want these to be no, make sure those statements aren't listed multiple times in the config. Rarely have I seen problems with the repo sources, but you may wish to verify there are no unwanted third party repos enabled.

Bad grub/kernel update

This only happened to me once, but I recently ran into a provider that has only one Debian template, an early stretch install, and it is apparently broken beyond repair (confirmed by the provider). You literally could not update the kernel and hence not upgrade to Debian 10. I ended up completely removing grub, then did the dist-upgrade, removed the old kernel, re-installed grub, and ran update-grub. Only then was I able to move forward. That was a strange one.

OpenVZ still doesn't support 4.x kernels

You cannot install Debian 10 on OpenVZ today, most providers that provide OpenVZ are probably running under a 2.x kernel, and systemd isn't supported. The last one some may consider a feature. Nevertheless, enough said.

Comments

  • Adding to this thread as I come across things or remember things that I think may help others.

    Latest kernel not in use

    I've seen this only a few times, all on OpenStack VMs. Perhaps there was some old default template. I haven't seen this much recently. The symptom is that the latest installed kernels are not being used upon a restart. You can verify this by comparing the kernels installed with something like dpkg -l linux-image*" and the running kernel withuname -r`. When I've seen this grub was not used so the easiest fix has been to install and set it up.

    sudo apt-get install grub-common grub-pc
    sudo grub-install /dev/vda
    sudo update-grub
    sudo reboot
    

    Replace /dev/vda with the appropriate block device for your system.

  • @jtk said:
    You cannot install Debian 10 on OpenVZ today

    I was wrong here. You can't upgrade your OpenVZ-based VM from 9 to 10. However, if a provider is using OpenVZ 7 they may have, or may be willing to provide a Debian 10 image for a clean install. Some can, some do, some don't, some can't, some won't.

Sign In or Register to comment.