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:
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.
/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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"