I just downloaded
FreeBSD-10.2-RELEASE-amd64-memstick.img.xz, uncompressed it, and dd'ed the result to a USB stick on an Arch Linux system.
The boot process gets as far as
Code:
Trying to mount root from ufs:/dev/ufs/FreeBSd_Install [re,noatime] ...
Sep 20 18:01:38 init: login_getclass: unknown class 'daemon'
This is on a Thinkpad X11, 4GB.
I don't have a lot to offer on this specific issue, except that setting verbose on at boot time may help isolate where the problem is coming from.
There are also some issues with BIOS-level emulation of one storage type by another (for example, remote management card pretending it is a real CD/DVD drive). That all works great, right up to the point where the BIOS hands off to the operating system. The operating system was told it booted from a CD and looks around at the hardware and doesn't see anything it recognizes as a CD.
The same thing can happen with USB storage devices, since they come with varying levels of BIOS boot and emulation support.
I have been writing for years about what is, in my opinion, FreeBSD's broken QA process. I keep trying, hoping against hope, that things have improved, because on paper, FreeBSD has a lot to offer. But it continues to disappoint ...
I would have to point some of the blame at the users. There's an announced release schedule, along with when beta and release candidate versions will be available. Yet relatively few people download those, and fewer still do any sort of regression testing with them. Instead, the week after the official release of the new version, reports start coming in for regressions (used to work, now doesn't) or new features that don't work as expected. A lot of this could be avoided if those users had experimented with the beta / release candidates and provided feedback before the official release was built. I've heard many reasons for this - "I can't risk my production servers", etc. - but if you have multiple production servers you surely must have a spare, right? Test on that. A home user who expects to rely on a feature can simply disconnect their existing hard drive and try an upgrade or clean install on a different drive. If anything goes wrong, provide feedback.
On the opposite side, I would really appreciate it if certain developers didn't go out of their way to rip out lots of infrastructure and replace it either with something completely different*, or worse with nothing at all**, during the lifetime of a FreeBSD release. And for those of us who wanted to go from 8.4 to 10.2 and had 8.4 support dropped on August 1st, while 10.2 wasn't available until 2 weeks later. Ideally there would be a several-month window where both the last releases in a branch and the newest release in the newest branch were all under support.
* Forcing pkgng on users who were successfully using the old version. Let users make the transition when they upgrade, either to the next point release or the next major release. Not to mention the pkgng we were forced onto was itself broken and got a new version each week or so for a month after the forced change.
** Dropping REPLACE_BASE in the dns/bindxx ports in the middle of a release's lifecycle, and then faffing around for months to even re-add chroot support, until surrounded by a virtual mob waving clue-by-fours.
