No announcement yet.

Debian Enabling Support For Booting From Root F2FS File-Systems

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by flux242 View Post
    there's never pottering when you need one to unify all these darn file systems into ultimate one badass file system!
    I hear that Poettering created his own hardware, just so he could have a single unified platform to call his own.

    It's called ... wait for it ... 'systemd-hardware'.

    When asked about if or when Poettering might show off his latest creation it is reported that his response was:




    • #12
      Clear Linux is looking to enable f21fs as root installation as well
      Last edited by insilications; 12 January 2020, 08:32 PM.


      • #13
        That is great for running debian and derivates from SD over all this SOCs available on the market!


        • #14
          Originally posted by Julien Bear View Post
          So will we see Raspberry/Raspbian support for f2fs soon? The SD-cards would appriciate it.
          Raspbian supports F2FS right out of the box (just format the 2nd partition as F2FS and use rsync to copy the files, instead of dd ing the EXT4 image as is. And change the 'rootfstype=' parameter passed to the kernel in cmdline.txt).
          I've been using this on most of the raspberry pis I use for this exact reason.

          It has the F2FS drivers already compiler in, so it just works as-is.

          (As opposed to other CoW and Log structured filesystem. BTRFS isn't compiled in, so if you count on that, you'd need some contrived method such as adding an initramfs (RPi don't normally use one) or recompiling your own kernel. Or simply restrict your BTRFS use to other sub-tree that, only after /lib/modules has been made accessible - e.g.: for /home, /srv, etc.).

          Originally posted by Danielsan View Post
          That is great for running debian and derivates from SD over all this SOCs available on the market!
          In fact many other SBCs and embed SOCs ship with kernel that have F2FS already embed too (among other: Pinebook Pro).
          (Though depending on the boot sequence of your peculiar board, changing a hardcoded fs type parameter might be a little bit less trivial than editing a text file).


          • #15
            Originally posted by DrYak View Post
            (Though depending on the boot sequence of your peculiar board, changing a hardcoded fs type parameter might be a little bit less trivial than editing a text file).
            Exactly now should work ootb...


            • #16
              Originally posted by Danielsan View Post
              Exactly now should work ootb...
              - Raspberry Pi up to 3+ included actually first boot an entirely different realtime OS inside the VideoCore IV GPU, and this OS is in charge of bringing up the "parasite" ARM core and boot linux on it. Reading a text file is trivial for that OS, and that's how parameters are fetched and passed to the kernel. So simple trivial text file edit.
              - Raspberry Pi starting from 4 has changed things a bit. The VideoCore VI GPU isn't in charge of everythingy anymore, a small SPI hold the boot code that is used for the main ARM core to bootstrap itself. That boot code is able to fetch a text file for the parameters. So simple trivial text edit again.
              - A lot of the Rockchip RK3399 (including the PineBoot Pro) use u-boot. u-boot can straight chainload an "all-included" Linux bootimage, but can also use a text file with parameters, etc. So simple trivial text edit.
              - A lot of android phone load an all included boot image (kernel + initramfs + hardcoded parameters). You need to rebuild (or hexedit) the boot image to ask it to load a F2FS partition.

              Notice: all of the above are special cases that use custom kernels for the board (well, a more or less generic-ish kernel + a device tree table), all of those which I have seen already have F2FS compiled in because it's overly popular in embed system. (and some like Jolla's even have BTRFS compiled in) The kernel is able to ready F2FS already, you just need to tell it to do so. Nearly all boot procedures rely on forced parameters instead of FS autodetection, so you need to change the parameters as stated above.

              And now the TFA :
              *this* is for "normal" systems. I.e.: things like desktop and servers. Those already have a "kind-of-OS" running before boot (UEFI). This one might even load another "kind-of-OS" in turn (GRUB). And then on of these will subsequently a pretty minimalistic kernel that contains close to nothing and an initramfs that contains everything the system might to boot (including complex partition management system like LVM or even a huge monster like OpenZFS if that is your kink).

              Debian has now added the necessary hooks so that if your root is F2FS, the F2FS.ko module gets packaged into the above-mentioned initramfs. Because, unlike SBC and embed that tend to run sort-of custom kernels, desktops and servers tend to usually run pretty generic kernels. Thus F2FS isn't compiled into the kernel (unlike on SBC), but needs instead to be included in the initramfs (like most other exotic filesystems on desktop and servers).

              That is the thing that is enabled by Debian, and that is what is news. Not running your SBC's SD card on F2FS - that has been available for ages - but running your server's SSD on F2FS -because somehow until now Debian wouldn't have been able to automatically detect and include F2FS when generating the initramfs.

              Note: Raspberry Pis are a bit of an exception - since RPi3 and more recent, their bootcode *is* also able to load UEFI payloads. So you *could* also boot into vanilla Debian UEFI kernels, and in that case - if you're using vanilla Debian instead of Raspbian - you'd be benefiting from these adds.