[PATCH v1] doc: README.distro: Special case with Windows formatted disk

[Andy Shevchenko]

On Mon, Dec 28, 2020 at 06:50:39PM +0100, Pali Rohár wrote:
> On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> > On Sunday, December 27, 2020, Pali Rohár <pali at kernel.org> wrote:
> > > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:

...

> > > > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > > > +======================================================================
> > > > +
> > > > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > > > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > > > +a disk via USB Mass Storage protocol.
> > > > +
> > > > +It may be useful to utilize that disk to copy bootable files from
> > > > +Windows machine to the board in case someone doesn't want to erase
> > > > +stock installation on it.
> > > > +
> > > > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > > > +that disk as a whole, meaning that it creates a partition table on it
> > > > +with requested (FAT) partition. As a result U-Boot may not see any
> > > > +files on it due to nesting partition tables.
> > > > +
> > > > +The workaround may be in formatting the partition under Linux OS,
> > > > +setting up a network connection between Linux OS and Windows 10 and
> > > > +use it to copy files to the partition.
> > >
> > > There is a better way how to do it. You can format partition to FAT with
> > > fake MBR table which reference to itself. Windows can correctly
> > > recognize such disk because it has MBR table and do not care that
> > > partition in MBR table starts at same offset as MBR table itself. And
> > > FAT filesystem can be put on such partition because first sector (where
> > > is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> > > there. Also Linux does not have any issue to access such partition
> > > because filesystem starts at offset zero (where it should be).
> > >
> > > FAT fs can be formatted with this fake MBR table by "mformat" tool which
> > > should work also on Windows systems. "mformat" supports this feature for
> > > a longer time but I do not remember how to activate it. Passing correct
> > > arguments to "mformat" always took me lot of time.
> > >
> > > Or alternatively it can be formatted by "mkfs.fat" tool with option
> > > --mbr=y but support for this option is not in any released version of
> > > "mkfs.fat"


> > While it’s a good idea, it’s not user friendly. The best option is to fix
> > U-Boot to recognize nested fat disks. But yeah, we may describe this in
> > U-Boot documentation at least.
> 
> I do not think that it is a good idea to recognize disks with nested MBR
> tables in u-boot. Neither linux support it. On linux you can hack it via
> device mapper kpartx or maybe also partx.

On Linux you can use loop and offset, there is no hack needed.

> But it is not something which
> is used by default or which is user friendly, as you need to do it every
> time when going to access such disk.

The case I got into has been achieved by very standard procedures. Hence it's
kinda default behaviour in some cases and should be handled accordingly. The
patch proposed here is to cover this in the U-Boot, because real fix has been
rejected by maintainer (probably I failed to explain that). But this is still
bug in U-Boot for such cases. And again, Linux has an offset option. I'm fine
if this can be added to the fat* commands in the U-Boot.

> My "solution" (or workaround or hack) is just to use non-standard /
> different arguments at the time when formatting disk and after this
> one-time operation, disk is accessible on all common systems without any
> future hacks. I think this is more user friendly.

As a compromise, but see above.

-- 
With Best Regards,
Andy Shevchenko