issues24
DragonFly Release 2.4
Possible Upgrade Issues
The kernel is unable to find the root and stops at the mountroot prompt. Due to the upgrade the drive may have changed names.
- Hit scroll-lock on the console, scroll up and locate the root drive.
- For BOOT+HAMMER try specifying: "hammer:xxxs1d", where xxx is the drive.
- For UFS try specifying: "ufs:xxxs1a", where xxx is the drive.
- Once you get the system up you may have to remount / read-write, then fix /etc/fstab and adjust /boot/loader.conf as necessary to specify the root mount using vfs.root.mountfrom="hammer:serno/SERIALNUMBER.s1d" (for example).
- We recommend specifying mount points by serial number, using /dev/serno/SERIALNUMBER.s1PARTITION as necessary. Also remember you may have a device specification in your /etc/rc.conf (for the dump device), and of course the root mount specification in /boot/loader.conf.
Your kernel and world are out of sync.
- ttys and ptys may not work properly in this case, you may have trouble getting a root prompt.
- Try booting into single user mode and complete the installation.
- Or boot the CD and re-upgrade.
HAMMER-only installation fails with BTX errors or is unable to load the loader, or kernel.
- An algorithmic bug in the loader's HAMMER implementation causes the loader to improperly parse file data in some cases.
- All we can recommend here is to switch to a BOOT+HAMMER installation, which is fully supported and actually considerably easier to manage. An existing installation can be adjusted by stealing 256MB from your swap partition to create a UFS boot partition, naming it 'a'. Then copy the HAMMER /boot into it (directly, not as a subdirectory called 'boot'). Of course we'd prefer a completely clean install so the partitions are well ordered but stealing an 'a' partition from swap space will work if you can't afford to blow away the current drive.
You have an AHCI SATA controller but the new AHCI driver is having problems detecting your drives.
- There is a boot menu option to disable the AHCI driver, which will cause the kernel to fall back to the NATA driver. Setting hint.ahci.disabled=1 in /boot/loader.conf will accomplish the same thing.
The installer errors out while trying to install a disklabel.
- Known issue. We blew the partition cleaning dd. Basically the installer wants to install a disklabel64 but there is a standard disklabel already installed. For safety reasons the disklabel program refuses to blow away the old label.
- You can blow away the whole disk or the slice from the emergency shell prompt (alt f3? alt f4?) and then start the installation over again.
- dd if=/dev/zero of=/dev/RAWDISK bs=32k count=4 This will blow away the whole disk. You can try it on just the slice, aka RAWDISKs1 but it is fairly dangerous to do so be careful.
Installer Issues
When installing w/ VMWare we recommend selecting a SCSI disk controller and using the CD ISO, not the DVD ISO.
When installing w/ VirtualBox we recommend defaults but select a hard disk size at least 3G and use the CD ISO, not the DVD ISO.
VirtualBox (and maybe VMWare too) do not implement the hard disk synchronize_cache command so a panic or hard shutdown may corrupt the filesystem. Because of this and also the fact that most user-specified hard drives are not the 200GB minimum recommended for HAMMER, we recommend that you install UFS on the virtual hard drive and not HAMMER.
GUI ISO (2.4.0 only) installs a bad /boot/beastie.4th file which will cause a HAMMER install on the HD boot to fail. You can fix this by booting from the DVD again, logging in as root, mounting /dev/ad0s1a /mnt (or da0s1a or whatever the hard drive winds up being), and editing /mnt/beastie.4th. Please remove the /boot prefix from the two include lines near the top. They should read: 'include screen.4th' and 'include frames.4th'.
When to install UFS - A HAMMER setup (actually BOOT+HAMMER) is the default installation but users with hard drives less then 50GB should probably select a UFS install instead of HAMMER. HAMMER is designed for larger hard drives, not tiny little hard drives or small virtual drives. Users who insist on using HAMMER on a small drive anyway should at least 'chflags nohistory /usr/obj /var/crash'.
Issues in 2.4.0 which are fixed in 2.4.1
- Issues with kqueue and SIGIO not working properly on pipes have been fixed. This issue affected numerous programs including postfix, dovecot, and others, which use pipes and kqueue for I/O notification.
- 64-bit kernels were unable to probe USB mass storage devices.
- cdrecord sometimes paniced after burning completed.
- Kernel failed to finish CAM probes during boot. (Note that some drivers may still register their CAM busses too late, and this problem has not yet been tracked down).
- Manual pages specified with relative paths which include a directory component did not work.
- Misc. setuid/setgid issues with exec and [f]chdir, operations sometimes failed.
- Installer's beastie.4th (boot loader issues) have been corrected.
- Boot loader now contains real-mode fixes which may improve booting from USB memory sticks.
- tcsh updated (fixes incorrect default autologout settings)
- Added support for VIA Nano and VIA C7
- Added support for probing OpenBSD slices
- Misc manual page improvements.
People can checkout the release branch and compile up a new kernel at any time, or wait for the incremental release.
IRC Help
There are usually DragonFly users and developers on EFNet in the #dragonflybsd channel who can help you if you have questions or problems.