Author: Alex

How to increase the size of the partition and file system after increasing the physical size of the disk

Disk partition size and file system size

In Linux, a disk can be used entirely by one partition or be divided into several partitions (similar to volumes in Windows).

Usually, at the stage of installing the operating system, disk partitioning is done: disk partitions are created, and then these partitions are formatted into one or another file system. In this case, the size of the file system corresponds to the size of the partition (or the entire disk, if there is only one partition). That is, the sizes of file systems are equal to the sizes of partitions.

But there may be situations when the size of the file system no longer matches the size of the partition on which it is located. Examples of such situations:

  • you increased the disk size of your virtual private server (VPS)
  • you replaced your computer's hard drive and transferred the root file system using the dd utility (or other utilities that support creating and writing clones of entire disks and partitions) to a new disk

In both cases described, the Linux operating system will only be able to use the size that the file system originally had.

For clarity, let's understand the terms:

Disk size – the entire size of a physical or virtual disk. It can be used by the operating system in whole or in part within the created partitions and file systems.

Partition size – the space that a particular partition occupies. When cloning partitions with dd to a disk of a larger partition, the layout of the previous disk is preserved. That is, the operating system can even use a new disk only within the limits of the old disk layout.

Filesystem size – similar to partition size, the OS can only use a partition up to the size of the filesystem, even if the filesystem is moved to a new disk of a larger partition.

If you still do not fully understand the difference between “partition size” and “file system size”, then you need to know that, from a practical point of view, when increasing the disk size, you need to run two commands:

  • partition increase command
  • file system increase command

Note: For some hosting providers, the file system size increases automatically after switching to a plan with a larger disk size. For example, with Digitalocean, it is enough to select a larger disk and wait for the changes to be applied. And with Ihor hosting, after increasing the size of the server disk (can be done only through the support service), you need to increase the size of the partitions and the file system yourself.

How to increase the partition size and file system size on the server

This article will show you how to increase the partition and file system size on a computer without a graphical user interface, without rebooting the computer, without unmounting the file system, and without having to boot into Live OS. That is, you can use the shown method on servers. But nothing prevents you from using the commands from this article also on your home computer, for example, when cloning the OS to a new disk.

In this article, I am expanding the ext4 file system. The described commands should definitely work for ext2/ext3/ext4 filesystems.

I'm following the steps on Arch Linux, but the commands shown should work for any OS. Only the file system type matters. That is, if you want to increase the size of ext2 / ext3 / ext4, then this instruction should work regardless of the Linux distribution.

Utilities for increasing the size of partitions and the file system.

We need the resize2fs utility. This utility is included in the e2fsprogs package and is most likely installed in your distribution by default, since it usually refers to core packages, that is, programs necessary for the normal functioning of the Linux OS.

We also need the growpart utility, which is included in the cloud-utils package.

  • On Debian and Ubuntu derivatives, to install this package, run the commands:
sudo apt update
sudo apt install cloud-utils
  • On Arch Linux and derivatives of this distribution, to install the cloud-utils package, run the command:
pacman -S cloud-utils

Backing up the partition table

Just in case something goes wrong, back up your drive's partition table:

sfdisk -d /dev/vdX > partition_bak.dmp

Save the partition_bak.dmp file to a safe location other than the drive you backed up the partition table, because if data loss occurs, this file will also become inaccessible.

How to check partition size and file system size

Let's look at the size of the file system with the following command

df -h

Sample output:

Filesystem      Size  Used Avail Use% Mounted on
dev             2.0G     0  2.0G   0% /dev
run             2.0G  552K  2.0G   1% /run
/dev/vda2        30G   28G     0 100% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G   27M  1.9G   2% /tmp
/dev/vda1       193M  103M   80M  57% /boot
tmpfs           393M     0  393M   0% /run/user/0

From this output it follows that the size of the file system on the /dev/vda2 partition is 30G and there is no free space on it.

Let's see the sizes of disks and partitions:

fdisk -l

Sample output:

Disk /dev/vda: 35 GiB, 37580963840 bytes, 73400320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4b23ea92

