Problems still with xfs

Problems still with xfs

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

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. After the reboot during the installation the screen went blank and nothing more happened.

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 different.

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.

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 versions of CU182.

Regards,

Adolf.

Re: Problems still with xfs

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

Hi Michael,

On 09/02/2024 13:00, Michael Tremer wrote:
> Hello Adolf,
> 
> Thanks for raising this. I had a look at this, but I believe it is a false alarm :)
:+1:
> 
>> 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. After the reboot during the installation the screen went blank and nothing more happened.
> 
> This is correct. Looking at the installation log, GRUB fails to install and shows a message. Sadly we don’t properly catch that on the installer.
> 
>> 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 different.
> 
> Yes, this is also correct. We rebuilt the update with GRUB 2.06 after seeing some problems with GRUB 2.12-rc1. But we actually only changed the updater and did not change the installation images.
> 
> This has two reasons: Mainly changing the images is a pain. We have ~30 mirrors 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 image.

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

> 
> The other one is that the problem has an easy workaround: Don’t use XFS. So installation of IPFire is possible. If you really want XFS, install the previous version and update.
> 
>> 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.
> 
> 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.
> 
> 
> 
>>
>> 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 versions of CU182.
> 
> 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 on my testbed so at least I can check the update and booting when a Testing release is done.

Regards,
Adolf.
> 
> -Michael
> 
>>
>> Regards,
>>
>> Adolf.
>>
> 

Re: Problems still with xfs

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

Hi Michael,

On 09/02/2024 13:20, Adolf Belka wrote:
> Hi Michael,
>
> On 09/02/2024 13:00, Michael Tremer wrote:
>> Hello Adolf,
>>
>> Thanks for raising this. I had a look at this, but I believe it is a false alarm :)
> :+1:
>>
>>> 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. After the reboot during the installation the screen went blank and nothing more happened.
>>
>> This is correct. Looking at the installation log, GRUB fails to install and shows a message. Sadly we don’t properly catch that on the installer.
>>
>>> 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 different.
>>
>> Yes, this is also correct. We rebuilt the update with GRUB 2.06 after seeing some problems with GRUB 2.12-rc1. But we actually only changed the updater and did not change the installation images.
>>
>> This has two reasons: Mainly changing the images is a pain. We have ~30 mirrors 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 image.
>
> I now remember you mentioning this for an earlier change but I had forgotten that.
> Can understand that it would be a right pita.
>
>>
>> The other one is that the problem has an easy workaround: Don’t use XFS. So installation of IPFire is possible. If you really want XFS, install the previous version and update.
>>
>>> 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.
>>
>> 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.
>
So I tested out the link for the master version you provided but that gave the CU183 iso.

xfs file system built without any problems with CU183.

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.

As it is a vm build that I am doing I can't access the logs from the install to see what is going wrong.

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.

CU183 will work fine with xfs so grub-2.12 has resolved whatever the problem was.


Regards,

Adolf.

>>
>>
>>>
>>> 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 versions of CU182.
>>
>> 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 on my testbed so at least I can check the update and booting when a Testing release is done.
>
> Regards,
> Adolf.
>>
>> -Michael
>>
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>

Re: Problems still with xfs

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4351 bytes --]

Hello,

Interesting. Maybe this was broken long before the GRUB update? Could be :)

-Michael

> On 9 Feb 2024, at 13:11, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 09/02/2024 13:20, Adolf Belka wrote:
>> Hi Michael,
>> 
>> On 09/02/2024 13:00, Michael Tremer wrote:
>>> Hello Adolf,
>>> 
>>> Thanks for raising this. I had a look at this, but I believe it is a false alarm :)
>> :+1:
>>> 
>>>> 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. After the reboot during the installation the screen went blank and nothing more happened.
>>> 
>>> This is correct. Looking at the installation log, GRUB fails to install and shows a message. Sadly we don’t properly catch that on the installer.
>>> 
>>>> 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 different.
>>> 
>>> Yes, this is also correct. We rebuilt the update with GRUB 2.06 after seeing some problems with GRUB 2.12-rc1. But we actually only changed the updater and did not change the installation images.
>>> 
>>> This has two reasons: Mainly changing the images is a pain. We have ~30 mirrors 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 image.
>> 
>> I now remember you mentioning this for an earlier change but I had forgotten that.
>> Can understand that it would be a right pita.
>> 
>>> 
>>> The other one is that the problem has an easy workaround: Don’t use XFS. So installation of IPFire is possible. If you really want XFS, install the previous version and update.
>>> 
>>>> 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.
>>> 
>>> 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.
>> 
> So I tested out the link for the master version you provided but that gave the CU183 iso.
> 
> xfs file system built without any problems with CU183.
> 
> 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.
> 
> As it is a vm build that I am doing I can't access the logs from the install to see what is going wrong.
> 
> 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.
> 
> CU183 will work fine with xfs so grub-2.12 has resolved whatever the problem was.
> 
> 
> Regards,
> 
> Adolf.
> 
>>> 
>>> 
>>>> 
>>>> 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 versions of CU182.
>>> 
>>> 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 on my testbed so at least I can check the update and booting when a Testing release is done.
>> 
>> Regards,
>> Adolf.
>>> 
>>> -Michael
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.