[Bug 299031] installation may create partition missing superblock

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299031

--- Comment #3 from Jin Guojun <jguojun@gmail.com> ---
Further analysis by using different sizes of a + b, which may provide useful
information:

The same 36GB s1 slice, with 3 GB "/" (a) and 5 or 6 GB swap (b), now we see
some strange numbers:
=>      0     75497472    da1s1    BSD (36G)
        0      6291456        1    freebds-ufs   (3.0G)
  6291456     10485760        2    freebsd-swap  (4.0G)
 16777216     58720256        4    freebsd-ufs   (24G)


Please note that the numbers on the left (offset and size) are correct and
match the values written to the disk partition table by `gpart`. 10,485,760
sectors are equivalent to 5 GB, but the column on the far right is incorrect:
regardless of whether partition s1b (2) is 5 GB or 6 GB in size, partition s1d
(4) is always 24 GB; and If you configure 5 GB of swap space, gpart shows s1b
as 4 GB; if you configure s1b as 6 GB, gpart shows it as 5 GB (it seems always
1 GB less, but the numbers in the partition table on the disk are correct and
will be explained further below).

This looks like that bsdinstall uses a separated table in memory cache or
memory disk to perform the installation task, and the cache content is not
flushed to the disk after installation and before rebooting, thus created a
dispersion issue.

Before rebooting, enter the shell and run `dumpfs` and `gpart`. `gpart` output
the information shown above, while `dumpfs` printed the superblock information
for the `s1d` partition. However, since `dumpfs` did not specify the physical
address of the `s1d` partition, I surmise that the `s1d` partition is located
in the swap area, which begins at the 7 GB mark on slice `s1`.
Another strange thing is that the size of partition s1d in this case should be
29GB rather than 24GB. Some arithemtic error appears.

Rebooting this installation fails to mount /usr (s1d) due to missing
superblock, but gpart shows correct partition size: s1b = 5G and s1d = 28G.

Now rerun the installation and using existing partition to install, the
installer complains s1d has no superblock.
Enter the shell and run newfs on da1s1d, then back to installation, everything
works and newly installed system boots up and runs.

Summary: it looks like that the installer uses a memory based partition table
and some alignment computation occurs there. Installation based on this
partition table in the memory cache that is not synced with the disk partition
table.

-- 
You are receiving this mail because:
You are the assignee for the bug.