problem after installkernel going from 9.0 to CURRENT

[Robert Huff]

(While this may not be a strictly CURRENT issue, I asked on questions@,
but have not found a solution.)

Situation:
One of my boxes failed, and for various reasons it became easier to
just scrub and rebuild it. Like its predecessor it will run CURRENT
1) Using BSDinstall, I flushed then created the first disk:

ada2p1 freebsd-boot 128k
ada2p2 freebsd-swap 4g
ada2p3 freebsd-ufs 25g

(There are non-bootable disks at ada0, -1, and -3.)

2) Installed off the 9.0 CD, got it up and running, everything was good.
3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30.
4a) Built world - OK.
4b) Build kernel - OK.
4c) Ran mergemaster - OK.
4d) Installed kernel - OK.
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".
6) Boot using installation CD and use "gpart show" to double check
device names and partitions; everything looks good.
7) Try normal booting again, no go.

This is my first time installing to a completely GPT partitioned
system, and I have (obviously) failed to grok something. I checked
src/UPDATING and found nothing which covered this.
What have I bungled, and how do I fix it?


Respectfully,


Robert Huff

[Benjamin Kaduk]

Post by Robert Huff
(While this may not be a strictly CURRENT issue, I asked on
One of my boxes failed, and for various reasons it became easier to
just scrub and rebuild it. Like its predecessor it will run CURRENT
ada2p1 freebsd-boot 128k
ada2p2 freebsd-swap 4g
ada2p3 freebsd-ufs 25g
(There are non-bootable disks at ada0, -1, and -3.)

For a full clean install, I believe that bsdinstall should prompt about
installing bootcode around here. I don't really understand from your
procedure how bsdinstall was used; there might be some edge case where
there is no prompt about bootcode.

Post by Robert Huff
2) Installed off the 9.0 CD, got it up and running, everything was good.
3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30.
4a) Built world - OK.
4b) Build kernel - OK.
4c) Ran mergemaster - OK.
4d) Installed kernel - OK.
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".
6) Boot using installation CD and use "gpart show" to double check
device names and partitions; everything looks good.
7) Try normal booting again, no go.
This is my first time installing to a completely GPT partitioned
system, and I have (obviously) failed to grok something. I checked
src/UPDATING and found nothing which covered this.
What have I bungled, and how do I fix it?

I think you should investigate the 'bootcode' subcommand of gpart(8).

-Ben Kaduk

[Robert Huff]

Post by Benjamin Kaduk
For a full clean install, I believe that bsdinstall should prompt about
installing bootcode around here. I don't really understand from your
procedure how bsdinstall was used; there might be some edge case where
there is no prompt about bootcode.

Post by Robert Huff
2) Installed off the 9.0 CD, got it up and running, everything was good.

Let me elaborate on this:

2) Installed off the 9.0 CD, had a fully bootable system connected to
the Internet, everything was good.

Post by Benjamin Kaduk
I think you should investigate the 'bootcode' subcommand of gpart(8).

Does the above change things?
It was my expectation "installkernel" would Do The Right Thing with
respect to new bootcode, and I am surprised it did not.

Respectfully,


Robert Huff

[Kevin Oberman]

Post by Robert Huff

Post by Benjamin Kaduk
For a full clean install, I believe that bsdinstall should prompt about
installing bootcode around here. I don't really understand from your
procedure how bsdinstall was used; there might be some edge case where
there is no prompt about bootcode.

Post by Robert Huff
2) Installed off the 9.0 CD, got it up and running, everything was good.

2) Installed off the 9.0 CD, had a fully bootable system connected
to the Internet, everything was good.

Post by Benjamin Kaduk
I think you should investigate the 'bootcode' subcommand of gpart(8).

Does the above change things?
It was my expectation "installkernel" would Do The Right Thing with
respect to new bootcode, and I am surprised it did not.

installkernel does absolutely nothing to the boot partition. You need
to use bsdinstall or gpart to write the new image to disk.

That said, I know of no reason that the boot code written by the 9.0
install would fail to boot head. I am running 9.1 on a GPT disk and it
works fine, but I that disk is ada1 and I have booteasy installed on
the MBR of ada0. It has no problems booting the 9.1 system. (Windows 7
in on ada0.) Then again, I am hardly an expert on the subject.

[Robert Huff]

Using the GPT labels is a winning solution.

Thanks to all those who helped,


Robert Huff

[Warren Block]

Post by Robert Huff
(While this may not be a strictly CURRENT issue, I asked on
One of my boxes failed, and for various reasons it became easier to
just scrub and rebuild it. Like its predecessor it will run CURRENT
ada2p1 freebsd-boot 128k
ada2p2 freebsd-swap 4g
ada2p3 freebsd-ufs 25g
(There are non-bootable disks at ada0, -1, and -3.)
2) Installed off the 9.0 CD, got it up and running, everything was good.
3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30.
4a) Built world - OK.
4b) Build kernel - OK.
4c) Ran mergemaster - OK.
4d) Installed kernel - OK.
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".
6) Boot using installation CD and use "gpart show" to double check
device names and partitions; everything looks good.
7) Try normal booting again, no go.
This is my first time installing to a completely GPT partitioned
system, and I have (obviously) failed to grok something. I checked
src/UPDATING and found nothing which covered this.
What have I bungled, and how do I fix it?

