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...
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.
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
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.
PC98 boot blocks don't support UFS2. We keep newfs(8) defaulting to
UFS2.
Warn users that FreeBSD can only boot from a root file system smaller
than 1.5TB; hopefully this will get fixed by the patches currently
floating around on -CURRENT.
Reviewed by: nyan
FreeBSD 5.1-RELEASE and later:
- newfs(8) will now create UFS2 file systems unless UFS1 is specifically
requested (-O1). To do this, I just twiddled the Oflag default.
- sysinstall(8) will now select UFS2 as the default layout for new
file systems unless specifically requested (use '1' and '2' to change
the file system layout in the disk labeler). To do this, I inverted
the ufs2 flag into a ufs1 flag, since ufs2 is now the default and
ufs1 is the edge case. There's a slight semantic change in the
key behavior: '2' no longer toggles, it changes the selection to UFS2.
This is very similar to a patch David O'Brien sent me at one point, and
that I couldn't find.
Approved by: re (telecon)
Reviewed by: mckusick, phk, bmah
physical memory. The default is still 2x physical memory. The nominal
calculation is used to back-off swap auto-allocation ('A'uto command)
when the disk is not large enough to accomodate all filesystem auto-defaults.
This gives other partitions (like /usr) more priority over swap on smaller
disks.
This should help solve reported auto-sizing failures on machines with small
hard drives and huge amounts of memory. For example, a machine with 2G of
disk and 4G of memory will fail to auto-size without this fix.
MFC after: 3 days
i386, remove the seatbelt preventing users from setting the UFS2 flag
on the root file system on i386. This seatbelt did not exist on
other platforms.
MFC candidate.
editor, in order to support specifying UFS2 as a newfs option.
(1) Support three different newfs types: NEWFS_UFS, NEWFS_MSDOS, and
NEWFS_CUSTOM. Don't mix up the arguments to them: you can't use
soft updates on an msdos file system.
(2) Distinguish adding new arguments to the newfs command line from
replacing it. Permit the addition of new arguments by the user for
NEWFS_UFS. If we entirely replace the command line provided by
sysinstall, call it NEWFS_CUSTOM. 'N' will now add additional
arguments; 'Z' will opt to replace the newfs command line entirely,
but will prompt the user with their current command line as a
starting point.
(3) Construct the newfs command line dynamically based on the options
provided by the user at label-time. Right now, this means selecting
UFS1 vs. UFS2, and the soft updates flag. Drop in some variables
to support ACLs and MAC Multilabel in the future also, but don't
expose them now.
This provides sysinstall with the ability to do more "in band" editing
of the newfs command line, so we can provide more support for the user,
but doesn't sacrifice the ability to entirely specify the newfs command
line of the user is willing to give up on the cushiness factor. It
also makes it easier for us to specify defaults in the future, and
define conditional behavior based on user configuration selections.
For now, we default to UFS1, and permit UFS2 to be used as the root
only on non-i386 systems.
While I was there, I dropped the default fragment and block sizes,
since newfs has much more sensible defaults now.
Reviewed by: jhb, marcel
Approved by: re
ia64 bits from: marcel
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
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.
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
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 :).