Device     Boot  Start      End  Sectors  Size Id Type
/dev/vda1  *      2048   411647   409600  200M 83 Linux
/dev/vda2       411648 62914559 62502912 29.8G 83 Linux

It follows from these information that the size of the /dev/vda disk is 35 GB, and the size of the partitions present on it is 30 GB. The fact is that I hosting provider increased the size of the disk at my request. But the OS can still only use the old disk size.

How to increase the size of a Linux partition on the command line without Live System and unmounting the file system

To increase the partition to the maximum (taking into account free disk space), use the following command:

growpart /dev/DISK NUMBER

In this command:

  • /dev/DISK – disk device name
  • NUMBER – the number of the partition you want to enlarge

I want to enlarge the /dev/vda2 partition, so in my case:

  • /dev/DISK is “/dev/vda
  • NUMBER is “2

The command itself takes the following form:

growpart /dev/vda 2

But before executing it, it is recommended to run your command with the -N option. This option will cause the command to show what changes it will make, but the changes themselves will not be performed.

So let's run the command:

growpart -N /dev/vda 2

Sample output:

CHANGE: partition=2 start=411648 old: size=62502912 end=62914559 new: size=72988639 end=73400286
# === old sfdisk -d ===
label: dos
label-id: 0x4b23ea92
device: /dev/vda
unit: sectors
sector-size: 512

/dev/vda1 : start=        2048, size=      409600, type=83, bootable
/dev/vda2 : start=      411648, size=    62502912, type=83
# === new sfdisk -d ===
label: dos
label-id: 0x4b23ea92
device: /dev/vda
unit: sectors
sector-size: 512

/dev/vda1 : start=        2048, size=      409600, type=83, bootable
/dev/vda2 : start=      411648, size=    72988639, type=83

“# === old sfdisk -d ===” shows that the /dev/vda2 partition has 62502912 sectors (to get the disk size, multiply the number of sectors by the size of one sector, for example, 62502912*512/1024/1024/1024 = 29.80 GB).

# === new sfdisk -d ===” shows the size of the /dev/vda2 partition after running the command. This size is 72988639 sectors (i.e. 72988639*512/1024/1024/1024 = 34.80 GB).

Since in my case the disk is 100% used, and the partition resizing operation is very serious, before actually moving on to the changes, I freed up some disk space. How to do this, see the articles:

If everything is correct, now we run a command that will actually resize the selected partition, increasing it to the maximum possible in accordance with the available free space on the disk (remember to substitute your disk value and partition number):

growpart /dev/vda 2

Sample output:

CHANGED: partition=2 start=411648 old: size=62502912 end=62914559 new: size=72988639 end=73400286

Check the partition and file system sizes:

df -h

fdisk -l

Pay attention to the line:

/dev/vda2        30G   28G  285M  99% /

The file system size is still around 30 gigabytes. Its usage dropped from 100% to 99% just because I freed up disk space.

Also note the following line:

/dev/vda2       411648 73400286 72988639 34.8G 83 Linux

That is, the size of the /dev/vda2 partition has really increased.

How to increase the size of a Linux filesystem on the command line without Live System and unmounting the filesystem

The command to increase the file system to the maximum size in accordance with the free space on the partition is as follows:

resize2fs /dev/DEVICE

In this command, /dev/DEVICE is the name of the disk device.

In my case, the name of the partition I want to enlarge is /dev/vda2, then the command is:

resize2fs /dev/vda2

Sample output:

resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/vda2 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/vda2 is now 9123579 (4k) blocks long.

The output says that the filesystem on /dev/vda2 is mounted on / (the root filesystem), so “on-line resizing” is required. The command completed successfully.

Check the partition and file system sizes:

df -h

fdisk -l

Pay attention to the line:

/dev/vda2        35G   28G  5.0G  85% /

The filesystem on /dev/vda2 is now 35G in size and only 28G is occupied. That is the file system is really increased.

Regarding the partition size we increased in the previous step

/dev/vda2       411648 73400286 72988639 34.8G 83 Linux

