some confusion as to how large the EFI system partition should be,
but 100MB seems to be either the maximum, the minimum or the default
size, so make the EFI partition 100MB.
global variables. On ia64, save a pointer to the efi chunk as well.
o At the same time, change checkLabels() to define these globals instead
of having the caller of checkLabels() pass addresses to variables for
these. Change the two callers correspondingly.
o Spent a bit more time adjusting try_auto_label() to prepate for having
the EFI partition created on ia64.
o Remove efi_mountpoint(). The EFI chunk is now available without having
to iterate over the disks and chunks to find it every time we need it.
o On ia64, now that the root chunk is globally available, set the
vfs.root.mountfrom tunable in loader.conf. This avoids that one cannot
boot into FreeBSD after an install. The kernel cannot find the root
device without a little help...
of releases. The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.
Approved by: re (scottl), markm
Discussed on: freebsd-current, in late April 2004
o Remove the code that creates the boot directory on the EFI file
system after it has been mounted, as well as remove the code
that creates the symlink from /boot -> /efi/boot (*). As a result,
/boot will be extracted onto the root file system.
o Add a function efi_mountpoint() that returns the mount point of
the EFI file system or NULL if no EFI partition is created. This
function is used to both check whether there's an EFI file system
and to return what its mount point is.
o When there's no EFI file system, ask the user if this is what he
or she wants. Since we extract /boot onto the root file system,
we do not actually need an EFI file system for the installation to
work. Whether one wants to install without an EFI partition is
of course an entirely different question. We allow it...
o When we're done installing and need to fix up the various bits
and pieces, check if there's an EFI partition and if yes, move
/boot to /efi/boot and create a symlink /boot -> /efi/boot (*).
This is a much more reliable way to get /boot onto the EFI
partition than creating the symlink up front and hope its being
respected. It so happened that we never had the boot directory
end up on the EFI partition. We make the symlink relative.
(*) /efi is a place holder for the actual EFI mount point of course.
we'll actually create an EFI partition with a FAT file system instead
of an UFS file system. It also allows us to give a sensible default
mount point for EFI partitions so that people don't have to guess.
This also means that we can now remove new_efi_part(), which did the
same thing as new_part(), except it created a FAT file system. The
function wasn't called when the EFI partition was created from scratch
though, which was the problem. By passing the partition type to the
various functions, we can deal with EFI without having to duplicate
code.
that actually need it. This makes it easier for a platform porter to
find the files that may need tweaking to support whatever MD specific
partitioning is needed. It also helps to prevent that the libdisk API
gets exposed and/or used where it's not needed.
installation as far as most people are concerned but both 'Standard' and
'Select' begin with S and 'Select' is winning. This makes it so 'Select'
is not select-able using a keystroke but that is probably for the best
and the text on the screen adequately describes how to move back and forth
between 'Select' and 'Exit'.
Adapted from work by: josef@
PR: i386/37999
MFC after: 1 week
- Don't look for partitions inside a FreeBSD chunk on ia64 when mounting
the filesystems just before the chroot and install.
- Write entries out to /etc/fstab for filesystems that aren't inside a
FreeBSD chunk, but are a top-level chunk under the disk.
addresses. For arch's with 64-bit longs, this is a nop, but for i386 this
allows sysinstall to properly handle disks and filesystems > 1 TB.
Changes from the original patch include:
- Use d_addr_t rather than inventing a blkcnt type based on int64_t.
- Use strtoimax() rather than strtoull() to parse d_addr_t's from config
files.
- Use intmax_t casts and %jd rather than %llu to printf d_addr_t values.
Tested on: i386
Tested by: kuriyama
Submitted by: julian
MFC after: 1 month
/libexec to /mnt2/libexec, and execute /mnt2/rescue/ldconfig to add
the /mnt2/lib and /mnt2/usr/lib library directories. Thanks to John Baldwin
for working to track this down.
Submitted by: jhb
(Lite Edition) respectively. These "lite" packages are streamlined to
provide users with the core essentials for each desktop and to fit on the
release disc 1.
Approved by: re (scottl)
permitting the administrator to select a securelevel top operate
at. Include a helpfile summarizing some of the information from
init(8). This allows for explicit configuration of securelevels,
which was previously implicit in Security Profile selection.
Currently, there are no checkboxes for the active securelevel,
because sysinstall's facilities for deriving "current settings"
from rc.conf may use only one variable, not two, and I opted for
the simplest approach at this point.
Approved by: re (scottl)
selection is used to drive two configuration parameters:
(1) Default enable/disable for sshd
(2) Default enable/disable for securelevels
Replace this with an explicit choice to enable/disable sshd. A
follow-up commit will add a configuration option to the Security
post-install configuration menu to set the securelevel in rc.conf
explicitly. This should reduce the level of foot-shooting associated
with accidental enabling of securelevels, make the nature and
implications of the securelevel configuration options more explicit,
as well as make the choice to enable/disable sshd more explicit.
Approved by: re (scottl)
a partition size on ia64. It's not true.
o Ask for a mountpoint for EFI partitions as well and check that it
isn't "/".
o On ia64 we may need to add EFI partitions. Make sure we pass the
right arguments to Create_Chunk_DWIM() in that case.
to better deal with the fact that we need an EFI partition and
that we need to have a mountpoint for it.
o When creating a new partition, add EFI to the list of types
the user can select from. This makes it easy to create an EFI.
o Do not include wizard.c on ia64.
o The user cannot create a partition on ia64 that's a multiple of
the cylinder size. We don't have a notion of cyclinders.
o Also allow swap and filesystem partitions outside a freebsd slice.
This is typically the case for GPT.
o Allow chunks of type "whole" to be displayed at the top. This is
to allow a GPT disk to be labeled. We need a slice out of which we
can make partitions, but a GPT disk doesn't have slices. For GPT
disks a chunk of type "whole" can then be used as a placeholder.
(1) Don't modify the configuration of the NFS server as a result of
selecting a profile. We already explicitly prompt for the NFS
server configuration during install, and the user may not get
much advance notice that we're turning it off again. Instead,
use profiles (for better or for worse) only for security tuning.
(2) Don't modify the sendmail setting as part of the security profile:
use the default from /etc/defaults/rc.conf rather than explicitly
specifying. Note that the default in /etc/defaults/rc.conf is
more conservative than the explicit rc.conf entry added by
sysinstall during install, as it does not permit SMTP delivery.
(3) Update "congratulations on your profile" text to reflect these
changes.
Note that security profiles now affect only the securelevel and sshd
settings. My leaning would be to make sshd an explicit configuration
option, move securelevels to the security menu, and drop security
profiles entirely. However, that requires more plumbing of sendmail
than I'm currently willing to invest.
We may want to add a "permit SMTP delivery" question to the install
process.
archaic at this point in time. Pretend nobody runs FreeBSD 1.x anymore
in order to not confuse people needlessly.
Laplink support probably doesn't even work at this point in time anyway...
