Installation of FreeBSD 8.2-RC1 fails on a Windows 2008 R2 Hyper-V virtual machine. 8.1 upgrades (either live or from DVD) exhibit the same issue. Installation of 8.0 was flawless (multiple servers, multiple guests). Symptom is generally that the VM will completely fail to start after installation - no FreeBSD boot menu, no kernel. Cursor shows empty, or a hyphen, at approx Row 3 Col 1 of the screen. Booting the Fixit shell on the DVD and mounting the root partition shows the partition is empty. Running fsck on the root partition shows errors for all items on disk - all are moved to lost+found. Problem could be timing related - in performing this installation and documenting it for this PR, the bug did not exhibit identical symptoms - the significantly delayed/slower build was able to display the FreeBSD boot menu, but hangs after selection with a backslash displayed in Row 25 Col 1 of the screen. Booting the fixit shell suggests the root filesystem is OK (mounts and displays a normal looking FreeBSD root directory). How-To-Repeat: Virtual machine configuration is as follows: 1 virtual processor 512MB RAM IDE controller 0 port 0: 40GB VHD (virtual hard disk) IDE controller 1 port 0: DVD Drive (FreeBSD-8.2-RC1-amd64-dvd.iso) Virtual SCSI controller Legacy Network Adapter COM1 COM2 Diskette Drive (no diskette) Follow the installation process: * Country Select: 232 United States * Standard installation * Starting with an empty disk (ie delete slices): + A (Use entire disk) + Q (Finish) * Standard MBR * Partition configuration (created in this order): + ad0s1a: 2048MB UFS2 on / + ad0s1b: 1024MB swap + ad0s1d: 6144MB UFS2+S on /var + ad0s1e: 2048MB UFS2+S on /tmp + ad0s1f: 29690MB UFS2+S on /usr (all remaining disk) + Q (Finish) * Distributions: + Custom - base - kernels (All) - man * Install from CD/DVD * Confirm installation * Progress bars show for base (42 chunks), GENERIC (53 chunks) and manpages (7 chunks) as they are extracted. Moments after completion, the Congratulations dialog is shown. * Congratulations: Press Enter. * Configure Ethernet: Yes * IPv6 configuration: No * DHCP configuration: Yes (successful on this network) * Configure hostname (mrtg), domain name (as per DHCP response) and other fields as appropriate for network * Network gateway: No * Configure inetd: No * Enable SSH login: Yes * Anonymous FTP: No * NFS Server: No * NFS Client: No * Customize console: No * Set time zone: Yes (Note: Sometimes, no selection dialog is shown - please advise if this should be another PR) * Select local or UTC: No [ie, clock is LOCAL time) * Time Zone Selector: Australia * Australia Time Zones: 5 New South Wales - most locations * Abbreviation EST: Yes * Does the system have a mouse: No * FreeBSD Packages: No * Initial user accounts: Yes * Add a single user account (member of wheel, shell=/bin/tcsh) * Exit * Set root password as desired (8+ chars, complex) * Visit the general menu: No * Exit install System automatically reboots, and shows a blank screen with the cursor on R3, C1 (approx). If desired, I can make a suitably sandboxed environment available, with the appropriate tools and Windows desktop available via RDP; otherwise, I'm happy to run any tools/scripts/provide any diagnostics requested.
It appears that the cause for the variable success of deployment (and potentially this PR) could be related to the fact that tools (such as tzsetup, dhclient and gunzip) are core dumping during the setup phase. For example, scrolling back on console 2 after a further setup attempt: pid 50 (dhclient), uid 0: exited on signal 11 (core dumped) /libexec/ld-elf.so.1: /usr/lib/libwrap.so.6: invalid file format ... pid 50 (dhclient), uid 0: exited on signal 11 (core dumped) pid 51 (ifconfig), uid 0: exited on signal 11 (core dumped) pid 52 (gunzip), uid 0: exited on signal 11 (core dumped) pid 53 (tzsetup), uid 0: exited on signal 10 (core dumped) pid 57 (gunzip), uid 0: exited on signal 11 (core dumped) I have confirmed that the DVD has the correct (MD5 and sha256) checksums - and this host runs other virtual machines with other operating systems without issue, suggesting that there is a reasonable likelihood that the hardware is operating correctly. Dave.
Responsible Changed From-To: freebsd-amd64->freebsd-emulation reclassify.
To submitter: does this problem still exist?
Feedback timout (> 3 months).