Wanted: A Clean Disk for Sys Installation

uname -a
Code:
FreeBSD MACH1 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386

A new disk was GPT formatted as an external drive through a USB port. The system disk was cloned onto it, but failed to boot the system.

I followed up by doing a clean install on the disk

Booting stalled, or hung repeatedly: A rapid display of the device probe, bright bold white text is observed (normal) then nothing after. In some instances a
Code:
No Boot Loader
message was received.On eventual login
frequent error messages were received ==>
Code:
ATA1: error issuing ATA PACKET command
This error condition may have been corrected by a suggested
/boot/loader.conf entry. Then a new error message popped up - A
Code:
gptboot: invalid backup GPT header

This is usually indicative of the disk been previously partitioned with GPT, then re-partitioned to MBR with persistent MBR metadata fragments and GPT table at the end of the disk. Well, there was no MBR on this disk, it was a new disk - except for GPT formatting as an external USB disk and the protected PMBR insertion with the bootcode. However, before the re-install I did perform a gpart delete of all partitions. [???]

I decided to start over de novo, from scratch. I did a gpart delete i <n> /dev/ada0 of each of the partitions. Then did a gpart destroy -F /dev/ada0
I decided on doing a zeroing of the disk with a dd if=/dev/zero of=/dev/ada0 bs=4MB prior to another reinstallation. On completion gpart show etc. revealed nothing, but on running fdisk /dev/ada0 it
showed some disk info in slice 1 (Sysid, start & end data, CHS) and then listed partition 2 - 4 as having <unused> data, which implies that partition data persisted as the count is correct.

I would have expected all of this, partition and boot info to be cleaned out.
What have I missed? How can I get a cleaned disk for installation? to avoid this GPT header problem.

Thanks!
 
For setting up a system disk, using gpart(8), I usually do as user root:
# gpart show -- in order to verify that I am operating on the correct device identifier, for now let's say adaX
# gpart destroy -F adaX -- completely destroy the old partition scheme
# gpart create -s gpt adaX -- create a new gpt scheme
# gpart add -s 128 -a 4k -t freebsd-boot adaX -- create the partition for the FreeBSD bootstrap code
# gpart add -s 4G -a 4k -t freebsd-swap -l Swap adaX -- create a 4 GB swap partition, and label it "Swap"
# gpart add -a 4k -t freebsd-ufs -l System adaX -- create a UFS2 partition utilizing the whole disk space, and label it "System"
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 adaX -- place the boot codes
# gpart set -a bootme -i 3 adaX -- set the BOOTME attribute (may be omitted)
# gpart set -a active /dev/adaX -- set the entire disk active in order the disk can be recognized by some too restrictive BIOS

Above command sequence sets up a well partitioned, but still empty, FreeBSD boot disk. You need to create the file system on the "System" partition using newfs(8):
# newfs -j /dev/adaXp3
If the old system used ACL's then enable those on the new "System" partition as well:
# tunefs -a enable /dev/adaXp3

Now clone your working FreeBSD system partition to the new "System" partition:
# mount -o noatime /dev/adaXp3 /mnt
# mount -- verify that the desired target partition is really mounted, i.e. it should read:
Code:
/dev/adaXp3 on /mnt (ufs, local, noatime, journaled soft-updates)
# tmux new "clone -c rwoff -x .snap:.sujournal / /mnt"
Wait ...
Wait ...
Be patient (well, not as much as with dump/restore) ...
Use df -h to follow the cloning advancement ...
Some hours later, after cloning has finished, edit /mnt/etc/fstab:
# nano /mnt/etc/fstab
Code:
# Device          Mountpoint    FStype  Options         Dump    Pass#
/dev/gpt/Swap     none          swap    sw              0       0
/dev/gpt/System   /             ufs     rw,noatime      0       1
Unmount the cloned volume:
# cd ; umount /mnt

Verify the cloned volume:
# fsck_ufs -fy /dev/adaXp3

The cloned disk is now perfectly prepared as a FreeBSD start-up disk and should simply work.
 
Thanks obsigna for your detailed step-wise response, I'll implement it. I did use almost all of your steps but perhaps not all in the same order - I will preserve your ordering.

I will omit your "cloning" step however, as I was wondering if some defect (corruption) in the old system was being inadvertently re-created on the new system. I'll just do a clean fresh re-install from the "release" *.iso distro, jut in the interest of "purity" and time.

Being "patient" and "Wait ...; Wait ...": had taken its toll. I was about considering the resurrection of my abacus and clay tablets! The cloning, although shorter was almost as long as the dump/restore sequence.

I'll just do a rebuild of the previously installed programs, I do have the codes (custom) and the files, + those from the ports.

Thanks again!
 
Some external USB disk adapters have buggy firmware. Some have off-by-one errors and put the last block in the wrong spot, some reserve the last block for their own use. Either of those will cause problems if the disk is moved. Connect the disk to a real SATA port and erase the last block. Do not trust what fdisk(8) reports on a blank disk, it uses default values. Just stop using fdisk at all.
 
TIME of RECKONING​

It did not work!
Followed everything in excruciating details and everything seemed to flow smoothly.

