[Testing Update] 2023-09-30 - Systemd, Firefox, LibreOffice, AMDVLK

Not sure if it’s a bug, but my /home directory with xfs filesystem-format can’t be mounted after this update. I had to go back to stable branch and downgrade.
I get the following error message:

% mount <m_dir>
mount: unknown filesystem type 'xfs'

Same error message when I try to mount the partition manually in emergency mode with
mount -t xfs /dev/sdxy /path/to/mountpoint

As stated previously: With the latest stable Update /home is mounted perfectly fine at boot.
It can also be that the problem is from the [Testing Update] 2023-09-27 - Kernels, Thunderbird, Firefox, LibreOffice - #6 Update as well. Or here: [Testing Update] 2023-09-22 - Kernels, NVIDIA, Mesa, GNOME
Both are Updates with kernel-updates.
Can someone confirm? Or tell me which Update exactely causes it?

Found this in archlinux-Forum: [SOLVED]mount : unknown filesystem type / Newbie Corner / Arch Linux Forums. It describes the same problem I have. I also tried rebooting, but for me the only solution atm is, that I downgrade to stable, otherwise I couldn’t boot.
Kernels tried after Update: linux61, linux515, linux510. Always the same error message when manjaro comes at the mount point of /home as described above.

That will with the utmost certainty be the kernel. Apparently your kernel does not have a driver — whether built in or via a loadable module — for the xfs filesystem.

Can you confirm by downgrading grub your system still works?

@philm, even though (the stock) grub has always had a problem with xfs, @seantum is talking about their /home filesystem, which grub has nothing to do with. grub only cares about the filesystem that grub.cfg, the kernels and the initcpios are on.

Obviously — as visible from the pasted terminal output — their root filesystem isn’t xfs.

I don’t see any pasted partitioning info from @seantum. However we always hold back grub for issues with xfs. Only the last two testing updates had grub updated. So let’s see if that the issue is or not.

I had to do the “remove grub-update before then doing an upgrade (including grub downgrade)” again, same as a couple months ago.

1 Like

@philm This update causes Manjaro linux on kde plasma to hard reset. I don’t know whether it’s kernel panic or something else, but if I rollback to previous update and do not update this one, everything is fine.
Here are my specs before update on the screenshot:

1 Like

The same problem and solution here.
grub-update-2.12rc1.r31.g42a831d74-1
Error: not found: grub-update-2.12rc1.r31.g42a831d74-1

Interesting that you mention that. I am running KDE plasma stable update 2023-09-18, after being away from my system for a couple of hours recently, I returned to find all the applications I had running were no longer there. I presumed I had accidentally logged out without realising and on returning had entered my password without noticing I was logging in again, but your post suggests my other suspicion of the desktop session resetting somehow.

@sibwase @kwacorn Can you make sur you’re not using a testing Kernel and report if the issue occurs on LTS Kernel too? I have latest update, did not notice hard reset with Kernel 6.1

Also @kwacorn this is the Testing update thread so problems with Stable are not really relevant here as we have more package updates.

:arrow_down:


So my root is btrfs and my home is xfs. Xfs can’t be mounted. I’m trying again now and then downgrading grub as you suggested.

So, installed all testing Updates > reboot > Error-messages as described:

FAILED - Failed to mount /home
Dependency failed for Local File Systems
You are in emergency mode [...]
[manjaro ~}# mount -t xfs /dev/sdb2 /home
mount: /home: unknown file system type "xfs"
dmesg(1) could give more information after a failed mount.

So I chrooted and did
sudo downgrade grub
as suggested > reboot > NOK

Back with chroot in live: tried
sudo downgrade linux61
(the kernel I am using) > OK!

Conclusion:
xfs works with linux 6.1.53-1 but doesn’t with linux 6.1.55-1
same for 5.15-133 and 5.10-197 - I can’t downgrade to the stable version for these two kernels in this case. Seems that I don’t have the packages anymore. (would need to go completely stable again to test that)
@philm

1 Like

But Kernel 6.1.55 LTS and 6.5.5 work fine with XFS on my encrypted partition for me.

strange. Trying 6.5.5 here as well.
Maybe I’ll open a ticket then.

Can you share $ sudo xfs_info /dev/[HOME_PARTITION] with us?

Info from my XFS partition on HDD:

meta-data=/dev/mapper/luks-e72345f-f640-4e44-a4f1-ab246546663 isize=512    agcount=5, agsize=268435455 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=1220933376, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[manjaro~]sudo xfs_info /dev/sdb2
[sudo] Passwort für thomas:

meta-data=/dev/sdb2              isize=512    agcount=4, agsize=21784250 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0 nrext64=0
data     =                       bsize=4096   blocks=87136997, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =Internes Protokoll     bsize=4096   blocks=42547, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =keine                  extsz=4096   blocks=0, rtextents=0

EDIT:
OK, I solved the problem. You’ll never believe me what the problem was.
/etc/fstab contained an error in the UUID at the entry of /boot. (It’s even in my screenshot above. I didn’t see it and noone else :D)
How Manjaro was able to boot in first place - I don’t get it. I corrected the UUID, and now I am on
Linux manjaro 6.5.5-1-MANJARO #1 SMP PREEMPT_DYNAMIC Sat Sep 23 12:48:15 UTC 2023 x86_64 GNU/Linux and in testing branch
Trying the other kernels now. - But I guess that was it.
These are errors you’re searching forever. :smiley:

EDIT2:
The other kernels work as well, linux61 and linux515

Thanks everyone for your valuable help :slight_smile:

Okay, I will test and respond tomorrow
Any additional tests/logs needed?

question about Grub :
in testing and after in stable ,manjaro team will downgrade version to 2.06.r499 ,
or this is just for some cases or new version 2.12rc1 will be added ?
there is 2 years between theses 2 versions

FYI
grub version 2.12rc1 is already in the unstable branch.

I remember Grub update caused Grub failing to boot. I have seen many same problem reports on the internet and EOS forum maybe 2 years ago.

I suspect that for stability reasons the Manjaro team prevents the Grub update in the testing branch and the stable branch for many inexperienced users who do not understand chroot.

1 Like