nothing has changed for it.

How to prevent money loss in international roaming. Setting up your phone for international roaming

Table of contents

1. How to disable mobile Internet in roaming

2. Setting up the phone to work with SIM cards in international roaming

3. Consider purchasing mobile data roaming packages


If you are traveling abroad, then you need to be prepared for the fact that mobile communications in roaming are quite expensive. Mobile Internet connection can also be expensive. But if calls and SMS are completely dependent on the user, and we decide on our own whether to receive a call while abroad, then it is more and more difficult with mobile Internet. Modern mobile phones are almost constantly online: instant messengers check for new messages, email programs check mail, the app store updates programs, and phone firmware looks for Android updates.

1. How to disable mobile Internet in roaming

You can disable mobile internet if your phone is abroad. This is a very convenient feature that does not affect the use of mobile Internet within your country. In addition, if you buy a SIM card abroad, you will still be able to use its mobile Internet, since for it the mobile networks of a foreign state will be local.

Go to “Settings”, to do this, slide the curtain down and click the gear icon.

Go to the “Connections” section.

Go to the “Mobile networks” section.

Turn off the “Data roaming” slider.

Now, when you get off the plane, and turn off Airplane mode, your phone will not try to connect to the Internet abroad.

But at the same time you will receive all SMS messages and incoming calls.

If you buy a foreign SIM card, then you can use its Internet without disabling the considered function (since mobile networks will be home for a foreign SIM card).

2. Setting up the phone to work with SIM cards in international roaming

If you purchased a SIM card for mobile data abroad, and if your phone supports dual SIM, you can explicitly specify which one should be used for different communication services.

Go to Settings → Connections → SIM manager.

Here you can explicitly select which SIM card should be used for calls, SMS messages and mobile data.

3. Consider purchasing mobile data roaming packages

Currently, many mobile operators offer packages for mobile roaming. Thanks to them, you can stay connected abroad without spending too much money. Check out your mobile operator's roaming offers.

How to update the GRUB bootloader on Debian and derivative distributions (Kali Linux, Ubuntu, Linux Mint)

The GRUB operating system loader is installed and updated on Linux like any other software package. But the peculiarity of the bootloader is that even after updating the package, the actual working files of the bootloader, which are located on the partition mounted along the /boot/grub/ path, are not automatically updated.

That is, when new versions of GRUB are released, the package in your OS is updated automatically.

But the bootloader itself, which is installed on a separate disk partition and mounted along the /boot/grub/ path, is not updated.

To start using the new features that are added in new versions of GRUB, you need to manually update the bootloader.

When to update the GRUB bootloader in /boot/grub/

The signal that a new version of GRUB has been released is something like the following messages:

Setting up grub-common (2.06-8+kali1) ...
...........
Setting up grub2-common (2.06-8+kali1) ...
...........
Setting up grub-pc-bin (2.06-8+kali1) …

Another sign that the GRUB package has been updated is a request to update the default GRUB configuration file.

In order to use the new features introduced in this GRUB update, it is recommended to install it in MBR or UEFI. Due to potential configuration incompatibilities, it is recommended that you perform both installation and configuration creation.

That is, if you see this message, then you need to update the bootloader in /boot/grub/.

How to check if GRUB is being used on the operating system

On Arch Linux and derivative distributions, the GRUB package can be installed but is not used because the bootloader is systemd-boot.

To verify that GRUB is the bootloader, run the following command:

ls -l /boot/grub/grub.cfg

If the /boot/grub/grub.cfg file is found, then GRUB is being used, if the grub.cfg file is not found, then GRUB is not used and does not need to be updated. That is, you do not need to follow the steps shown in this article!

For details, see the article: How to check if a computer is using BIOS or UEFI; GRUB or systemd-boot bootloader; MBR or GPT partition table

How to update the GRUB bootloader in /boot/grub/

To update the bootloader, you need to run a command like:

grub-install --recheck /dev/DISK

Where /dev/DISK should be the name of your drive.

Drive names can be checked with the command:

