DragonFlyBSD

OS: dfly-2.2.0-REL

Installer quits (at newfs) when you try to install using part of disk (i.e.
using partition no. 2, 3 or 4 for dfly).

Reason: missing device nodes for disk label letters.

Fix: manually add disk label device nodes before running installer.

1. ./MAKEDEV ad0s2a
2. ./MAKEDEV ad0s3a
3. ./MAKEDEV ad0s4a

Note.1: Doing it just for "a" makes all the other letters as well.

Note.2: problem occurs for both hammer and ufs FS selection.

Side note:

This has not been seen here if/as/when the target device has previously
been sliced/labeled by a prior DFLY install, OR with FreeBSD's toolset,
even if the target partition was not previously used by DFLY.

I have installed both/either of 2.3.0 // 2.2.0 to first and second
slices where FreeBSD 7 or 8 or Vector Linux previously lived, and to
where a slackware-based Linux once lived, and to a /dev/ar0 ATACONTROl
RAID1 array previously created with FreeBSD 8-

That holds for both 100%-HAMMER, 100%-UFS, and mixed, UFS-system +
HAMMER-add-on partitions.

Reboot between configuring the slice & partitions and completing the
install, as other OS'en may need, was not required.

All were CLI-mode cd iso installs, none yet tried here with the dvd.

No MAKEDEV yet required, other than whatever is inbuilt to the
installation process.

I suspect a label-reading issue, not a MAKEDEV fail per-se.

I shall now go off and format an external drive with the Mac for a test
of extreme weirdness, label-wise, and see if I can reproduce the
behaviour you report when converting it.

HTH,

Bill Hacker

Just to clarify further, when I encountered the problem, I was trying to
install to partition no. 3 which had dfly 2.0.1 on it.

First reaction is 'NFW that should have happened' - at least not as a
result of disklabel mismatch, device ID, etc.

Second thought is:

Did you do an upgrade with the DFLY toolset, OR a newfs and from-scratch
new install, or...

.just install over top of the old system, with neither an 'upgrade' nor
newfs - in which case, might there have been 'debris' - old files left
in place?

HTH,

Bill Hacker

I always do a fresh install.

• I JUST FOUND THE INSTALLER BUG ***

Just comparing install logs (on Alt-F1 screen):

DFly 2.0.1-REL:

<<< Executing `cd /dev && /bin/test -c ad0s3a || /bin/sh MAKEDEV ad0s3a'
>>> Exit status: 0

-<<< Executing `/sbin/newfs ...etc'

DFly 2.2.0-REL:

-<<< Executing `cd /dev && /bin/echo ad0s3a || /bin/sh MAKEDEV ad0s3a' | ad0s3a
->>> Exit status: 0

-<<< Executing `/sbin/newfs ...etc'

There is the problem, "echo ad0s3a" always returns 0, so MAKEDEV never happens.

Cheers, MK

Yep, you found it. :) Very nice, thanks.

I've committed a fix to HEAD which will go into 2.2.1.

Sascha

did this fix get mfc'd?

Yep