Jan Stary wrote:
> Hi all,
>
> this is a diff to faq4.html (the install faq) so that it mentions
> /altroot for the installing user before he partitions his drive. Now,
> the altroot feature is described in daily(8), which you only read when
> you already have a system installed, your disk is already partitioned,
> and typically you don't have the spare partition (of size at least that
> of /) to use for /altroot.
what benefit do you see in having /altroot on the same disk as / ?
> The current partitioning example uses a 20G disk with a pre-existing
> 1.5G windows partition. In the diff I use a 80G disk with a pre-existing
> 6G windows partition. I believe these are more realistic numbers
> nowadays (also, I don't have a 20G disk around :-). The 6G figure is
> used to stay below 8G, which INSTALL.i386 mentions as possible BIOS
> limit. I suppose the current example uses a 1.5G win partition to stay
> below 2G (which might be a BIOS limit on even older hardware) - is it so?
eh, kinda. The bigger reason was I wanted most of the disk for OpenBSD,
and only wanted the 1.5G as a token Windows partition for the sake of
example. You see, at the time I wrote this and committed this disk and
this computer to OpenBSD, it was a pretty cool system. PII-450, 20G
disk, physically tiny machine, relatively low power consumption. Highly
desirable. Still, for all that space, the idea of wasting any of it on a
Windows partition that would never be used was completely uninteresting.
Yes, five years after the machine was devoted to OpenBSD (and in fact,
this article in the FAQ), it's pretty unexciting, I'll grant you.
> Is using a larger disk in the example a problem? Using a 20G disk makes
> the point of showing how usable the system is even on a small disk, but
> 20G disks don't really exist anymore.
Bullshit.
No functional 10G drive that passes past me hits a trash can.
No functional 4G narrow SCSI drive that passes me hits a trash can
either.
(1G drives are starting to get a bit nervous around here, however)
There are a lot of people who do their first installs (which is what
the FAQ is pointed at) on very minimal hardware. 20G is actually much
bigger than many people still use, and loads bigger than many non-i386/
amd64 systems usually have on them.
So, no, the 80g change is just showing off. No way. At least, not
until someone floods me with 80G, 120G, 250G and bigger drives enough
that I think everyone must have big disks. :)
> Also, some disklabel messages and the output of disklabel's 'p' command
> have changed (either that, or the current faq which shows sizes in
> sectors as an output of 'p m' is mistaken).
>
> Jan
>
>
> PS: As this is a small diff, I edited (my copy of) faq4.html manually;
> but if I was to write up something bigger - is there some script(1)-like
> log of the whole installation, or can I create one? Drop into shell at
> the very beginning, and run 'install' inside script(1), or pipe it
> through tee, neither of which exists in bsd.rd? Or do something just
> before halt-and-reboot? Thanks.
I do the install for faq4.html every release with a serial cable attached,
and tip(1) running inside script(1).
argh. I don't suppose you noticed that OpenBSD developers only use
diff -u, right? Or actually looked at the output to see why?
(add to that that Thunderbird is a brain-dead piece of shit when it
comes to handling diffs in general and classic diffs even more so.
Apparently, either Thunderbird devs aren't programmers or they never
show their diffs to each other.)
Anyway...
* your diff makes gratuitous and pointless changes.
* Those changes will be a pain in the butt for me to maintain, as I
don't have your machine.
* It doesn't say a word about the point of the diff (/altroot),
just silently adds a partition to the install without explanation.
* It puts the /altroot partition in a nearly pointless place.
* 40G home? Only if I had a deliberate plan for why I needed that
much. Of the dozens of machines I have around here, the only one
that has a /home that big is my NFS server...
I may sound overly critical, but let me say in no uncertain terms:
you had an idea, you implemented it. That puts you *above* 95% of
the rest of the people who "help" around here. So for that I commend
you. So, while my response may not be overly positive sounding, it
is worth my time, I think, to tell you in some detail why. So, take
it as constructive criticism (or constructive "no way" :)
An /altroot discussion in the FAQ would be appropriate, but it would
not be handled anything like this. It wouldn't be a change to the
install example, it would be in section 4.7, and possibly in a RAID
discussion somewhere in faq14.html.
/altroot is very cool, but like RAID, it does what it does, not what
people dream of it doing. I don't think it is in any way an
"automatic" thing that all users should be doing. I suspect you are
thinking it will help you if you blow out your 'a' partition.
However, the boot system won't "automatically" boot a system off
a "same disk" /altroot, and booting from it would require manual
work. About the only thing it can do for you if you have only
one disk is give you a less-than-a-day-old copy of your config files
should you do something you regret and catch it soon enough. If this
is your concern, a better idea would be to tar(1) up your /etc and
maybe /var files, and stick them in a dated file name, and put them
in a partition that is only mounted for the backup process. Doing
this, you can get probably a few MONTHS of past configs for a firewall
or DNS server in a partition the size you made for /altroot.
Where altroot comes in handy is when you have a pair of disks in an
already redundant machine (i.e., firewall or DNS server). I did this
for some systems:
wd0: 6G
wd1: 20G or 40G
wd1 had the same partition layout as wd0, 'cept it also had a big
partition mounted as /bkup.
Every night, /etc/daily duped / to /altroot (on wd1), and
/etc/daily.local made a dated .tgz file of everything in /var and /etc
and put it in /bkup. /etc/weekly.local used dump or rsync to copy
the rest of the partitions from wd0 to wd1. If wd1 blows out, there
is a copy of all the backup files on the other machine in the set
anyway, no big deal. If wd0 fails, wd1 can take over at pretty much
any time after a disconnect of the failed drive and a reboot.
Cheap and easy "mirroring". This system looked like it could hold a
decade or two of configuration history on those non-existant drives.
/altroot is also good for software mirroring systems as a way to
keep your second drive fully bootable.
One problem I have is every time I sit down to write something about
this, it decays into a general study of "good system design" rather
than OpenBSD documentation. :)
Again, worth repeating, you had an idea, and you followed it
through. I didn't like the implementation, but the idea (documenting
/altroot) isn't bad. Feel free to try again (I probably won't have a
chance to do it for a while myself. Think of section 4.7, under
"additional thoughts", maybe starting with, "If you have a second
disk, you can ...")
Nick.