fdisk -l

Example output:

Disk /dev/vda: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors Size Id Type
/dev/vda1  *     2048 104857566 104855519  50G 83 Linux


Disk /dev/vdb: 450 KiB, 460800 bytes, 900 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

In this case, the drive name is /dev/vda. Note that /dev/vda is not a boot partition or some other partition – it's the entire drive.

So, the command to update GRUB in /boot/grub/ in my case is the following:

grub-install --recheck /dev/vda

Example output:

Installing for i386-pc platform.
Installation finished. No error reported.

You also need to create a new configuration file with the following command:

grub-mkconfig -o /boot/grub/grub.cfg

Example output:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.0.0-kali6-cloud-amd64
Found initrd image: /boot/initrd.img-6.0.0-kali6-cloud-amd64
Found linux image: /boot/vmlinuz-6.0.0-kali5-cloud-amd64
Found initrd image: /boot/initrd.img-6.0.0-kali5-cloud-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

GRUB bootloader update and GRUB configuration update completed successfully. The next time you boot, your operating system will use the new features that were added by the GRUB update.

Updating packages: whether to update the config file

Consider a situation when the package manager of your Linux distribution (Debian, Linux Mint, Ubuntu, Kali Linux) asks about updating the configuration file – what to do and how to get the latest version of the configuration file? Let’s figure it out.

With some updates of some packages, the structure of the configuration file changes. As a rule, the new file contains directives and settings that are necessary for the new version of the program, without which it cannot work.

Setting up a services is almost always changing configuration files. The end file can be the result of lengthy configuration work and many tests. This can take hours or even days.

Therefore, if it is necessary to update the configuration, a dilemma arises:

  • do not update the config, as a result of which the new version of a package will not work normally
  • update config and erase service configuration results

It is for this reason that the system asks you every time what needs to be done if the configuration file is updated with the program update?

An example of a message in which the package manager asks what to do with the new config file:

Configuration file '/etc/squid/squid.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** squid.conf (Y/I/N/O/D/Z) [default=N] ? 

The options are:

  • Y or I – install a new config file
  • N or O – save the currently used config file
  • D – show differences between versions
  • Z – open the shell to examine the situation

The default option is to save the current config file (N).

If in reality you have not used this program, or the settings made are of no value to you, then always agree to update the configuration file. If the settings made are important to you, then:

  • refuse to update the config file
  • make a backup copy of your config, update the config file to the new version, and then make the necessary settings in it

