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)
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.
Peter had repocopied sys/disklabel.h to sys/diskpc98.h and sys/diskmbr.h.
These two new copies are still intact copies of disklabel.h and
therefore protected by #ifndef _SYS_DISKLABEL_H_ so #including them
in programs which already include <sys.disklabel.h> is currently a
no-op.
This commit adds a number of such #includes.
Once I have verified that I have fixed all the places which need fixing,
I will commit the updated versions of the three #include files.
Sponsored by: DARPA & NAI Labs.