So Bullseye can't use exfat?

[Head_on_a_Stick]

Code: Select all

i A linux-image-5.7.0-2-pinebookpro-arm64 - Linux kernel, version 5.7.0-2-pinebookpro-arm64
i  linux-image-pinebookpro-arm64 - Linux kernel (meta-package)

Those aren't Debian kernels, which is probably why you're having problems.

https://wiki.debian.org/InstallingDebia ... 4/Pinebook says that the buster kernels should work so try them. Also consider re-installing from scratch, looks like your system is a bit of a mess:

Code: Select all

i  libc6 - GNU C Library: Shared libraries

Where's that from then?

Code: Select all

apt policy libc6

Can you elaborate ?

I was just speaking in general terms rather than specifically addressing the mkfs & fsck issues seen in this thread.

[p.H]

The exfatprogs package should be preferred because it uses the native kernel driver

What part of the exfatprogs package uses the native kernel driver ?

[Head_on_a_Stick]

Hmm, apparently it doesn't. Sorry for the misinformation and thanks for the correction.

@OP: exfatprogs should probably be preferred because it's written by the Samsung developers who wrote the kernel driver. But that's just my opinion.

@p.H: which would you recommend and why?

[p.H]

I do not use exFAT and have no reason to recommend one package over the other. I just wanted to make sure that either package was not recommended for the wrong reason.

[ab1jx]

OK, so it comes down to a kernel problem, I didn't expect that. And this is the only Bullseye machine I have running so I can't test.

Mark it solved.

[p.H]

Not sure what exactly is your problem. If the current kernel does not have native exFAT support, which you can check with

Code: Select all

grep -i exfat /boot/config-$(uname -r)
grep -i exfat /proc/filesystems
modinfo exfat

then all you have to do is install exfat-fuse and create the missing symlink mount.exfat -> mount.exfat-fuse.

[ab1jx]

Yes, I can with contortions mount and fsck exfat. But in Stretch and Buster I didn't need the contortions, I could just do mount /dev/sdb2 /sd or fsck /dev/sdb2 and it worked. I have a broken kernel which was made before that change, I don't know if I can get the config file and build a new one from it or not. Or if there's a way to dump out the config settings from a running kernel.

grep -i exfat /boot/config-$(uname -r)
gives

Code: Select all

# DOS/FAT/EXFAT/NT Filesystems
# CONFIG_EXFAT_FS is not set
# end of DOS/FAT/EXFAT/NT Filesystems


grep -i exfat /proc/filesystems
gives nothing at all

modinfo exfat
gives: modinfo: ERROR: Module exfat not found.
(And exfat-utils is installed, also exfat-fuse)

And the kernel actually is from Gentoo or Manjaro I think so it's complicated. I got it from https://forum.pine64.org/showthread.php?tid=8487 so I should grumble there [done], but I didn't know the issue was caused by the kernel.

I wouldn't use exfat by choice but my Nikon cameras do for SD cards over 32 GB, I could read them with no fuss until Bullseye with this kernel.

[p.H]

I can with contortions mount and fsck exfat.

Creating a symlink is not a huge contortion.

But in Stretch and Buster I didn't need the contortions,

Because the symlink was part of the exfat-fuse package.

I don't know if I can get the config file

I indicated it in my first command : /boot/config-$(uname -r)
Or /proc/config.gz but the related build option is not enabled in Debian kernels.

# CONFIG_EXFAT_FS is not set

This confirms that ExFAT support was disabled at build time. No need to run the other commands, I provided them only in case the config file was not available.

[ab1jx]

I didn't think just a symlink would do it. Maybe there's a place where mount checks and if it can find something it enables a file type. But there's no exfat in /proc/filesystems or /lib/modules. I'm used to mount -t <something>. There is an /sbin/mount.exfat-fuse. Also /sbin/mount.ntfs -> /sbin/mount.ntfs-3g -> /bin/ntfs-3g. But looking those up I would call a contortion, I probably won't remember it even a few months unless I use it a lot.

Wouldn't it be possible to write a utility that can read through a kernel and list out the options chosen in a format that you could feed back in to make a clone of that kernel? Like using a disassembler and assembling the output. Or make a small change. Except here I'd need to add in the binaries of the driver and the version would need to match. Or a .ko file, but again it would need to match.

[ab1jx]

Code: Select all

i A linux-image-5.7.0-2-pinebookpro-arm64 - Linux kernel, version 5.7.0-2-pinebookpro-arm64
i  linux-image-pinebookpro-arm64 - Linux kernel (meta-package)

Those aren't Debian kernels, which is probably why you're having problems.

https://wiki.debian.org/InstallingDebia ... 4/Pinebook says that the buster kernels should work so try them. Also consider re-installing from scratch, looks like your system is a bit of a mess:

Code: Select all

i  libc6 - GNU C Library: Shared libraries

Where's that from then?

Code: Select all

apt policy libc6

Can you elaborate ?

I was just speaking in general terms rather than specifically addressing the mkfs & fsck issues seen in this thread.

------------------
There's a Pinebook, which is older, smaller, different cores, then the Pinebook Pro which is 6 cores, 14 inch 1920x1080 display. I wouldn't trust anything that doesn't mention Pinebook Pro. Then again it's just on an SD card I can swap out. It's not much over a year old https://www.pine64.org/pinebook-pro/

