From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4g8L7p5L1dz2yXJ for ; Mon, 04 May 2026 12:10:30 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4g8L7l36l5z2y59 for ; Mon, 04 May 2026 12:10:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4g8L7k43THz1yW; Mon, 04 May 2026 12:10:26 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1777896626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vMdeybYgYE0F4R21br2Ok/2TlYCwN+9Fltp3F4xPAts=; b=Qded882PceIJGTmiWB734G49XUkXQfnH/1DcxZINNFEtM/tpx3qooLOVwWdysiMmbxiTEd KIUfbrLDx+3+htCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1777896626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vMdeybYgYE0F4R21br2Ok/2TlYCwN+9Fltp3F4xPAts=; b=BryM32taMDzQhgXytQsGajsjBXezi41LpZ//+PcFf9Knx0DctIZrUNl9CVps5ck9u077nh dT8+EjcvG0e8hrMJzeK1lhJ4U3CfwnJHOeMEexYsRrp42WXutVAMT3zGJZjOWXnfhf3Owc ebvdytPSOap3y0AT6lNcbK17o9hAoSD5CfbdDT9yPyZfMXbgsFL0vNAwWvQqvBMXIi6+F1 zMkbhlF17HFUueUWSvqOC6Xwr2xb/CapxLNxE8W6HXpirtAIcNiA9auOs19fMynnHGc8No +VGnS+yLlIjgwRIyQ8pSAyo9Ar1ZWQ2+F2yY+gu0969KcYtuH50J/LDgZGaF3g== Message-ID: Date: Mon, 4 May 2026 14:10:22 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: Testing release for BTRFS/Snapshots feature To: Stefan Schantl References: <6d8f15e3-079a-4601-951c-d607dee51e37@ipfire.org> <980b24a9a4a3df6db711d9c082a4061627c00200.camel@ipfire.org> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: <980b24a9a4a3df6db711d9c082a4061627c00200.camel@ipfire.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >>> >> >