No Implementation: GNU Parted cannot resize this partition to this size.
We're working on it!

Dozens of Gnome developers working on it full time over 15 years and cannot solve it:
https://alioth-lists.debian.net/pipermail/parted-devel/2009-September/003200.html
https://bugzilla.gnome.org/show_bug.cgi?id=649324
https://gitlab.gnome.org/GNOME/gparted/-/issues/245
#gnome #parted #fat #vfat
@linuxmemes

[parted-devel] resizing FAT partitions does not work at all

wieder was gelernt: künftig #exFAT, nicht #vFAT für usbsticks etc verwenden..
@nabor @Klimakipppunkt @CrazyIT @alexantemachina

Da ich tatsächlich keine Möglichkeit sehe, HA auf ein vernünftiges Filesystem zu installieren - so ich das sehe, hat man, egal welche Installationsvariante man wählt, immer ein
#vFat #Dateisystem - wird wohl das Auslagern der #Datenbank respektive, eine ganz andere DB anzuflanschen, der einzige Ansatz sein, der Sinn macht, um ein stabiles System zu bekommen, bei dem nicht nach jedem Stromausfall alle Daten weg sind.

Den statischen Teil von /homeassistant kann man ja einmal wegsichern und bei Bedarf zurückspielen.

Die Datenbank muss aber stabil sein, um nicht immer wieder zeitweise Datenverlust zu haben, weil zwischen letzem Backup und Ausfall Zeit vergangen ist.

Am Besten kenne ich mich mit
#mySQL / #MariaDB aus. Da würde ich eine VM in #Proxmox damit machen und dann mit dem ensprechenden #Addon von HA anflanschen.

Eine komplette (Debian o.ä.)-VM für die Datenbank halte ich für übertrieben. Also
#LXC, oder was spricht dagegen (außer, dass ich LXC noch nie genutzt und deshalb damit keine Erfahrung habe)?

Wichtig wäre mir, wenn ich dieSQLite-DB schon in eine echte DB auslagere, dass ich mit
#phpMyAdmin darauf zugreifen kann. phpMyAdmin lief bisher bei mir immer auf demselben Server wie die DB. Ist das bei LXC easy?

#linux #archlinux #reborneos #pregunta #vfat #exFat

Hoy me ha sucedido algo muy extraño. Al conectar un stick USB y tratar de montarlo, me ha aparecido el mensaje de error 'filesystem type vfat not configured in kernel'

Pero...

$ pacman -Q -i exfatprogs Version : 1.2.7-1

Me pregunto ¿donde esta el problema?

disk partitions are a social construct. true anarchists rawdog their drives. "gptfdisk" this "mkfs.vfat -F32" that, the ONLY WAY TO LIBERATE THE WORKING CLASS is to PUT your REISERFS DIRECTLY ON-DISK

none of that "lvm" bullshit either. you ever hear a true #proletarian go "oo I'd love to put #lvm on my #disk so I can #resize my #ext4 #vfat #partitions? NO. you don't NEED to resize your partition if you don't have any in the first place!

luks is on thin ice.

I wonder why vfat in kconfig does not select these options:

  • CONFIG_NLS_CODEPAGE_437
  • CONFIG_NLS_ISO8859_1

Noticed this while putting together #systemd image. You really cannot use FAT meaningfully without 437, so there should be IMHO either depends or select relation between these and FAT kconfig options.

In my opinion selecting VFAT in 2024 from kconfig should lead to selecting all the options that are required for filenames at minimum because it has exactly two use cases:

  • USB sticks
  • ESP
  • In both cases proper interpretation of filenames is required.

    PS. I also wonder why systemd does not list them as its required CONFIG_*. They are not obvious kconfig options in the context of kernel QA ;-) I always begin with tinyconfig and add up from there when doing this. Using ESP is required by practical means with systemd-boot so all three options should exist in this file: https://github.com/systemd/systemd/blob/main/README. I used it as a reference and failed.

    #linux #kernel #vfat #codepage #437

    systemd/README at main · systemd/systemd

    The systemd System and Service Manager . Contribute to systemd/systemd development by creating an account on GitHub.

    GitHub
    After checking details, it seems that using #gpt and #vfat is the simplest way. Direct #boot from #Btrfs doesn't seem to be at least easily possible.

    I just wrote about some work done a long time ago, but never found the time before to finish the post.

    This is the support added to the Linux vfat filesystem to atomically exchange files.

    https://blog.dowhile0.org/2024/02/10/atomically-exchange-vfat-files-in-linux/

    #linux #kernel #filesystems #vfat

    Atomically exchange vfat files in Linux

    The Linux kernel implements the POSIX renameat() system call that atomically renames a file, moving it between directories if required. If the newpath already exists, it is atomically replaced by t…

    Blog | Javier Martinez Canillas
    Anyone know why a #VFAT / #FAT volume would have its #FileSystem Information Sector for the #FileAllocationTable in the middle of the partition instead of at offset 0x0200? My largely-broken #EFI system partition has that and I'm trying (naively) to fix it...

    @londubh What perms were you trying to set?

    AFAIR vfat doesn't permit setting any file permissions via standard methods (e.g., chmod). It also doesn't have the notion of file ownership (user and group associations). Both are defined for the filesystem.

    Instead you define both of these at mount time through mount arguments. These include uid, gid, umask, and dmask. The mask values apply to regular files and directories respectively.

    https://linux.die.net/man/8/mount Search for "Mount options for fat" and "Mount options for vfat".

    #linux #vfat #filesystems

    mount(8): mount filesystem - Linux man page

    mount -a [-t type] [-O optlist] (usually given in a bootscript) causes all filesystems mentioned in fstab (of the proper type and/or having or not having ...