Re: mkimg used to create gpt image, problem booting
On 24.08.2014 19:23, Marcel Moolenaar wrote:
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused,
NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Actually, no. There is *a* problem in that function:
The function does not respect hdr.hdr_entsz when it
needs the next entry. It simply uses ent++, which
is fixed our definition of struct gpt_ent and may
not match the definition of the writer.
Yes, you are right. I'll fix this. Thanks.
I don't see how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
Also there is bootparttest utility in the tools/tools/bootparttest. I
think it can be useful for debugging.
--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
On 24.08.2014 20:59, Craig Rodrigues wrote: Also, in the gptboot man page, it mentions that gptboot can only boot on systems with 128 partitions or less. This seems like an artificial restriction. Does the gptboot code really enforce this? Not that I have a system with more than 128 partitions. :) It's because gptboot uses static buffer to read and write GPT table. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
On 25.08.2014 03:55, Marcel Moolenaar wrote: Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. IMHO, mkimg should behave like gpart and create images in gpart-compatible way. Some users may want to copy the partition layout from the image to real hardware and they will not be able to do it. Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same problem and the BSD disk label can also be created with more than just 8 partitions. I thought about implementing `gpart modify` or `gpart set` -n entries to change number of entries when it is possible (i.e. disklabel(8) can do it, but gpart doesn't). Also in r228076 I changed APM code to calculate maximum number of entries depending from available free space. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1311
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1311/changes Changes: [rdivacky] The standard we compile libc++ with is called c++11 not c++0x. [ae] Since the size of GPT entry may differ from the sizeof(struct gpt_ent), use the size from GPT header to iterate entries. Suggested by: marcel@ MFC after: 1 week -- [...truncated 229878 lines...] --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- depend_subdir_dtrace --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/dtrace/systrace_freebsd32/@ --- @ - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/dtrace/systrace_freebsd32/machine --- machine - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/amd64/include --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/dtrace/systrace_freebsd32/x86 --- --- depend_subdir_et --- --- pci_if.h --- awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h --- depend_subdir_dtrace --- x86 - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/x86/include --- vnode_if_newproto.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p --- depend_subdir_et --- --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- depend_subdir_dtrace --- --- vnode_if_typedef.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q --- depend_subdir_et --- --- miibus_if.h --- --- depend_subdir_dtrace --- --- vnode_if.h --- --- depend_subdir_et --- awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h --- depend_subdir_dtrace --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h --- depend_subdir_et --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -std=iso9899:1999 https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/modules/et/../../dev/et/if_et.c --- depend_subdir_dtrace --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -DFREEBSD32_SYSTRACE -D_KERNEL -DKLD_MODULE -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/cddl/compat/opensolaris -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/cddl/contrib/opensolaris/uts/common -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -std=iso9899:1999 https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/cddl/dev/systrace/systrace.c --- depend_subdir_exca --- === exca (depend) --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/exca/@ --- @ - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/exca/machine --- machine - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/amd64/include --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/exca/x86 --- x86 - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/x86/include --- depend_subdir_ext2fs --- --- depend_subdir_exca --- --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- depend_subdir_ext2fs --- === ext2fs (depend) --- depend_subdir_exca --- --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- depend_subdir_ext2fs --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/ext2fs/@ --- @ - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys --- depend_subdir_exca --- --- power_if.h --- awk -f @/tools/makeobjops.awk @/dev/pccard/power_if.m -h --- depend_subdir_ext2fs --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/ext2fs/machine --- machine - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/amd64/include --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/ext2fs/x86 --- x86 - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/x86/include --- depend_subdir_exca --- --- card_if.h --- awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h --- depend_subdir_ext2fs --- --- opt_ddb.h --- ln -sf /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/opt_ddb.h opt_ddb.h --- opt_directio.h --- ln -sf /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/opt_directio.h
Re: ktrace -c behavior
On 08/24/2014 19:53, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: On 08/22/2014 15:20, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. and/or just add specified: Clear the specified trace points ... But what if I didn't specify them? You specified the default by not specificly specifing any different ones.. :) Confused? :) Amused. :) or maybe selected? Perhaps, but I didn't select them, either. My original suggestion is more--dare I use this word again--specific. It explains exactly how the command behaves. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crash on xen/amd64
On 25/08/14 02:28, Shawn Webb wrote: I've been getting these occasional kernel panics in my VM: http://imgur.com/BYes0gj,Ay8iDar This time around pkg-static seemed to cause the crash. Hello, AFAICT this doesn't seem to be related to the other crash you posted on: http://lists.freebsd.org/pipermail/freebsd-xen/2014-July/002159.html Can you get a backtrace? Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote: On 25.08.2014 03:55, Marcel Moolenaar wrote: Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. IMHO, mkimg should behave like gpart and create images in gpart-compatible way. It already does. There's s difference between behaving like something else or behaving exactly identical to that something. The same applies to compatible. It is not the same as identical. There is no compatibility issue. mkimg follows the GPT specification (modulo bugs) and gpart happily groks the partition table. Some users may want to copy the partition layout from the image to real hardware and they will not be able to do it. I'm inclined to say that generally speaking this is not possible. The GPT has metadata in the first few sectors *and* the last few sectors and LBAs of these sectors are part of the metadata. You cannot blindly copy an image onto a physical medium unless the image and the physical medium are of exactly the same size. Odds are they are not. To reliably transfer or convert an image (e.g. RAW-VHD) one must modify the image as part of the process. Not a hard rule, but best to assume as a rule of thumb. This seems to warrant a utility all by itself. Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On 25.08.2014 18:40, Marcel Moolenaar wrote: Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. `gpart restore` just uses a number of commands to geom_part(4) to create partition table similar to what was backed up. If your partition table on the old system had a partition that starts from LBA 34, now `gpart create` isn't able to create such partition table. Because by default the first usable LBA is 40. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crash on xen/amd64
Mon, Aug 25, 2014 at 10:04 AM, Roger Pau Monné roger@citrix.com wrote: On 25/08/14 02:28, Shawn Webb wrote: I've been getting these occasional kernel panics in my VM: http://imgur.com/BYes0gj,Ay8iDar This time around pkg-static seemed to cause the crash. Hello, AFAICT this doesn't seem to be related to the other crash you posted on: http://lists.freebsd.org/pipermail/freebsd-xen/2014-July/002159.html Can you get a backtrace? Backtrace is shown in the second image here: http://imgur.com/BYes0gj,Ay8iDar Thanks, Shawn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to normal : FreeBSD_HEAD #1312
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1312/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld commands used to generate manifest for makefs?
On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: Hi, Is there an easy way to take most of the commands performed during make installworld and create a manifest file which is compatible with makefs? make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld should result in a foo/METALOG file suitable for passing to makefs. You may also want the distribution target if you want a populated /etc. -- Broks pgptPGNp8VyD0.pgp Description: PGP signature
Re: make installworld commands used to generate manifest for makefs?
On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
Hi,
Is there an easy way to take most of the commands performed
during make installworld and create a manifest file
which is compatible with makefs?
make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld
should result in a foo/METALOG file suitable for passing to makefs.
You may also want the distribution target if you want a populated /etc.
-- Broks
Hi,
I got this:
# make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld
mkdir -p /tmp/install.hEJfJDhM
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo
egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if
progpath=`which $prog`; then echo $progpath; else echo Required
tool $prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd
-f %o %p\n -f %o %p\n $progs 2/dev/null | sort -u | while read
line; do set -- $line; if [ $2 $3 != not found ]; then echo $2;
else echo Required library $1 not found. 2; exit 1; fi;
done); cp $libs $progs /tmp/install.hEJfJDhM
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.hEJfJDhM/locale
echo #mtree 2.0 /tmp//METALOG
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f
Makefile.inc1 INSTALL=install -N /usr/src/etc -U -M /tmp//METALOG -D
/tmp MTREE_CMD=mtree -N /usr/src/etc -W
__MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG
reinstall; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM
make[2]: /usr/src/share/mk/bsd.compiler.mk line 37: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
Andrey V. Elsukov wrote this message on Mon, Aug 25, 2014 at 19:02 +0400: On 25.08.2014 18:40, Marcel Moolenaar wrote: Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. `gpart restore` just uses a number of commands to geom_part(4) to create partition table similar to what was backed up. If your partition table on the old system had a partition that starts from LBA 34, now `gpart create` isn't able to create such partition table. Because by default the first usable LBA is 40. Luckily, gpart restore won't work: # gpart backup /dev/md0 GPT 4 1 freebsd-ufs 8 262144 # gpart restore md1 /tmp/foob.gpt.back gpart: entries '4': Invalid argument So, we're somewhat safe, guess gpart restore needs to learn how to handle entries properly We should fix this, since other OS's might not use 128 for entries.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld commands used to generate manifest for makefs?
On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote:
On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
Hi,
Is there an easy way to take most of the commands performed
during make installworld and create a manifest file
which is compatible with makefs?
make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld
should result in a foo/METALOG file suitable for passing to makefs.
You may also want the distribution target if you want a populated /etc.
-- Broks
Hi,
I got this:
# make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld
you really don't want DESTDIR=/tmp, it will install a full OS in that
directory along with the METALOG file.
mkdir -p /tmp/install.hEJfJDhM
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo
egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if
progpath=`which $prog`; then echo $progpath; else echo Required
tool $prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd
-f %o %p\n -f %o %p\n $progs 2/dev/null | sort -u | while read
line; do set -- $line; if [ $2 $3 != not found ]; then echo $2;
else echo Required library $1 not found. 2; exit 1; fi;
done); cp $libs $progs /tmp/install.hEJfJDhM
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.hEJfJDhM/locale
echo #mtree 2.0 /tmp//METALOG
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f
Makefile.inc1 INSTALL=install -N /usr/src/etc -U -M /tmp//METALOG -D
/tmp MTREE_CMD=mtree -N /usr/src/etc -W
__MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG
reinstall; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM
make[2]: /usr/src/share/mk/bsd.compiler.mk line 37: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
You need to build world before you can install it.
-- Brooks
pgpMgj7DkgPit.pgp
Description: PGP signature
Re: RFC: Remove pty(4)
On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD = 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. Why not just statically create the pairs in /dev? Use some loader tunable (kern.ptymax) to set a count on the number of pre-created device pairs to create and then just explicitly create them in the mod_event handler? It could default to 100 or so. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is LOR a new feature in 11-CURRENT?
Greetings, all. I'm testing 11 current, and booting installing from the 2014-08-11-r269824-disc1.iso returns the following, via dmesg(8): kernel: lock order reversal: kernel: 1st 0xf80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 kernel: 2nd 0xf80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 Further info: kernel: FreeBSD 11.0-CURRENT #0 r269824: Mon Aug 11 20:18:52 UTC 2014 kernel: r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 kernel: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 kernel: WARNING: WITNESS option enabled, expect reduced performance. Operation of FreeBSD will feel as tho it's running off of a 5/14 floppy disk! kernel: CPU: AMD Athlon(tm) ... Of course, an svn checkout of src ports followed by a make install of world kernel reconciled the matter. I thought it worth mentioning. All the best. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
How to get a mouse in vt(4) -- NEWCONS
Greetings, I'm testing 11-CURRENT, and have build/installed a kernel, and world. The KERNCONF includes both sc, and vt. As I understand it. If both are included, I get sc, not vt. But all previous kerns I've built that had sc, provided a mouse upon boot. However, in 11, I don't get one. What must be done? I'd like to try vt(4), and I've read the man page for it, and have added: kern.vty=vt in /boot/loader.conf having done so, does NOT enable mouse support, and turns OFF cursor=blink which is defined in rc.conf(5). I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. I would choose graphics (0) if it was available. But appears not. Thank you for all your time, and consideration. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is LOR a new feature in 11-CURRENT?
Hi Chris, On Mon, Aug 25, 2014 at 1:19 PM, Chris H bsd-li...@bsdforge.com wrote: Greetings, all. I'm testing 11 current, and booting installing from the 2014-08-11-r269824-disc1.iso returns the following, via dmesg(8): kernel: lock order reversal: kernel: 1st 0xf80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 kernel: 2nd 0xf80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 I'm pretty sure this is one of the known LORs (introduced around 8.x/9.x?), but I could be wrong. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is LOR a new feature in 11-CURRENT?
Hi Chris, On Mon, Aug 25, 2014 at 1:19 PM, Chris H bsd-li...@bsdforge.com wrote: Greetings, all. I'm testing 11 current, and booting installing from the 2014-08-11-r269824-disc1.iso returns the following, via dmesg(8): kernel: lock order reversal: kernel: 1st 0xf80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 kernel: 2nd 0xf80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 I'm pretty sure this is one of the known LORs (introduced around 8.x/9.x?), but I could be wrong. Thanks! -Garrett Ahh, I see. Well, it wasn't a show stopper, or anything. But thought it worth mentioning. Thanks for the reply, Garrett. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld commands used to generate manifest for makefs?
On 8/25/14, 12:36 PM, Brooks Davis wrote:
On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote:
On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
Hi,
Is there an easy way to take most of the commands performed
during make installworld and create a manifest file
which is compatible with makefs?
make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld
if you haven't already this should be documented in the base makefiles
along with the other -D
values.
should result in a foo/METALOG file suitable for passing to makefs.
You may also want the distribution target if you want a populated /etc.
-- Broks
Hi,
I got this:
# make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld
you really don't want DESTDIR=/tmp, it will install a full OS in that
directory along with the METALOG file.
mkdir -p /tmp/install.hEJfJDhM
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo
egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if
progpath=`which $prog`; then echo $progpath; else echo Required
tool $prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd
-f %o %p\n -f %o %p\n $progs 2/dev/null | sort -u | while read
line; do set -- $line; if [ $2 $3 != not found ]; then echo $2;
else echo Required library $1 not found. 2; exit 1; fi;
done); cp $libs $progs /tmp/install.hEJfJDhM
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.hEJfJDhM/locale
echo #mtree 2.0 /tmp//METALOG
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f
Makefile.inc1 INSTALL=install -N /usr/src/etc -U -M /tmp//METALOG -D
/tmp MTREE_CMD=mtree -N /usr/src/etc -W
__MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG
reinstall; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM
make[2]: /usr/src/share/mk/bsd.compiler.mk line 37: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
You need to build world before you can install it.
-- Brooks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
vt(4) -- vidcontrol: setting cursor type: Inappropriate ioctl for device
Greetings, On 11-CURRENT, and with vt(4) chosen. I receive the following at boot: vidcontrol: setting cursor type: Inappropriate ioctl for device I _believe_ this is caused by the entry in rc.conf(5) cursor=blink This entry has always worked fine with sc(4), and as I read it, [should] in vt(4) as well. But the vt(4) man pages seem to be lagging. They discuss oid(s) that don't seem to exist, and I'm unable to determine _what_ I should be doing to get a similar terminal/console as I get w/sc(4). Are there any other docs, or links available to help me with this? Thank you for all your time, and consideration. --Chris P.S. I'm using an Nvidia 8400, w/512Mb ram onboard, as well as the Nvidia blob. If that makes any difference. Thanks again. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld commands used to generate manifest for makefs?
On Mon, Aug 25, 2014 at 03:28:43PM -0700, Julian Elischer wrote:
On 8/25/14, 12:36 PM, Brooks Davis wrote:
On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote:
On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
Hi,
Is there an easy way to take most of the commands performed
during make installworld and create a manifest file
which is compatible with makefs?
make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld
if you haven't already this should be documented in the base makefiles
along with the other -D
values.
It was documented in the initial commit.
-- Brooks
should result in a foo/METALOG file suitable for passing to makefs.
You may also want the distribution target if you want a populated /etc.
-- Broks
Hi,
I got this:
# make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld
you really don't want DESTDIR=/tmp, it will install a full OS in that
directory along with the METALOG file.
mkdir -p /tmp/install.hEJfJDhM
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo
egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if
progpath=`which $prog`; then echo $progpath; else echo Required
tool $prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd
-f %o %p\n -f %o %p\n $progs 2/dev/null | sort -u | while read
line; do set -- $line; if [ $2 $3 != not found ]; then echo $2;
else echo Required library $1 not found. 2; exit 1; fi;
done); cp $libs $progs /tmp/install.hEJfJDhM
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.hEJfJDhM/locale
echo #mtree 2.0 /tmp//METALOG
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f
Makefile.inc1 INSTALL=install -N /usr/src/etc -U -M /tmp//METALOG -D
/tmp MTREE_CMD=mtree -N /usr/src/etc -W
__MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG
reinstall; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM
make[2]: /usr/src/share/mk/bsd.compiler.mk line 37: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
You need to build world before you can install it.
-- Brooks
pgprsdqPiaURf.pgp
Description: PGP signature
Re: How to get a mouse in vt(4) -- NEWCONS
On Mon, 25 Aug 2014, Chris H wrote: I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to get a mouse in vt(4) -- NEWCONS
On Mon, 25 Aug 2014, Chris H wrote: I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. Ahh, I see. Thank you very much, Warren, for the reply. :) --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gbde destroy doesn't match man page?
On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org, Michae l W. Lucas writes: Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde destroy device -n -1. It's in the examples. When I try it I get: I think that is an oversight in the code. Can you expand on this? I.e. what should the code do if it is fixed? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ktrace -c behavior
On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote: On 08/24/2014 19:53, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: On 08/22/2014 15:20, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. and/or just add specified: Clear the specified trace points ... But what if I didn't specify them? You specified the default by not specificly specifing any different ones.. :) Confused? :) Amused. :) Adding specified is the first thing that came to my mind as well. or maybe selected? Perhaps, but I didn't select them, either. My original suggestion is more--dare I use this word again--specific. It explains exactly how the command behaves. But then do we need to annotate every place that uses trace points to add this language? Note that the 'command' description uses the language John- mark suggested: command Execute command with the specified trace flags. My vote would be to add specified to the description of -c, but to improve the the description of -t itself from: -t trstr The string argument represents the kernel trace points, one per letter. The following table equates the letters with the trace- points: to: -t trstr Specify the list of trace points to enable or disable, one per letter. If an explicit list is not specified, the default set of trace points is used. The following trace points are supported: -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to get a mouse in vt(4) -- NEWCONS
On Mon, Aug 25, 2014 at 5:54 PM, Chris H bsd-li...@bsdforge.com wrote: On Mon, 25 Aug 2014, Chris H wrote: I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. Ahh, I see. Thank you very much, Warren, for the reply. :) --Chris But the mouse should work fine with vt(4). It does for me. You do need to run moused, though that was the case with cs(4), as well. The lack of blink support was just noted in the last post to this list, so we can hope to hear a bit about the status of blink soon. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Inconsistent behavior with dd(1)
On 8/18/14 12:00 PM, William Orr wrote:
Reply inline.
On 08/16/2014 10:34 AM, John-Mark Gurney wrote:
Alan Somers wrote this message on Fri, Aug 15, 2014 at 10:42 -0600:
On Thu, Aug 14, 2014 at 11:55 PM, William Orr w...@worrbase.com wrote:
Hey,
I found some inconsistent behavior with dd(1) when it comes to specifying
arguments in -CURRENT.
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551616
dd: count: Result too large
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551617
dd: count: Result too large
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551615
dd: count cannot be negative
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=-18446744073709551615
1+0 records in
1+0 records out
512 bytes transferred in 0.000373 secs (1373071 bytes/sec)
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-1
dd: count cannot be negative
???
Any chance someone has the time and could take a look?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263
Thanks,
William Orr
???
IMHO, this is a bug in strtouq(3), not in dd(1). Why should it parse
negative numbers at all, when there is stroq(3) for that purpose? The
standard is clear that it must, though. Oddly enough, stroq would
probably not accept -18446744073709551615, even though strtouq does.
Specific comments on your patch below:
Here???s the patch:
Index: bin/dd/args.c
===
--- bin/dd/args.c (revision 267712)
+++ bin/dd/args.c (working copy)
@@ -186,46 +186,31 @@
static void
f_bs(char *arg)
{
- uintmax_t res;
-
- res = get_num(arg);
- if (res 1 || res SSIZE_MAX)
- errx(1, bs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
- in.dbsz = out.dbsz = (size_t)res;
+ in.dbsz = out.dbsz = get_num(arg);
+ if (in.dbsz 1 || out.dbsz 1)
Why do you need to check both in and out? Aren't they the same?
Also, you eliminated the check for overflowing SSIZE_MAX. That's not
ok, because these values get passed to places that expect signed
numbers, for example in dd.c:303.
The type of dbsz is size_t, so really:
+ errx(1, bs must be between 1 and %ju, (uintmax_t)-1);
This should be SIZE_MAX, except there isn't a define for this? So maybe
the code really should be:
(uintmax_t)(size_t)-1
to get the correct value for SIZE_MAX...
Otherwise on systems that uintmax_t is 32bits and size_t is 32bits,
the error message will be wrong...
Yes, this should probably be SIZE_MAX rather than that cast. Same with
the others
}
static void
f_cbs(char *arg)
{
- uintmax_t res;
-
- res = get_num(arg);
- if (res 1 || res SSIZE_MAX)
- errx(1, cbs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
- cbsz = (size_t)res;
+ cbsz = get_num(arg);
+ if (cbsz 1)
+ errx(1, cbs must be between 1 and %ju, (uintmax_t)-1);
}
Again, you eliminated the check for SSIZE_MAX, but cbsz must be signed.
What do you mean by this? cbsz is size_t which is unsigned...
I believe he's referring to this use of cbsz/in.dbsz/out.dbsz:
https://svnweb.freebsd.org/base/head/bin/dd/dd.c?revision=265698view=markup#l171
Really, this is more wrong since there is math inside of a malloc(3)
call without any overflow handling. By virtue of making this max out at
a ssize_t, it becomes more unlikely that you'll have overflow.
This math should probably be done ahead of time with proper overflow
handling. I'll include that in my next patch, if there's no objection.
I don't see any other reason why in.dbsz, out.dbsz or cbsz should be
signed, but it's very possible that I didn't look hard enough.
Again, the cast above is wrong... Maybe we should add a SIZE_MAX
define so we don't have to see the double cast...
static void
f_count(char *arg)
{
- intmax_t res;
-
- res = (intmax_t)get_num(arg);
- if (res 0)
- errx(1, count cannot be negative);
- if (res == 0)
- cpy_cnt = (uintmax_t)-1;
This is a special case. See dd_in(). I think that eliminating this
special case will have the unintended effect of breaking count=0.
- else
- cpy_cnt = (uintmax_t)res;
+ cpy_cnt = get_num(arg);
}
static void
f_files(char *arg)
{
-
Don't eliminate these blank lines.. they are intentional per style(9):
/* Insert an empty line if the function has no local variables. */
files_cnt = get_num(arg);
if (files_cnt 1)
- errx(1, files must be between 1 and %jd, (uintmax_t)-1);
+ errx(1, files must be between 1 and %ju, (uintmax_t)-1);
Good catch.
}
static void
@@ -241,14 +226,10 @@
static void
f_ibs(char *arg)
{
- uintmax_t res;
-
if (!(ddflags C_BS)) {
- res = get_num(arg);
- if (res
