Update README.md

[StanDMan2003]

Combined and merged information from this examples site:
https://github.com/raspberrypi/noobs/wiki/Adding-custom-OS-version-examples

With the original noobs site:
https://github.com/raspberrypi/noobs#how-to-create-a-custom-os-version

This produces a single source that was tested on a Raspberry Pi3 yesterday 2/7/2017. Using Custom OS instructions from the two sites was able to port and build the current 16.04LTS UbuntuMate for install with noobs. Noobs load contains the Raspbian that comes with the latest noobs, Kano OS, OSMC, and UbuntuMate 16.04 all on a single 32GB SD card. Raspbian, UbuntuMate, and Kano OS all are set to 8GB OS partitions. Read and Review.

[procount]

The actual size should be in MiB (1024x1024 bytes)

[procount]

The actual size should be in MiB (1024x1024 bytes)

[XECDesign]

@procount are you sure about that?

I wise man (@lurch) once told me this:

• partitions.json needs to have "correct" partition sizes (the base-10
  version rather than the base-2 version, because that's what parted
  uses) for each partition

• the "uncompressed_tarball_size" should be the size in MB, rounded
  up to the next whole MB (i.e. the uncompressed root.tar file has a
  size of 2,336,133,120 bytes and so should have
  "uncompressed_tarball_size": 2337). This is simply used for the
  install-progress-bar.
• the "partition_size_nominal" is the minimal size that the
  partition will be created at. For Raspbian's root partition, this
  experimentally needs to be approximately 400MB larger than the
  "uncompressed_tarball_size" as this then leaves (at least) enough
  space for the 100MB swapfile that gets created during the first
  bootup, and to allow the user to run both apt-get upgrade and
  rpi-update before running out of diskspace.

[procount]

A wise man indeed! But maybe that information is now out of date?
I wasn't party to that information, so I worked it out myself from the source code.
I also recall that the whole partitioning code was revamped when Windows IoT was added with partclone and other enhancements (@maxnet maybe?)

No, I'm not sure, but I am fairly certain. I invite you to verify my findings. There are many calculation instances in multiimagewritethread.cpp, but here are a few pertinent ones I pulled out for you:

https://github.com/raspberrypi/noobs/blob/master/recovery/multiimagewritethread.cpp#L45
uint availableMB = (totalSectors-startSector)/2048;
When availableMB==1, the number of sectors must==2048. Each sector is 512 bytes, so 2048 sectors is 1048576, = 1024*1024 = 1MiB not 1MB.

https://github.com/raspberrypi/noobs/blob/master/recovery/multiimagewritethread.cpp#L140
emit parsedImagesize(qint64(totaluncompressedsize)*1024*1024);
The progressSlideShowDialog class uses the IoStats to measure the number bytes written to the disk for progress. So here, totaluncompressedsize is actually in MiB units (1024*1024)

https://github.com/raspberrypi/noobs/blob/master/recovery/multiimagewritethread.cpp#L400
proc.start("/sbin/sfdisk -uS --force "+drive);
sfdisk is now used to write the partition table instead of parted, and it uses sectors, not MBs.

AFAICT, all calculations of partition sizes use multiples of 1024. There are only 3 mentions of 1000, and each is to do with converting milliseconds to seconds.

However, I think there might be something slightly wrong with the progress bar calculation, because I often notice that the progress bar reaches 100% quite a while before it has finished writing the partitions. I've not had time to look into it yet as I consider it fairly minor.

[XECDesign]

Ah, thanks. Looks like I'll need to take a closer look at some point. Sounds like I may have been doing it wrong for quite a while then.

I assumed the reason it waits after 100% is that it's flushing the cached data. By default linux will flush every X seconds or when it reaches a certain percentage of RAM. I don't remember off the top of my head exactly, but it's something like 30 seconds or 20% or RAM. So although linux may claim the data has been written, it won't actually be until fsync completes.

[procount]

You're probably right.
I use df to measure the used space, instead of the size of the resultant tar file. I thought that might have something to do with it. Or maybe because filesizes didn't account for the actual size on disk - i.e. not rounding up to a whole number of sectors per file.
I added some debug code at one point to spew out the actual number of sectors written compared to what the json file indicated, but I can't remember what I did with the outcome. Maybe I'll have to resurrect it.
In any case, I was just being pedantic. Unless you are really squashing many OSes onto an SD card to the point that they become unusable due to lack of disk space, It's really not going to make much of a difference since every partition has some contingency. But it is better to advocate getting it right in the first place.

[maxnet]

A wise man indeed! But maybe that information is now out of date?
I wasn't party to that information, so I worked it out myself from the source code.
I also recall that the whole partitioning code was revamped when Windows IoT was added with
partclone and other enhancements (@maxnet maybe?)

• I do not recall ever using parted for anything other than the initial FAT partition resize on initial installation, and even that was something I advised against (my recommendation -at least for NOOBS Lite- was for saving files in memory and creating new file system, as that also works in situations in which parted is known to fail, such as when there is no partition table on the SD card).
  So no idea where the conclusion that things were base10 because parted likes it that way comes from.
  Partition modification was originally done in custom code, because it was a special requirement that no writes were done to the MBR after initial installation, and normal partitioning tools do are known to do that.
  This requirement was removed for Windows, as you cannot create primary partitions without touching that. So now partition creation does is outsourced to standard tools (sfdisk). Works on sector basis as well, so base2.

• Recall Linux can only write to storage in block size chunks (typically 512 bytes). So even if you write a 10 byte file, that can count as 512 bytes in stats. And also writes to filesystem metadata and journal are counted.
  Using write stats for progress is certainly not ideal. But doing proper progress is problematic when you have multiple input files (different archive files, for different partitions).
  If a single tarball for all partitions was used (like done in piserver) things would be a lot simpler.