Steve Polyack wrote:
I've seen some oddities with the partition and bsdlabel editors in the sysinstall program on the 7.0 and 7.1 releases. The partition editor seems to be reading or parsing the partition table incorrectly. I had a 6.3-RELEASE system with the following layout:
/dev/amrd3s1a on / (ufs, local)
/dev/amrd3s1g on /opt (ufs, local, soft-updates)
/dev/amrd3s1f on /usr (ufs, local, soft-updates)
/dev/amrd3s1d on /var (ufs, local, soft-updates)
/dev/amrd3s1e on /var/log (ufs, local, soft-updates)

Upon booting into the 7.x install media and encountering the FDISK Partition Editor, the partition it's seeing is amrd3*a*s1, as opposed to amrd3s1. Trying to continue with the partition table and bsd labels as is only led to the installer bailing out. As soon as it would attempt to newfs the disk partitions, the installer would error and report that it can't find a device entry in /dev for amrd3*a*s1a. Since preserving the data on the disk was not critical, I was able to continue by deleting the original partition/slice and recreating them. This worked fine.

However, I'm still curious as to what the cause of this is. I have seen this before on two other systems while installing 7.x, quite possibly while upgrading from 6.3. When this occurred, I was also moving from i386 to amd64; Is there some kind of offset for partition tables which may change based on architecture?

Lastly, here's a screenshot of the partition editor:

Unfortunately, I do not have any screenshots of the errors during the newfs step. If this comes up again, I'll be sure to take some. Thanks.

This also occurs in VMWare. I'm able to get the exact same behavior by installing a 7.1-RELEASE system (single slice, da0s1), then booting off the install media and start a new installation. It picks up the partition as da0as1 instead of da0s1, making it impossible to use sysinstall while preserving existing partitions.

-Steve Polyack
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to