Size optimization improvements

[SuperMaxusa]

Hi, I found a few improvements for kernel size, currently it shaves about 96k.

// left: bzImage size, right: vmlinux size

	- Generic setup
		- Configure standard kernel features (expert users)
			- untick Enable support for printk (-49k, -552k [4])
		- Support initial ramdisk/ramfs compressed using LZMA (-4k, -9k [6])
	- Processor type and features
		- Supported processor vendors
			- untick Hygon, Centaur, Transmeta, UMC, Zhaoxin, Vortex processors (-4k, -14k [7])
	- Device Drivers
		- Input device support
			- Generic input layer
				- untick Mice (-20k, -60k [1])
		- Character devices
			- untick Unix98 and Legacy (BSD) PTY support (-4k, -10k [2])
	- Memory Management options
		- untick Support for paging of anonymous memory (-12k, -30k [3])
	- Enable the block layer
		- Partition Types
			- untick EFI GUID Partition support (-4k, -9k [6])
		- IO Schedulers
			- untick Kyber I/O scheduler (-4k, -1k [5])
	- Library routines
		- untick XZ decompression support (-4k, -9k [6])

Notes:

After step 6, compress your initramfs to LZMA:

find . | cpio -H newc -o | xz --format=lzma --check=crc32 --lzma1=dict=512KiB -e > ../rootfs.cpio.lzma

...and change syslinux.cfg:

INITRD rootfs.cpio.lzma

If you test on real hardware, be careful with step 7, test any changes here with Enable support for printk (see step 4).

---

Step	bzImage	vmlinux
0 (original)	885248	3146912
1	864768	3086424
2	860672	3076152
3	848384	3045692
4	799232	2492808
5	795136	2491676
6	791040	2482396
7	786944	2468308

GCC version: gcc (Debian 14.2.0-19) 14.2.0
Linux config: linux-config7.txt

Thanks @mikebdp2 for the tips, see floppinux-amd64net.

[mikebdp2]

@w84death and @SuperMaxusa : Dear friends, you may look at my new "AMD64NET" fork (some documentation is still WIP but I wanted to share ASAP to save your time) for more size optimization ideas. In short, I did a lot of hardcore optimizations and now have a 2.88MB floppy with a working Ethernet & WiFi (only for some selected adapters though) with Dropbear SSH/SCP, wpa_supplicant, wpa_cli and kirc (standalone wget download) - https://github.com/mikebdp2/floppinux-amd64net/blob/main/floppinux.md

[SuperMaxusa]

@mikebdp2 Awesome work! I will take note of that, thanks.

[mikebdp2]

@SuperMaxusa and @w84death , here is a summary of my main optimization approaches:
1) -Oz flag if your compiler supports. Unfortunately this flag has been introduced only in GCC 12.1, while our musl.cc's GCC is just 11.2.1 (didn't find a suitable replacement yet - i.e. dyne's newer GCC musl is giving worse size results), however this approach works for building a Linux kernel - since we are doing that with our host OS compiler and it is guaranteed to be newer:

git clone --depth=1 --branch v6.18.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd ./linux/
mv ./.git/ ./../temp.git/ # Temporarily move ./.git/ to avoid damaging its contents in the process
find . -type f -print0 | xargs -0 sed -i -e "s/-O1/-Oz/g"
find . -type f -print0 | xargs -0 sed -i -e "s/-O2/-Oz/g"
find . -type f -print0 | xargs -0 sed -i -e "s/-O3/-Oz/g"
find . -type f -print0 | xargs -0 sed -i -e "s/-Os/-Oz/g"
mv ./../temp.git/ ./.git/

While using GCC 14.2.1 (bad experience with 15 for an unrelated project) and a custom config from a fork above, my bzImage byte sizes are 2249728 with -Oz vs 2270208, so a 20480 bytes win - yes, just 1%, but still big considering the kernel size

