Btrfs as root filesystem?

[rick]

 

Hello.

 

I want to use btrfs as my rootfs (Armbian Ubuntu xenial 5.14 on M2) so I can use snapshots to roll back, freeze for backups, and to help manage changes. Btrfs is also good for error checking and can provide cheap easy data redundancy.

 

How does booting work on my BPI M2? How can I change the target root partition? What has to be on /boot (ext4) and what can be on / (btrfs)?

 

Along the same lines, is it possible to boot off of a USB device either directly or indirectly (Small SD with bootloader and /boot→ USB large root device)?

 

Is there some documentation or good keywords to learn about how booting works in the ARM world?

[tkaiser]

You would need to use our build system and use the $ROOTFS_TYPE option: http://docs.armbian.com/Developer-Guide_Build-Options/#hidden-options-for-advanced-users-default-values-are-marked-bold

 

IIRC u-boot can still not deal with btrfs so you would need a separate ext4 /boot partition (adding a line BOOTSIZE=64 to lib/config/sources/sun6i.conf should be sufficient)

[zador.blood.stained]

... or clone existing SD to another one with rsync. In any case you need to use separate ext4 boot partition and adjust boot.cmd and /etc/fstab

[arox]

... or clone existing SD to another one with rsync. In any case you need to use separate ext4 boot partition and adjust boot.cmd and /etc/fstab

I am not sure it is so simple or I would guess you had add it in nand-sata-install. But it is anyway an interesting configuration concept. So I will try that when I received the new cards I ordered (chip, nanopi neo and air). Hope I will have much luck than with bpim2+, as I am looking for "clonable" solutions in order to ensure hardware redundancy. And ro fs is also part of stability strategy when dealing with IoT.

 

BTW, what kernel should I choose for IoT, legacy or vanilla ?

[rick]

It worked. It took some trial and error because I was missing something btrfs related, but here is a cleaned up version of my steps:


# If the kernel has btrfs as external module (turns out I did not need this step):
  #Insert a line to /etc/initramfs-tools/modules containing:  "btrfs"

  #make new uInitrd with btrfs module:
  mkinitramfs -c gzip -o ./initrd `uname -r`
  mkimage -C none -A arm -O linux -T ramdisk  -a 0 -e 0 -n initramfs -d ./initrd uInitrd
  rm -f ./initrd

# now insert SD into another device like a PC

# create a new btrfs partition for root

#create subvolume for root
  btrfs sub create @

#move everything in "/"  to @ except for /boot which remains ext4

# mkdir /boot on the NEW btrfs  root filesystem

# move everything from originalext4fs/boot on the OLD ext4 filesystem up one level to originalext4fs/

# from the root of the OLD ext4 ( originalext4fs/ )
  ln -s . boot

# use "btrfs filesystem show" or whatever to find the new uuid

# edit/update /boot/boot.cmd

  #change root=??? to root=UUID=YourNewBtrfsUUID

  #change to rootfstype=btrfs

  #add rootflags=subvol=@

# generate new boot.scr:
  apt-get install u-boot-tools  # if not installed already
  mkimage -C none -A arm -T script -d ./boot.cmd ./boot.scr

# edit fstab to look something like this:

  #old ext4 now /boot:
  /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
  #new btrfs root :
  UUID=newuuid-for-btrfs / btrfs subvol=@,defaults,noatime,nodiratime 0 1
  # no change:
  tmpfs /tmp tmpfs defaults,nosuid 0 0
  /var/swap none swap sw 0 0


#reboot and see if you can do the happy dance like me!
 

[tkaiser]

One minor remark: Based on some testing it seems like a great idea to use "-o compress=zlib" when transferring the files to the freshly created btrfs filesystem. Saves a lot of space and should even slightly improve filesystem performance on dual core or better equipped boards. Some details: https://github.com/igorpecovnik/lib/commit/b14da27a4181e8e232bd8f526e71d2a931a8252f

