fdisk command for sysinstall (and other boot oddities)

Hi,

Without going into much background for what I have done to get where I am now, in short, I am writing a scripted install for FreeBSD. I have everything completed successfully except one final step. When I write my disk partition information I execute this:

[cmd=]fdisk -BI -a -b /boot/mbr ad0[/CODE]

Once everything is done and installed successfully and I go to boot I am prompted with a
Code:
No Operating System Installed
Ok, that tells the BIOS can't find the proper active partition.

Ok, so I run fdisk to print the fdisk configuration file.

Code:
$ fdisk -p ad0
g c41610 h16 s63
p 1 0xa5 63 41942817
a 1

..odd, it tells me partition one is the active paritition. Ok, so hs a good measure I run sysinstall -> custom -> parititions -> "S" to set the bootable flag on ad0s1.

Lets run fdisk -p again.

Code:
$ fdisk -p ad0
g c41610 h16 s63
p 1 0xa5 63 41942817
a 1

Odd...looks the same

...Reboot


Success!

But why?

Here is my dilemma: I do not know what sysinstall does to write disk/boot information so that the BIOS knows where to find the active parittion. That is to say, the configuration that fdisk holds is exactly the same both prior to and after running sysinstall. Is there another command I need to execute to "seal the deal" on marking what is the true active partition? What exactly does sysinstall do outside of just running writing fdisk information.

Any help would be greatly appreciated!
 
Still
Code:
Missing Operating System
:(

Any other ideas?

If it's any consolation: on my preconfigured msfroot.gz file I have added a /var/tmp/bsdLabelFile which holds my labeling schema.

Code:
a:     10G      16      4.2BSD    0       0       0
b:      4G       *      swap      0       0

Just a very basic setup.

Right after I run the fdisk command I run:

[cmd=]bsdlabel -R /dev/ad0s1 /var/tmp/bsdLabelFile[/cmd]

And now as per your suggestion right after the above command I execute:

[cmd=]bsdlabel -B /dev/ad0s1[/cmd]

I am going to try a few other things with bsdlabel though I believe anything I do may offset what I have done with -R?
 
Thank you soooo much for your lead!

I had tried -B by itself and as the man pages say it should default to the /boot/boot file but for some reason it wasn't. Once I gave it an absolute path with the -b option, everything worked fine.

Steps:
Code:
dd if=/dev/zero of=${DISK} count=500
fdisk -BI -a -b /boot/mbr ${DISK}
bsdlabel -R ${DISK}s1 /var/tmp/bsdLabelFile
bsdlabel -B -b /boot/boot ${DISK}s1
newfs -EJ ${DISK}s1a
mount ${DISK}s1a /mnt
...ftp tar.gz base & kernel files, extract, and run install.sh
reboot

That's the gist of running a scripted install!

Thanks again!
 
Why are you using -a ("change the active slice only")?

# fdisk -BI ad0
writes a standard MBR. But don't forget to use
# sysctl kern.geom.debugflags=16
first.

Code:
sysctl kern.geom.debugflags=16        # enable writes to the bootblock
dd if=/dev/zero of=${DISK} count=500  # 500 sectors is not necessary, even GPT only uses the first 35.  But also the last 35 blocks on the drive.
fdisk -BI ${DISK}                     # as above
bsdlabel -R ${DISK}s1 /var/tmp/bsdLabelFile
bsdlabel -B -b /boot/boot ${DISK}s1   # maybe not necessary
newfs -EJ ${DISK}s1a                  # -E is slow and maybe not useful, add -U for softupdates
mount ${DISK}s1a /mnt
...ftp tar.gz base & kernel files, extract, and run install.sh
reboot

sysinstall(8) is scriptable, but nearing death. The new installers might not be compatible with it.
 
wblock said:
Why are you using -a ("change the active slice only")?

# fdisk -BI ad0
writes a standard MBR. But don't forget to use
# sysctl kern.geom.debugflags=16
first.

Code:
sysctl kern.geom.debugflags=16        # enable writes to the bootblock
dd if=/dev/zero of=${DISK} count=500  # 500 sectors is not necessary, even GPT only uses the first 35.  But also the last 35 blocks on the drive.
fdisk -BI ${DISK}                     # as above
bsdlabel -R ${DISK}s1 /var/tmp/bsdLabelFile
bsdlabel -B -b /boot/boot ${DISK}s1   # maybe not necessary
newfs -EJ ${DISK}s1a                  # -E is slow and maybe not useful, add -U for softupdates
mount ${DISK}s1a /mnt
...ftp tar.gz base & kernel files, extract, and run install.sh
reboot

sysinstall(8) is scriptable, but nearing death. The new installers might not be compatible with it.


Thank you for this. I have made some changes to remove -E and not using -J for journalling since I don't really need it. The dd 500 count is too much, I know, it was just what I was using for debugging and knew I only needed 35.

I guess -a would be pretty unnecessary since I am using -I to create an entire slice of the disk.

I'm not scripting sysinstall specifically, I am using /etc/rc.conf from mfsroot.gz to kick off an init script that runs my install process. After it completes, it reboots and boots from the primary hard drive.

What would -U for softupdates give in terms of benefits?

This all stemmed from trying to work with sysinstall with install.cfg but realizing how rudimentary it was, I ended up making a modified mfsroot.gz to include some extra binaries for much better/easier scripting capabilities making my automated install process much more reliable.

Using what I have put above has worked. I didn't need to use the sysctl command but if you think I should then please let me know. I have so far tested this via PXE on a Dell 1950 server, VirtualBox, and a desktop PC and netbook-- all were successful.

This was my very first attempt at this and the entire process will be cleaned up and tested over and over again. I was merely putting together a personal POC and I still have much to learn.
 
ckozler said:
What would -U for softupdates give in terms of benefits?

Much faster deletes. (I was advised that my Disk Setup On FreeBSD had left it out... and then the reason removing /usr/obj before a buildworld took so much longer lately became obvious. Oops.)

Using what I have put above has worked. I didnt need to use the sysctl command but if you think I should then please let me know. I have so far tested this via PXE on a Dell 1950 server, VirtualBox, and a desktop PC and netbook-- all were successful.

Depends on the version of FreeBSD. And maybe how GEOM noticed the disk.
 
wblock said:
Much faster deletes. (I was advised that my Disk Setup On FreeBSD had left it out... and then the reason removing /usr/obj before a buildworld took so much longer lately became obvious. Oops.)



Depends on the version of FreeBSD. And maybe how GEOM noticed the disk.

I will probably implement the softupdates part for future implementations as the 1950 I tested on so far has already become the destination of a migration for the office share...enabled ZFS and compression too :p.

Perhaps GEOM spit out an error but I did not see it. For all of these tests I watched but I have a 5 second sleep between operations such as setting IP, formatting, etc just to let things settle.
 
Back
Top