From: Adolf Belka <adolf.belka@ipfire.org>
To: Stefan Schantl <stefan.schantl@ipfire.org>
Cc: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: Testing release for BTRFS/Snapshots feature
Date: Mon, 4 May 2026 14:10:22 +0200 [thread overview]
Message-ID: <b55960c0-19ac-4216-9c3c-c8d43011bb3a@ipfire.org> (raw)
In-Reply-To: <980b24a9a4a3df6db711d9c082a4061627c00200.camel@ipfire.org>
Hi Stefan,
Sorry for the delay but other things got in the way.
On 29/04/2026 20:53, Stefan Schantl wrote:
> Hello Adolf,
>
> thanks for joining the conversation.
>> Hi Stefan,
>>
>> On 29/04/2026 19:25, Stefan Schantl wrote:
>>> Hello list followers,
>>>
>>> a lot of time has been passed since the initial support for BTRFS
>>> has
>>> been introduced in IPFire. Sadly the further development process
>>> has
>>> been slowed down significantly - mainly because of personal reasons
>>> and
>>> as a result of them, the lack of spare time on my side.
>>>
>>> All the more I'm very happy to announce the next milestone on this
>>> list
>>> and share the current development state. The roadmap on our wiki
>>> page
>>> can be found here: https://www.ipfire.org/docs/roadmap/btrfs
>>>
>>> The code to take snapshots, manage them, boot into a certain
>>> snapshot
>>> or to restore them finally has been arrived. All these actions
>>> easily
>>> can be accessed from the CGI page for backups on the IPFire WUI. On
>>> this page a new section called "Snapshots" will be displayed in
>>> case
>>> BTRFS has been chosen during the install process of IPFire.
>>>
>>> The page layout and style is not final yet, but everything is
>>> expected
>>> to work properly. In case you have any ideas how to improve the
>>> look
>>> and feel of the CGI page please provide some feedback here.
>>>
>>> The grub boot menu automatically will be extended when the first
>>> snapshot has been created with an additional entry to access and
>>> boot
>>> into a select-able snapshot in case the system broke or for any
>>> other
>>> testing purposes.
>>>
>>> I've also extend the code of the pakfire package manager to create
>>> a
>>> snapshot before installing a core update.
>>>
>>> To summarize the above the snapshot feature would be a big step
>>> forward, because it a allows anybody to go back if some unexpected
>>> error occur after an update, a testing update breaks anything, for
>>> hunting when a certain bug has been seen for the first time, etc...
>>>
>>> To took the last remaining steps and get the feature into the
>>> distribution some more testing and feedback is required. Therefore
>>> I've
>>> backed and uploaded an ISO image for all who are interested and
>>> want to
>>> join testing.
>>>
>>> Sadly IPFire has to be re-installed with BTRFS because there is no
>>> way
>>> to migrate an existing installation to a different file system.
>>
>> IPFire has to be installed from fresh to get the btrfs filesystem but
>> can you confirm that then you can do a restore from an IPFire backup
>> from an ext4 filesystem to get all settings, without any issues due
>> to the filesystem.
>>
>> My understanding is that bis the case but I would just like to have
>> it confirmed.
>
> Yes indeed, it should be possible to restore a backup which has been
> taken on a different filesystem. I did not tested this yet, but there
> shouldn't be any issues to be expected.
So the install worked fine and once I found the location of the snapshot section, I was able to take a snapshot of the system as I had installed it.
I then did a restore from one of my backups. That did not go 100% smoothly.
After doing the restore and then doing a reboot, unbound failed to start with the message user unbound can not be found.
I did a fresh install and then checked the /etc/passwd file and it had a user unbound in it.
I checked two of my CU201 systems and neither of them have user unbound.
unbound in my CU201 systems is running with user nobody.
I confirmed that in the btrfs testing release unbound is running with user unbound.
I could not find anything to explain why the user had been changed but if it is required then the restore process will need to add that user otherwise it will be missing after doing a restore, as was the case with my restore attempt.
Regards,
Adolf.
>
> Thanks for the hint, we defenitely should drop a few lines about this
> in the wiki and/or release notes when we are in a release stage.
>
> Best regards,
>
> -Stefan
>>
>> Regards,
>>
>> Adolf.
>>
>>>
>>> The current (and may later) images can be found here:
>>>
>>> https://people.ipfire.org/~stevee/BTRFS/
>>>
>>> According to testing and feedback there are some additional
>>> questions
>>> which appeared during development and needs some attention:
>>>
>>> * Should BTRFS become the default selected file system during
>>> installation? (At the moment this is ext4)
>>>
>>> * Should the pre-generated images use BTRFS? (At the moment they
>>> are
>>> also ext4)
>>>
>>> * Do we want an automatic snapshot for each single core update, or
>>> do
>>> we want a single one in case multiple core updates will be
>>> installed in
>>> one go? (Currently I've implemented a snapshot for each single
>>> update)
>>>
>>> * Maybe I missed something - feel free to ask any questions or
>>> share
>>> your opinions here.
>>>
>>> A big thanks in advance to anyone who wants to contribute and helps
>>> to
>>> finalize this amazing feature.
>>>
>>> Best regards,
>>>
>>> -Stefan
>>>
>>
>
prev parent reply other threads:[~2026-05-04 12:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 17:25 Stefan Schantl
2026-04-29 18:36 ` Adolf Belka
2026-04-29 18:53 ` Stefan Schantl
2026-05-04 12:10 ` Adolf Belka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b55960c0-19ac-4216-9c3c-c8d43011bb3a@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
--cc=stefan.schantl@ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox