9.0 observations

[rank1seeker at gmail.com]

--------
OpenSSH:
--------
After taking advantage of new 'KexAlgorithms'
# sshd -T | grep KexAlgorithms
    will never show it ...


-----
WiFi:
-----
'media OFDM/54Mbps' breaks setup (supplied to 'ifconfig wlan0').
'ucastrate' and 'mcastrate' will set it instead.


-----
gpart
-----

On a MD vnode bassed image, of size:

1g or 2g:
    # gpart create -s MBR md0
        Will create starting offset at 63 sector
=>     63  2097089  md0  MBR  (1.0G)
=>     63  4194241  md0  MBR  (2.0G)

1432m:
    # gpart create -s MBR md0
        Will create starting offset at 33 sector
=>     33  2932703  md0  MBR  (1.4G)


NOW, looking at this new interesting alignment flag (-a 4k) ...
I started to add slices with it and taking into consideration BOTH above cases, all it really does under MBR, is it takes INITIAL offset and simply STAMPS it between slices, making NONE to align(nor to offset, nor to size => mess!):
1g or 2g:
       63       63         - free -  (31k)
1432m:
       33       33         - free -  (16k)


However, with GPT, all is stable:
# gpart create ... always sets offset to 34, regardless of img size
And (-a 4k) properly modifies BOTH slice's 'offset' and 'size', to be divisable with 8, without residue(=0)

In case:
--
# gpart show -p md0
=>     34  2932669    md0  GPT  (1.4G)
       34     1024  md0p1  freebsd-boot  (512k)
     1058        6         - free -  (3.0k)
     1064   501760  md0p2  freebsd-ufs  (245M)
--
6 sectors were added in favor of aligning md0p2's offset
Here I have a question. Is it true that FIRST slice, should always start at 1Mb offset (-b 1M) and why?
Should I use (-b 1M) for first and (-a 4k) for all other added slices?


Finally, taking into consideration first MBR alignment issues.
How should one proceed if he wants to put MBR on 4k sector disk?



Domagoj Smolčić