contents of /usr/src/rescue. Until now, the files were shipped with
releases but sysinstall would ignore them (resulting in a non-buildable
source tree).
Sanity checked by: jhb
Specifically, change the second level menu title from 'Country' to
'Country or Region', since e.g. Hong Kong is not a country.
Submitted by: Xin LI <delphij@frontfree.net>
another process already has /dev/snp0 open, the snp(4) will return
EBUSY, in which case watch will try to open /dev/snp1..9. Currently
watch does not check errno to see if the failure was a result of EBUSY.
This results in watch making futile attempts to open snp0..snp9 even
though devices may not exist or the caller does not have permissions
to access the device.
In addition to this, it attempts to setup the screen for snooping even
though it may not ever get an snp device.
So this patch does two things
1) Checks errno for EBUSY, if open(2) fails for another reason
print that reason and exit.
2) setup the terminal for snooping after the snp descriptor has
been obtained.
Approved by: bmilekic (mentor)
install of Postfix fails since Postfix 1 is picked from INDEX instead
of Postfix 2.
The problem is that the package_add function matches multiple Postfix
packages and then installs a "random" version (the last one found in
INDEX). This does not occur with a CD-ROM install since there is only
one Postfix package on the CD-ROM.
The correct solution to this would be to check the origin field from
INDEX instead of the package name, but due to the way sysinstall is
made that is not trivial, so instead work around the problem by
hard-coding the Postfix major and minor revision (for the current
stable version) to install directly into the package_add call.
PR: misc/65426
Reported by: Harold Kachelmyer <bugs@princessharold.net>
Approved by: trhodes
or 'env MAKEOBJDIRPREFIX=... make' depending on the setting of
MAKEOBJDIRPREFIX in the environment. In any case this line kills the
original value of ${MAKE}. When during buildworld a new make is built (as
is the case during the upgrade) this causes a wrong make to be picked up
(the first one in the path). Use the same technique as Makefile.inc1:
create a MAKEENV variable and a CRUNCHMAKE that calls ${MAKE} with that
MAKEENV prefixed. Use CRUNCHMAKE instead of MAKE throughout the generated
makefile. This leaves the original ${MAKE} undisturbed.
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.
instead of BD_ADDRs
- Convert BD_ADDRs in l2ping(8) output into the human readable names via
bt_gethostbyaddr(3)
- Introduce and document '-n' - numberic output option
Suggested by: Anil Madhavapeddy <anil at recoil dot org>
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.
While I'm here, document the existence of the '-l' option, which allows
one to use moused to use psm in some more interesting ways.
Approved by: njl (mentor)
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.
some debug support turned on. It turns out the sections in this driver
binary had relative virtual addresses (RVAs) that were different
from the raw addresses, and it had a .data section where the virtual size
was much larger than the raw size. (Most production binaries produced
with the Microsoft DDK have RVA == PA.)
There's code in the ndiscvt(8) utility that's supposed to handle
the vsize != rsize case, but it turns out it was slightly broken,
and it failed to handle the RVA != RA case at all. Hopefully, this
commit will fix all that.
- Give ndiscvt(8) the ability to process a .SYS file directly into
a .o file so that we don't have to emit big messy char arrays into
the ndis_driver_data.h file. This behavior is currently optional, but
may become the default some day.
- Give ndiscvt(8) the ability to turn arbitrary files into .ko files
so that they can be pre-loaded or kldloaded. (Both this and the
previous change involve using objcopy(1)).
- Give NdisOpenFile() the ability to 'read' files out of kernel memory
that have been kldloaded or pre-loaded, and disallow the use of
the normal vn_open() file opening method during bootstrap (when no
filesystems have been mounted yet). Some people have reported that
kldloading if_ndis.ko works fine when the system is running multiuser
but causes a panic when the modile is pre-loaded by /boot/loader. This
happens with drivers that need to use NdisOpenFile() to access
external files (i.e. firmware images). NdisOpenFile() won't work
during kernel bootstrapping because no filesystems have been mounted.
To get around this, you can now do the following:
o Say you have a firmware file called firmware.img
o Do: ndiscvt -f firmware.img -- this creates firmware.img.ko
o Put the firmware.img.ko in /boot/kernel
o add firmware.img_load="YES" in /boot/loader.conf
o add if_ndis_load="YES" and ndis_load="YES" as well
Now the loader will suck the additional file into memory as a .ko. The
phony .ko has two symbols in it: filename_start and filename_end, which
are generated by objcopy(1). ndis_open_file() will traverse each module
in the module list looking for these symbols and, if it finds them, it'll
use them to generate the file mapping address and length values that
the caller of NdisOpenFile() wants.
As a bonus, this will even work if the file has been statically linked
into the kernel itself, since the "kernel" module is searched too.
(ndiscvt(8) will generate both filename.o and filename.ko for you).
- Modify the mechanism used to provide make-pretend FASTCALL support.
Rather than using inline assembly to yank the first two arguments
out of %ecx and %edx, we now use the __regparm__(3) attribute (and
the __stdcall__ attribute) and use some macro magic to re-order
the arguments and provide dummy arguments as needed so that the
arguments passed in registers end up in the right place. Change
taken from DragonflyBSD version of the NDISulator.