2) Strong CFLAGS/LDFLAGS optimization flags for Busybox and others (except it didn't work for Linux kernel). I.e. for Busybox (comment updated to reflect the findings below, dropped -no-flt and please note that -fno-pie gives variable results) :
CONFIG_EXTRA_CFLAGS="-I/home/artix/my-floppy-distro/x86_64-linux-musl-cross/include -static -Os -s -ffunction-sections -fdata-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-stack-protector -fomit-frame-pointer -fmerge-all-constants -fno-ident -fno-math-errno -fno-unroll-loops -ffast-math -fvisibility=hidden -fno-exceptions -march=x86-64 -mtune=generic -fno-align-functions -fno-align-jumps -fno-align-loops -fno-align-labels -fno-pie"
CONFIG_EXTRA_LDFLAGS="-L/home/artix/my-floppy-distro/x86_64-linux-musl-cross/lib -static -s -Wl,--gc-sections -Wl,--strip-all -Wl,--build-id=none -Wl,-z,norelro -Wl,--hash-style=sysv -Wl,--no-eh-frame-hdr -Wl,-z,noseparate-code -Wl,--no-undefined-version -Wl,--as-needed -Wl,--sort-common -Wl,--sort-section=alignment -Wl,--compress-debug-sections=none -Wl,--warn-common -Wl,--fatal-warnings -Wl,--discard-all -Wl,--discard-locals -Wl,--no-ld-generated-unwind-info -Wl,--orphan-handling=place -no-pie"
Please let me know if you have any idea for even more "hardcore" CFLAGS/LDFLAGS that still produce the good builds

Program	Normal build sizes, bytes	Optimized build sizes, bytes	Bytes saved	Relative win
Busybox	334312	325136	9176	3%
Dropbear - dbclient (SSH)	275992	225968	50024	18%
Dropbear - scp client	78168	71952	6216	8%
libnl-tiny (for WPA supplicant)	66806	54894	11912	18%
WPA supplicant - daemon	2665736	426248	2239488	84%
WPA supplicant - wpa_cli	336504	86688	249816	74%
KIRC	241560	94680	146880	61%

3) "normal" strip, and sstrip utility from elfkickers package - https://archlinux.org/packages/extra/x86_64/elfkickers/

strip helps to remove the non-essential sections of the executables, and sstrip helps to strip even better:

Program	Optimized build sizes before sstrip, bytes	Optimized build sizes after strip, bytes	Bytes saved	Relative win
Busybox	325136	324047	1089	0.3%
Dropbear - dbclient (SSH)	225968	224920	1048	0.5%
Dropbear - scp client	71952	70904	1048	1.5%
WPA supplicant - daemon	426248	425376	872	0.2%
WPA supplicant - wpa_cli	86688	85816	872	1%
KIRC	94680	93628	1052	1.1%

4) Stronger compression for rootfs filesystem. According to my experience, while XZ gives a better compression for a Linux kernel, actually it's better to use LZMA for rootfs filesystem because the archive's filesize is nearly the same while the decompression routine in a Linux kernel is larger for LZMA rootfs, so XZ kernel + LZMA rootfs combination is smaller in size than XZ kernel + XZ rootfs. Also, make sure to use very detailed compression parameters. Lets compare three methods:

A) find . | cpio -H newc -o | xz --check=crc32 --lzma2=dict=512KiB -e > ../rootfs.cpio.xz
B) find . | cpio -H newc -o | xz --check=crc32 --format=lzma --lzma1=dict=512KiB -e > ../rootfs.cpio.lzma
C) find . -print0 | LC_ALL="C" sort -z | cpio -0 -H newc -o --reproducible 2>/dev/null > ./../rootfs.cpio && strip-nondeterminism -t cpio -T 1770768000 ./../rootfs.cpio && xz --threads=1 --format=lzma --check=crc32 --lzma1=dict=64MiB,lc=3,lp=0,pb=2,mode=normal,nice=273,mf=bt4,depth=0 < ./../rootfs.cpio > ./../rootfs.cpio.lzma
(for "C" I also do "strip-nondeterminism" to avoid the +-~100 byte size fluctuations between the experiments, caused by variable inodes/timestamps; by the way, if your build barely fits and every byte counts - remove this "strip-nondeterminism" part, make a script that does cp -r ./busybox/_install/ ./filesystem && cd ./filesystem && "populate and archive it" and re-roll it a few times until you get a "lucky" archive size, may even write a script to brute-force it)

