>What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures.

There is no requirement for a given OS -- to use the filesystem of other OS'es...

If I am using DOS -- then DOS will not see nor use an ext2 filesystem on the same disk.

If I am using Linux -- then typically Linux will NOT see nor use a Novell, BeOS or Amiga filesystem(!) -- at least not without loading a specialized driver...

Every filesystem that ever is or was or could ever be -- is implemented as a highly specialized data structure, a pattern of data -- on the storage device.

This data structure, this pattern of data -- will have different rules (which will be completely different in two different filesystems) for "what data is supposed to go where" -- in that data structure...

Some filesystems -- may use the boot sector to store information about the filesystem in the boot sector. This is the case with DOS/MBR -- but may not be the case with other file systems! (There's nothing preventing a given filesystem from storing information about that filesystem on the last block of a storage device, or the middle block -- or any other block or blocks!)

The Starman's Realm, an ancient website (apparently) hosted on Geocities from 1998 - 2009 -- does a much better job of explaining all of this than I can:

https://thestarman.pcministry.com/asm/mbr/STDMBR.htm

"The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk."

Again, that's for old-style DOS/MBR partition tables.

When an OS is loaded -- it could look at the data on a storage device in any way it wishes, any way that it is programmed to do so. It may honor the pattern of data that implements a file system on that storage device, or it may not.

All file systems are software/algorithm/code-created abstractions -- on top of a simpler block-based (send/receive n bytes at time, where n typically equals one of the following: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 -- bytes at time) storage device.

At the absolute lowest level, that interface looks something like this:

ReadBlock(BlockID, PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedTo);

WriteBlock(PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedFrom, BlockID);

BlockID is just an Integer from 0 (first block, typically boot block) to some high integer -- which is the storage space of the storage device in bytes, divided by the block size.

ReadBlock() and WriteBlock() exist as things that the hardware can do -- even before any operating system is loaded -- whether that operating system respects any given filesystem (patterning) on the physical hardware device...

All filesystems are subsequently "created" -- by software, data structures, rules, algorithms, and abstraction... on top of this lower level...

Also, the first couple of pages of the following are good:

https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.p...

Last -- any data, any data -- can exist "inside" of a filesystem (the filesystem knows that it is there as a file, the OS recognizes it, etc.) -- but that data can also exist "outside" of that filesystem -- that is, as a series of blocks on that storage device.

If inside of a filesystem -- then the OS typically knows how to open, read, write and close the data -- as a file.

If outside of the filesystem -- then some other mechanism needs to know how to read that data.

In the case of a kernel, for example, the Linux kernel, the Linux kernel can exist inside of a filesystem -- everyone is familiar with that; it's just a file with a filename...

But it can also exist outside of a filesystem, as a series of (usually contiguous!) blocks on a storage device.

If a kernel (or any other data) needed at boot time exists in this manner -- then it is typically the responsibility of the boot block (or the boot sequence, since the boot block may load additional code) -- to know about that sequence of blocks -- and to load them into memory in a manner similar to what an OS would do with a file -- but since there's no OS running, there is no file system, and thus, the boot sector code -- needs to know the block range for kernel such that it can do a direct load of those blocks into memory...