For some packages, like Tor, the config file is just a set of comments with no setting active – for such files (if you haven't changed them), the update is more of a formality.

Package configuration

Another option for reporting a new version of the configuration file:

Package configuration

  ┌──────────────────────────────────┤ Configuring privoxy ├──────────────────────────────────┐
  │ A new version (/etc/privoxy/config.ucftmp) of configuration file /etc/privoxy/config is   │ 
  │ available, but the version installed currently has been locally modified.                 │ 
  │                                                                                           │ 
  │ What do you want to do about modified configuration file config?                          │ 
  │                                                                                           │ 
  │                   install the package maintainer's version                                │ 
  │                   keep the local version currently installed                              │ 
  │                   show the differences between the versions                               │ 
  │                   show a side-by-side difference between the versions                     │ 
  │                   show a 3-way difference between available versions                      │ 
  │                   do a 3-way merge between available versions                             │ 
  │                   start a new shell to examine the situation                              │ 
  │                                                                                           │ 
  │                                                                                           │ 
  │                                          <Ok>                                             │ 
  │                                                                                           │

By default, the option “keep the local version currently installed” is selected. This is the best option if you want to keep your previous settings. To continue updating packages, press the “Tab” key, as a result you will switch to the “<Ok>” button.

And press the “Enter” key.

If you do not want to save the settings you made earlier, but want to get a new version of the configuration file, then use the cursor keys to select the “install the package maintainer's version” option. Then press “Tab” and “Enter” again.

Should I update configuration files in the /etc/default/ directory

A special case, in my opinion, is the /etc/default/ directory.

For example, the following screenshot shows that a request is being made to update the /etc/default/grub file.

As the name of the directory itself implies, it contains default configuration files, which, most likely, do not change even if you configured a particular service or program.

Therefore, by default, these configuration files can be updated, except in special cases when you specifically make changes to them.

How to view the new config file

Typically, system administrators and users save the current configuration file. But how do you view the new file? After all, it is quite possible that there are important changes in it.

One way to do this is to download the latest version of a package and see the configuration file for the latest version in that package.

Download the package with a command like:

apt download PACKAGE

For example, to download the squid package

apt download squid

Unpack the downloaded installation file with a command like:

ar x FILE.deb

For example:

ar x squid_5.1-2_amd64.deb

Now we need to unpack a file called data.tar.gz or data.tar.xz.

Look at the contents of the folder to find out the name of the file:

ls -l

If the file has a .tar.gz extension, then the command is as follows:

tar xzf data.tar.gz

If the file has the extension .tar.xz, then the command is as follows:

tar xf data.tar.xz

Let's check the contents of the current directory again in search of unpacked folders and files:

ls -l

Configuration files on the system are usually placed in the /etc/ directory, when you unpack the package, you will find this folder under the path ./etc/ (that is, in the current folder).

For example, the command to view the configuration file of the latest version of the squid package I am interested in:

gedit ./etc/squid/squid.conf

How to update the GRUB bootloader in Arch Linux and derivatives (Manjaro, BlackArch)

The GRUB operating system loader is installed and updated on Linux like any other software package. But the peculiarity of the bootloader is that even after updating the package, the actual working files of the bootloader, which are located on the partition mounted along the /boot/grub/ path, are not automatically updated.

That is, when new versions of GRUB are released, the package in your OS is updated automatically.

But the bootloader itself, which is installed on a separate disk partition and mounted along the /boot/grub/ path, is not updated.

To start using the new features that are added in new versions of GRUB, you need to manually update the bootloader.

When to update the GRUB bootloader in /boot/grub/

The signal that a new version of GRUB has been released is something like the following message:

(3/4) upgrading grub                               [######################] 100%
:: To use the new features provided in this GRUB update, it is recommended
   to install it to the MBR or UEFI. Due to potential configuration
   incompatibilities, it is advised to run both, installation and generation
   of configuration:
     $ grub-install ...
     $ grub-mkconfig -o /boot/grub/grub.cfg

This message says that in order to use the new features introduced in this GRUB update, it is recommended to install it in MBR or UEFI. Due to potential configuration incompatibilities, it is recommended that you perform both installation and configuration creation. And also given exemplary commands.

That is, if you see this message, then you need to update the bootloader in /boot/grub/.

How to check if GRUB is being used on the operating system

On Arch Linux and derivative distributions, the GRUB package can be installed but is not used because the bootloader is systemd-boot.

To verify that GRUB is the bootloader, run the following command:

ls -l /boot/grub/grub.cfg

If the /boot/grub/grub.cfg file is found, then GRUB is being used, if the grub.cfg file is not found, then GRUB is not used and does not need to be updated. That is, you do not need to follow the steps shown in this article!

For details, see the article: How to check if a computer is using BIOS or UEFI; GRUB or systemd-boot bootloader; MBR or GPT partition table

How to update the GRUB bootloader in /boot/grub/

To update the bootloader, you need to run a command like:

grub-install --recheck /dev/DISK

Where /dev/DISK should be the name of your drive.

Drive names can be checked with the command:

fdisk -l

Example output:

Disk /dev/vda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4b23ea92

Device     Boot  Start      End  Sectors  Size Id Type
/dev/vda1  *      2048   411647   409600  200M 83 Linux
/dev/vda2       411648 62914559 62502912 29.8G 83 Linux

In this case, the drive name is /dev/vda. Note that /dev/vda is not a boot partition or some other partition – it's the entire drive.

So, the command to update GRUB in /boot/grub/ in my case is the following:

grub-install --recheck /dev/vda

You also need to create a new configuration file with the following command:

grub-mkconfig -o /boot/grub/grub.cfg

Example output:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot:  initramfs-linux-fallback.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

GRUB bootloader update and GRUB configuration update completed successfully. The next time you boot, your operating system will use the new features that were added by the GRUB update.

Error “No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed” (SOLVED)

Debian and derivative distributions (Ubuntu, Linux Mint, Kali Linux, and many others) may experience a “FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed” error when migrating from PHP 8.1 to PHP 8.2.

Apache web server log

sudo tail /var/log/apache2/error.log

contains the following error messages:

[Sun Jan 29 03:05:45.213609 2023] [proxy:error] [pid 1313500] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:05:45.213763 2023] [proxy_fcgi:error] [pid 1313500] [client 127.0.0.1:58950] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:06:39.789031 2023] [proxy:error] [pid 1313496] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:06:39.789110 2023] [proxy_fcgi:error] [pid 1313496] [client 127.0.0.1:50024] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:06:41.336218 2023] [proxy:error] [pid 1313499] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:06:41.336297 2023] [proxy_fcgi:error] [pid 1313499] [client 127.0.0.1:50040] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:07:24.027400 2023] [proxy:error] [pid 1313497] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:07:24.027445 2023] [proxy_fcgi:error] [pid 1313497] [client 127.0.0.1:44688] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:09:55.008467 2023] [proxy:error] [pid 1504919] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:09:55.008530 2023] [proxy_fcgi:error] [pid 1504919] [client 127.0.0.1:38382] AH01079: failed to make connection to backend: httpd-UDS