Compression method	Compressed filesystem archive, bytes	Bytes saved	Relative win
A)	503512	0	0%
B)	503385	127	0.03%
C)	501939	1573	0.3%

5) If you produce a floppy with a working network like what I'm doing - instead of storing some binary files directly on a floppy, you could upload them to some online "repository" and wget them with a simple minimalistic script each time, like I am doing with KIRC :

cat >> ./etc/get_kirc.sh << EOF
wget https://raw.githubusercontent.com/mikebdp2/floppinux-amd64net/refs/heads/main/kirc
wget https://raw.githubusercontent.com/mikebdp2/floppinux-amd64net/refs/heads/main/kirc.txt
chmod +x ./kirc
EOF

Obviously, this is much smaller than storing KIRC on a floppy directly, and anyway it is almost useless without an Internet connection. You could even build a huge repository of various software and wget them all, so that your "thin client" of a live floppy will be much more functional

[SuperMaxusa]

Please let me know if you have any idea for even more "hardcore" CFLAGS/LDFLAGS that still produce the good builds

Have you tried -fno-pic in CFLAGS? For me, it takes -12k on Busybox binary (i486):

	busybox	+ sstrip	busybox_unstripped
original (config)	263820	262711	334824
extra CFLAGS/LDFLAGS (config)	261676	260947	261752
CFLAGS+="-fno-pic" (config)	251372	250643	251448
CFLAGS-="-fno-plt" (config)	248940	248211	249016

Inside the packed rootfs.cpio.xz (I will try later with LZMA), it's still negligible (less than -1k).

I would also to suggest trying other libcs (i.e. uclibc-ng or dietlibc) if they can build your programs.
Unfortunately I haven't tested it myself because I couldn't find toolchains for i486.

[mikebdp2]

@SuperMaxusa Thank you for your tip and encouragement to play more with these flags! Here are the new findings:

1) Sorry I made a mistake, -fno-plt is actually bloating the builds, so please drop -fno-plt from CFLAGS everywhere!

2) -fno-pic effect in general is positive/neutral but really depends on the software, so we need to be careful with it:

• libnl-tiny, wpa_cli, busybox, dropbear (luckily both dbclient/ssh and scp) - either size DECREASES or no changes
• kirc and wpa_supplicant (despite that it is using libnl-tiny and slightly benefiting from its shrink) - size INCREASES

Therefore now I am building wpa_cli and wpa_supplicant separately, let's hope they will still play together nicely

Also: -fno-pie seems to have the same effect as -fno-pic, maybe slightly better when the size wants to increase (maybe a smaller size increase at some cases), so I've decided to use -fno-pie (where it helps) in the end

3) If we are using some static library like libnl-tiny and are linking against it, sadly sometimes the flags that could be decreasing a library's .a file size - at the same time could be increasing a size of a binary that uses this library. I saw a significant size decrease when I dropped -ffunction-sections -fdata-sections from libnl-tiny's flags, but wpa_supplicant/wpa_cli that use this library - ended up significantly more bloated

So these things are a bit confusing / counter-intuitive and there is a chance I may have overlooked something else (i.e. some flag in general may be neutral but sometimes gives a bloat). I will highly appreciate any extra tips! Here are the new results:

Program	Previous result	New result (-fno-plt dropped, -fno-pie sometimes added)	Bytes saved	Relative win
Busybox	324047	320751	3296	1.0%
Dropbear - dbclient (SSH)	224920	210552	14368	6.4%
Dropbear - scp client	70904	70072	832	1.2%
WPA supplicant - daemon	425376	420608	4768	1.1%
WPA supplicant - wpa_cli	85816	82168	3648	4.3%
KIRC	93628	93500	128	0.1%

