It's TRUE!
I don't have much time because I'm working with the problem right now. So my ideas and words can get cross, so I'll explain it the best I can. I have 10 partitions, the first three primaries are in this order -- FreeBSD's 9.1 December-4 version, 8.2 and 9.0 . I switch from the December 04, 2012 download ((version)) to the so-called RELEASE version December 30, 2012 (problem may be personal, because I don't think they are the same). I never build the kernel since FreeBSD 8.2 until yesterday for 9.1.
So finally we get the announcement and I download that file to be sure to have the latest copy in my mind. FreeBSD 9.1 did install well and very "strong" which I notice many times .. you can hear more churning into the tin as the system install, much more than the others (and no, this was not my imagination), I could feel it and it sounded good and made me happy! .. weird, I know, but true.
So as of yesterday, I decided to I build custom kernel with the same file as I used to build 9.0 kernel and the announced-FreeBSD 9.1 crash to vfs:,
[I waste lots of time wiping any partition before replacing it so there would never be an excuse of cross-bit or whatever.]
... so I reinstalled announced-FreeBSD 9.1 and build kernel with its own GENERIC file and it still crashed to vfs:. I did this more than a few times before concluding that with announced-FreeBSD 9.1, by chance, it could have been compromise even after the port system had been compromise. But I really feel that mistakes was made with the super-block, trying to rush-in the final [unnoticeable[/i] touches before New-Years.
I went back to wipe that partition for the final time. I reboot to FreeBSD-8.2 and it was gone .. so I booted to FreeBSD 9.0 and it was gone .. So I reinstalled my working MBR (backups) just to make sure and it did not help the situation in any kind of way...
All of my primary disk are gone and I am not about to hook it to my backup hard drive that has no FreeBSD 9.1 on it. I will be looking at that hard drive later in hope to see that at lease the extended partitions with no effects.
See the numbers below. I use these exact-size since 7.2 and I check these numbers with each and every install and they were always EXACTLY the same up until FreeBSD 9.0. I never tried 8.3 but I'm sure it has the new installer also. This was the beginning of understanding the real change to me and I feared upgrade from that day. I never build kernel with 9.0 and now I think the same thing might happen anyway since reading this thread about 8.3 Maybe this has relations, maybe not, but who would ever thought to see the change and now 9.1 maybe difference. I did not check this one. It's the only one I never checked until tonight maybe. I think it is the cause of the problem. If not, I like to see someone explain this other than to say "It gives you more free-bytes".
Code:
FreeBSD 8.2
.................. size block Used free
/dev/ad4s1a / 11360 11173 643 9644
FreeBSD 9.0 GIVES
.................. size block Used free
/dev/ad4s1a / 11360 11001 773 9347
As you see the new installer provides more free BLOCKS, which I don't think is a good thing. I'm sure they dug deeper into this and the problems of the core could have just begun. It only make good since to go back to the old installer. The new one only plus is that it build slices in the order you make them and not by the size such as the var or tmp slices like the old installer did. That was all that had to be change, and gpart is far from excellent during installation. If sysinstall was not broken why fix-it? You suppose to just add to it!
I may be wrong but I have a feeling that core has been change since December 4 with something that did not change the size of the distribution, or maybe I even received a bad download ..
All I know for sure is that it did not match the 8.2 block-size. Changing the all mighty SUPER-BLOCK would be the perfect way to lose at lease that present partition, but to loss all three primary would mean that there is a possibility that one of those new features in 8.3 than 9.1 created a virus/detour in the core, even on it's own.. It makes me think, if not after, that the core was compromise long before the ports to get all of the attention as the decoy just like in the spy movies (mission accomplished, ahead of time). I have no other idea until I explore this hard drive a bit deeper tonight. I'm very happy to have had my ZERO-DAY in advance.