[opensuse] exfat support in kernel 5.7
Provided I have the former exfat support installed on my system, is this a problem when now kernel 5.7 comes, with integrated new exfat support and is there any action needed from my part (like e.g. un-install of the former rpm)? Thank you in advance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2020 06:12, Stakanov wrote:
Provided I have the former exfat support installed on my system, is this a problem when now kernel 5.7 comes, with integrated new exfat support and is there any action needed from my part (like e.g. un-install of the former rpm)?
Thank you in advance.
Well I'm finding it a problem! I have some large (128G/256G) cards that i got at a good price. I've taken the time to check out their quality using tools like F3 and they are fine. I'm delighted! So I plan to use one of these in my late model phone which can handle that size card. These are not high speed cards (which is probably why they were cheap) and are not great in any of my cameras, but for books and texts and music on my phone I can manage.[1] So I 'm using # uname -a Linux main.HOME.SystemI.ca 5.7.0-3.gad96a07-default #1 SMP Wed Jun 3 06:57:28 UTC 2020 (ad96a07) x86_64 x86_64 x86_64 GNU/Linux Actually there's 5.7.1-2.1 in my /boot waiting for a reboot and what I'm finding is that I can load up three levels of directory Books +- PDF | +- | +- ePUB | +- Authorname1 | +- various books | | +- authorname2 | +- various books and that's fine. Then I remove= the card and insert it in the phone/tablet/laptop and LO! everything except the top level and any files there are GONE! Contrariwise if I create multi level folders/directories and content on the other devices it stays there ... until I put the card in the PC running Linux and the Linux EXFAT driver, whence it vanishes, as in vanishes so that even when the card is returned to other devices only the top level is visible. Use in Linux has 'removed' or removed access to the rest. Something odd is going on. I've tried monitoring space usage. When the files were visible they seemed to take up space as reported by 'DF'. When the files had vanished DF reported the same space consumption. [1] I don't use my phone camera much -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 9 giugno 2020 13:54:57 CEST, Anton Aylward ha scritto:
On 09/06/2020 06:12, Stakanov wrote:
Provided I have the former exfat support installed on my system, is this a problem when now kernel 5.7 comes, with integrated new exfat support and is there any action needed from my part (like e.g. un-install of the former rpm)?
Thank you in advance.
Well I'm finding it a problem!
I have some large (128G/256G) cards that i got at a good price. I've taken the time to check out their quality using tools like F3 and they are fine. I'm delighted!
So I plan to use one of these in my late model phone which can handle that size card. These are not high speed cards (which is probably why they were cheap) and are not great in any of my cameras, but for books and texts and music on my phone I can manage.[1]
So I 'm using # uname -a Linux main.HOME.SystemI.ca 5.7.0-3.gad96a07-default #1 SMP Wed Jun 3 06:57:28 UTC 2020 (ad96a07) x86_64 x86_64 x86_64 GNU/Linux
Actually there's 5.7.1-2.1 in my /boot waiting for a reboot
and what I'm finding is that I can load up three levels of directory
Books +- PDF
| +-
+- ePUB
| +- Authorname1 | | +- various books | | +- authorname2 | | +- various books
and that's fine. Then I remove= the card and insert it in the phone/tablet/laptop and LO! everything except the top level and any files there are GONE!
Contrariwise if I create multi level folders/directories and content on the other devices it stays there
... until I put the card in the PC running Linux and the Linux EXFAT driver, whence it vanishes, as in vanishes so that even when the card is returned to other devices only the top level is visible. Use in Linux has 'removed' or removed access to the rest.
Something odd is going on. I've tried monitoring space usage. When the files were visible they seemed to take up space as reported by 'DF'. When the files had vanished DF reported the same space consumption.
[1] I don't use my phone camera much
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon? Did you have exfat support with rpm installed? Then maybe the two are conflicting?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/2020 09:34, Stakanov wrote:
Did you have exfat support with rpm installed? Then maybe the two are conflicting?
As it happens I do, but they are not conflicting since I don't have the kernel module version enabled. # rpm -qa | grep -i exfat exfat-utils-1.3.0-lp151.5.3.x86_64 fuse-exfat-1.3.0-lp151.6.3.x86_64 main:~ # lsmod | grep -i exfat main:~ # OO, I'll reverse that situation and try again :-) main:~ # zypper rm fuse-exfat Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: fuse-exfat 1 package to remove. After the operation, 87.5 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): (1/1) Removing fuse-exfat-1.3.0-lp151.6.3.x86_64 ...........................................................[done] Additional rpm output: Deleted 'exfat' and 'exfat_fuse' from the file /etc/filesystems OUCH! main:~ # modprobe exfat main:~ # lsmod | grep fat exfat 86016 0 vfat 24576 0 fat 86016 1 vfat main:~ # grep fat /etc/filesystems vfat Wait a moment ... main:~ # cat /etc/filesystems vfat hfs minix reiserfs * That isn't very helpful. Where did the hfs and minix come from? What does the "*" mean. RTFM main:~ # cat /proc/filesystems nodev sysfs nodev tmpfs nodev bdev nodev proc nodev cgroup nodev cgroup2 nodev cpuset nodev devtmpfs nodev debugfs nodev tracefs nodev securityfs nodev sockfs nodev bpf nodev pipefs nodev ramfs nodev hugetlbfs nodev devpts ext3 ext2 ext4 nodev autofs nodev mqueue nodev pstore reiserfs jfs fuseblk nodev fuse nodev fusectl vfat exfat I think I ned to do some manual editing ... What's with that asterix? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Well the kernel version of the exfat driver is, as expected, faster than the FUSE version. it seems to be running at about the speed limit of the card. Which, as I said, isn't that fabulous, but for the application required, I think it will be adequate. I'll post more details about the result. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data mercoledì 10 giugno 2020 15:29:15 CEST, Anton Aylward ha scritto:
Well the kernel version of the exfat driver is, as expected, faster than the FUSE version. it seems to be running at about the speed limit of the card. Which, as I said, isn't that fabulous, but for the application required, I think it will be adequate.
I'll post more details about the result.
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
Interesting, so, if you install the 5.7 with e.g. Tumbleweed and have the fuse installed, it is not "kernel obsoletes" but you need to uninstall fuse and activate the kernel version? FUSE was known to have issues. I hope you have better outcome with the kernel version one. (To defend FUSE, it was reverse engineering, I think after Samsung did let escape the code. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/06/2020 09:58, Stakanov wrote:
Interesting, so, if you install the 5.7 with e.g. Tumbleweed and have the fuse installed, it is not "kernel obsoletes" but you need to uninstall fuse and activate the kernel version?
Not that simple! I now have to, one way or another, do a modprobe exfat I could fail to do that and manually load the FUSE-exfat instead. Just don't do both! OBTW, I'm not, otherwise, running tumbleweed. This may be a weedie kernel but ... # zypper info kernel-default-5.7.1-3.1.g6a549f6.x86_64 Information for package kernel-default: --------------------------------------- Repository : Kernel_Stable Name : kernel-default Version : 5.7.1-3.1.g6a549f6 Arch : x86_64 Vendor : obs://build.opensuse.org/Kernel Installed Size : 171.8 MiB Installed : Yes Status : up-to-date Source package : kernel-default-5.7.1-3.1.g6a549f6.nosrc Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems. Source Timestamp: 2020-06-10 11:53:46 +0000 GIT Revision: 6a549f6dd07f682dbe4308ce21c26c40dca1ffa2 GIT Branch: stable Now how to get info on the exfat driver itself? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 11 giugno 2020 14:17:22 CEST, Anton Aylward ha scritto:
On 10/06/2020 09:58, Stakanov wrote:
Interesting, so, if you install the 5.7 with e.g. Tumbleweed and have the fuse installed, it is not "kernel obsoletes" but you need to uninstall fuse and activate the kernel version?
Not that simple!
I now have to, one way or another, do a modprobe exfat
I could fail to do that and manually load the FUSE-exfat instead.
Just don't do both!
OBTW, I'm not, otherwise, running tumbleweed. This may be a weedie kernel but ...
# zypper info kernel-default-5.7.1-3.1.g6a549f6.x86_64
Information for package kernel-default: --------------------------------------- Repository : Kernel_Stable Name : kernel-default Version : 5.7.1-3.1.g6a549f6 Arch : x86_64 Vendor : obs://build.opensuse.org/Kernel Installed Size : 171.8 MiB Installed : Yes Status : up-to-date Source package : kernel-default-5.7.1-3.1.g6a549f6.nosrc Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems.
Source Timestamp: 2020-06-10 11:53:46 +0000 GIT Revision: 6a549f6dd07f682dbe4308ce21c26c40dca1ffa2 GIT Branch: stable
Now how to get info on the exfat driver itself?
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with $ cat /proc/filesystems get a list with all supported file systems. Unlike fuse that did not show up with this command AFAIK for IP reasons, this time it "should"(!) actually show up. If you succeed I would enjoy your feedback here. Thanks in advance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 11 giugno 2020 17:40:53 CEST, Stakanov ha scritto:
In data giovedì 11 giugno 2020 14:17:22 CEST, Anton Aylward ha scritto:
On 10/06/2020 09:58, Stakanov wrote:
Interesting, so, if you install the 5.7 with e.g. Tumbleweed and have the fuse installed, it is not "kernel obsoletes" but you need to uninstall fuse and activate the kernel version?
Not that simple!
I now have to, one way or another, do a
modprobe exfat
I could fail to do that and manually load the FUSE-exfat instead.
Just don't do both!
OBTW, I'm not, otherwise, running tumbleweed. This may be a weedie kernel but ...
# zypper info kernel-default-5.7.1-3.1.g6a549f6.x86_64
Information for package kernel-default: --------------------------------------- Repository : Kernel_Stable Name : kernel-default Version : 5.7.1-3.1.g6a549f6 Arch : x86_64 Vendor : obs://build.opensuse.org/Kernel Installed Size : 171.8 MiB Installed : Yes Status : up-to-date Source package : kernel-default-5.7.1-3.1.g6a549f6.nosrc Summary : The Standard Kernel
Description : The standard kernel for both uniprocessor and multiprocessor systems.
Source Timestamp: 2020-06-10 11:53:46 +0000 GIT Revision: 6a549f6dd07f682dbe4308ce21c26c40dca1ffa2 GIT Branch: stable
Now how to get info on the exfat driver itself?
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
get a list with all supported file systems. Unlike fuse that did not show up with this command AFAIK for IP reasons, this time it "should"(!) actually show up. If you succeed I would enjoy your feedback here. Thanks in advance. BTW, here fuse shows up as a module.
cat /proc/modules fuse 118784 1 - Live 0x0000000000000000 So if the first does not work, try this one. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 12 giugno 2020 01:42:49 CEST, Anton Aylward ha scritto:
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon? Yeap, sorry, I overlooked it. BTW, there is nearly no information about this problem on the net. Seems to recent?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 01.42, Anton Aylward wrote:
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems
I would say that /etc/filesystems is deprecated. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data venerdì 12 giugno 2020 09:27:46 CEST, Carlos E. R. ha scritto:
On 12/06/2020 01.42, Anton Aylward wrote:
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems
I would say that /etc/filesystems is deprecated. In favor of....?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 12 Jun 2020 14:34:04 +0200 Stakanov <stakanov@disroot.org> wrote:
In data venerdì 12 giugno 2020 09:27:46 CEST, Carlos E. R. ha scritto:
On 12/06/2020 01.42, Anton Aylward wrote:
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems
I would say that /etc/filesystems is deprecated. In favor of....?
According to Mr google, followed by Mr man, the two serve different purposes: https://www.man7.org/linux/man-pages/man5/proc.5.html /proc/filesystems A text listing of the filesystems which are supported by the kernel, namely filesystems which were compiled into the kernel or whose kernel modules are currently loaded. (See also filesystems(5).) If a filesystem is marked with "nodev", this means that it does not require a block device to be mounted (e.g., virtual filesystem, network filesystem). Incidentally, this file may be used by mount(8) when no filesystem is specified and it didn't manage to determine the filesystem type. Then filesystems contained in this file are tried (excepted those that are marked with "nodev"). https://linux.die.net/man/8/mount "If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid or volume_id library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesystem types listed there will be tried, except for those that are labeled "nodev" (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single * only, mount will read /proc/filesystems afterwards. FWIW, /etc/filesystems on my system contains: # cat /etc/filesystems vfat hfs minix reiserfs * /proc/filesystems contains a list of the filesystems I can use, including things like btrfs and xfs and other obscure things. It doesn't contain hfs or minix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 10:28, Dave Howorth wrote: (Thank you for the RTFM extract highlighting the matter. I'd overlooked part of that :-/)
FWIW, /etc/filesystems on my system contains:
# cat /etc/filesystems vfat hfs minix reiserfs *
That seems to be the installation default.
/proc/filesystems contains a list of the filesystems I can use, including things like btrfs and xfs and other obscure things. It doesn't contain hfs or minix.
Those two seem real outliers. In the 98% case I can't see their presence there being useful and they might introduce unwarranted effort/delays in the 'auto' scanning. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 16.28, Dave Howorth wrote:
On Fri, 12 Jun 2020 14:34:04 +0200 Stakanov <stakanov@disroot.org> wrote:
In data venerdì 12 giugno 2020 09:27:46 CEST, Carlos E. R. ha scritto:
On 12/06/2020 01.42, Anton Aylward wrote:
On 11/06/2020 11:40, Stakanov wrote:
I am far from being an expert, but, provided you have uninstalled fuse and that you are running the linux 5.7 kernel then you should with
$ cat /proc/filesystems
Go back over the thread and I discussed the disparity between that and /etc/filesystems
I would say that /etc/filesystems is deprecated. In favor of....?
According to Mr google, followed by Mr man, the two serve different purposes:
https://www.man7.org/linux/man-pages/man5/proc.5.html
/proc/filesystems A text listing of the filesystems which are supported by the kernel, namely filesystems which were compiled into the kernel or whose kernel modules are currently loaded. (See also filesystems(5).) If a filesystem is marked with "nodev", this means that it does not require a block device to be mounted (e.g., virtual filesystem, network filesystem).
Incidentally, this file may be used by mount(8) when no filesystem is specified and it didn't manage to determine the filesystem type. Then filesystems contained in this file are tried (excepted those that are marked with "nodev").
https://linux.die.net/man/8/mount
"If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid or volume_id library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesystem types listed there will be tried, except for those that are labeled "nodev" (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single * only, mount will read /proc/filesystems afterwards.
FWIW, /etc/filesystems on my system contains:
# cat /etc/filesystems vfat hfs minix reiserfs *
/proc/filesystems contains a list of the filesystems I can use, including things like btrfs and xfs and other obscure things. It doesn't contain hfs or minix.
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified. But you see, I use both xfs and btrfs which are not listed in /etc/filesystems, so this file is no use. Further, this file comes direct from an rpm: cer@Telcontar:~> rpm -qf /etc/filesystems util-linux-2.33.1-lp151.3.3.2.x86_64 cer@Telcontar:~> So it can not reflect what the system actually supports - which is why I say that it must be deprecated, in favour of /proc/filesystems. cer@Telcontar:~> cat /etc/filesystems vfat hfs minix reiserfs exfat exfat_fuse * cer@Telcontar:~> cer@Telcontar:~> cat /proc/filesystems nodev sysfs nodev rootfs nodev ramfs nodev bdev nodev proc nodev cpuset nodev cgroup nodev cgroup2 nodev tmpfs nodev devtmpfs nodev debugfs nodev tracefs nodev securityfs nodev sockfs nodev dax nodev bpf nodev pipefs nodev hugetlbfs nodev devpts ext3 ext2 ext4 nodev autofs nodev pstore nodev mqueue nodev resctrl nodev efivarfs nodev configfs nodev rpc_pipefs nodev nfsd vfat xfs reiserfs nodev binfmt_misc fuseblk nodev fuse nodev fusectl cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified.
No. /proc/filesystems tells what is loaded in the current kernel. I don't use xfs, so currently xfs is not in /proc/filesystems. If I would mount an xfs partition(*) it would load the respective module(s), and it would show up. /etc/filesystems is read by mount if no filesystem type has been specified, and the built-in autodetection via blkid fails. So basically /etc/filesystems should list filesystem types that cannot be autodetected, but that you might want to mount without specifying the type with -t (*)which would succeed although xfs is neither in /proc/filesystems nor in /etc/filesystems, because mount can auto-detect this type, so it will anyhow not look at either of them.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 19.45, Peter Suetterlin wrote:
Carlos E. R. wrote:
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified.
No.
/proc/filesystems tells what is loaded in the current kernel. I don't use xfs, so currently xfs is not in /proc/filesystems. If I would mount an xfs partition(*) it would load the respective module(s), and it would show up.
Ah! I see what you mean. ... So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data venerdì 12 giugno 2020 20:09:28 CEST, Carlos E. R. ha scritto:
On 12/06/2020 19.45, Peter Suetterlin wrote:
Carlos E. R. wrote:
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified.
No.
/proc/filesystems tells what is loaded in the current kernel. I don't use xfs, so currently xfs is not in /proc/filesystems. If I would mount an xfs partition(*) it would load the respective module(s), and it would show up.
Ah! I see what you mean.
...
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse. But if I looked well at your output you have both, exfat and exfat-fuse installed? Does this cause no conflict?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 20.22, Stakanov wrote:
In data venerdì 12 giugno 2020 20:09:28 CEST, Carlos E. R. ha scritto:
On 12/06/2020 19.45, Peter Suetterlin wrote:
Carlos E. R. wrote:
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified.
No.
/proc/filesystems tells what is loaded in the current kernel. I don't use xfs, so currently xfs is not in /proc/filesystems. If I would mount an xfs partition(*) it would load the respective module(s), and it would show up.
Ah! I see what you mean.
...
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse. But if I looked well at your output you have both, exfat and exfat-fuse installed? Does this cause no conflict?
I have not done that myself. I don't recall doing it, at least. cer@Telcontar:~> rpm -qa | grep exfat fuse-exfat-1.2.8-lp151.1.1.x86_64 exfat-utils-1.2.8-lp151.1.2.x86_64 cer@Telcontar:~> cer@Telcontar:~> uname -a Linux Telcontar 4.12.14-lp151.28.48-default #1 SMP Fri Apr 17 05:38:36 UTC 2020 (18849d1) x86_64 x86_64 x86_64 GNU/Linux cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 12 Jun 2020 20:54:15 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/06/2020 20.22, Stakanov wrote:
In data venerdì 12 giugno 2020 20:09:28 CEST, Carlos E. R. ha scritto:
On 12/06/2020 19.45, Peter Suetterlin wrote:
Carlos E. R. wrote:
Ok, so both say in different words that can be used to mount a filesystem when the type is not specified.
No.
/proc/filesystems tells what is loaded in the current kernel. I don't use xfs, so currently xfs is not in /proc/filesystems. If I would mount an xfs partition(*) it would load the respective module(s), and it would show up.
Ah! I see what you mean.
...
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse. But if I looked well at your output you have both, exfat and exfat-fuse installed? Does this cause no conflict?
No, his output was /etc/filesystems which shows a list of possibilities to be tested and says nothing about actual capabilities.
I have not done that myself. I don't recall doing it, at least.
cer@Telcontar:~> rpm -qa | grep exfat fuse-exfat-1.2.8-lp151.1.1.x86_64 exfat-utils-1.2.8-lp151.1.2.x86_64 cer@Telcontar:~> cer@Telcontar:~> uname -a Linux Telcontar 4.12.14-lp151.28.48-default #1 SMP Fri Apr 17 05:38:36 UTC 2020 (18849d1) x86_64 x86_64 x86_64 GNU/Linux cer@Telcontar:~>
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 14:22, Stakanov wrote:
But if I looked well at your output you have both, exfat and exfat-fuse installed? Does this cause no conflict?
I'm sorry, I don't see why it should. There's a whole raft of kernel modules under /lib/modules/$(uname -r)/kernel in general and under fs/ in particular. So what? Unless you do a modprobe to wake a specific one of them, activate them, then nothing doing. Similarly unless you startup the FUSE and exfat-FUSE then nothing doing. I realise that you can set up a module to be loaded automatically on boot or demand, but that's another matter. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse.
Not a file. But you can 'ls /lib/modules/$(uname -r)/kernel/fs/' to see available file system modules. Together with /proc/filesystems (which has those compiled into the kernel) that should be fairly complete.... (minus the fuse ones, as you noted) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/06/2020 23.16, Peter Suetterlin wrote:
Carlos E. R. wrote:
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse.
Not a file. But you can 'ls /lib/modules/$(uname -r)/kernel/fs/' to see available file system modules. Together with /proc/filesystems (which has those compiled into the kernel) that should be fairly complete.... (minus the fuse ones, as you noted)
Interesting. cer@Telcontar:~> ls /lib/modules/$(uname -r)/kernel/fs/ 9p cramfs gfs2 nfs_common quota adfs dlm hfs nfsd reiserfs affs ecryptfs hfsplus nilfs2 romfs befs efivarfs hpfs nls squashfs bfs efs isofs ocfs2 squashfs3 binfmt_misc.ko exofs jffs2 omfs sysv btrfs f2fs jfs orangefs ubifs cachefiles fat lockd overlayfs udf ceph freevxfs minix pstore ufs cifs fscache ncpfs qnx4 xfs configfs fuse nfs qnx6 cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data sabato 13 giugno 2020 13:20:27 CEST, Carlos E. R. ha scritto:
On 12/06/2020 23.16, Peter Suetterlin wrote:
Carlos E. R. wrote:
So we do not have a file with full list of possible filesystems supported by running kernel. Even less including those supported by fuse.
Not a file. But you can 'ls /lib/modules/$(uname -r)/kernel/fs/' to see available file system modules. Together with /proc/filesystems (which has those compiled into the kernel) that should be fairly complete.... (minus the fuse ones, as you noted)
Interesting.
cer@Telcontar:~> ls /lib/modules/$(uname -r)/kernel/fs/ 9p cramfs gfs2 nfs_common quota adfs dlm hfs nfsd reiserfs affs ecryptfs hfsplus nilfs2 romfs befs efivarfs hpfs nls squashfs bfs efs isofs ocfs2 squashfs3 binfmt_misc.ko exofs jffs2 omfs sysv btrfs f2fs jfs orangefs ubifs cachefiles fat lockd overlayfs udf ceph freevxfs minix pstore ufs cifs fscache ncpfs qnx4 xfs configfs fuse nfs qnx6 cer@Telcontar:~> I am getting also: binfmt_misc.ko but I have no idea what this could be? Is this to tell me some file system went KO? (just joking).
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Peter Suetterlin -
Stakanov