At the moment, my Linux kernel is the same 2249728 bytes and rootfs.cpio.lzma with all the goodies is 490891, after put to a floppy (a minimal size consumption by a file is 1024 bytes, so i.e. the syslinux.cfg occupies almost 10x times more than it weights!) - I have somewhere between 11-12 KB available! This is a very awesome result, and if all the stuff still works OK - then I could put even more goodies to this wonderful virtual floppy

[mikebdp2]

@SuperMaxusa I am sure that using LZMA will help you to win slightly more: the archive size is nearly the same as XZ (you may even lose a couple of bytes), however your Linux kernel should shrink by like 5 KB.

I would also to suggest trying other libcs (i.e. uclibc-ng or dietlibc) if they can build your programs

Atm I am a bit concerned that the apps might not work properly with a lighter lib, i.e. was a bit unsure that wpa/wifi will work just with musl, and the smaller libs might be more obscure and risky; however, this is a nice idea to try out when we hit a limit again

Unfortunately I haven't tested it myself because I couldn't find toolchains for i486

In the worst case you'll have to build a toolchain by yourself, its a bit time consuming but definitely doable. I.e. you may check out the toolchain of coreboot opensource BIOS - it is i386, and maybe if build it on a musl-only OS it will be musl-compatible (need to explore this). One issue though: as you could see by http://dangerousprototypes.com/docs/Lenovo_G505S_hacking page, I am staying on gcc 8.3.0 because the newer gcc were giving me bad BIOS builds, but its not a good idea in our case since we definitely want to use the -Oz optimization, so I'd suggest grabbing the latest GCC from them, building for musl and hope that it works OK (like it does for many modern coreboot-supported hardware boards)

[SuperMaxusa]

Thanks for suggestion to remove -fto-plt, I saved about 2k in size.

Atm I am a bit concerned that the apps might not work properly with a lighter lib, i.e. was a bit unsure that wpa/wifi will work just with musl, and the smaller libs might be more obscure and risky;

As far I know, uclibc is used in Buildroot, so I hope this will work.

[mikebdp2]

@SuperMaxusa Thank you, I'll keep uclibc in mind. At the moment I'd like to research if there anything - aside of "-Oz upgrade" - could be done with a Linux kernel, since it's our fattest component and even 1% shrink is a huge gain. I've already tried playing with the flags (both C/LD and XZ ones at ./scripts/xz_wrap.sh) but they either gave me the same kernel size or were bloating it. Right now the built-in flags look like this (got them by inserting a printout into one of the daughter Makefiles) :
KBUILD_CFLAGS = -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -mno-sse4a -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -march=x86-64 -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Oz -fno-allow-store-data-races -fno-stack-protector -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -fmin-function-alignment=16 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check -fconserve-stack -fno-builtin-wcslen -Wall -Wextra -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wmissing-declarations -Wmissing-prototypes -Wframe-larger-than=2048 -Wno-main -Wno-dangling-pointer -Wvla-larger-than=1 -Wno-pointer-sign -Wcast-function-type -Wno-array-bounds -Wno-stringop-overflow -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wenum-conversion -Wunused -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-stringop-truncation -Wno-override-init -Wno-missing-field-initializers -Wno-type-limits -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -Wno-unused-parameter
KBUILD_LDFLAGS = -m elf_x86_64 -z noexecstack --no-warn-rwx-segments

[SuperMaxusa]

After your previous test, I also tried testing different kernel and initramfs compressions, and here are my results.

tl;dr XZ and LZMA compressed cpio with initramfs almost on same level, XZ better for kernel compression, the best combo is LZMA for initramfs and XZ for kernel

Zstd was skipped because it takes a lot of RAM to unpack.

Initramfs compression

To get accurate results, I used 512 kB dictionary size and maximum compression level, if possible.
Initramfs for testing contains Busybox with this config and some init scripts from the original tutorial.

Commands

# xz
find . | cpio -H newc -o | xz --check=crc32 --lzma2=dict=512KiB -e > ../flp/rootfs.cpio.xz

# lzma
find . | cpio -H newc -o | xz --format=lzma --check=crc32 --lzma1=dict=512KiB -e > ../flp/rootfs.cpio.lzma