[rick]

<snip> use "-o compress=zlib"

 

Yes!! compression has worked very well for me on usb flash boot devices (on pc).

 

A couple of hints for those new to btrfs:

 

If you mount by UUID (as above) you can migrate your root partition to usb and simply have /boot on a tiny SD for booting the kernel.  When I take snapshots of / I also copy /boot into the empty folder on the snapshot so that each snapshot is a complete OS along with its /boot. Snapshots are linked subvolumes and are writable unless you specify otherwise.

 

 

DO NOT RUN fsck (you don't need to) before you read this, and even then :

https://btrfs.wiki.kernel.org/index.php/Btrfsck. Adjust your fstab accordingly to not autocheck.

 

 

For some boards, we still use older kernels. From https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_defragment_many_files.3F :

 

Caveat: since Linux 3.14-rc2, 3.13.4, 3.12.12 and 3.10.31 (which removed the snapshot-aware defragmentation) defragmenting a file which has a COW copy (either a snapshot copy or one made with cp --reflink or bcp) would produce two unrelated files. If you defragment a subvolume that had a snapshot, you would roughly double the disk usage, as the snapshot files would no longer be COW images of the originals.

One would get this rather unexpected outcome when using defragment (together with "-c") to compress files with the hope of saving space.

Note that this is the same behaviour as observed with any pre 3.9 kernel (which added snapshot-aware defragmentation).

 

Since defragment with "-c" is how you compress files that have already been saved uncompressed. It seems important to note.

 

 

 

Some older kernels/btrfs progs/tools will choke on btrfs partitions that have been mounted or touched by newer tools/kernel. According to https://wiki.debian.org/Btrfs:

 

In my personal and professional opinion, btrfs before linux-4.4 and btrfs-progs-v4.4 is simply not worth the risk, and that this is the point where one could stop worrying "is my btrfs volume going to mysteriously blow up tomorrow, even with a simple use-case"; please use a kernel and progs >=4.4 to avoid needless maintenance headaches and needless risk.<snip> --NicholasDSteeves

[tkaiser]

If you mount by UUID (as above) you can migrate your root partition to usb and simply have /boot on a tiny SD for booting the kernel.

 

O yes, did that yesterday with Pine64 and kernel 4.9 and moved the rootfs to a connected UAS capable SSD: https://github.com/igorpecovnik/lib/commit/61f5dc4b4144f4a82c9b87b0eb9ea19971c6d025#commitcomment-19945561 (amazingly fast!)

 

And I absolutely second the recommendation to not play around with btrfs with kernel 4.3 or below

[Peter Lindener]

I just finished building BtrFS_Armbian_5.32_Nanopineo2_Ubuntu_xenial_dev_4.11.10.img for an 8GigByte SD card..

once I got the resulting image to actually fit on the card with a config-default.conf file containing:

    ROOTFS_TYPE=btrfs

    FIXED_IMAGE_SIZE=7200

It seems this fixed image size specification is for just the BtrFS partition size and does not include thee Ext4 boot partition that is also included in the SD card image..   after 4 attempt at building a Xenial system with a BtrFS root volume finally fits within the SD card.. 

->df -h -T    yields:
/dev/mmcblk0p1 ext4      58M   25M   32M  44% /boot

/dev/mmcblk0p2 btrfs     7.0G  500M   5.9G   8% /

 

   Changes to /etc/network/interfaces seem remain following a reboot...    

the good news is that ARMbian's support for BtrFS root file systems, with U-boot support via a small Ext4 boot partition seems to be working..

    Ya! way to go!...

That said... since not everyone ends up using the same size SD card, and burning full card size flash images being a fairly slow process..  I know I'm longing for another ARMbain team miracle here.. but it would be great if we figured out how to do dynamic BtrFS partition expansion, similar to how nice the ARMbian team has already done with Ext4 first boot SD card partition expansion.. 

see: Resizing a Btrfs File System..

    https://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case2_btrfs.html

    Then I'm Already a very happy camper...   Thanks for the great Linux build system!...   the ARMbain team made my day!

 

      -Peter

  

 

 

 

[tkaiser]

4 hours ago, Peter Lindener said:

but it would be great if we figured out how to do dynamic BtrFS partition expansion, similar to how nice the ARMbian team has already done with Ext4 first boot SD card partition expansion.. 

 

Please follow discussion/progress here: https://github.com/armbian/build/issues/650

 

4 hours ago, Peter Lindener said:

Thanks for the great Linux build system!...   the ARMbain team made my day!

 

You're welcome! But you might already know what's coming now?  

 

Armbian's core team is really small and we do all of this in our spare time. So help is needed, that's the 'if anybody has the time to play around with btrfs resizing and calculating $imagesize and $sdsize in debootstrap-ng.sh' part I mentioned above. Looking forward to some insights from you

[Peter Lindener]

T-Kaiser -

While computing  $imagesize and $sdsize will eventually become an issue.. 

Do we have a way to expand the underlying partition of an SD card built with a BtrFS root file system

while it is mounted as / (root)..at this point ?.   

 that is it seems: btrfs filesystem resize max     only works after expanding the underlying partition containing the BtrFS root file system

Can this partition resize be accomplished while mounted ?.. or does this problem also need solving before we can dream about expanding BtrFS root file systems on first boot..?    

 

[tkaiser]

The rootfs resize mechanism can be studied in nand-sata-install. Currently we allow only resizing ext4, if someone wants the same for btrfs there's some work to do (testing, testing, testing). I'm sorry but the whole thing can be rather time consuming and that's also the reason why at least I won't look into it yet. Since I've no need for it and don't want to waste too much time any more on Armbian features I don't need.

 

Anyway: If you come up with a solution or at least test results please post them here. BTW: stuff like this is somewhat typical for the type of work I contribute to Armbian regularly: testing a whole day and then commiting 2 changed line as direct result  

[Peter Lindener]

8 hours ago, tkaiser said:

The rootfs resize mechanism can be studied in nand-sata-install.

I read through nand-sata-install.... did not find, did you instead intend to reference:

armbian-lib/scripts/firstrun

see:  https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/resize2fs

line# 92:  # Start resizing... 

lines#101-106   fdisk ${DEVICE})

line# 108:   partprobe ${DEVICE} 
... 

line# 112: (for Ext4 file system resize) then calls: resize2fs

 

for a good explanation of what is going on here with the partition tables see:

https://raspberrypi.stackexchange.com/questions/499/how-can-i-resize-my-root-partition

 

to resize a BtrFS file system we would call:

btrfs filesystem resize [max, $RootFS_size]..  

see: https://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case2_btrfs.html

instead of calling resize2fs (for a Ext4 file system resize)

 

http://www.legendiary.at/2013/10/06/resize-btrfs-filesystem/

 

While making any adjustments to ARMbian's SD_card rootFS resize logic..

it may be good to see the day when uBoot knows how to read/boot directly from a BtrFS root file system..

see: https://github.com/falstaff84/u-boot/blob/master/fs/btrfs/btrfs.c

and: https://patchwork.ozlabs.org/patch/300593/

   I take it that this capability will at some point also land in the ARMbian OS builder ?

 

I don't mind doing my share of homework and testing..

..then it's always good to point others towards the file they might actually need to looking at.  

Please forgive me, I'm still learning how to do this..

 

   -Peter

 

[zador.blood.stained]

8 minutes ago, Peter Lindener said:

I read through nand-sata-install.... did not find, did you instead intend to reference:

armbian-lib/scripts/firstrun

see:  https://github.com/martinayotte/armbian-lib/blob/master/scripts/firstrun

This is an old fork, now discontinued since @martinayotte has push access to Armbian repositories 

 

Current resize logic lives here: https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/resize2fs

[Peter Lindener]

Zador-

 

    It seems, as I have been reading that Resizing the SD_Card's root file system happens in two stages:

1.resizing the underlying file partitions and then 2. resizing the file system (Ext4 or BtrFS) logic.

It's the first part, that seems tricky to do while the Root file system is still mounted... 

 

    Ahh..  as you point out,  I see that the SD_card partition resize logic has now also been folded into: 

https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/resize2fs

    has this code settled into its final resting place, of might the partition resize logic end up being re-factored to be a separate script called by the File system specific logic one level above?

 

   -Peter

 

[zador.blood.stained]

9 hours ago, Peter Lindener said:

It's the first part, that seems tricky to do while the Root file system is still mounted... 

Resizing the partition looks scary but it works.

Resizing the filesystem is safe - either kernel supports on-line resizing and it can be done, or you have to reboot to finish it (for kernels < 3.10).

 

9 hours ago, Peter Lindener said:

has this code settled into its final resting place, of might the partition resize logic end up being re-factored to be a separate script called by the File system specific logic one level above?

I don't expect any changes to this code or changing the file path anytime soon, so it should be safe to experiment with btrfs and f2fs resizing.

[martinayotte]

16 hours ago, zador.blood.stained said:

This is an old fork, now discontinued since @martinayotte has push access to Armbian repositories 

... now this one is deleted ...

[Peter Lindener]

Thanks for the assistance getting acquainted with ARMbian's first boot,  SD_card resizing logic.

see;  https://github.com/armbian/build/blob/54d71ef32ff0ce51bafeb26b2a7f864241316e55/packages/bsp/common/etc/init.d/resize2fs

 

    I'm still getting acquainted with the logic in this bash script..  

a pair of Question: on lines 112 and 127,  I find:

 resize2fs $rootpart >>${Log} 2>&1

     At first this looked like some kind of recursive invocation of this very same script.

But now after reading the code a second time...

It's clear there is a near miss on a same name collision between:

this bash script, located in the target at: 

 /etc/init.d/resize2fs

and the program this script calls, located in the target at: 

 /sbin/resize2fs

 

I realize that near miss program / script name collisions are an excellent way to confuse new-newcomers like your's truly.  In this case,  we would seem just a minor adjustment in the program search path away from the fun of an infinite first boot recursive script invocation.   

   Confusing newcomers aside,  as we are about to extend this logic to also work with BtrFS root file systems, maybe it would be good to rename this SD_card root file system expansion script, to have a more clarifying name, such as "expand_last_fileSys" or "Expand_root_fileSys" that would not create this kind of same name confusion, as well the potential bugs of a recursive script invocation during first boot?   

---------- also:   

   While I'm new to using best GIT practices to submit code changes.

I have cleaned up the section of this scripts code that provides for fdisk's control via stdin.

   see: attached test script... with workaround for bash printf \n truncation bug

(bash printf will often omit trailing \n's)..

 

   cheers

     -Peter

 

  

 

 

 

Test_FDisk_Cntl.sh

[tkaiser]

On 23.8.2017 at 2:26 AM, Peter Lindener said:

In this case,  we would seem just a minor adjustment in the program search path away from the fun of an infinite first boot recursive script invocation.

 

Well, if anyone wants to alter the source to add /etc/init.d to $PATH then nothing bad would happen since parameters are missing. Anyway: I agree that a less confusing name for the service would be desirable but have to admit that I'm not that much into how bsp packages are built. In case there's no trouble involved I vote for renaming script and service to resizepartitions.

 

Anyway: I gave it a try today and ended up here: https://github.com/armbian/build/commit/527acd30353e0c2c3ffc5a92815396b1667bc3ee

 

Seems to work on Jessie, Xenial and Stretch without a reboot (I immediately started a 'dd if=/dev/urandom of=rubbish bs=1M' after fs resize on Jessie without issues. FS was full after an hour with 28K left and after deletion of the file everything fine again).

 

Open questions:

• How to deal with swap (btrfs does not support swap files)?
• The partition size calculation is too naive for situations where experienced users use customize-image.sh to import few hundred GB of uncompressable data. A better approach would be to already use btrfs to create the tmpfs since then a 'btrfs filesystem df' could be used to calculate the size of an ext4 rootfs while we could use the compressed size 1:1 for creating partitions. On the other hand this use case is very special and experienced users could make use of a fixed image size in such situations
• How to deal with snapshots? Creating an initial 'release' snapshot seems like a good idea to me. Also installing 'apt-btrfs-snapshot' on Xenial by default is worth a consideration IMO 

[Igor]

35 minutes ago, tkaiser said:

How to deal with swap (btrfs does not support swap files)?

Create a separate partition? We do this when using nand-sata-install.

[zador.blood.stained]

33 minutes ago, tkaiser said:

• How to deal with swap (btrfs does not support swap files)?

Ignore for now? btrfs is not a default option currently and an experienced user should be able to create a swap partition or use zram.

 

35 minutes ago, tkaiser said:

• The partition size calculation is too naive for situations where experienced users use customize-image.sh to import few hundred GB of uncompressable data. A better approach would be to already use btrfs to create the tmpfs since then a 'btrfs filesystem df' could be used to calculate the size of an ext4 rootfs while we could use the compressed size 1:1 for creating partitions. On the other hand this use case is very special and experienced users could make use of a fixed image size in such situations

I'm pretty sure that tmpfs doesn't work that way - it's a file system on its own and you can't create another FS on top of it. And while ramdisks (/dev/ramX) may be an alternative, they have their own limitations.

[tkaiser]

30 minutes ago, Igor said:

Create a separate partition?

 

Hmm... I think exploring zram is the better idea as Zador suggested. At least I lack the patience dealing with a system that starts to swap on a SD card

 

30 minutes ago, zador.blood.stained said:

I'm pretty sure that tmpfs doesn't work that way

 

Understood. It's not that much of an issue anyway since a 'normal' rootfs with compress-force=zlib should never exceed 70% of the uncompressed size. So if we focus a bit more on btrfs this is stuff for documentation.

[tkaiser]

9 hours ago, zador.blood.stained said:

an experienced user should be able to create a swap partition or use zram

 

Well, I was thinking about switching with OMV to compressed btrfs (to get some experiences from real installations, other OMV maintainers are fine with this). After reading in Debian wiki that installations relying on systemd should make use of Ubuntu's zram-config package I simply gave it a try:

wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb
dpkg -i zram-config_0.5_all.deb
reboot

Before:

root@bananapi:~# free
             total       used       free     shared    buffers     cached
Mem:       1023600     362812     660788      34884       3512     262440
-/+ buffers/cache:      96860     926740
Swap:            0          0          0

After:

root@bananapi:~# free
             total       used       free     shared    buffers     cached
Mem:       1023600     291148     732452      32856       1100     199564
-/+ buffers/cache:      90484     933116
Swap:       511792          0     511792

Full armbianmonitor -u output: http://sprunge.us/GdDK

 

Any idea about testing performance/reliability?

[Peter Lindener]

Tkaiser and Zador -

   Thanks for giving ARMbian's adjustment towards supporting the BtrFS some additional thought.

from my perspective resizing of SD_card partitions / File system images should not be automatic on first_boot,

but instead queried if should be done during first_login just after ARMbian's mandatory PassWd adjustment.

   I make this point, as a long delay during first boot, makes it hard for newbies to know what is going on, not to mention 

increasing any challenges associated with debugging the initial boot process.

 

   I'm not sure what how important it is for Linux to have a swapFile (in my case: NanoPi Neo2 has 512meg of RAM)..  

sure using ZRAM might help,.. then as Tkaiser points out swapping to/from the SD_card (the only mass storage on a Neo2)..

is not a very attractive solution..   since the SD_card resizing logic and this SD-card swap space allocation are both issues that are somewhat unique to systems that run with just the SD-card...   it might make sense to also ask (with defaults) how one would like to configure the SD-card/ ZRAM swap space options...

    Then these additional swap space parameters would be factored into the SD-card's partition adjustment / file system adjustment logic...

 

    Yes: taking an initial (post resize?) BtrFS snapshot sound like it would be a good thing!

 

   -Peter

     

[zador.blood.stained]

9 hours ago, Peter Lindener said:

from my perspective resizing of SD_card partitions / File system images should not be automatic on first_boot,

but instead queried if should be done during first_login just after ARMbian's mandatory PassWd adjustment.

And from a perspective of an average inexperienced user it's better to use automatic FS resize. For experienced users there are different customization options during the build process, and for some people it may be even easier to plug the SD card into another system and use gparted to resize the root partition or create additional partitions (including swap)

 

9 hours ago, Peter Lindener said:

I make this point, as a long delay during first boot, makes it hard for newbies to know what is going on, not to mention 

increasing any challenges associated with debugging the initial boot process.

When I'm testing images on fast SD cards (like Samsung Evo+ 16GB) I don't notice any delays, only very old and much slower cards cause a delay during FS resizing.

[tkaiser]

10 hours ago, Peter Lindener said:

as a long delay during first boot, makes it hard for newbies to know what is going on

 

Huh? A 'btrfs filesystem resize' happens almost instantly and resizing is the desired behaviour for average users anyway. You can adjust this behaviour at build time or prior to first boot: https://docs.armbian.com/Developer-Guide_User-Configurations/#partitioning-of-the-sd-card

 

Wrt zram it's as easy as this followed by a reboot (given the kernel is configured correctly and recent enough). What's missing are experiences and I fear I'm not able to get any since I can't remember ever having seen more than 0 bytes swap used on any board (seems like a matter of use case).

[Peter Lindener]

from your replies:

     I gather the first boot Ext4 resize delay (still an issue) others have mentioned (likely for a larger, 64Gig SD-card),

apparently are not much on an an issue when resizing a BtrFS file system.

    While at some point most users will in some way connect to the internet, the whole point of providing most of the ARMbian OS as an SD_card image might be able to come up running without the need for an additional downloads of:

wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb 

yes, "it's easy" if your ARMbian target on line..  but it may not be during first boot? 

    New ARMbian users (those who have not yet created a customized first boot script) would likely prefer to be asked (with defaults) how the ARMbian SD_card image should be handled.. this includes the possible size of a Linux swap partition near the end,  as well as the nature RootFS partition / FS resize operation.  That is: I think, blind first boot SD_card state change should be avoided.   On target boards that provide additional NV store beyond the SD_card, this first boot user interaction would likely be a good opportunity to prompt for an image install in addition to any options for a possible SD_card resizing operation.     

   Since one is already insisting that users set the root passWord..  it would be nice if new ARMbian users can easily understand that ARMbian SD_card image is being modified... and yes it's great that more advanced users can customize most all of this, then lets keep in mind that it's newcomers who will help grow the ARMbian community yet further.  

[zador.blood.stained]

38 minutes ago, Peter Lindener said:

aI gather the first boot Ext4 resize delay (still an issue) others have mentioned (likely for a larger, 64Gig SD-card),

apparently are not much on an an issue when resizing a BtrFS file system.

I still wouldn't call it an issue. Documentation says that first boot may take up to few minutes due to FS resizing, and I can't imagine what SD card would resize for longer than 1 minute in reality.

 

38 minutes ago, Peter Lindener said:

While at some point most users will in some way connect to the internet, the whole point of providing most of the ARMbian OS as an SD_card image might be able to come up running without the need for an additional downloads of:

wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb 

yes, "it's easy" if your ARMbian target on line..  but it may not be during first boot? 

But who says that swap is required at all? Armbian or any Linux OS won't magically break without swap unless Android-optimized legacy kernels have LMK related bugs.

 

38 minutes ago, Peter Lindener said:

New ARMbian users (those who have not yet created a customized first boot script) would likely prefer to be asked (with defaults) how the ARMbian SD_card image should be handled.. this includes the possible size of a Linux swap partition near the end,  as well as the nature RootFS partition / FS resize operation.

...

On target boards that provide additional NV store beyond the SD_card, this first boot user interaction would likely be a good opportunity to prompt for an image install in addition to any options for a possible SD_card resizing operation.     

It's a matter of opinion, and, for example, in my opinion first boot has too much interactivity already.

 

Also please keep in mind that default Armbian images are provided with ext4 root only so you don't need a swap partition at all - you can use a swap file instead, and changing the size of a swap file is very easy compared to moving/resizing partitions and filesystems. If you want btrfs root you need to build an image first so you may as well disable auto FS resize in this case.

 

Edit: In addition this extra interactivity probably would be relatively complicated - we would probably want to make it very obvious for beginners, so you would have to accept size and percentage inputs, provide reasonable defaults and recommendations based on SD size and amount of RAM, ...

[Peter Lindener]

Yes, I get it that when using an Ext4 file system, one can just use a "swap file",  such is not the case with BtrFS. of course there is this patch:

https://lkml.org/lkml/2014/12/9/718

while I'm not keen on the idea of swap space mounted on the one and only SD-card in a system... one does have to admit, that if one is to create a swap partition on the SD-card, it would be best to place it near the end... BEFORE growing the Root File system..    as you Zador points out, the need for swap space is application specific..    

   The resize2fs script,  code seems to already implement some of the "accept size and percentage input" functionality Zador mentions.  but takes it's input from file system customization vars, rather than defaulting to prompt for user input, if they do not exist.

 

   I'm posting this messages as I'm interested in using the BtrFS instead of Ext4.  Zador has already suggested adjusting the nightly build to default build to use BtrFS..   I find fixed, a full size SD-card image size build to be prohibitively big to handle for even a 8 giaByte SD_card.    If the BtrFS advantages of snapshot / rollback is to become part of the ARMbian ecosystem. it would seem we will be needing to adapt to ARMbian BtrFS SD-card image deployment. 

   

   I agree that building up a user friendly first boot dialog (that could be avoided by way of system customization vars) if well designed and effectively implemented, would take a amount bit of effort. That said: It kind of goes without saying that this interaction is the first experience new uses will have with ARMbian.  

 

   In summary:    It would be great if the requirement for any first boot user interaction could be completely mitigated by way of a custom_install_config file that could be placed in either the current Ext4 based boot partition or the BtrFS rootFS ( not all operating systems may be able to access the BtrFS root FS tree )    If EFI boot is in ARMbian's future the boot partition may eventually want to be FAT?..     The level of interaction provided for custom Kernel configuration during the ARMbian build process. illustrates how nice things can be with regard to ARMbian's ease of use.   I'm just asking that newcomer's might also enjoy the same kind of user friendly interaction during there first boot experience...    I'll help test, and provide quality new user feedback.    I am quite in awe of the build system you folks have constructed.   

    I realize ARMbian developer's often find ther need to carefully choose there priority's.

I'm currently doing my best learning how to use Git, let me know how best I can help.

    -Peter

[Tido]

16 hours ago, Peter Lindener said:

building up a user friendly first boot dialog

I fully agree with you. It can suggest a size and in brackets (recommended) but the user can still change the value.

I raised that topic a while ago - even if related to a bug at that time.

 

@zador.blood.stained "in my opinion first boot has too much interactivity already."

I disagree - either you want a SBC and security or you buy a RPi. 

-> You will horribly fail, if you try to make everybody happy (translated from german).