From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Problems still with xfs Date: Thu, 15 Feb 2024 14:53:22 +0000 Message-ID: In-Reply-To: <1167237b-01fc-427a-868e-ae06951622f2@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4006417400667853853==" List-Id: --===============4006417400667853853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Interesting. Maybe this was broken long before the GRUB update? Could be :) -Michael > On 9 Feb 2024, at 13:11, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 09/02/2024 13:20, Adolf Belka wrote: >> Hi Michael, >>=20 >> 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 fals= e alarm :) >> :+1: >>>=20 >>>> On 8 Feb 2024, at 12:23, Adolf Belka wrote: >>>>=20 >>>> Hi Michael and Arne, >>>>=20 >>>> I decided to build a vm testbed clone that would have an xfs filesystem. >>>>=20 >>>> I did the installation from Core Update 182 downloaded from the website.= After the reboot during the installation the screen went blank and nothing m= ore happened. >>>=20 >>> This is correct. Looking at the installation log, GRUB fails to install a= nd shows a message. Sadly we don=E2=80=99t properly catch that on the install= er. >>>=20 >>>> I then checked the sha256 hash for the website version with the one in t= he nightly build for Core Update 182 with the grub reversion and they are dif= ferent. >>>=20 >>> Yes, this is also correct. We rebuilt the update with GRUB 2.06 after see= ing some problems with GRUB 2.12-rc1. But we actually only changed the update= r and did not change the installation images. >>>=20 >>> This has two reasons: Mainly changing the images is a pain. We have ~30 m= irrors and getting them all up to date is too difficult. People might downloa= d parts of the file from different servers which results in an utterly broken= image. >>=20 >> I now remember you mentioning this for an earlier change but I had forgott= en that. >> Can understand that it would be a right pita. >>=20 >>>=20 >>> The other one is that the problem has an easy workaround: Don=E2=80=99t u= se XFS. So installation of IPFire is possible. If you really want XFS, instal= l the previous version and update. >>>=20 >>>> I then built a system with xfs filesystem using the CU182 from the night= ly build with the grub reversion but it still failed at the reboot stage of t= he 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/) a= nd this boots fine on XFS. >> Ah. That might be where my problem was. I used the CU182 nightly build. >>=20 >> https://nightly.ipfire.org/core182/2024-01-10%2021:49:02%20+0100-c903d67c/= x86_64/ >>=20 >> The changelog for that mentioned the grub revert commit so I thought that = was the one I should use. >>=20 >> Is master now the 182 version? I thought it was still the 183 testing one? >>=20 >> Anyway, I will test out the one from your link to confirm. >>=20 > So I tested out the link for the master version you provided but that gave = the CU183 iso. >=20 > xfs file system built without any problems with CU183. >=20 > I then tried the CU182 version again from the nightly and it failed again. = The log for that build shows it has grub-2.06 so the reversion was definitely= applied. >=20 > As it is a vm build that I am doing I can't access the logs from the instal= l to see what is going wrong. >=20 > However it is probably best to leave everything as it is. Most people will = use the download site for the iso's and can download CU181 and then update to= CU182, if they want to use xfs. >=20 > CU183 will work fine with xfs so grub-2.12 has resolved whatever the proble= m was. >=20 >=20 > Regards, >=20 > Adolf. >=20 >>>=20 >>>=20 >>>>=20 >>>> I then did an xfs build using the CU181 website download version and tha= t built without any problems. >>>>=20 >>>> I then did a pakfire update from CU181 to CU182 and that went without an= y problems, including the reboot. >>>>=20 >>>> Not sure what is going on but there seems to still be a problem with doi= ng a fresh installation with xfs using either the website or nightly build ve= rsions 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 a= nd confirm that. >>=20 >> Sorry for any noise. I just thought it was worth having an xfs based syste= m on my testbed so at least I can check the update and booting when a Testing= release is done. >>=20 >> Regards, >> Adolf. >>>=20 >>> -Michael >>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. --===============4006417400667853853==--