Date: Fri, 31 Aug 2012 11:26:17 -0700 From: David Wolfskill <david@catwhisker.org> To: freebsd-stable <freebsd-stable@freebsd.org> Subject: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] Message-ID: <20120831182617.GC2990@albert.catwhisker.org> In-Reply-To: <1345697446.84337.11.camel@neo.cse.buffalo.edu> References: <1345697446.84337.11.camel@neo.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--yLVHuoLXiP9kZBkt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I had occasion yesterday to install FreeBSD on a machine (an HP Compaq
dx7200 Slim Tower) that had never (AFAIK) had FreeBSD installed on it.
Since I don't often use the installer, I thought it might be good to try
the 9.1-RC1 installer.
While the exercise was ultimately successful, I needed to make use of
additional hardware (including a second FreeBSD machine -- my laptop) to
complete it. Had I been trying to install with just the target machine
and the USB drive (memstick), as far as I can tell, I would have ended
up with a brick.
I like to set up machines with a minimum of 3 slices -- e.g.:
albert(8.3-S)[2] df -ht ufs
Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s1a 1.5G 363M 1G 27% /
/dev/ad4s1d 3.4G 378M 2.8G 12% /usr
/dev/ad4s3d 7.8G 3.9G 3.3G 54% /var
/dev/ad4s3e 96G 45G 42G 52% /common
albert(8.3-S)[3]=20
While that only shows 2 of the slices, slice 2 is set up like slice 1
is; an excerpt from fstab:
albert(8.3-S)[3] grep ufs /etc/fstab
/dev/ad4s1a / ufs rw 1 1
/dev/ad4s1d /usr ufs ro 2 2
/dev/ad4s2a /S2 ufs rw,noauto 2 2
/dev/ad4s2d /S2/usr ufs rw,noauto 2 2
/dev/ad4s3d /var ufs rw 2 2
/dev/ad4s3e /common ufs rw 2 2
albert(8.3-S)[4]=20
When I am about to upgrade such a machine -- albert, there, generally
gets updated weekly -- I "clone" the / and /usr file systems from
the currently-booted slice to the other one, reboot from the copy, and
upgrade it in place. If I have a problem, I can boot from the slice that
it had been booted from before I started the upgrade, lick my wounds,
and figure out what to do next. (Granted, it's very rare that I need to
do that -- but I very much like having the ability to do so.)
Accordingly, when I was to install 9.1-RC1 on the HPaq, the first slient
(to the above) thing I recall noticing was that the installer was
referring to "partitions" (in the context of reserving space for "other
Operating Systems") which confused me a great deal: I thought those were
"slices".
It was fairly obvious (even to me) that the "automatic" option wouldn't
suit my purposes; after a false start, I managed to use the Manual
approach & set up the 3 slices; here's what "gpart show" says about it
(now that it works):
=3D> 63 156249937 ada0 MBR (74G)
63 20971503 1 freebsd [active] (10G)
20971566 20971503 2 freebsd (10G)
41943069 113246154 3 freebsd (54G)
155189223 1060777 - free - (518M)
=3D> 0 20971503 ada0s1 BSD (10G)
0 4194304 1 freebsd-ufs (2.0G)
4194304 16777198 2 freebsd-ufs (8G)
20971502 1 - free - (512B)
=3D> 0 20971503 ada0s2 BSD (10G)
0 4194304 1 freebsd-ufs (2.0G)
4194304 16777198 2 freebsd-ufs (8G)
20971502 1 - free - (512B)
=3D> 0 113246154 ada0s3 BSD (54G)
0 12582912 1 freebsd-swap (6.0G)
12582912 41943040 2 freebsd-ufs (20G)
54525952 58720201 4 freebsd-ufs (28G)
113246153 1 - free - (512B)
The first fairly major problem occurred once the installation was
complete: I rebooted the system... or tried to. It wouldn't boot, and I
couldn't even get the machine to go into BIOS "setup" mode (still can't,
for that matter).
I pulled the disk drive, then connected it to my laptop via one of
those UCB <=3D> SATA adaptors; "gpart show" showed that slice 3 (ada0s3)
was marked "active".
Oops.
I don't recall a point during the install where I had a chance to
actually mention which slice I might want active. And absent other
clues, I would have expected the slice that contained the file system
that was to be mounted on / to get that honor.
So using my laptop, I set slice 1 (ada0s1) as "active", then replaced
the drive and tried again.
No go.
It seems that the boot0 code wasn't written to the disk, either.
So I re-attached the drive to my laptop & ran "boot0cfg" to set to boot
code -- and, while I was there, told the MBR that slice 1 would be a good
place from which to boot.
That finally worked.
I was, however, a bit surprised to find that my script to accomplish the
"cloning" didn't work without some ... exercise: it uses a "dump |
restore" pipeline to read the (mounted) / and /usr & restore them (after
newfs, of course) on the target slice. Well, dump wants to make a
snapshot if it's reading from a FS mounted read/write, and that's
apparently not (currently?) compatible with SU+J, which is the default
that the installer used. (I was subsequently able to manually disable
the journaling, clone the slice, and re-enable the journaling. A
subsequent test verified that I could then boot from either slice 1 or
slice 2, and that I could control this by running a script before
rebooting.)
So I got there, though I did encounter a bit of turbulence. :-}
Peace,
david
--=20
David H. Wolfskill david@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
--yLVHuoLXiP9kZBkt
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlBBAcgACgkQmprOCmdXAD0tKgCePvgN12PUXi4OG78K4PZyuGRK
8usAoIP3K+F13EF4M/ZYSPg2BhbuwyQf
=aPA4
-----END PGP SIGNATURE-----
--yLVHuoLXiP9kZBkt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120831182617.GC2990>