Installation/release confusion?

When 10.3 RC3 became available, I downloaded a copy and installed it on a test basis on one of my machines. So far, it has worked well, no issues to report.

Yesterday, I decided to install it on another machine. I have the mini version on a USB key, so the sets have to be downloaded from a server. At the point that the installer tried to do the downloads, I was informed that the files were not available. So I checked the FreeBSD site and 10.3 is still "upcoming" and the announcement of RC3 is still a clickable link under "Latest news". But if you go to a mirror, 10.3-RC3 is no longer available, which is why the installer can't find the sets. It's now 10.3-RELEASE. So I downloaded the FreeBSD-10.3-RELEASE-amd64-memstick.img file and dd'ed it to the USB key and re-did the installation, which proceeded normally. Except the machine won't boot. The install was done the same way it was done on the 10.3-RC3 machine I'm typing on -- ZFS root, GPT.

I understand that at this point, we are on the cusp of the 10.3 release and things may not be quite ready yet, since the release has not been announced. But if that's the case, why not just leave the 10.3-RC3 files in place while getting the release ready to go, rather than removing something that worked and replacing it with something apparently broken, while the website misleads you into thinking RC3 is still available?
 
Which is your concern: that 10.3-RC3 images are no longer available, or that your machine won't boot? You haven't presented any reason to believe there's any connection between those two things...

Release clients are for testing; the testing period is over. That's all there really is to that, and the absence of -RC3 images doesn't hurt anyone.

So I checked the FreeBSD site and 10.3 is still "upcoming" and the announcement of RC3 is still a clickable link under "Latest news"

10.3-RELEASE images are not yet available everywhere, because it takes time for mirrors around the world to synchronize all that data. The official announcement will be made when the sync is complete. In the meantime, the fact that -RC3 was released on 03/20/2016 will continue to be true ad infinutum, and the announcement of that fact will be among the latest announcements on the website until it is replaced by other, more recent announcements.
 
Which is your concern: that 10.3-RC3 images are no longer available, or that your machine won't boot? You haven't presented any reason to believe there's any connection between those two things...

Release clients are for testing; the testing period is over. That's all there really is to that, and the absence of -RC3 images doesn't hurt anyone.

10.3-RELEASE images are not yet available everywhere, because it takes time for mirrors around the world to synchronize all that data. The official announcement will be made when the sync is complete. In the meantime, the fact that -RC3 was released on 03/20/2016 will continue to be true ad infinutum, and the announcement of that fact will be among the latest announcements on the website until it is replaced by other, more recent announcements.

You ask about my concern and provide me an explanation about how things don't get to mirrors instantaneously; why not just read my message carefully instead? On the latter point, I said "we are on the cusp of the 10.3 release and things may not be quite ready yet". As to the former, look at the last paragraph. That's my concern. It's about the *process*. At the moment, there is no installable version of 10.3 available, when there could have been, had the RC3 files been left in place until the RELEASE was ready. Disk space is cheap, why create an unnecessary limbo period? And why confuse people with clickable links to places that tell you how to obtain release candidates that no longer exist? The "Latest news" could be left on the home page, but those links should not be clickable, which leads people astray.
 
At the moment, there is no installable version of 10.3 available..,