# gzip
find . | cpio -H newc -o | gzip -9 > ../flp/rootfs.cpio.gz

# bzip2
find . | cpio -H newc -o | bzip2 -9 > ../flp/rootfs.cpio.bz

# lzo
find . | cpio -H newc -o | lzop -9 > ../flp/rootfs.cpio.lzo

# lz4
find . | cpio -H newc -o | lz4 -12 > ../flp/rootfs.cpio.lz4

Method	Size
Unpacked	254464
XZ	136296
Bzip2	144663
Gzip	149811
LZ4	170953
LZMA	136226
LZO	160705

Kernel compression + initramfs compression module

Kernel decompression uses a different module than for initramfs, so you can combine them.

Note: Initramfs compression module is General setup -> Support initial ramdisk/ramfs compresed <...>, which was selected only once in each test.

	Initramfs compression module	Kernel compression	bzImage size	Config
0	XZ	XZ	848384	config-0.txt
1	XZ	LZMA	885248	config-1.txt
2	XZ	LZO	1146242	config-2.txt
3	XZ	LZ4	1171968	config-3.txt
4	XZ	Gzip	1040896	config-4.txt
5	XZ	Bzip2	967168	config-5.txt
6	LZMA	XZ	844288	config-6.txt
7	LZMA	LZMA	885248	config-7.txt
8	Bzip2	XZ	844288	config-8.txt
9	Bzip2	LZMA	885248	config-9.txt
10	Gzip	XZ	848384	config-10.txt
11	Gzip	LZMA	885248	config-11.txt

Overall

	Initramfs compression	Kernel compression	bzImage size	Initramfs size	bzImage + initramfs size
0	XZ	XZ	848384	136296	984680
1	XZ	LZMA	885248	136296	1021544
2	XZ	LZO	1146242	136296	1282538
3	XZ	LZ4	1171968	136296	1308264
4	XZ	Gzip	1040896	136296	1177192
5	XZ	Bzip2	967168	136296	1103464
6	LZMA	XZ	844288	136226	980514
7	LZMA	LZMA	885248	136226	1021474
8	Bzip2	XZ	844288	144663	988951
9	Bzip2	LZMA	885248	144663	1029911
10	Gzip	XZ	848384	149811	998195
11	Gzip	LZMA	885248	149811	1035059

[SuperMaxusa]

@mikebdp2 I have looked at your kernel config and manual, and have a few questions:

• in the kernel config you had enabled CONFIG_FAT_FS, but you didn't have any floppy or USB drives, was there a reason to leave it on?
• the manual says that Elantech PS/2 was enabled for the Lenovo laptop, but there are more enabled extensions in the kernel config, is this to support other touchpads?

