Bug 238349 - Fresh install will not boot under some circumstances
Summary: Fresh install will not boot under some circumstances
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2019-06-05 21:46 UTC by Ronald F. Guilmette
Modified: 2019-06-21 19:42 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ronald F. Guilmette 2019-06-05 21:46:56 UTC
It appears to be the case that if a fresh install, e.g. of 12.0-RELEASE onto a hard drive which has previously had all of its partitions removed (but not its partition table), e.g. under Ubuntu/Linux, via the gparted tool, may result in a system that will not boot.

This specifically happened to me when I attemtped to do a fresh install of 12.0-RELEASE onto such a hard drive.  Note that in this specific case I had elected to perform "manual" partitioning during the FreeBSD install process.

I ended up resolving this problem by putting the drive, temporarily, into an existing FreeBSD system and then doing the following steps:

1)  gpart destroy -F ada0
2)  dd if=/dev/zero of=/dev/ada0 bs=1M count=10
3)  Re-doing the entire FreeBSD install from scratch

The fact that these steps resulted in a bootable FreeBSD system suggests to me that there are some things that aren't being done properly, i.e. to clear out old partition-related cruft, when and if one is doing a fresh install of FreeBSD, but possibly only when the person doing the install has elected to perform manual partitioning during the install process, and possibly only when all old partitions (but not the partition table) have been removed previously using, e.g., Linux+gparted.
Comment 1 Rodney W. Grimes freebsd_committer 2019-06-21 04:09:36 UTC
I do believe that you are correct in that this is only triggered by a manual partitioning operation.  The other types of installs do in fact wipe out and write an new partition table.

Can you go into some detail about what you did during the manual partition operations?

I have had a couple experiences here, and I know from first hand experience that if you do not produce a valid setup things go very wrong in spectacular ways.
Comment 2 Ronald F. Guilmette 2019-06-21 19:42:07 UTC
I can only tell you what I *believe* I did, obviously, since I wasn't videoing myself as I did this.  (Maybe I will next time! :-)

I'm not sure that any of this info will help though, as I believe that I did all of the exact same manual partitioning actions the second time around, i.e. *after* I had *also* done:

1)  gpart destroy -F ada0
2)  dd if=/dev/zero of=/dev/ada0 bs=1M count=10

However on this second install attempt everything worked, no problem.

Anyway, what I did, to the best of my recollection was this:

I started out, of course, selecting GPT as the partitioning scheme.

I created a 1 GiB / (root) partition... type freebsd-ufs of course.

I created a 16 GiB swap partition (freebsd-swap).

The rest is as you can see here, which is the "df -k" output from my (now running) system:

/dev/ada0p2      1014940    231756    701992    25%    /
devfs                  1         1         0   100%    /dev
/dev/ada0p4      3044988   1174092   1627300    42%    /var
/dev/ada0p5      2031132     16444   1852200     1%    /var/ftp
/dev/ada0p6      1015324    392428    541672    42%    /tmp
/dev/ada0p7     16233660   8574620   6360348    57%    /usr
/dev/ada0p8     32487548  22888624   6999924    77%    /home
/dev/ada0p9    400156276 258842812 109300964    70%    /v
/dev/ada0p10   473796804     32808 435860252     0%    /w
procfs                 4         4         0   100%    /proc

I hope and trust that this answers your question.