WITH_SYSCONS is defined.
- Only define mouse menus and mouse menu items if WITH_MICE is defined.
- Use WITH_SLICES instead of explicit lists of architectures to control
the layout of menus dependent on if slices are used on this arch or not.
- Only include the linux startup option if WITH_LINUX is defined.
- Only include the SVR4 startup option on i386. It doesn't work on sparc64,
and it is debatable that it even works on i386.
- Change the OSF1 startup option to execute configOSF1() instead of just
setting the variable so that /compat/osf1 gets created.
Tested on: i386, alpha, sparc64
Approved by: re
fdisk editor if WITH_SLICES. Before this on arch's that didn't support
slices such as alpha and sparc64 you would drop into the fdisk editor after
doing an Undo in the label editor.
Approved by: re
of an explicit list of architecture defines.
- Tweak the message prior to the label editor in the !WITH_SLICES case to
make it slightly less awkward since this is the first dialog we see after
starting an install.
- Only offer to customize syscons settings if WITH_SYSCONS.
- Offer to enable Linux compat if WITH_LINUX. Before we only did this for
i386.
- On the alpha, offer to enable OSF/1 compat after asking about Linux
compat.
- Only offer to configure moused(8) if WITH_MICE is defined.
Tested on: i386, alpha, sparc64
Approved by: re
and more maintainable.
- WITH_SYSCONS: defined on all arch's that support syscons (currently i386,
alpha, and ia64)
- WITH_MICE: defined on all arch's that support moused(8) (currently i386,
alpha, and ia64)
- WITH_SLICES: defined on all arch's that use disk slices (currently i386
and ia64)
- WITH_LINUX: defined on all arch's that support Linux binary compat
(currently i386 and alpha)
Approved by: re
the two GNOME 1-based alternatives.
While here, note that a majority of the items in this menu are not
sentences, and remove trailing dots to make the remainder consistent.
Reviewed by: marcus
Approved by: re (bmah)
of the EFI file system. This makes the EFI partition non-optional.
I don't think that the links are actually correct, given that all
the mount points are under /mnt when sysinstall is run as init.
(ie a non-upgrade). Thus: I think I need to go in once more, but
at least this doesn't get lost...
partitions marked as being of type efi. This change adds code to
1. actually run the newfs command at mount time (install.c),
2. display the newfs state on screen (label.c)
3. allow toggling of the newfs state (label.c)
Even though newfs(8)-ing FAT partitions can be of use on i386
machines in general, it has been opted to minimize impact for
now.
With this change there's no a priori difference between EFI and
FAT partitions. With this change and the corresponding change to
libdisk, we can create EFI partitions, just like regular FAT
partitions.
the loop that runs through the environment variables to be a bit more
intuitive. Also, change some 'continue's in failure cases to 'break's
instead. If we are going to fail, we should just do it.
PR: bin/40654
Submitted by: Thomas Zenker <thz@Lennartz-electronic.de> (partially)
argument as of revision 1.52 (July 12, 1996, about a month after I
graduated from high school) when 'newfs -u' support was axed, so remove it.
This also allows us to remove a hack in the create partition case where we
created the partition twice since we didn't have the size the first time.
- Disabled 'Syscons, Font', 'Syscons, Screenmap' and 'Syscons, Ttys' menus
on pc98.
- Fixed the MenuMouseType and MenuMousePort menus for pc98.
- Fixed some comments for pc98.
something applies to. So change #ifndef to an explicit list of defines.
* Treate sparc64 and ia64 as 64-bit platforms, which means larger roots.
* sparc64 should halt back to the firmware, not reset.
* sparc64 doesn't need to play MS-DOS/BIOS partition crap games.
Reviewed by: jake
one can set the 'noError' variable to ignore any errors that occur for the
next command. However, the code was only unsetting 'noError' when an error
actually occurred, so if you set 'noError', the next command completed ok,
and the command after that failed, the second command's failure would be
ignored. This fixes this by performing the 'noError' check earlier and
then unsetting 'noError' after every command that is run.
Sponsored by: The Weather Channel
Also add the ability to use Bzip'ed distributions -- but this is exclusive
of being able to use Gzip'ed distributions.
Sponsored by: FreeBSD Mall, Inc.
so know we have proper PKG registration and dependency information.
This is a WIP for 5.0 DP #1, so it is still rough around the edges and
does not GC the old XFree86 3.3.6 handling stuff that should be GC'ed.
Sponsored by: FreeBSD Mall, Inc.
from CD-ROM in 4-stable. Note that in 5-current, we use devfs so this
change (hopefully) shouldn't change anything.
I'll MFC to 4-stable later.
Tested with: FreeBSD/i386, 4.5-STABLE-20020330-JPSNAP
While I'm here, make the menu entries on the documentation menu begin
with "1" instead of "2".
Reviewed by: imp, rwatson, murray
Approved by: imp, rwatson, murray
MFC after: 1 week
installed ones under /boot (which we may not even have in the
case of a cross build).
This introduced chicken and egg problem - we need boot images
early in the "depend" stage but they have not yet been built.
Work around this by excluding the generated makeboot.c source
from the "depend" list; it's okay because we hardcode all its
dependencies explicitly. We actually lose the dependency bit
on <sys/types.h> but it's probably okay too as the only thing
we use is the u_char datatype and this is unlikely to change.
After all, it's normal for sloppy cleaning to cause problems.
beast.FreeBSD.org running 5.0-CURRENT alpha has been able to
cross build i386 world with this patch.
Prodded by: gallatin
all facilities that previously relied on /proc have been rewritten
to use ptrace(). procfs has presented a substantial security
hazard for years, with several user->root compromises in the last
few years. Procfs will continue to be available but will require
administrator intervention to use.
Reviewed by: scottl, jedgar, mike, tmm
block sizees larger than 8192 bytes have been resolved, as per the
following deltas:
rev 1.34 src/sys/boot/i386/boot2/boot2.c
rev 1.5 src/sys/boot/alpha/boot1/sys.c
filesystem using a block size of 8192. Since this seems unlikely to
be fixed soon (specifically in time for 4.5-RELEASE on the RELENG_4
branch), fall back to the old default block and frag sizes of 8192 and
1024 in sysinstall on the alpha.
Reported by: jhb
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.
o Move nfs_reserved_port_only out of security profiles (where it was
set somewhat improperly) to the Security options menu directly.
Previously, the variable was set to true for Moderate, but not for
Extreme, which is at best inconsistent.
o Update the Security Profiles help file to remove reference to the
NFS reserved port.
o Note that the kernel currently defaults the sysctl to '0', but
sysinstall has changed it to '1' as a default as of late; however,
rc.conf sets the value to NO as the default. This change brings
them relatively into sync.
Sponsored by: DARPA, NAI Labs
and pull configSecurityProfile under that menu. Add a menu option
to determine whether LOMAC is enabled at boot. Probably, eventually,
many of the 'Security Profile' menu choices should be pulled out
independently into the Security Menu, so as to make them individually
selectable.
Sponsored by: DARPA, NAI Labs
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
16384/2048.
Following recent discussions on the -arch mailing list, involving dillon
and mckusick, this change parallels the one made over a decade ago when
the default was bumped up from 4096/512.
This should provide significant performance improvements for most
folks, less significant performance losses for a few folks and
wasted space lost to large fragments for many folks.
For discussion, please see the following thread in the -arch archive:
Subject: Using a larger block size on large filesystems
The discussion ceases to be relevant when the issue of partitioning
schemes is raised.
have a USB mouse. Here's the deal on how this works: USB mouse have
moused run for them automatically by usbd so we don't need to setup moused
for them. We do need to setup moused for other mice though, so if the
user has a USB mouse, we don't need to do anything. Hence the wording
"Do you have a non-USB mouse installed?" for the question. The question
can be reworded as "Do you have a PS/2 or Serial mouse installed?" instead
if that is preferred.
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
1) Use devfs to mount filesystems. If mounting devfs is fail,
fallback to old code.
2) When fscking filesystems, use 'fsck_ffs' explicitly. As a
result, we no longer need 'fsck' the wrapper program.
Reviewed by: jkh
Since userconfig feature is implemented by tweaking variables (hint.*)
with loader(8), we can put back an equivalent feature. Maybe the first
step for this is to commit yokota-san's patch (add userconfig command
for loader).
Approved by: jkh
ethernet controllers. This adds support for the 3Com 3c996-T, the
SysKonnect SK-9D21 and SK-9D41, and the built-in gigE NICs on
Dell PowerEdge 2550 servers. The latter configuration hauls ass:
preliminary measurements show TCP speeds of over 900Mbps using
only normal size frames.
TCP/IP checksum offload, jumbo frames and VLAN tag insertion/stripping
are supported, as well as interrupt moderation.
Still need to fix autonegotiation support for 1000baseSX NICs, but
beyond that, driver is pretty solid.
survive a sysinstall Ctrl-C -> 'Restart'. This fixes another annoying
bug where restarting sysinstall will try to reload kernel modules and
do other external things that have already been done. For now, use
these persistent variables to keep track of module, usbd, and pccardd
initialization.
Bug found by: rwatson
MFC after: 1 week
environment. This fixes an annoying bug where hitting Ctrl-C and
telling sysinstall to 'restart' will do no such thing since many of
the options are still set and so you won't be prompted for them
again.
MFC after: 1 week
variable to check for debug functionality. Previously, you had to set
both 'debug' and 'SYSINSTALL_DEBUG' to get a log of sysinstall's
activities. Now, only 'debug' is necessary.
useful for post install configuration or other cases that might not be
handled by usb.c. (usb.c already sets usbd_enable iff sysinstall
detects usb during install).
PR: bin/18946
Submitted by: Peter van Heusden <pvh@egenetics.com>
Reviewed by: jhb
and RTSOL in sysinstall. If the respective TRY_FOO variable is set to
"YES" then it will be tried without prompting the user.
However, if the TRY_FOO variable is set to "NO" then the user will not
be prompted for a choice. This is the correct behavior, since we want
people to be able to script sysinstall in either case.
However, the default TRY_FOO variable has been "NO" since 1999. This
is incorrect, and when the logic was corrected in tcpip.c this has the
effect of never giving the user a choice to use DHCP or IPv6. The
value should be undefined until it is set by a script or by the user.
Submitted by: Randy Pratt, Chern Lee, many others.
post-configuration "Startup" menu. In the event that diskcheckd is
removed, this can easily be trimmed also; in the mean time, it allows
diskcheckd to be easily disabled using our documented management
tool
the name for the moderate security profile is "moderate", not
"medium", so update this one reference to it as "medium".
This is a 4.4-RELEASE MFC candidate.
MFC after: 2 days
Add a timestamp to the comment so that it's possible to see when
changes were made.
e.g.:
# -- sysinstall generated deltas -- # Wed Aug 15 18:10:20 2001
conservative default, and actually prompt specifically for inetd rather
than handling it as a side effect of the security profile. Update the
help file to reflect this change.
o Rename "Fascist" to "Extreme" in the source code, to match the names
presented to the user.
o Remove portmap and inetd from profile management. Portmap is now
disabled by default, but automatically turned on if a feature requires
it (such as NFS, etc).
This is an MFC candidate for 4.4-RELEASE.
Reviewed by: freebsd-arch@FreeBSD.org
Approved by: re@FreeBSD.org
MFC after: 2 days
post-install config, reduce the potential confusion from the existence
of both configTTYs and configTtys by renaming configTTYs to
configEtcTtys. While this is not a C naming conflict, it was probably
a poor choice of names on my part.
system installation process. This allows users installing via serial
console to enable serial console login during the installation
process using an un-customized install. The user is not prompted to
modify /etc/ttys during a normal install, but is offered the
opportunity during post-install configuration.
- Introduce configTTYs(), which describes the benefits of editing
/etc/ttys, and asks for confirmation before spawning the editor.
- add configTTYs to the post-install configuration, as well as to
the global configuration index.
by providing the opportunity to edit inetd.conf during the system
installation process. The following modifications were made:
(1) Expand the Anonymous FTP description dialog to indicate that inetd
and ftpd must be enabled before it can be used.
(2) Introduce a new configInetd() pair of dialogs, the first describing
inetd, giving a couple of examples of services that require it, and
hinting at potential risk, then asking the user if they wish to
enable it. The second indicates that inetd.conf must be configured
to enabled specific services, and asks if the user would like to
load inetd.conf into the editor to modify it. Add this
configuration action to the index.
There are some further improvements that might be considered:
(1) Provide a more inetd.conf-specific configuration tool that speaks
inetd.conf(5). However, this is made difficult by the "yet another
configuration format" nature of inetd.conf, as well as its use of
commenting to disable services, rather than an in-syntax way to
disable a service without commenting it out. Submissions here
would probably be welcome.
(2) There's some overlap between settings in the somewhat obtuse
Security Profile mechanism and other settings, including the inetd
setting, and NFS server configuration. As features become
individually tunable, they should probably be removed from the
security profile mechanism. Otherwise, somewhat counter-intuitively,
sysinstall (in practice) queries multiple times whether inetd, nfsd,
etc, should be enabled/disabled. A possible future direction might
be to drive profiles not by degree of paranoia, rather, the set
of services desired. Or simply to remove the Security Profile
mechanism and resort to feature-driven configuration.
Reviewed by: imp, chris, jake, nate, -arch, -stable
blown over by the Hurricane and had a house dropped on you by the Tornado.
Now it's time to have your parade rained on by... the Typhoon!
This commit adds driver support for 3Com 3cR990 10/100 ethernet
adapters based on the Typhoon I and Typhoon II chipsets. This is actually
a port of the OpenBSD driver with many hacks by me.
No Virginia, there isn't any support for the hardware crypto yet. However
there is support for TCP/IP checksum offload and VLANs.
Special thanks go to Jason Wright, Aaron Campbell and Theo de Raadt for
squeezing enough info out of 3Com to get this written, and for doing
most of the hard work.
Manual page is included. Compiled as a module and included in GENERIC.
names suggest, they perform methods on Device's. In addition, they
check that the pointer passed to them is valid; if it isn't, they
pretend that the action failed. This fixes some crashes due to NULL
dereferences (e.g., PR 26509).
Approved by: jkh (some time ago)
/usr/share/syscons/keymaps. This should prevent word breakage when new keymaps
have been added.
Prompted by: Matthew D. Fuller <fullermd@over-yonder.net>
and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000
copper PHY. There are a whole bunch of very low cost cards available with
this chipset selling for $150USD or less. This includes the SMC9462TX,
D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards
from Addtron.
This chip supports TCP/IP checksum offload, VLAN tagging/insertion.
2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs.
I have not done serious performance testing with this driver. I know
it works, and I want it under CVS control so I can keep tabs on it.
Note that there's no serious mutex stuff in here yet either: I need
to talk more with jhb to figure out the right way to do this. That
said, I don't think there will be any problems.
This driver should also work on the alpha. It's not turned on in
GENERIC.
/usr/src/usr.sbin/sysinstall/menus.c:1323: initializer element is not computable at load time
/usr/src/usr.sbin/sysinstall/menus.c:1323: (near initialization for `MenuNetworking.items[9].aux')
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?
1. Has a time-stamp to show when it was created
2. Sorts and uniq's the output to only contain single instances of a
given setting. This doesn't mean you still can't have settings which
override one another, that's still possible since it's too much
trouble to do the redundancy checking here.
Requested by: lots of people
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.
and also obey most of the rules of english in their construction.
Add a help screen for the security menu which gives the user a rough idea
just what the various security profiles do.
need to manually force the network_interfaces variable in /etc/rc.conf,
and it only ever gets in the way. rc.network and rc.network6 DTRT with
the default of 'auto'. This should have died over a year ago.
not right because rtermcap would be reading the *host* termcap, not
from the termcap in the src tree. Besides, /usr/sbin/sysinstall
(not the crunched one in /stand) should use the runtime termcap
not the precompiled set.
static version that installs in /stand. Also, don't use an extra
before-install target to create /stand.
- Add missing $FreeBSD$.
- Fix dependencies to handle keymap.h. (*)
Submitted by: obrien (*)
non-advertised option (F = "FreeBSD only"), and leave the A key with
standard partitioning. It seems people still want a runtime backdoo
to get to dangerously dedicated mode.
at people. This has been sitting in my tree for a few months now. I
have spoken with quite a few folks about this and the support for doing
this was pretty strong. I dont remember names though, so I cannot share
the blame :-(. Note that this does not *remove* DD mode, it just stops
waving it at new users. You can still set it via config files etc, and
the bootblocks and kernel still support it. You can still use disklabel
to make true DD disks.
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 :).
