From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Problems still with xfs
Date: Fri, 09 Feb 2024 13:20:45 +0100
Message-ID: <1cd61387-6d99-4428-8f84-a08d7b970363@ipfire.org>
In-Reply-To: <7FA3C905-6DAA-4433-89FA-077E1E93EC61@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7124540318228527872=="
List-Id: <development.lists.ipfire.org>

--===============7124540318228527872==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

On 09/02/2024 13:00, Michael Tremer wrote:
> Hello Adolf,
>=20
> Thanks for raising this. I had a look at this, but I believe it is a false =
alarm :)
:+1:
>=20
>> On 8 Feb 2024, at 12:23, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael and Arne,
>>
>> I decided to build a vm testbed clone that would have an xfs filesystem.
>>
>> I did the installation from Core Update 182 downloaded from the website. A=
fter the reboot during the installation the screen went blank and nothing mor=
e happened.
>=20
> This is correct. Looking at the installation log, GRUB fails to install and=
 shows a message. Sadly we don=E2=80=99t properly catch that on the installer.
>=20
>> I then checked the sha256 hash for the website version with the one in the=
 nightly build for Core Update 182 with the grub reversion and they are diffe=
rent.
>=20
> Yes, this is also correct. We rebuilt the update with GRUB 2.06 after seein=
g some problems with GRUB 2.12-rc1. But we actually only changed the updater =
and did not change the installation images.
>=20
> This has two reasons: Mainly changing the images is a pain. We have ~30 mir=
rors and getting them all up to date is too difficult. People might download =
parts of the file from different servers which results in an utterly broken i=
mage.

I now remember you mentioning this for an earlier change but I had forgotten =
that.
Can understand that it would be a right pita.

>=20
> The other one is that the problem has an easy workaround: Don=E2=80=99t use=
 XFS. So installation of IPFire is possible. If you really want XFS, install =
the previous version and update.
>=20
>> I then built a system with xfs filesystem using the CU182 from the nightly=
 build with the grub reversion but it still failed at the reboot stage of the=
 installation.
>=20
> That should actually work. I just tested the current master image (https://=
nightly.ipfire.org/master/2024-02-02%2007:52:09%20+0000-8c43d148/x86_64/) and=
 this boots fine on XFS.
Ah. That might be where my problem was. I used the CU182 nightly build.

https://nightly.ipfire.org/core182/2024-01-10%2021:49:02%20+0100-c903d67c/x86=
_64/

The changelog for that mentioned the grub revert commit so I thought that was=
 the one I should use.

Is master now the 182 version? I thought it was still the 183 testing one?

Anyway, I will test out the one from your link to confirm.
>=20
>=20
>=20
>>
>> I then did an xfs build using the CU181 website download version and that =
built without any problems.
>>
>> I then did a pakfire update from CU181 to CU182 and that went without any =
problems, including the reboot.
>>
>> Not sure what is going on but there seems to still be a problem with doing=
 a fresh installation with xfs using either the website or nightly build vers=
ions of CU182.
>=20
> That might be, but it should be fine from Core Update 183.
I hadn't actually tested out the Core Update version, so I will also try and =
confirm that.

Sorry for any noise. I just thought it was worth having an xfs based system o=
n my testbed so at least I can check the update and booting when a Testing re=
lease is done.

Regards,
Adolf.
>=20
> -Michael
>=20
>>
>> Regards,
>>
>> Adolf.
>>
>=20

--===============7124540318228527872==--