It really does not sound like a GPT problem, because 9.0 booted. The
-current kernel can't find/detect the device. Scrolling back in the
console buffer might find a problem. buildworld/kernel/installworld do
not affect the disk partitioning, but can change the code that looks for
those partitions.

[Robert Huff]

Post by Warren Block

Post by Robert Huff
(While this may not be a strictly CURRENT issue, I asked on
One of my boxes failed, and for various reasons it became easier
to just scrub and rebuild it. Like its predecessor it will run CURRENT
ada2p1 freebsd-boot 128k
ada2p2 freebsd-swap 4g
ada2p3 freebsd-ufs 25g
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".

It really does not sound like a GPT problem, because 9.0 booted.

I don't (at the moment) think it's GPT caused; but I do think it may be
GPT related.

Post by Warren Block
The
-current kernel can't find/detect the device. Scrolling back in the
console buffer might find a problem. buildworld/kernel/installworld do
not affect the disk partitioning, but can change the code that looks for
those partitions.

Exactly. I'm looking for help figuring out how the hand-off from
loader to kernel got broken and what I have to do to fix it.
One possibility: I believe I labeled each of the partitions during the
gpt creation process. Can I use those labels to (hopefully) by-pass
this issue?


Robert Huff

[Kevin Oberman]

Post by Robert Huff

Post by Warren Block

Post by Robert Huff
(While this may not be a strictly CURRENT issue, I asked on
One of my boxes failed, and for various reasons it became easier
to just scrub and rebuild it. Like its predecessor it will run CURRENT
ada2p1 freebsd-boot 128k
ada2p2 freebsd-swap 4g
ada2p3 freebsd-ufs 25g
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".

It really does not sound like a GPT problem, because 9.0 booted.

I don't (at the moment) think it's GPT caused; but I do think it may
be GPT related.

Post by Warren Block
The
-current kernel can't find/detect the device. Scrolling back in the
console buffer might find a problem. buildworld/kernel/installworld do
not affect the disk partitioning, but can change the code that looks for
those partitions.

Exactly. I'm looking for help figuring out how the hand-off from
loader to kernel got broken and what I have to do to fix it.
One possibility: I believe I labeled each of the partitions during
the gpt creation process. Can I use those labels to (hopefully) by-pass
this issue?

Yes! This is the current recommended way of doing it.

Post by Robert Huff
cat /etc/fstab

# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/swap none swap sw 0 0
/dev/gpt/root / ufs rw 1 1
/dev/gpt/tmp /tmp ufs rw 2 2
/dev/gpt/usr /usr ufs rw 2 2
/dev/gpt/var /var ufs rw 2 2

[Warren Block]

Post by Kevin Oberman

Post by Robert Huff
One possibility: I believe I labeled each of the partitions during
the gpt creation process. Can I use those labels to (hopefully) by-pass
this issue?

Yes! This is the current recommended way of doing it.

Post by Robert Huff
cat /etc/fstab

# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/swap none swap sw 0 0
/dev/gpt/root / ufs rw 1 1
/dev/gpt/tmp /tmp ufs rw 2 2
/dev/gpt/usr /usr ufs rw 2 2
/dev/gpt/var /var ufs rw 2 2

To avoid collisions, I recommend people use unique labels on each
system. I sometimes pick a couple of letters from the system name or
drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs.

[Kevin Oberman]

Post by Kevin Oberman

Post by Robert Huff
One possibility: I believe I labeled each of the partitions during
the gpt creation process. Can I use those labels to (hopefully) by-pass
this issue?

Yes! This is the current recommended way of doing it.

Post by Robert Huff
cat /etc/fstab

# Device Mountpoint FStype Options Dump
Pass#
/dev/gpt/swap none swap sw 0 0
/dev/gpt/root / ufs rw 1 1
/dev/gpt/tmp /tmp ufs rw 2 2
/dev/gpt/usr /usr ufs rw 2 2
/dev/gpt/var /var ufs rw 2 2

To avoid collisions, I recommend people use unique labels on each system. I
sometimes pick a couple of letters from the system name or drive: xfswap,
xfrootfs, xftmpfs, xfusrfs, xfvarfs.

Good point (as usual).

The example was from my laptop where this is not an issue, but in
larger environments it is an excellent suggestion.

I would put the unique ID at the end of the label as the eye tends to
read from left to right (at least in most language so you can
recognize whether it is usr or swap or home pretty much instantly.
Sticking letters at the start make the most fundamental information
harder to see.
swaprxf xfswap
usrfsxf xfusrfs

Still, this is a nit and I appreciate the suggestion!..