By the way, if you want to look what and how much space is taken up inside the kernel, use nm --size-sort <path to linux src>/vmlinux
(thanks to this old presentation by Bootlin: http://events17.linuxfoundation.org/sites/events/files/slides/opdenacker-embedded-linux-size-reduction-techniques_0.pdf)

[mikebdp2]

@SuperMaxusa thank you very much for your review - actually, I think my repo may be useful for you even if you have a different goal in mind, since you can take that large .sh script (that builds everything at once) and modify it for your needs, or i.e. take some tips from a config. Also, I wonder if you already tried the "-Oz optimization" for your Linux kernel - this gives a quite significant win without any bad side effects (at least didn't notice them yet) - and also the advanced LZMA options for rootfs compression, this all should help you to get more other cool stuff into your floppy

• although my floppy is intended to be used as a virtual one (# CONFIG_ISA_DMA_API is not set to save space, + 2.88 MB physical drive/floppies are rare anyway) , it still uses a FAT filesystem (for storing a bzImage, rootfs and syslinux.cfg) so I can't disable it
• Elantech is a part of my G505S but sometimes I've seen the laptop manufacturers pulling the parts from different OEMs. However I thank you for drawing my attention to this - considering that a mouse is quite a limited use in this text mode, most likely I will be disabling it entirely

Right now I want to enable USB_STORAGE (also requires SCSI and BLK_DEV_SD) - since I already have USB and FAT enabled, this will allow me to use a USB flash drive and save some files or notes there. If the space constraints will be too much of a trouble, I will have to produce three different floppy versions:

• with an Atheros Ethernet
• with a Realtek Ethernet
• maybe with PCNET32 for testing this floppy in a VirtualBox with "PCnet-FAST III / Am79C973" adapter
  since you are unlikely to have two different Ethernets on the same system

Also, considering that we could wget files from online if our Internet works, I would like to build a web browser like "links" and maybe some other cool software - that could be downloaded with a simple script after the successful network configuration

By the way, another interesting observation: bzImage is always rounded to 1024, that explains why disabling some options does not show any bzImage size change. There's also a similar effect for busybox, but I don't know if its the same reason or simply some code is still needed for another stuff: i.e. I tried disabling umount but didn't win anything - perhaps because a regular mount is still enabled, similar thing with no size savings by disabling some side features of chosen programs. So, there is a chance we could ENABLE some extra features/programs in busybox while not suffering any bloating from doing that

[SuperMaxusa]

Thanks for your reply!

By the way, another interesting observation: bzImage is always rounded to 1024, that explains why disabling some options does not show any bzImage size change.

vmlinuz rounds to 16 inside bzImage: https://zhuanlan.zhihu.com/p/73077391

Currently I'm experimenting with Clang but it gives no profit for size. Feel free to correct me it I'm doing something wrong.

Compiler/config	Size
GCC (config)	885248
Clang (config)	901632
Clang with ThinLTO (config)	897536
Clang with full LTO (config)	938496

Compiler versions:
GCC: 14.2.0
Clang: 19.7.1 (3+b1)

Make commands:
GCC: make CC=gcc ARCH=x86 bzImage
Clang: make CC=clang ARCH=x86 LLVM=1 bzImage

I didn't checked -Oz and other flags, just the standard LD/CFLAGS.

[mikebdp2]

@SuperMaxusa TBH being a GNU fan I don't have much experience with Clang, but I really encourage you to try out -Oz like I did (just a blind replacement of -O1, -O2, -O3 and -Os at all the sources). However, please make sure not to replace -O0 because while looking through the sources I think I found a few places that HAVE to be compiled with -O0 or the things won't work as intended (perhaps something related to time and timers, there was some note in source code comments indicating that -O0 is really needed there). Now I am trying to automatize the things a bit, i.e. today I figured out that mdev -d & is needed at startup script to ensure that plugged-in USB drive gets a /dev/sda /dev/sda1 path like we are used to, and some work on background udhcpc runners that I plan to test tomorrow (so that a network is more user friendly there). Right now the things barely fit for ath/rtl/pcn floppies (rtl has less than 1KB free) but they still fit, while intel ethernet is too fat & overboard for now

[SuperMaxusa]

I tried replacing all optimization levels (except -O0) with -Oz (using find . -type f -name Makefile -print0 -path ./.git -prune | xargs -0 sed -i -e "s/-O1\|-O2\|-O3\|-Os/-Oz/g").

With GCC and this config, bzImage takes 791040 bytes (-4096), vmlinux - 2450716 bytes (-40k).
Unfortunately, Clang breaks on arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found both with and without LTO.

Also I tried adding -Oz optimization level to menuconfig, this works less effective than batch replacing, but also less aggressively and it can be turned on/off.
Here is a patch: 0001-add-Oz-level-option.patch (created for v6.14.11). To enable: General setup -> Compiler optimization level -> Optimize for smaller size (-Oz).

For me, it doesn't affect the size of bzImage (still 795136 bytes) when using GCC, maybe some parts aren't affected by CFLAGS.

[SuperMaxusa]

@mikebdp2 Since you are using a virtual floppy in Coreboot and there is no need to write to a floppy disk, you can replace syslinux with https://github.com/oerg866/w98qi-tiny-floppy-bootloader (saves about 174k), but you will need to use CONFIG_INITRAMFS_SOURCE and CONFIG_CMDLINE_OVERRIDE.