Using separate /var

Hardware
1

Hi,

I am currently trying to setup a new ipfire (Core 181) from scratch.
Installation worked fine, I can access the WebUI and ssh on the machine.

Now I wanted to change the partitioning to use a separate /var:
So I create a new partition copy all data from /var onto it and
change /etc/fstab to mount it to /var as in:

UUID=daf9fd04-ec8d-410b-8922-d2b1fc47f0dd /boot    auto defaults,nodev,noexec,nosuid 1 2
UUID=0BC2-2B6E /boot/efi auto defaults   1 2
UUID=d8a5436e-d965-46dc-aa22-26beebc1ab72 swap     swap defaults,pri=1 0 0
UUID=9d4ff173-f8e6-4bc7-a9ac-88b009eca9df /        auto defaults   1 1
UUID=f1b00d69-7ba2-4d99-88b8-71a20b7ae4e2 /var     auto defaults   1 2

But when I boot, the machine cannot start any NIC (GREEN, RED, ORANGE).
After running setup they work again - until the next reboot.
Browsing into /var looks shows a reasonable list of files and folders.

Any hint what I am doing wrong.

Thanks
Manfred.

2

Hello @mdheuler, welcome to our community!

Based on the details you have provided, there are two primary hypotheses to consider regarding the issues you are encountering with your IPFire setup:

  1. Incorrect Partition Mounting Post-Reboot: It’s possible that the new partition isn’t being mounted correctly to /var after each reboot. This would mean that any modifications or configurations in /var wouldn’t persist through a reboot. To verify if the partition is correctly mounted, you can look for the presence of a lost+found directory within /var. Additionally, executing the command mount | grep /var can provide insights into whether the partition is mounted as expected.

  2. Issues with File Copying: Another possibility is that the files from the original /var directory weren’t copied correctly to the new partition. This includes ensuring that permissions, ownership, and attributes of the files are preserved. For such a task, the command rsync -aAXv /old_var/* /new_var/ is typically used. This command maintains all aspects of the files during the copy process.

There could be other unforeseen issues, but at the moment I cannot think of any other possibility.

Please let us know how it goes or if you need further assistance.

Good luck.

1 Like
3

Thanks @cfusco for the suggestions but I have to reject both of your issues as reason:

  1. When I manually create a file in /var I still see this after reboot.

  2. I moved the files instead of copying, mv /var/* new_var/. so all ownership and permissions should be preserved. Even more interestingly if I revert my changes mv new_var/* var/. and disable the respective entry in /etc/fstab it works again.

In fact after shutting down ipfire I see 3 new folders (lock log run) in the previously empty /var on the root partition. So it seems as if during some critical phase of the bootup the new /var is not yet mounted.

Would I need to adapt the ramdisk or grub config as well?

I found posts indicating that support for a separate var-partition was dropped at same version in the past but I assumed that this only meant the installer not creating separate partitions any longer. Maybe this is a wrong interpretation.

4

I think you are correct. Only someone with a deeper understanding of IPFire boot process can help you here.

5

It is many years since I have created addtional system partitions. The process that was recommended by openSUSE and which I followed, was:

  • create required partition and mount it to /mnt
  • cp -ax /var/* /mnt/
  • umount /mnt
  • mount new partition to /var
  • amend /etc/fstab

The rsync command, as recommended above, would probably work as well.
The cp & rsync commands are configured to ignore transient files, such as the lock file that you are seeing, as well as the contents of tmp. It is possible that the mv command handles files differently.

6

Why? I cannot see any need for that.

7

We had removed the seperate /var partition with core122 because it cause problems if
many addons result in out of disk space on root with corrupting the whole system.
So we don’t recommend a seperate /var partition since then.
I’m not really sure yet, but the separate partition may the reason for failing updated systems updated to core181 with a ramdisk that not load scsi kernel modules anymore.

6 Likes
8

Now that you mention it. In fact the new ipfire is to replace an old instance running since at least Core 67, surviving every update over the last decade.

I had issues with the 181 update, so I considered installing a fresh instance.

I was not aware of the issue with separate /var partions so I just tried to setup the new machine similar to the old one.

Now that I know I will stick with just one root partition - I agree that the bonus of a separate /var partition is limited. I just think that the system is a bit more resilient in case of a overflowing var (or was it root?).

3 Likes