You haven't presented any reason to believe there's any connection between [the installation image you used and your system's failure to boot]...

New machine. New install. New variables to contend with. Things didn't work for you automatically---that doesn't mean 10.3-RELEASE is broken, which is your implication. Logically, if 10.3-RC3 and 10.3-RELEASE are virtually identical, the minute differences between them (which mostly consist of updates to the release notes) are unlikely to be the cause of your problem.
 
New machine. New install. New variables to contend with. Things didn't work for you automatically---that doesn't mean 10.3-RELEASE is broken, which is your implication. Logically, if 10.3-RC3 and 10.3-RELEASE are virtually identical, the minute differences between them (which mostly consist of updates to the release notes) are unlikely to be the cause of your problem.

We are in agreement on this point.

This is a vanilla PC, a machine I use for OS tests. Arch Linux ran fine on it before I blew it away (having backed it up first) with FreeBSD. I've just installed OpenBSD 5.9 on that machine and that runs too. I installed Dfly 4.4 on it a few months ago, and it ran, though there were networking problems. FreeBSD doesn't boot on this machine, so something's broken and it's not the machine. The problem *could* be a result of my installing prematurely, prior to the release announcement and the mirrors settling down. But if that's the case, then my point about leaving RC3 in place until the RELEASE was ready stands. I'm not claiming to *know* that RC3 would have run on this machine -- I never tried it -- but if my problem is indeed file skew on the mirrors, then it's likely RC3 would have been ok.
 
I tried this install again this morning, this time with the full .img file (last time I used the mini version, downloading the sets). Same result -- does not boot. This machine has an Asus AM1I-a motherboard, an AMD processor, 4G of memory and a 320G 7200 rpm SATA disk. Nothing fancy.

This issue has nothing to do with file skew or mirrors not updated yet. The non-booting install was done with ZFS and GPT and the latter is the problem. I have set up the BIOS (which is up-to-date) to disable UEFI. Arch runs fine on this system, as does Clonezilla, as does OpenBSD, but the difference is that none use GPT. OpenBSD now gives you the option of installing using GPT, but the installer warns that the system may not boot. It was this warning that prompted me to do another install of FreeBSD 10.3 just now, also with ZFS, but using an MSDOS partition table (with ZFS, there's really no need for the extended capabilities of GPT). The install was otherwise identical, but the machine now boots and, so far, runs properly (though I've done nothing beyond the installation yet).

Oddly, I'm typing this on another machine, also AMD/Asus (but different MB and different processor), which is running 10.3 RC3, ZFS and GPT. No booting problems. It appears from my experience and the OpenBSD warning that use of GPT makes the probability of the machine booting less than 1. I can see the point of using GPT with UFS, if you use a lot of filesystems and you also avoid the slice vs. partition confusion, but I don't see the point of using it with ZFS. I think this issue ought to be looked into by the FreeBSD developers and if my diagnosis is correct, the documentation ought to be changed to apprise people that they may be wasting their time trying to do GPT installs at this point and that they should have a damned good reason for attempting one, because it may not work.
 
Wow, what a complete waste of time this has been. Installed xorg and try to start the server -- no screens found,

[drm] Failed to open DRM device

There is stuff all over the web about this with ati/amd radeon graphics hardware, which this is. I tried a suggestion or two with no luck and realized that when you are in a hole, the first step is to stop digging. Restoring Linux. (My main motivation for trying FreeBSD yet again, after finding show-stopping bugs in all previous attempts going back to 7.x, was ZFS. But if I can't run X, the virtues of ZFS are moot.)
 
So that's the end of that and we can close this thread. donallen has not been able to properly install FreeBSD since 2009, and longer ago from his posting history, so there is no hope, I guess.
 
I think this issue ought to be looked into by the FreeBSD developers and if my diagnosis is correct, the documentation ought to be changed to apprise people that they may be wasting their time trying to do GPT installs at this point and that they should have a damned good reason for attempting one, because it may not work.
GPT installs work fine. Why did you disable UEFI again?

Wow, what a complete waste of time this has been. Installed xorg and try to start the server -- no screens found,

[drm] Failed to open DRM device

There is stuff all over the web about this with ati/amd radeon graphics hardware, which this is. I tried a suggestion or two with no luck and realized that when you are in a hole, the first step is to stop digging. Restoring Linux. (My main motivation for trying FreeBSD yet again, after finding show-stopping bugs in all previous attempts going back to 7.x, was ZFS. But if I can't run X, the virtues of ZFS are moot.)
I wish you'd have provided more details on your Hardware/GPU, your /var/log/Xorg.0.log etc.

In the end if you're having trouble with your GPU might I suggest just buying a cheap NVIDIA card or other known working card. The GT210 can be had for ~30 EUR (a lot cheaper if you buy it used, I've seen it for ~10 EUR on Ebay). Or try VESA. Or boot from UEFI and use SCFB. Lots of options.
 
GPT installs work fine. Why did you disable UEFI again?
UEFI is not required for GPT, or vice versa. With the new gop boot loader command, I even ran X on that UEFI-booted Minnowboard with a Bay Trail chipset using scfb.

10.3 amd64 is working fine here on an Intel system with a 5000-series AMD GPU. I've also used an AMD A8-3850 APU with a built-in 6550 GPU successfully, although it's been a while. The APUs are cheap but have newer GPUs that are probably not supported by the FreeBSD port of Xorg yet. As you say, vesa or scfb are options.
 
GPT installs work fine. Why did you disable UEFI again?

Because I was not about to get involved in the additional complexity of UEFI and I have done GPT installs of FreeBSD with UEFI disabled previously, such as on the machine on which I am typing this. As I described in a previous post, for some reason using GPT on the machine in question did not result in a system that would boot. I had to revert to an MSDOS partition table in order to solve the booting problem.

I wish you'd have provided more details on your Hardware/GPU, your /var/log/Xorg.0.log etc.

And you know that I was not going to file a bug report how? Why would I bother providing details to this list rather than to the bug database?


In the end if you're having trouble with your GPU might I suggest just buying a cheap NVIDIA card or other known working card. The GT210 can be had for ~30 EUR (a lot cheaper if you buy it used, I've seen it for ~10 EUR on Ebay). Or try VESA. Or boot from UEFI and use SCFB. Lots of options.

Adding a card is not an option. We are talking about an ITX machine with no room in the case for another cable tie. As for VESA, its max resolution is 1280x1024; I have a 1920x1080 monitor on the machine in question. As for SCFB, why would I want to screw around with UEFI to try something that might or might not work, when I had an easily restore-able (Clonezilla -- very good) backup of Arch Linux that works fine on the machine in question. At this point, going back to Linux was clearly the best choice for me on the machine we are discussing. I am continuing to use FreeBSD on the machine on which I am typing and it has worked well since I installed it when RC2 came out. It's my first look at ZFS and to date the experience has been very positive. And, so far, I have not encountered any of the show-stopping kinds of problems that have prevented me from using FreeBSD in the past. So I'm hopeful that, at least on the machines where it supports the hardware, I can finally take advantage of the good aspects of FreeBSD.
 
So that's the end of that and we can close this thread. donallen has not been able to properly install FreeBSD since 2009, and longer ago from his posting history, so there is no hope, I guess.

Not quite right. I have encountered serious problems, such as the USB subsystem not working, with every version of FreeBSD I have tried in the past, starting with the 7.x series. You seem to be into blaming the messenger; not a good strategy. As for your guess about hope, see my post of a few minutes ago.
 
Back
Top