to recover its space into the previous partition. Revert 'D'elete
to not attempt to recover any space.
Do not auto-create /home as per release engineers decision (though
I think this is a mistake). However, all of this code will be
replaced later on anyway either with Jordan's stuff or with
some other sort of templater, so it isn't a big deal.
The user can still toggle it back off in the label editor (or post-install
for that matter) if they explicitly do not want soft updates to be used
for some reason.
Agreed to be a good thing by: kirk
sysinstall will automatically expand the previous partition to take up
the freed up space. So you can 'D'elete /home and /usr will get the
combined space, or you can 'D'elete /tmp and /var will get the combined space.
This gives the user, developer, or lay person a huge amount of flexibility
in constructing partitions from an 'A'uto base. It takes only 3 or 4
keystrokes to achieve virtually any combination of having or not having
a /tmp and/or /home after doing an 'A'uto create.
Change 'A'uto creation of /var/tmp to 'A'uto creation /tmp, which should
be less controversial.
MFC after: 6 days
defaults both in regards to the size of the partitions that are created
and in regards to safety and functional separation.
Still TODO: extend the previous partition to cover a deleted partition
if the previous partiton was auto-created, and supply some sort of
solution for /tmp.
Reviewed by: Just about everyone
Approved by: Nobody except maybe my pet mouse fred
Obtained from: God, so complain to HIM
MFC after: 1 week
Eliminate an old warning brought about by insufficient foresight when creating
the Menu structure. Have I ever mentioned that sysinstall really needs to
be rewritten?
a few cosmetic problems:
o Allow it to work with scripts (see man page or install.cfg file).
o Preserve old softupdates flag across newfs toggles
o Clean up partitioned/labelled flag handling
o Don't ask for MBR choice again if you've already written it out.
o Actually document the new features.
no as a default. Sysinstall should be both less dangerous and less
annoying as a result of this change, though that's just my opinion
(since they're the defaults which annoy ME the least :).
on locale.
o Allow use of "G" in label editor to stand for gigabytes. This
is actually an unrelated patch which I meant to commit separately
but what the heck, it's late.
Partially submitted by: phk
as redoing all the menus to have proper, or at least non-hallucinogenic,
keyboard accelerators.
This requires my recent update to libdialog to work properly and will
probably also exhibit some other "interesting" behavior while the last
few missing screen clears are found (which is why I'm not going to MFC
immediately). At least now, however, sysinstall does not gratuitously
redraw random screens at the drop of a hat and drive serial console
installers out of their minds.
Now we know which variables are internal and which need to be
backed to /etc/rc.conf.site. rc.conf is not touched now.
Also kget kernel change information back properly and set up a loader.rc
file to use it.
Now you can use one without entering the other and it will DTRT.
These changes just allowed me to do the most straight-forward new disk
installation I've ever managed with sysinstall.
lots of disks from sysinstall. Yay! Please test this as much as
possible with any 3.0 SNAP later than 970910 (I.E. tomorrow's snap),
especially those of you with larger disk farms.
Submitted by: Ed Gold <vegold01@starbase.spd.louisville.edu>
so you don't need to re-enter it for each and every filesystem. Heads up!
This change is incompatible with the previous scripting format,
so those folks (all 2 of you) using config files should take a look
at the changes to the sample install.cfg file for the diskLabelEditor's
new calling syntax.
Finally write a man page for this thing, documenting all of the above
and more. I can't drive a stake through this thing's heart without
properly documenting it first, so please consider this step #1 in that
process (to be honest, sysinstall will also live on for some time in
the 2.2. branch since it's unlikely that the new install tools will ever
make it over there - they're strictly 3.0 material).