Sites and engines that use PHP, such as phpMyAdmin, give the following error:

503 Service Unavailable
Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.55 (Debian) Server at localhost Port 80

The essence of the problem is indicated in the web server logs – it is impossible to connect to the php8.1-fpm.sock socket. This is a fairly predictable problem when changing the PHP version, in this case from PHP 8.1 to PHP 8.2.

FPM (FastCGI Process Manager, FastCGI process manager) is an alternative implementation of PHP FastCGI with several additional features commonly used for high load sites.

To disable an outdated version of FPM, run the following commands:

sudo a2disconf php8.1-fpm
sudo systemctl restart apache2

At this point, engines and sites that don't use FPM should already be working fine.

If you are really using FPM and want to enable the new version, then run the following commands:

sudo a2enconf php8.2-fpm
sudo systemctl reload apache2
sudo systemctl restart apache2.service
sudo systemctl restart php8.2-fpm

Error “error: failed to commit transaction (invalid or corrupted package)” (SOLVED)

When using pacman while updating packages, for example

sudo pacman -Syu

An error may occur:

error: binutils: signature from "Frederik Schwan <frederik.schwan@linux.com>" is unknown trust
:: File /var/cache/pacman/pkg/binutils-2.39-4-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]

If you choose the proposed option – remove an invalid or damaged package – then the update will fail with the following error:

error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

The specific error message in your case may be different, for example, another package may be invalid or corrupted, or the PGP signature may belong to another person.

In any case, to fix the error, start by reinstalling the archlinux-keyring package:

sudo pacman -S archlinux-keyring

After that, the system update should pass without error.

sudo pacman -Syu

Error “TypeError: ‘AURPackageInfo’ does not have attribute ‘submitter’” (SOLVED)

pikaur is a utility for facilitating the installation and updating of programs from the AUR. You can read more about pikaur in the article “Automatic installation and update of AUR packages”.

pikaur's options are similar to pacman, but you don't need to use sudo. For example, updating all packages is done with the following command:

pikaur -Syu

On my Arch Linux (BlackArch) I once got the following error:

Reading AUR packages info...
  File "/usr/lib/python3.10/site-packages/pikaur/main.py", line 369, in main
    cli_entry_point()
  File "/usr/lib/python3.10/site-packages/pikaur/main.py", line 272, in cli_entry_point
    run_with_sudo_loop(pikaur_operation)
  File "/usr/lib/python3.10/site-packages/pikaur/core.py", line 417, in run_with_sudo_loop
    raise catched_exc
  File "/usr/lib/python3.10/site-packages/pikaur/core.py", line 411, in run_with_sudo_loop
    result = main_thread.get()
  File "/usr/lib/python3.10/multiprocessing/pool.py", line 774, in get
    raise self._value
  File "/usr/lib/python3.10/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib/python3.10/site-packages/pikaur/main.py", line 136, in cli_install_packages
    InstallPackagesCLI()
  File "/usr/lib/python3.10/site-packages/pikaur/install_cli.py", line 186, in __init__
    self.main_sequence()
  File "/usr/lib/python3.10/site-packages/pikaur/install_cli.py", line 193, in main_sequence
    self.get_all_packages_info()
  File "/usr/lib/python3.10/site-packages/pikaur/install_cli.py", line 273, in get_all_packages_info
    self.install_info = InstallInfoFetcher(
  File "/usr/lib/python3.10/site-packages/pikaur/install_info_fetcher.py", line 71, in __init__
    self.get_all_packages_info()
  File "/usr/lib/python3.10/site-packages/pikaur/install_info_fetcher.py", line 212, in get_all_packages_info
    self.get_aur_pkgs_info(self.not_found_repo_pkgs_names)
  File "/usr/lib/python3.10/site-packages/pikaur/install_info_fetcher.py", line 468, in get_aur_pkgs_info
    aur_updates_list, not_found_aur_pkgs = find_aur_updates()
  File "/usr/lib/python3.10/site-packages/pikaur/updates.py", line 125, in find_aur_updates
    aur_pkgs_info, not_found_aur_pkgs = find_aur_packages(package_names)
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 184, in find_aur_packages
    results = [request.get() for request in requests]
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 184, in <listcomp>
    results = [request.get() for request in requests]
  File "/usr/lib/python3.10/multiprocessing/pool.py", line 774, in get
    raise self._value
  File "/usr/lib/python3.10/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 143, in aur_rpc_info_with_progress
    result = aur_rpc_info(search_queries)
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 133, in aur_rpc_info
    return [
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 134, in <listcomp>
    AURPackageInfo(**{key.lower(): value for key, value in aur_json.items()})
  File "/usr/lib/python3.10/site-packages/pikaur/aur.py", line 60, in __init__
    super().__init__(**kwargs)
  File "/usr/lib/python3.10/site-packages/pikaur/core.py", line 88, in __init__
    setattr(self, key, value)
  File "/usr/lib/python3.10/site-packages/pikaur/core.py", line 102, in __setattr__
    raise TypeError(

TypeError: 'AURPackageInfo' does not have attribute 'submitter'

To fix this error, you need to reinstall pikaur. To reinstall pikaur, run the following commands:

git clone https://github.com/actionless/pikaur.git
cd pikaur
makepkg -fsri

If an error occurs

fatal: destination path 'pikaur' already exists and is not an empty directory.

Then instead of the previous ones, run the following commands:

cd pikaur
git pull
makepkg -fsri

In my case, when installing pikaur, the following dependencies were additionally installed:

  • python-mdurl
  • python-pep517
  • python-uc-micro-py
  • python-build
  • python-installer
  • python-markdown-it-py

After that, pikaur began to work without errors.

“Initramfs unpacking failed: invalid magic at start of compressed archive” error (SOLVED)

This article will show you how to fix the Linux won't boot error. In this case, the solution is shown using Kali Linux as an example, but the steps are also applicable to Debian, Ubuntu, Linux Mint, and derivative distributions.

An error occurred while booting Linux:

Initramfs unpacking failed: invalid magic at start of compressed archive
Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The bottom line is that it was not possible to unpack the Initramfs due to archive corruption. Without this, the loading and operation of the operating system is impossible.

However, you can try to solve this problem without booting from a rescue disk (for example, a Live CD image).

First, try booting into Recovery Mode/Root Access on your current kernel.

To do this, select “Advanced options” in the bootloader.

Then select the item with “recovery mode” – usually the second line.

If you managed to do this, then run the following command:

sudo update-initramfs -c -k $(uname -r)

In my case, the error message changed, but the system was never booted.

If it was not possible to boot into recovery mode, then boot with a previous version of the kernel.

My system booted successfully with the previous version:

Now we need to recreate the ramdisk file. This can be done with a special command, but you need to know the kernel version number. Also, the ramdisk file is recreated each time a Linux kernel package is installed. Let's consider both options.

1. Reinstalling the Linux kernel

To reinstall the kernel, run the command:

sudo apt install linux-image-amd64

This command is suitable for 64-bit systems, if you have a 32-bit or ARM computer, then use the appropriate kernel package name linux-image-*

The previous command didn't work, and I got an error:

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

To fix the error, it is recommended to run the following command:

sudo dpkg --configure -a

It also didn't work and generated an error:

dpkg: error: fgets gave an empty string from ‘/var/lib/dpkg/triggers/Unincorp’

To fix it:

sudo rm /var/lib/dpkg/triggers/Unincorp
sudo touch /var/lib/dpkg/triggers/Unincorp

See also: dpkg: error: fgets gave an empty string from ‘/var/lib/dpkg/triggers/Unincorp’ (SOLVED)

Then the command to fix problems with packages was successfully executed:

sudo dpkg --configure -a

During its execution, the ramdisk file was re-created (as a step in setting up one of the packages), that is, reinstalling the Linux kernel was not required. After that I rebooted Linux and the operating system booted up as usual.

2. Generate ramdisk file

To generate an initramfs (ramdisk), you need to run a command like:

sudo update-initramfs -c -k VERSION

Instead of NUMBER, you need to specify the latest version of the Linux kernel installed on your system. That is, this is the version that causes problems.

You can view the available kernels with the command:

ls -al /boot

Execution result:

итого 149988
drwxr-xr-x  4 root root     4096 ноя 27 06:02 .
drwxr-xr-x 20 root root     4096 ноя 15 03:40 ..
-rw-r--r--  1 root root   254811 окт 10 16:05 config-5.19.0-kali2-amd64
-rw-r--r--  1 root root   257010 ноя  7 16:51 config-6.0.0-kali3-amd64
drwx------  3 root root     4096 янв  1  1970 efi
drwxr-xr-x  6 root root     4096 ноя 27 06:00 grub
-rw-r--r--  1 root root 67132798 ноя  9 03:32 initrd.img-5.19.0-kali2-amd64
-rw-r--r--  1 root root 70411394 ноя 27 06:02 initrd.img-6.0.0-kali3-amd64
-rw-r--r--  1 root root       83 окт 10 16:05 System.map-5.19.0-kali2-amd64
-rw-r--r--  1 root root       83 ноя  7 16:51 System.map-6.0.0-kali3-amd64
-rw-r--r--  1 root root  7703168 окт 10 16:05 vmlinuz-5.19.0-kali2-amd64
-rw-r--r--  1 root root  7788992 ноя  7 16:51 vmlinuz-6.0.0-kali3-amd64

The kernel version is numbers followed by words. For example, on this system, the latest kernel version is “6.0.0-kali3-amd64”. Then the command to create a new initramfs file is:

sudo update-initramfs -c -k 6.0.0-kali3-amd64

After that restart your computer:

reboot

dpkg: error: fgets gave an empty string from ‘/var/lib/dpkg/triggers/Unincorp’ (SOLVED)

When trying to use the apt package manager, for example:

sudo apt install linux-image-amd64

An error occurred:

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

The error is caused by disk problems or package upgrade failure.

When trying to use the recommended command:

sudo dpkg --configure -a

There was another error:

dpkg: error: fgets gave an empty string from '/var/lib/dpkg/triggers/Unincorp'
E: Sub-process /usr/bin/dpkg returned an error code (2)

To fix the issue, run the following commands:

sudo rm /var/lib/dpkg/triggers/Unincorp
sudo touch /var/lib/dpkg/triggers/Unincorp
sudo dpkg --configure -a

After that, run

sudo dpkg --configure -a
Loading...
X