Deviation from steps -
eliminate disk confusion by just using only one (1) disk in machine
# gpart show --> showed nothing as the partitions were probably previously all destroyed
# gpart destroy -F /dev/ada0 --> Thought I'd clobber it again if anything survived
# gpart create -s gpt /dev/ada0
# gpart add -s 512 -a 4k -t freebsd-boot /dev/ada0 --> made it a bit larger
# gpart add -s 10G -a 4k -t freebsd-swap -l gptswap /dev/ada0 --> made it a large, lots of space ~ 3-4 times memory
# gpart add -a 4k -t freebsd-ufs -l gptrootfs /dev/ada0 --> partition added smoothly
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 /dev/ada0 --> bootcode added, notification & no problems
# gpart set -a bootme -i 3 /dev/ada0 --> added for good measure
# gpart set -a active /dev/ada0
# newfs -j /dev/ada0p3
# tunefs -a enable /dev/ada0p3

Now with 'install' mode in Release 10.2 distro disk
Went through the usual installation steps, set up partition manually which were already there, just had to set the mountpoints for /dev/ada0p2 as "/" and /dev/ada0p3 as "none" for gptswap
and proceeded with the installation as normal - no hiccups observed.

On completion rebooted as per instructions

FreeBSD started as usual then hit the rails, with
"invalid backup GPT header"

If it makes a difference I'll give the whole lead up and beyond to it.

Code:
Verifying DMI Pool Data ........................ Update Success
Boot from ATAPI CD_ROM:
Boot from ATAPI CD_ROM:
gptboot: invalid backup GPT header
gptboot: No /boot/loader on 0:ad(0p3)
gptboot: No /boot/kernel/kernel on 0:ad(0p3)

Code:
FreeBSD /x86 boot
Default : 0:ad(0p3) /boot/kernel/kernel
boot:

-----
Mounting /dev/ada0p3 on /mnt on the FreeBSD Live File System showed all the directory/files as expected.
Superficially the /boot/ directory seems normal
Except that in the /boot/kernel I did not see the GENERIC kernel, I might have missed it or looked in the wrong place.
boot, boot0, boot1,boot2, boot3, boot4, beastie etc, loader.rc & loader.conf are all present

gpart show shows info on disk partitions as expected

Any suggestion?
 
... just had to set the mountpoints for /dev/ada0p2 as "/" and /dev/ada0p3 as "none" for gptswap and proceeded with the installation as normal - no hiccups observed. ... Any suggestion?

/dev/ada0p2 would be the swap partition and /dev/ada0p3 the system partition, that means you mixed up the mount points.

Mount /dev/ada0p3 on /mnt, and edit the file /mnt/etc/fstab:
ee /mnt/etc/fstab
Code:
# Device          Mountpoint    FStype    Options        Dump    Pass#
/dev/gpt/gptswap     none        swap    sw                0    0
/dev/gpt/gptrootfs   /           ufs     rw,noatime        0    1
 
eliminate disk confusion by just using only one (1) disk in machine

Good, that reduces the chance of erasing the wrong disk. :)

# gpart show --> showed nothing as the partitions were probably previously all destroyed
# gpart destroy -F /dev/ada0 --> Thought I'd clobber it again if anything survived

Yes, but this only destroys what it finds. If the disk is MBR, it only removes the MBR. So it is not a bad idea to create and then destroy a GPT partitioning scheme:
Code:
gpart create -s gpt ada0
gpart destroy -F ada0

Then create the desired partitioning scheme.

# gpart create -s gpt /dev/ada0

/dev/ is not necessary, it can just be the device name: gpart show ada0.

# gpart add -s 512 -a 4k -t freebsd-boot /dev/ada0 --> made it a bit larger

That makes a 512-byte boot partition. It should be -s 512k.

# gpart add -s 10G -a 4k -t freebsd-swap -l gptswap /dev/ada0 --> made it a large, lots of space ~ 3-4 times memory

10G for swap is probably a waste. Most systems have enough memory these days.

# gpart add -a 4k -t freebsd-ufs -l gptrootfs /dev/ada0 --> partition added smoothly
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 /dev/ada0 --> bootcode added, notification & no problems

Looks fine.

# gpart set -a bootme -i 3 /dev/ada0 --> added for good measure
# gpart set -a active /dev/ada0

These are probably not needed and just add noise. I would skip them unless testing proves they are required.

# newfs -j /dev/ada0p3

-j is Soft Updates Journaling, which I have found best to avoid. -U is Soft Updates, which are harmless.

# tunefs -a enable /dev/ada0p3

Why? Until it works, leave out everything not required.

Now with 'install' mode in Release 10.2 distro disk
Went through the usual installation steps, set up partition manually which were already there, just had to set the mountpoints for /dev/ada0p2 as "/" and /dev/ada0p3 as "none" for gptswap
and proceeded with the installation as normal - no hiccups observed.

Why not just let the installer do all this partitioning?
 
That makes sense. I prefer to specifically set sizes, and use the largest boot block size possible (512K) because the bootcode has grown over the years.
 
Thanks guys for the review and overview wonderful! Everything works fine now, just the task of rebuilding the other installed programs and disks now. I goofed with the mount point issue earlier, it was really just a typo transpositional error. I had previously and over a long time had my swap in slice 3 and with that mind set could not resist the reflex response... I did have it set correctly as I did follow the steps almost "religiously".
Thanks again!
 
Back
Top