It's mostly running, stable, uptime of a week, it's sort of a production machine. I have a 1 TB nvme SSD drive in it which I manually mount, I've gone on to other things. I wrote this on it: https://sourceforge.net/projects/cgi-jukebox/

This is all temporary, some day I'll get it booting from the nvme drive. It's good enough for now, I just thought something was wrong with Bullseye but hadn't been noticed.

[p.H]

Maybe there's a place where mount checks and if it can find something it enables a file type.

See the -t/--type option description in the mount manpage for details about how mount handles the type.
Quotes :

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
library for guessing the filesystem type

So if the type is not specified, mount will use the type displayed by blkid.

mount will execute the program /sbin/mount.type (if that exists) when called with type type.

So if blkid says that the filesystem type is "exfat", mount will try to run /sbin/mount.exfat first. If that does not exist, it will try to use the native kernel filesystem driver.

/sbin/mount.ntfs -> /sbin/mount.ntfs-3g -> /bin/ntfs-3g

This means that mount uses ntfs-3g to mount filesystems of the "ntfs" or "ntfs-3g" type.

I didn't think just a symlink would do it

The exfat-fuse package from bullseye does not create /sbin/mount.exfat any more, so that mount tried to use the exfat native kernel driver. If the running kernel lacks such driver, /sbin/mount.exfat must exist and point to the actual exfat external handler, /sbin/mount.exfat-fuse.

[p.H]

Wouldn't it be possible to write a utility that can read through a kernel and list out the options chosen in a format that you could feed back in to make a clone of that kernel?

If a kernel image was built with CONFIG_IKCONFIG enabled, its config information can be extracted with the script scripts/extract-ikconfig present in the kernel source. This option is disabled in official Debian kernels, but the kernel-image packages provide the config-* file in /boot, so extracting it from the kernel image is not needed.

[ab1jx]

Ah, from the pine64 forum moonwalkers pointed out
zcat /proc/config.gz
which in this case works. Very interesting, but I thought having hardcopy of the IBM PC AT bios source was interesting, I spent many lunch hours going through it (1980s). So:

Code: Select all

#
# DOS/FAT/EXFAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_EXFAT_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
# end of DOS/FAT/EXFAT/NT Filesystems


So why is there an exfat when there's also an ntfs? https://en.wikipedia.org/wiki/ExFAT Is the exfat a replacement for the ntfs?

Anyway I'm probably going to try this next: https://github.com/xmixahlx/pbp-tools/b ... tall-linux If I had the correct exfat.ko I'd be all set I think. But really know that I know why I can't easily mount it I'm sort of all set. I use /etc/motd to keep snippets in because I can cat it from anywhere, it would be a good place to put the mount.exfat stuff.

[p.H]

from the pine64 forum moonwalkers pointed out
zcat /proc/config.gz

I also pointed this pseudo-file out in a previous post. Anyway it should have the same contents as the regular file /boot/config-$(uname -r) that you already examined.

By the way, this configuration snippet is quite different from Debian standard kernel configuration.
Debian disabled NTFS support in buster kernel and disabled the very limited NTFS write support in previous kernel releases, whereas this one has both enabled. Also Debian builds most features as modules (=m) whereas this kernel has FAT and NTFS support built in (=y).

I thought having hardcopy of the IBM PC AT bios source was interesting

What does the BIOS source have to do with the kernel configuration ?

So why is there an exfat when there's also an ntfs?

Because they are different filesystems and the kernel has separate configuration options for each of them.

Is the exfat a replacement for the ntfs?

No, it is rather a replacement for FAT targeted at removable storage such as SD cards or USB flash drives.

If I had the correct exfat.ko I'd be all set I think.

Debian buster does not have exfat.ko and still can mount exFAT filesystems with exfat-fuse. Creating the missing symlink mount.ext4 -> mount.exfat-fuse in bullseye seems a lot easier than building the missing exfat.ko module to me.

[ab1jx]

Yes, it was easier:

Code: Select all

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *    32768 124735487 124702720 59.5G  7 HPFS/NTFS/exFAT
root@pbp:/data# mount /dev/sda1 /sd
FUSE exfat 1.3.0


But I had no idea it would do that, it's exactly what I wanted. If all these little mount programs were in some special place that had nothing else it would make more sense to me, like kernel modules are all in /lib/modules. Maybe /etc/filesystems or have that hold symlinks to them. It's still not in /proc/filesystems.

And fsck now also works on it

Code: Select all

fsck /dev/sda1
fsck from util-linux 2.36.1
exfatfsck 1.3.0
Checking file system on /dev/sda1.
File system version           1.0
Sector size                 512 bytes
Cluster size                128 KB
Volume size                  59 GB
Used space                   17 MB
Available space              59 GB
Totally 1 directories and 1 files.
File system checking finished. No errors found.


The kernel originates with tsys at pine64.org https://forum.pine64.org/showthread.php?tid=8207 and https://gitlab.manjaro.org/tsys/linux-pinebook-pro

But from reading the Wikipedia page more exfat is Extensible File Allocation Table, it doesn't have much in common with ntfs. Both exfat and ntfs were initially proprietary with no details released. Exfat came out a year before I retired so I never used it until lately on SD cards, I only used ntfs when I had to on a 64 GB RAID stack because Norton Disk Doctor couldn't work on it. I used 32 GB max FAT32 partitions, still do.