only being able to create 1TB partitions:
o) Use an unsigned 32-bit quantity to store the number of disk sectors.
o) Detect overflow of said 32-bit quantity and clamp to 2^32.
o) Rather than returning the disk sector count from get_params, return 0 on
success, since its return value is only ever compared to -1 to detect
failure. This would cause returning 2^32 sectors to be interpreted as an
error.
Reviewed by: bde ("good for a quick fix")
Remove obsolete code which uses DIOCSMBR ioctl.
When writing MBR first check that GEOM_MBR is available, if it is not
available, then try write MBR directly to provider. If both are failed,
then recommend to use gpart(8).
MFC after: 2 week
These tools declare global variables without using the static keyword,
even though their use is limited to a single C-file, or without placing
an extern declaration of them in the proper header file.
maximum value instead of number of bits. But for case when
limitation is not needed it erroneously skips conversion to
number and always returns zero. So, don't skip conversion
for case when limitation is not needed.
PR: bin/159765
Approved by: re (kib)
fdisk(1) internally uses a signed int. Should a user attempt to specify
a slice containing more than 2^31 - 1 sectors, an error will be reported
on systems with sizeof(long) == 4 and the slice size will be silently
truncated on systems with sizeof(long) > 4.
Instead use an unsigned long to store the slice size in fdisk(1). This
allows the user to specify a slice size up to the maximum permitted by
the MBR on-disk format and does not have any problems with silent
truncation should the use specify an slice size larger than 2^32 on systems
with sizeof(long) > 4.
Submitted by: Mark Johnston (markjdb AT gmail DOT com)
MFC after: 2 weeks
by the MBR for the given parameter and set that parameter to the
maximum value instead of just truncating the most significant part
silently.
Could happen for example if the capacity of the device is more
than 2TB, so that the number of sectors is greater than 2Mib.
MFC after: 1 month
replace the table of partition with a simpler and faster array of strings.
The change in the array is done mechanically, using vi commands.
Most entries in the table are probably 15+ years old and largely outdated,
so the next step is to remove stale entries with more current values.
Submitted by: Christoph Mallon, with small changes from me
MFC after: 3 days
+ Remove a dead field of a struct. It serves no purpose anymore.
+ Remove a \n at the end of the format string of err(); the err()
function already adds a \n ;
+ remove many unnecessary casts which obfuscate the code.
This file has a huge number of indentation bugs, but I'd rather fix
them when/if we happen to modify the relevant parts of the code.
Submitted by: Christoph Mallon
MFC after: 3 days
duplication of code in fdisk and boot0cfg. Also make use of g_providername to
fix an issue with fdisk and boot0cfg not using the correct provider when
writing the MBR.
Reviewed by: phk
Approved by: pjd (mentor)
: fdisk.c revision 1.74
: date: 2004/06/14 07:21:19; author: phk; state: Exp; lines: +3 -3
: Make fdisk initialize the first instead of the last slice by default.
sector size, instead of later failing with an error about /boot/mbr
not being a multiple of the sector size (since we end up with an
assumed sector size of MAX_SEC_SIZE * 2).
- We query the sector size via an IOCTL anyway, so if that succeeds
use that instead of probing for it via read(2) calls. This fixes
the problem with fdisk failing to operate on at least graid3 and
md(4) devices on kernels with src/sys/geom/geom_dev.c before
rev. 1.90, due to fdisk failing to detect the sector size.
- When detecting the root device allow "/" characters in it, which
happens with e.g. gmirror devices.
Reviewed by: cperciva
MFC after: 1 week
Always set the magic sequence when we write, rather than trusting the
previously read boot code to do so.
Use explicit encoding/decoding of little endian disk image.
Remove a comment which was OBE.
Change the test vector for "fdisk -I" to reflect that there is a magic
sequence in the result now.
Add test case for "fdisk" which reads the image back.
At least for the two test-cases this program now gives the same result
on sparc64 as on i386. The lack of an installed /boot/mbr on sparc64
raises an (un)interesting question.
