kernel panic caused by Opera 11.50
uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #2: Mon Aug 8 17:05:59 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/HYDROGEN amd64 kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor write data, page not present instruction pointer = 0x20:0x804bfff0 stack pointer = 0x28:0xff8223c4ba40 frame pointer = 0x28:0xff8223c4ba60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2691 (operapluginwrapper.) Step to reproduce: 1. Open Opera 11.50 browser 2. Try to enter to Gmail or any web page with flash player and panic! -- netSys-- http://www.byteandbit.info ___ 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: kernel panic caused by Opera 11.50
On Sun Aug 14 11, Alvaro Castillo wrote: uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #2: Mon Aug 8 17:05:59 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/HYDROGEN amd64 kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor write data, page not present instruction pointer = 0x20:0x804bfff0 stack pointer = 0x28:0xff8223c4ba40 frame pointer = 0x28:0xff8223c4ba60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2691 (operapluginwrapper.) Step to reproduce: 1. Open Opera 11.50 browser 2. Try to enter to Gmail or any web page with flash player and panic! try http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html -- netSys-- http://www.byteandbit.info ___ 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: kernel panic caused by Opera 11.50
On Sun, 14 Aug 2011 07:07:57 +0100 Alvaro Castillo gobl...@gmail.com wrote: uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #2: Mon Aug 8 17:05:59 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/HYDROGEN amd64 kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor write data, page not present instruction pointer = 0x20:0x804bfff0 stack pointer = 0x28:0xff8223c4ba40 frame pointer = 0x28:0xff8223c4ba60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2691 (operapluginwrapper.) Step to reproduce: 1. Open Opera 11.50 browser 2. Try to enter to Gmail or any web page with flash player and panic! Are you using the native opera or linux opera? I'm running the native version with 9.0-BETA1 FreeBSD 9.0-BETA1 #134: Tue Aug 9 14:36:26 CEST 2011 amd64 and I can watch videos on YouTube w/o any problem. -- Gary Jennejohn ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is generated
by the shell's built-in test command, specifically '[ -r'. It is looking for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
tar(1). What you could try is to comment out the line 'rm ${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
Regards!
--
Niclas
___
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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On 08/14/11 11:48, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is generated
by the shell's built-in test command, specifically '[ -r'. It is looking for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
tar(1). What you could try is to comment out the line 'rm ${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
Regards!
Just got a notebook, build with the old gcc 4.2 of the system FreeBSD
9.0/amd64 -r224579: portsnap works as expected.
I will build a most recent system on that box (with systems's outdated
gcc 4.2) and I'll report if the problem is still present.
By the way: My boxes of failure are all built with CLANG.
Oliver
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: Alexander Best arun...@freebsd.org i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. Regards Steve ___ 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: FreeBSD 9.0-BETA1/amd64 r224808: buildworld failure: === lib/clang/include (all), 1 error, *** Error code 2, 1 error, *** Error code 2, 1 error
On 08/13/11 18:30, Test Rat wrote: Test Ratttse...@gmail.com writes: [...] Remaking `cat' Results of making cat: clang -O2 -pipe -O3 -Qunused-arguments -fcolor-diagnostics -march=native -g -fno-omit-frame-pointer -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o cat cat.o /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 FYI, above error was tracked to broken /dev/stdout and fixed in r224842. Thanks, will try. I'm still with -r224810 ... Oliver ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
2011/8/14 Hartmann, O. ohart...@zedat.fu-berlin.de:
On 08/14/11 11:48, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it
with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
Regards!
Just got a notebook, build with the old gcc 4.2 of the system FreeBSD
9.0/amd64 -r224579: portsnap works as expected.
I will build a most recent system on that box (with systems's outdated gcc
4.2) and I'll report if the problem is still present.
By the way: My boxes of failure are all built with CLANG.
Oliver
Trying again today, with my 9.0-BETA1 amd64 box built with clang.
Not the same error, but the same kind when using portsnap extract :
/usr/ports/lang/p5-JavaScript-Value-Escape/
/usr/ports/lang/p5-JavaScript/
/usr/ports/lang/p5-List-MoreUtils/
/usr/ports/lang/p5-Modern-Perl/
/usr/ports/lang/p5-POE-Component-Hailo/
files/b54a58da6d23d31f19a9105f70af03ef797aba8db6bdbc03d6deb72e62011d56.gz
not found -- snapshot corrupt.
This file is not present in /var/db/portsnap/files/.
# ll /var/db/portsnap/files/ | wc -l
22862
This was after removing /var/db/portsnap/files/ and
/var/db/portsnap/t* and a fresh portsnap fetch, on the portsnap5
mirror.
# fetch
http://portsnap5.freebsd.org/s/c9a2c992e8bde0c98309f76a0ecfb00eb76558c7c3dcbd0405a88316b775e66b.tgz
# tar tf c9a2c992e8bde0c98309f76a0ecfb00eb76558c7c3dcbd0405a88316b775e66b.tgz
| grep b54a58
nothing...
I tried on portsnap2 and the file was not present in
c9a2c992e8bde0c98309f76a0ecfb00eb76558c7c3dcbd0405a88316b775e66b.tgz
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email vCards X
www: http://www.gid0.org - against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
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: oddity mounting MMC/SD cards
Hi. On 13.08.2011 23:56, Michael Butler wrote: I tried to mount a card from my phone (it's quicker to copy directly than through USB) but I get this .. what am I missing here? Aug 13 16:53:37 toshi kernel: sdhci0-slot0: Card inserted Aug 13 16:53:37 toshi kernel: mmc0:MMC/SD bus on sdhci0 Aug 13 16:53:37 toshi kernel: mmc0: Probing bus Aug 13 16:53:37 toshi kernel: mmc0: SD probe: OK (OCR: 0x00ff8000) Aug 13 16:53:37 toshi kernel: mmc0: Current OCR: 0x00ff8000 Aug 13 16:53:38 toshi kernel: mmc0: Probing cards Aug 13 16:53:38 toshi kernel: mmc0: New card detected (CID 03534453553136478080d4290400a300) Aug 13 16:53:38 toshi kernel: mmc0: Card at relative address 36832 added: Aug 13 16:53:38 toshi kernel: mmc0: card: SD High Capacity (0x3/0x5344/SU16G rev 8.0 m/d 03.2010 s/n 80d42904) Aug 13 16:53:38 toshi kernel: mmc0: bus: 4bit, 50MHz, high speed timing Aug 13 16:53:38 toshi kernel: mmc0: memory: 31116288 blocks, erase sector 8192 blocks, read-only Aug 13 16:53:38 toshi kernel: mmc0: setting transfer rate to 30.000MHz Aug 13 16:53:38 toshi kernel: mmcsd0: 2905MBSDHC Memory Card (read-only) at mmc0 24MHz/4bit Aug 13 16:53:38 toshi kernel: GEOM: new disk mmcsd0 Aug 13 16:53:38 toshi kernel: mmc0: setting bus width to 4 bits vvv Aug 13 16:53:38 toshi kernel: GEOM_PART: partition 1 has end offset beyond last LBA: 31116287 5950463 Aug 13 16:53:38 toshi kernel: GEOM_PART: integrity check failed (mmcsd0, MBR) ^^^ It looks like consequence of r222475. Could you try this patch: --- dev/mmc/mmcsd.c.prev2011-08-14 14:09:35.0 +0300 +++ dev/mmc/mmcsd.c 2011-08-14 14:09:14.0 +0300 @@ -137,7 +137,7 @@ mmcsd_attach(device_t dev) d-d_drv1 = sc; d-d_maxsize = 4*1024*1024; /* Maximum defined SD card AU size. */ d-d_sectorsize = mmc_get_sector_size(dev); - d-d_mediasize = mmc_get_media_size(dev) * d-d_sectorsize; + d-d_mediasize = (off_t)mmc_get_media_size(dev) * d-d_sectorsize; d-d_stripeoffset = 0; d-d_stripesize = mmc_get_erase_sector(dev) * d-d_sectorsize; d-d_unit = device_get_unit(dev); -- Alexander Motin ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On Sun Aug 14 11, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
same here:
/usr/ports/databases/gigabase/
/usr/ports/databases/godis/
files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz not
found -- snapshot corrupt.
running r224841 on amd64 built with base clang.
Regards!
--
Niclas
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
Eduardo Morras nec...@retena.com writes: At 22:06 13/08/2011, Steven Hartland wrote: i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot ___ 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: [rfc] replacing /boot/kernel.old with a unique directory name
Test Rat ttse...@gmail.com writes: Eduardo Morras nec...@retena.com writes: At 22:06 13/08/2011, Steven Hartland wrote: i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ 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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun Aug 14 11, Test Rat wrote: Test Rat ttse...@gmail.com writes: Eduardo Morras nec...@retena.com writes: At 22:06 13/08/2011, Steven Hartland wrote: i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot the above works for me. just booted a compressed kernel. Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
2011/8/14 Alexander Best arun...@freebsd.org:
On Sun Aug 14 11, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it
with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
same here:
/usr/ports/databases/gigabase/
/usr/ports/databases/godis/
files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz not
found -- snapshot corrupt.
running r224841 on amd64 built with base clang.
Aparently fixed with latest HEAD *kernel* :
# svn log -v -r224842
r224842 | rwatson | 2011-08-13 18:03:40 +0200 (sam 13 aoû 2011) | 10 lignes
Chemins modifiés :
M /head/sys/kern/vfs_syscalls.c
When falloc() was broken into separate falloc_noinstall() and finstall(),
a bug was introduced in kern_openat() such that the error from the vnode
open operation was overwritten before it was passed as an argument to
dupfdopen(). This broke operations on /dev/{stdin,stdout,stderr}. Fix
by preserving the original error number across finstall() so that it is
still available.
Approved by:re (kib)
Reported by:cognet
You won't be able to buildworld with the buggy kernel, but you can
buildkernel and reboot on the new kernel. No problems with portsnap
after that (don't know if you have to clean the old portsnap files, I
did it).
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email vCards X
www: http://www.gid0.org - against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
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: oddity mounting MMC/SD cards
On 08/14/11 07:13, Alexander Motin wrote: On 13.08.2011 23:56, Michael Butler wrote: vvv Aug 13 16:53:38 toshi kernel: GEOM_PART: partition 1 has end offset beyond last LBA: 31116287 5950463 Aug 13 16:53:38 toshi kernel: GEOM_PART: integrity check failed (mmcsd0, MBR) ^^^ It looks like consequence of r222475. Could you try this patch: --- dev/mmc/mmcsd.c.prev2011-08-14 14:09:35.0 +0300 +++ dev/mmc/mmcsd.c 2011-08-14 14:09:14.0 +0300 @@ -137,7 +137,7 @@ mmcsd_attach(device_t dev) d-d_drv1 = sc; d-d_maxsize = 4*1024*1024; /* Maximum defined SD card AU size. */ d-d_sectorsize = mmc_get_sector_size(dev); - d-d_mediasize = mmc_get_media_size(dev) * d-d_sectorsize; + d-d_mediasize = (off_t)mmc_get_media_size(dev) * d-d_sectorsize; d-d_stripeoffset = 0; d-d_stripesize = mmc_get_erase_sector(dev) * d-d_sectorsize; d-d_unit = device_get_unit(dev); That worked :-) However, I found another (smaller) card where it didn't help :-( sdhci0-slot0: Card inserted mmc0: MMC/SD bus on sdhci0 mmc0: Probing bus mmc0: SD probe: OK (OCR: 0x00ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 02544d5341303447049c02a7f6009b00) mmc0: Card at relative address 4660 added: mmc0: card: SD High Capacity (0x2/0x544d/SA04G rev 0.4 m/d 11.2009 s/n 9c02a7f6) mmc0: bus: 4bit, 50MHz, high speed timing mmc0: memory: 7733248 blocks, erase sector 8192 blocks, read-only mmc0: setting transfer rate to 30.000MHz mmcsd0: 3776MB SDHC Memory Card (read-only) at mmc0 24MHz/4bit GEOM: new disk mmcsd0 mmc0: setting bus width to 4 bits GEOM_PART: partition 1 has end offset beyond last LBA: 7741438 7733247 GEOM_PART: integrity check failed (mmcsd0, MBR) The complaint appears to be valid, given fdisk's output .. is this something to do with the 'relative address'? imb@toshi:/usr/src fdisk /dev/mmcsd0 *** Working on device /dev/mmcsd0 *** parameters extracted from in-core disklabel are: cylinders=481 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=481 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 11 (0x0b),(DOS or Windows 95 with 32 bit FAT) start 8192, size 7733247 (3775 Meg), flag 0 beg: cyl 1/ head 2/ sector 3; end: cyl 960/ head 48/ sector 48 imb ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On Sun Aug 14 11, Olivier Smedts wrote:
2011/8/14 Alexander Best arun...@freebsd.org:
On Sun Aug 14 11, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it
with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
same here:
/usr/ports/databases/gigabase/
/usr/ports/databases/godis/
files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz
not found -- snapshot corrupt.
running r224841 on amd64 built with base clang.
Aparently fixed with latest HEAD *kernel* :
# svn log -v -r224842
r224842 | rwatson | 2011-08-13 18:03:40 +0200 (sam 13 aoû 2011) | 10 lignes
Chemins modifiés :
M /head/sys/kern/vfs_syscalls.c
When falloc() was broken into separate falloc_noinstall() and finstall(),
a bug was introduced in kern_openat() such that the error from the vnode
open operation was overwritten before it was passed as an argument to
dupfdopen(). This broke operations on /dev/{stdin,stdout,stderr}. Fix
by preserving the original error number across finstall() so that it is
still available.
Approved by:re (kib)
Reported by:cognet
You won't be able to buildworld with the buggy kernel, but you can
buildkernel and reboot on the new kernel. No problems with portsnap
after that (don't know if you have to clean the old portsnap files, I
did it).
thanks. switching to a newer revision alone didn't solve the issue. however
after doing
rm -r /var/db/portsnap/files/; rm /var/db/portsnap/t*; portsnap fetch update
everything's back to normal. :)
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email vCards X
www: http://www.gid0.org - against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
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: For about a week I've been trying to build a release that breaks at docproj. Just low priority break information.
Quoting Garrett Cooper yaneg...@gmail.com: On Sat, Aug 13, 2011 at 9:09 AM, Garrett Cooper yaneg...@gmail.com wrote: On Sat, Aug 13, 2011 at 8:37 AM, eculp ec...@encontacto.net wrote: I've been building a release about once a week on current. The last successful build was on august 8 but don't know when this started but in the last few days. I am building on # uname -a FreeBSD Home.EnContacto.net 9.0-BETA1 FreeBSD 9.0-BETA1 #16: Sat Aug 13 05:09:17 CDT 2011 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 All builds include ports kernel updated ports, etc. I build it with generate-release.sh script below. sh generate-release.sh head /local3/release Please try the attached patch. This will work better. Thanks, -Garrett World was broken for me on my early csup, I'm retrying and will get back after a successful build. Thanks, ed ___ 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: oddity mounting MMC/SD cards
On 14.08.2011 16:34, Michael Butler wrote: On 08/14/11 07:13, Alexander Motin wrote: On 13.08.2011 23:56, Michael Butler wrote: vvv Aug 13 16:53:38 toshi kernel: GEOM_PART: partition 1 has end offset beyond last LBA: 31116287 5950463 Aug 13 16:53:38 toshi kernel: GEOM_PART: integrity check failed (mmcsd0, MBR) ^^^ It looks like consequence of r222475. Could you try this patch: --- dev/mmc/mmcsd.c.prev2011-08-14 14:09:35.0 +0300 +++ dev/mmc/mmcsd.c 2011-08-14 14:09:14.0 +0300 @@ -137,7 +137,7 @@ mmcsd_attach(device_t dev) d-d_drv1 = sc; d-d_maxsize = 4*1024*1024; /* Maximum defined SD card AU size. */ d-d_sectorsize = mmc_get_sector_size(dev); - d-d_mediasize = mmc_get_media_size(dev) * d-d_sectorsize; + d-d_mediasize = (off_t)mmc_get_media_size(dev) * d-d_sectorsize; d-d_stripeoffset = 0; d-d_stripesize = mmc_get_erase_sector(dev) * d-d_sectorsize; d-d_unit = device_get_unit(dev); That worked :-) However, I found another (smaller) card where it didn't help :-( sdhci0-slot0: Card inserted mmc0:MMC/SD bus on sdhci0 mmc0: Probing bus mmc0: SD probe: OK (OCR: 0x00ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 02544d5341303447049c02a7f6009b00) mmc0: Card at relative address 4660 added: mmc0: card: SD High Capacity (0x2/0x544d/SA04G rev 0.4 m/d 11.2009 s/n 9c02a7f6) mmc0: bus: 4bit, 50MHz, high speed timing mmc0: memory: 7733248 blocks, erase sector 8192 blocks, read-only mmc0: setting transfer rate to 30.000MHz mmcsd0: 3776MBSDHC Memory Card (read-only) at mmc0 24MHz/4bit GEOM: new disk mmcsd0 mmc0: setting bus width to 4 bits GEOM_PART: partition 1 has end offset beyond last LBA: 7741438 7733247 GEOM_PART: integrity check failed (mmcsd0, MBR) The complaint appears to be valid, given fdisk's output .. is this something to do with the 'relative address'? imb@toshi:/usr/src fdisk /dev/mmcsd0 *** Working on device /dev/mmcsd0 *** parameters extracted from in-core disklabel are: cylinders=481 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=481 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 11 (0x0b),(DOS or Windows 95 with 32 bit FAT) start 8192, size 7733247 (3775 Meg), flag 0 beg: cyl 1/ head 2/ sector 3; end: cyl 960/ head 48/ sector 48 This time it looks different. Card size looks consistent, but partition is bigger then card size. Could you check card and partition sizes in some other (USB) card reader? -- Alexander Motin ___ 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
nroff -mandoc | more no longer works
I'm guessing this relates to nroff/groff tweaks, but I was a bit unhappy to learn that the command I've used for the last decade to render man pages while editing them (nroff -mandoc foo.1 | more) no longer works (output below). It seems likely this has to do with teaching groff to use ANSI escape codes that more, by default, rejects. I'm aware there are lots of other command lines I could use, but it seems unfortunate that this is broken -- possibly more should accept more escape codes in its default configuration, or nroff should generate fewer of them? (I'd love to see this fixed for 9.0) Robert N M Watson Computer Laboratory University of Cambridge robert@cinnamon-freebsd:/usr/src/lib/libc/sys nroff -mandoc dup.2 | more DUP(2)FreeBSD System Calls Manual DUP(2) ESC[1mNAMEESC[0m ESC[1mdupESC[22m, ESC[1mdup2 ESC[22m-- duplicate an existing file descriptor ESC[1mLIBRARYESC[0m Standard C Library (libc, -lc) ESC[1mSYNOPSISESC[0m ESC[1m#include unistd.hESC[0m ESC[4mintESC[0m ESC[1mdupESC[22m(ESC[4mintESC[24m ESC[4molddESC[24m); ___ 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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best arun...@freebsd.orgwrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as
the
results of target installkernel, we create a unique directory name for the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking
issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
A better method may be to use KODIR to install the *new* kernel to a unique
directory via installkernel (make KERNCONF=SOMEKERNEL
KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using nextboot
-k SOMEKERNEL-rev-whatever to set that kernel as bootable on the next boot.
You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
/boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
Sure, it's not automated yet, but the building blocks are there.
This way, you never disturb the currently working kernel until you know the
new kernel works. And if things go south with the new kernel, a simple
reboot is all that's needed to revert back to the working /boot/kernel.
All that's needed is to automate things a bit (pick KODIR, set nextboot,
create a post-install target of some kind to run after booting the new
kernel).
And, this leaves all of your kernels around if you want to play with
different ones.
cheers.
alex
___
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
--
Freddie Cash
fjwc...@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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash fjwc...@gmail.com wrote:
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best arun...@freebsd.orgwrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as
the
results of target installkernel, we create a unique directory name for the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking
issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
A better method may be to use KODIR to install the *new* kernel to a unique
directory via installkernel (make KERNCONF=SOMEKERNEL
KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using nextboot
-k SOMEKERNEL-rev-whatever to set that kernel as bootable on the next boot.
You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
/boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
Sure, it's not automated yet, but the building blocks are there.
This way, you never disturb the currently working kernel until you know the
new kernel works. And if things go south with the new kernel, a simple
reboot is all that's needed to revert back to the working /boot/kernel.
All that's needed is to automate things a bit (pick KODIR, set nextboot,
create a post-install target of some kind to run after booting the new
kernel).
And, this leaves all of your kernels around if you want to play with
different ones.
Again, why build more complexity into the system when it does what
you want in a more generic manner? Just to illustrate what I do on a
weekly basis, here's my script and example invocation (I have other
instances where I have more KERNCONFs and things are more
complicated). You shouldn't have to do much more than what I did below
when dealing with your specific case of interest -- especially
because, as you and others have identified elsewhere it may not work,
it might fill up whatever partition /boot is on, etc.
Thanks,
-Garrett
$ cat ~root/bin/installkernel
#!/bin/sh
SRCCONF=${SRCCONF:=/etc/src.conf}
set -e
for i in $(make -f $SRCCONF -V KERNCONF); do
# Using svn info is bad because that captures the sourcebase revision,
# which may or may not match the actual kernel being installed's revision.
# Something like `strings kernel | awk '/^FreeBSD [0-9]+/' ' would be
# better.
sudo make installkernel \
KERNCONF=$i \
INSTKERNNAME=$i.r$(svn info | awk '/^Revision/ {print
$2}')${SUFFIX:+.$SUFFIX} \
$*
done
Example:
$ make -VKERNCONF -f /etc/src.conf
BAYONETTA
$ cd /usr/src ~root/bin/installkernel ln -sfh BAYONETTA
/boot/kernel reboot
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
Freddie Cash fjwc...@gmail.com writes:
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best arun...@freebsd.orgwrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as
the
results of target installkernel, we create a unique directory name for the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking
issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
A better method may be to use KODIR to install the *new* kernel to a unique
directory via installkernel (make KERNCONF=SOMEKERNEL
KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using nextboot
-k SOMEKERNEL-rev-whatever to set that kernel as bootable on the next boot.
You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
/boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
[...]
nextboot needs write access in loader to reset kernel, which is only
available for ufs. So, forget about zfs and every other fs from
libstand(3), e.g. ext2fs, msdosfs, nfs.
bootonce is also only supported in gptboot (ufs), not gptzfsboot.
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
On 8/14/11 3:27 AM, Eduardo Morras wrote: At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: Alexander Best arun...@freebsd.org i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. What would make more sense to me for thsi would be a kernel name that was recognised by teh final boot stages as being an exeprimental kernel and moved to the new location only on successful boot.. Once you have successfully booted it, then you delete the kernel[-1] and do the replacement that make installkernel now does. Regards Steve ___ 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: nroff -mandoc | more no longer works
I also use this line for testing man page edits. It will be a very sad thing if it's been broken in 9.0. On 8/14/11 8:29 AM, Robert Watson wrote: I'm guessing this relates to nroff/groff tweaks, but I was a bit unhappy to learn that the command I've used for the last decade to render man pages while editing them (nroff -mandoc foo.1 | more) no longer works (output below). It seems likely this has to do with teaching groff to use ANSI escape codes that more, by default, rejects. I'm aware there are lots of other command lines I could use, but it seems unfortunate that this is broken -- possibly more should accept more escape codes in its default configuration, or nroff should generate fewer of them? (I'd love to see this fixed for 9.0) Robert N M Watson Computer Laboratory University of Cambridge robert@cinnamon-freebsd:/usr/src/lib/libc/sys nroff -mandoc dup.2 | more DUP(2)FreeBSD System Calls Manual DUP(2) ESC[1mNAMEESC[0m ESC[1mdupESC[22m, ESC[1mdup2 ESC[22m-- duplicate an existing file descriptor ESC[1mLIBRARYESC[0m Standard C Library (libc, -lc) ESC[1mSYNOPSISESC[0m ESC[1m#include unistd.hESC[0m ESC[4mintESC[0m ESC[1mdupESC[22m(ESC[4mintESC[24m ESC[4molddESC[24m); ___ 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
Failed Buildworld 9.0 Beta 1
Hello all. I cvsuped yesterday, and did a buildworld, all was fine. cvsuped today again, and now i can not do a buildworld, it errors out on atrun It ends like this (written by hand) ===libexec (all) ===libexec/atrun (all) cc -O2 -pipe .. cc -O2 -pipe .. cc -O2 -pipe .. /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylex` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyin` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyytext` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyerror` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylineno` *** error code 1 Stop in /usr/src/libexec/atrun my make.conf CPUTYPE?=nocona KERNCONF=KRNL BATCH_DELETE_OLD_FILES= yes CUPS_OVERWRITE_BASE=yes # added by use.perl 2011-08-11 12:41:27 PERL_VERSION=5.10.1 my src.conf WITHOUT_BLUETOOTH= yes WITHOUT_CALENDAR= yes WITHOUT_DICT= yes WITHOUT_GAMES= yes WITHOUT_HTML= yes WITHOUT_I4B=yes WITHOUT_IPFILTER= yes WITHOUT_IPX=yes WITHOUT_LPR=yes WITHOUT_NIS=yes WITHOUT_RCMDS= yes WITHOUT_RCS=yes #WITHOUT_PROFILE= yes WITHOUT_SENDMAIL= yes WITHOUT_SHAREDOCS= yes WITHOUT_WIRELESS= yes and my KRNL conf file include GENERIC ident KRNL # hast support options GEOM_GATE # Carp support device carp # pf options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync # Console color options options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # Console video mode options VESA # Vesa Support for Splash options SC_PIXEL_MODE # add support for the raster tex # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines # Disable debugging in -current nooptions KDB # Enable kernel debugger support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions INVARIANTS # Enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed regards Johan Hendriks ___ 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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper yaneg...@gmail.com wrote:
On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash fjwc...@gmail.com wrote:
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best arun...@freebsd.org
wrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel
as
the
results of target installkernel, we create a unique directory name for
the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking
issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a
kernel
without /dev/{u}random support.
A better method may be to use KODIR to install the *new* kernel to a
unique
directory via installkernel (make KERNCONF=SOMEKERNEL
KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using
nextboot
-k SOMEKERNEL-rev-whatever to set that kernel as bootable on the next
boot.
You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
/boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
Sure, it's not automated yet, but the building blocks are there.
This way, you never disturb the currently working kernel until you know
the
new kernel works. And if things go south with the new kernel, a simple
reboot is all that's needed to revert back to the working /boot/kernel.
All that's needed is to automate things a bit (pick KODIR, set nextboot,
create a post-install target of some kind to run after booting the new
kernel).
And, this leaves all of your kernels around if you want to play with
different ones.
Again, why build more complexity into the system when it does what
you want in a more generic manner? Just to illustrate what I do on a
weekly basis, here's my script and example invocation (I have other
instances where I have more KERNCONFs and things are more
complicated). You shouldn't have to do much more than what I did below
when dealing with your specific case of interest -- especially
because, as you and others have identified elsewhere it may not work,
it might fill up whatever partition /boot is on, etc.
Unless I'mmissing something, we're saying essentially the same thing
(install new kernel to unique directory) , but you've done the work to
actually automate it. :)
--
Freddie Cash
fjwc...@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
Recent HEAD: buildworld is broken with clang
=== libexec (all) === libexec/atrun (all) clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=gnu99' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/libexec/atrun. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop 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: [Soekris] FreeBSD 9.0 beta on a Net5501?
On Thu, Aug 4, 2011 at 2:21 PM, Patrick Lamaiziere patf...@davenulle.org wrote: Hello, I've tried to update my net5501 running an old FreeBSD-current from october to 9.0 beta 1. Unfortunaly installworld crashed and the system is broken now : # make installworld ... === libexec/rtld-elf (install) chflags noschg /usr/libexec/ld-elf.so.1 install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1 /libexec install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 *** Signal 4 Stop in /usr/src/libexec/rtld-elf. *** Error code 1 # ls Instruction interdite(core dumped) (instruction interdite = illegal/forbidden instruction) The world and kernel were built with llvm/clang. [CC-ing freebsd-current@] Is this issue resolved? I'm having a bunch of net4801 in production here, and I was planning to move them to 9.0 soon after RELEASE. So thanks for the heads up. I'll be holding back now, and will stay with 8.2-STABLE. Unfortunately, I have no spare net4801 (and no net5501) at the moment, so I can't test BETA on them. :( Could you tell me if it works for you on a net5501? Thanks, regards. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: nroff -mandoc | more no longer works
The proper way to do this atm is 'man ./foo.1'. I had the same set of commands under the fingers as well, but doing it the new way has many benefits. Not the least of which is that you will see the page the same way man will render it when it's installed. Doug (change is hard) On 8/14/2011 12:08 PM, Julian Elischer wrote: I also use this line for testing man page edits. It will be a very sad thing if it's been broken in 9.0. On 8/14/11 8:29 AM, Robert Watson wrote: I'm guessing this relates to nroff/groff tweaks, but I was a bit unhappy to learn that the command I've used for the last decade to render man pages while editing them (nroff -mandoc foo.1 | more) no longer works (output below). It seems likely this has to do with teaching groff to use ANSI escape codes that more, by default, rejects. I'm aware there are lots of other command lines I could use, but it seems unfortunate that this is broken -- possibly more should accept more escape codes in its default configuration, or nroff should generate fewer of them? (I'd love to see this fixed for 9.0) Robert N M Watson Computer Laboratory University of Cambridge -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Failed Buildworld 9.0 Beta 1
Oh good, I'm not the only one seeing this - I have had it for a few days at least, but haven't had time to look into it. dave c On Sun, Aug 14, 2011 at 9:16 AM, Johan Hendriks jo...@double-l.nl wrote: Hello all. I cvsuped yesterday, and did a buildworld, all was fine. cvsuped today again, and now i can not do a buildworld, it errors out on atrun It ends like this (written by hand) ===libexec (all) ===libexec/atrun (all) cc -O2 -pipe .. cc -O2 -pipe .. cc -O2 -pipe .. /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylex` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyin` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyytext` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyerror` /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylineno` *** error code 1 Stop in /usr/src/libexec/atrun my make.conf CPUTYPE?=nocona KERNCONF=KRNL BATCH_DELETE_OLD_FILES= yes CUPS_OVERWRITE_BASE=yes # added by use.perl 2011-08-11 12:41:27 PERL_VERSION=5.10.1 my src.conf WITHOUT_BLUETOOTH= yes WITHOUT_CALENDAR= yes WITHOUT_DICT= yes WITHOUT_GAMES= yes WITHOUT_HTML= yes WITHOUT_I4B=yes WITHOUT_IPFILTER= yes WITHOUT_IPX=yes WITHOUT_LPR=yes WITHOUT_NIS=yes WITHOUT_RCMDS= yes WITHOUT_RCS=yes #WITHOUT_PROFILE= yes WITHOUT_SENDMAIL= yes WITHOUT_SHAREDOCS= yes WITHOUT_WIRELESS= yes and my KRNL conf file include GENERIC ident KRNL # hast support options GEOM_GATE # Carp support device carp # pf options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync # Console color options options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # Console video mode options VESA # Vesa Support for Splash options SC_PIXEL_MODE # add support for the raster tex # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines # Disable debugging in -current nooptions KDB # Enable kernel debugger support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions INVARIANTS # Enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed regards Johan Hendriks ___ 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: Recent HEAD: buildworld is broken with clang
On 2011-08-14 20:58, Oleg V. Nauman wrote: === libexec (all) === libexec/atrun (all) clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=gnu99' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/libexec/atrun. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This is fixed. I had no trouble building r224865 some hours ago. This issue might be related to the fix in r224842, Try to rebuild just the kernel, and boot to the new kernel before doing another buildworld. HTH! -- Niclas Zeising ___ 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: Recent HEAD: buildworld is broken with clang
On Aug 14, 2011, at 11:58 AM, Oleg V. Nauman o...@opentransfer.com wrote: ... There was an issue with file descriptor handling introduced with the capsicum work. Please update your src, rebuild your kernel, install, or use an older kernel, and try again. -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: Failed Buildworld 9.0 Beta 1
On Aug 14, 2011, at 12:16 PM, Johan Hendriks jo...@double-l.nl wrote: Hello all. I cvsuped yesterday, and did a buildworld, all was fine. cvsuped today again, and now i can not do a buildworld, it errors out on atrun It ends like this (written by hand) This is a kernel regression introduced by Capsicum. Please check the archives for more details.. -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: Recent HEAD: buildworld is broken with clang
Not sure this is CLANG related - I see this on a system where WITHOUT_CLANG is set, and someone else reported it in another thread. dave c On Sun, Aug 14, 2011 at 8:58 AM, Oleg V. Nauman o...@opentransfer.comwrote: === libexec (all) === libexec/atrun (all) clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.**lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\** -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../..**/usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.**lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\** -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../..**/usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/**gloadavg.c clang -O -pipe -march=i686 -mtune=i686 -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.**lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\** -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../..**/usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=gnu99' /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/libexec/atrun. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: nroff -mandoc | more no longer works
On Sun, Aug 14, 2011 at 12:56:16PM -0700, Doug Barton wrote:
The proper way to do this atm is 'man ./foo.1'. I had the same set of
commands under the fingers as well, but doing it the new way has many
benefits. Not the least of which is that you will see the page the same
way man will render it when it's installed.
In ancient times, the UNIX philosphy was to have small
programs that one could chain together via a pipe. I've
had the following alias in my .cshrc for well over ar
decade:
alias doc 'cat \!* | eqn | tbl | nroff -mdoc | more'
Now, when I'm working on a manpage in my local projects,
I get the wonderfully useful
doc mkpic.1
MKPIC(1)FreeBSD General Commands Manual MKPIC(1)
ESC[1mNAMEESC[0m
ESC[1mmkpic ESC[22m-- construct a contour image in MIFF image format
ESC[1mSYNOPSISESC[0m
ESC[1mmkpic ESC[22m[ESC[1m-aBbcefilsvESC[22m] [ESC[1m-C
ESC[4mESC[22mnumESC[24m] [ESC[1m-d ESC[4mESC[22mdenESC[24m] [ESC[1m-F
ESC[4mESC[22m{v|h}ESC[24m] [
ESC[1m-G ESC[4mESC[22mCLxRLESC[24m] [ESC[1m-g ESC[4mESC[22mR,G,BESC[24m]
[ESC[1m-L ESC[4mESC[22mlvalESC[24m] [ESC[1m-M
ESC[4mESC[22mmaxESC[24m] [ESC[1m-m ESC[4mESC[22mminESC[24m] [ESC[1m-n
ESC[4mESC[22mcolorsESC[24m] [ESC[1m-O ESC[4mESC[22mnameESC[24m] [ESC[1m-o
ESC[4mESC[22mnameESC[24m]
[ESC[1m-R ESC[4mESC[22mR,G,BESC[24m] [ESC[1m-r ESC[4mESC[22mCOLxROW
ESC[24m] [ESC[1m-S ESC[4mESC[22mscaleESC[24m] [ESC[1m-T
ESC[4mESC[22mmapESC[24m] [ESC[1m-t ESC[4mESC[22mCOLxROW+COFF+ROFFESC[24m]
ESC[4mfileESC[0m
ESC[1mDESCRIPTIONESC[0m
The purpose of ESC[1mmkpic ESC[22mis to produce a pixelized contour of a 2D
nroff needs to be fixed.
--
Steve
___
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
buildworld failure
hi there, has anybody seen this buildworld failure? === sys/modules/portalfs (depend) @ - /usr/git-freebsd-head/sys machine - /usr/git-freebsd-head/sys/amd64/include x86 - /usr/git-freebsd-head/sys/x86/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend CC='clang' mkdep -f .depend -a -nostdinc -DSTRIP_FBSDID -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vfsops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c:41:10: fatal error: 'opt_capsicum.h' file not found #include opt_capsicum.h ^ 1 error generated. mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error cheers. alex ___ 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: buildworld failure
The module makefile needs to be updated evidently. Just add it to the dependencies until rwatson gets around to fixing it. On Sun, Aug 14, 2011 at 11:50 PM, Alexander Best arun...@freebsd.org wrote: hi there, has anybody seen this buildworld failure? === sys/modules/portalfs (depend) @ - /usr/git-freebsd-head/sys machine - /usr/git-freebsd-head/sys/amd64/include x86 - /usr/git-freebsd-head/sys/x86/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend CC='clang' mkdep -f .depend -a -nostdinc -DSTRIP_FBSDID -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vfsops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c:41:10: fatal error: 'opt_capsicum.h' file not found #include opt_capsicum.h ^ 1 error generated. mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error cheers. alex ___ 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: [Soekris] FreeBSD 9.0 beta on a Net5501?
On 8/14/2011 3:50 PM, C. P. Ghost wrote: On Thu, Aug 4, 2011 at 2:21 PM, Patrick Lamaiziere patf...@davenulle.org wrote: Hello, I've tried to update my net5501 running an old FreeBSD-current from october to 9.0 beta 1. Unfortunaly installworld crashed and the system is broken now : Instruction interdite(core dumped) (instruction interdite = illegal/forbidden instruction) The world and kernel were built with llvm/clang. [CC-ing freebsd-current@] Is this issue resolved? I'm having a bunch of net4801 in production here, and I was planning to move them to 9.0 soon after RELEASE. So thanks for the heads up. I'll be holding back now, and will stay with 8.2-STABLE. Unfortunately, I have no spare net4801 (and no net5501) at the moment, so I can't test BETA on them. :( Could you tell me if it works for you on a net5501? Not sure about the 4801, I dont have one online right now. But I netbooted a 5501 and it seems fine. KERNEL is essentially GENERIC minus the debug stuff +option CPU_GEODE +option CPU_SOEKRIS +ident ipsec BTW, watchdog seems to work fine as I just tested that soekris3# cat /var/run/dmesg.boot Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA1 #2: Sun Aug 14 19:15:05 EDT 2011 mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/ipsec i386 ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) module_register: module pci/xhci already exists! Module pci/xhci failed to register: 17 CPU: Geode(TM) Integrated Processor by AMD PCS (433.26-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x5a2 Family = 5 Model = a Stepping = 2 Features=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX AMD Features=0xc040MMX+,3DNow!+,3DNow! real memory = 268435456 (256 MB) avail memory = 247726080 (236 MB) K6-family MTRR support enabled (2 registers) kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: software crypto on motherboard pcib0: Host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 Geode LX: Soekris net5501 comBIOS ver. 1.33 20070103 Copyright (C) 2000-2007 pci0: encrypt/decrypt, entertainment crypto at device 1.2 (no driver attached) vr0: VIA VT6105M Rhine III 10/100BaseTX port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:24:c9:aa:9c vr1: VIA VT6105M Rhine III 10/100BaseTX port 0xe200-0xe2ff mem 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 vr1: Quirks: 0x2 vr1: Revision: 0x96 miibus1: MII bus on vr1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:00:24:c9:aa:9d vr2: VIA VT6105M Rhine III 10/100BaseTX port 0xe300-0xe3ff mem 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 vr2: Quirks: 0x2 vr2: Revision: 0x96 miibus2: MII bus on vr2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr2: Ethernet address: 00:00:24:c9:aa:9e vr3: VIA VT6105M Rhine III 10/100BaseTX port 0xe400-0xe4ff mem 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 vr3: Quirks: 0x2 vr3: Revision: 0x96 miibus3: MII bus on vr3 ukphy3: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr3: Ethernet address: 00:00:24:c9:aa:9f isab0: PCI-ISA bridge at device 20.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD CS5536 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 ohci0: OHCI (generic) USB controller mem 0xa0005000-0xa0005fff irq 15 at device 21.0 on pci0 usbus0: OHCI (generic) USB controller on ohci0 ehci0: AMD CS5536 (Geode) USB 2.0 controller mem 0xa0006000-0xa0006fff irq 15 at device 21.1 on pci0 usbus1: EHCI version 1.0 usbus1: AMD CS5536 (Geode) USB 2.0 controller on ehci0 cpu0 on motherboard pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc8000-0xd27ff pnpid ORM on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 ppc0: parallel port not found. uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (115200,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff
Re: buildworld failure
On Mon, 15 Aug 2011, Kip Macy wrote: The module makefile needs to be updated evidently. Just add it to the dependencies until rwatson gets around to fixing it. Building modules with world is pretty uncommon (I assume that's what is going on here -- MODULES_WITH_WORLD), so it looks like we missed this in testing. I'll enqueue something to re@ shortly. In general, I'm a bit surprised we support doing this still, especially with -CURRENT where you really want modules tuned to a particular kernel configuration file, rather than built stand-alone. (Otherwise you get modules that aren't built for INVARIANTS but a GENERIC kernel that is built for INVARIANTS...) It sounds like a recipe for unfortunate things. Robert On Sun, Aug 14, 2011 at 11:50 PM, Alexander Best arun...@freebsd.org wrote: hi there, has anybody seen this buildworld failure? === sys/modules/portalfs (depend) @ - /usr/git-freebsd-head/sys machine - /usr/git-freebsd-head/sys/amd64/include x86 - /usr/git-freebsd-head/sys/x86/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend CC='clang' mkdep -f .depend -a -nostdinc -DSTRIP_FBSDID -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vfsops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c:41:10: fatal error: 'opt_capsicum.h' file not found #include opt_capsicum.h ^ 1 error generated. mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error cheers. alex ___ 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 ___ 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
Avoid kernels between r224778 and r224841; bug causes buildworld failure
Dear all:
As you may have seen from current@ traffic, a bug crept in during the Capsicum
merge, introduced by the infamous Last Minute Cleanup and not caught in
pre-commit testing. The most noticed effect of the bug is to cause buildworld
to fail due to a problem with /dev/{stdin,stdout,stderr} when running an
affected kernel. The bug doesn't break buildkernel, so it's possible to
update from bad revisions by doing that (or rolling back to a pre-update
kernel). The problem appeared in r224778 (11 August), and was fixed in
r224842 (13 August), so it's a pretty short window and hopefully the problem
will scroll out quickly.
I'm currently awaiting approvel from re@ to commit a note to UPDATING saying
the above.
Sorry about that!
Robert N M Watson
Computer Laboratory
University of Cambridge
___
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: buildworld failure
On Sun, 14 Aug 2011, Alexander Best wrote: has anybody seen this buildworld failure? Could you try the attached patch and see if it helps? I currently have it in the re@ approval queue. It does appear to fix the problem here. Generally, I would strongly advise against using modules built with world, and wonder if we should be de-supporting that explicitly at this point. Checking that the below works for you would be great, but you might not want to use MODULES_WITH_WORLD anymore. (If we do want to keep MODULES_WITH_WORLD, we may want to add it to the tinderboxes.) Robert -- Fix two cases involving opt_capsicum.h and module builds: (1) opt_capsicum.h is no longer required in ffs_alloc.c, so remove the #include. (2) portalfs depends on opt_capsicum.h, so have the Makefile generate one if required. Note, however, that attempting to use modules built without a kernel configuration is a bad idea generally -- it's a bit worrying that we still provide MODULES_WITH_WORLD. Approved by:re (xxx) Sponsored by: Google Inc Index: ufs/ffs/ffs_alloc.c === --- ufs/ffs/ffs_alloc.c (revision 224860) +++ ufs/ffs/ffs_alloc.c (working copy) @@ -62,7 +62,6 @@ #include sys/cdefs.h __FBSDID($FreeBSD$); -#include opt_capsicum.h #include opt_quota.h #include sys/param.h Index: modules/portalfs/Makefile === --- modules/portalfs/Makefile (revision 224860) +++ modules/portalfs/Makefile (working copy) @@ -4,6 +4,7 @@ KMOD= portalfs SRCS= vnode_if.h \ - portal_vfsops.c portal_vnops.c + portal_vfsops.c portal_vnops.c \ + opt_capsicum.h .include bsd.kmod.mk ___ 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: ghost files
On Sun, Aug 7, 2011 at 3:08 AM, deeptec...@gmail.com deeptec...@gmail.com wrote: as of recent times, some git rebase operations fail unexpectedly with an error: cannot create .git/index.lock: file exists. an investigation session was something like the following: $ ls -l .git the index.lock file is not in the shown list. $ ls -l .git/index.lock the file is listed! it's a regular file, its size is ~60KiB. $ cat .git/index.lock some file content is shown. $ mv .git/index.lock .git/someplace moving fails with: index.lock: file does not exist. $ ee .git/index.lock some file content is shown, which i edit and save. then the .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. do not find the file), and the content i put in the .git/index.lock file via ee is now in .git/index. H$X!111 i still have some git rebase operations (which are notably disk-active) fail from time to time with impossible reasons (for example: something like cherry picking failed, or something like cannot move git-rebase-new to git-rebase-todo: file does not exist). i'd note that the hard drive is kind of old (7 years), and i recently had the power cut during port build operations twice, although the (UFS) filesystem is fsck-clean. has anyone experienced anything like this? what is the possibility of a filesystem/kernel bug or fsck bug? Do not start supposing that this is a filesystem/kernel bug so early. I have seen similar mysterious messages @work, with Git servers running on Linux, so I'm inclined to believe that it is a software issue. -- The flames are all long gone, but the pain lingers on ___ 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
Packages for FreeBSD 9.0 CURRENT on PowerPC
http://code.google.com/p/freebsd-powerpc-9-0-current-updated-packages/downloads/list?can=2q=colspec=Filename%20Summary%20Uploaded%20ReleaseDate%20Size%20DownloadCountsort=filenamenum=100start=0 One reason I have the packages up is due to the fact bthat there are none for the PowerPC/POWER architectures. The other reason is because some people have machines that cannot readily build packages without doing the load-store choke. The packages are clean. They were made as a general desktop environment. If any are missing, let me know; and, I will be quick- unless something happens with real life- to make the packages. The only thing to do if anyone wants to make the packages a part of the FreeBSD download repositories is copy them over to repository # blah. ___ 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: makefs(8) broken iso9660 images
On Wed Aug 10 11, Test Rat wrote: $ tar tf FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso | fgrep -i kernel [nothing] $ mount -t cd9660 /dev/$(mdconfig -f FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso) /media $ ls -1 /media/boot/kernel aac.ko accf_data.ko As you found earlier, makefs and makeisofs lay out the disk images differently. This has revealed a regression in libarchive that causes it to not see the contents of certain directories. (Specifically, it appears that any directory that follows a non-directory on the image is ignored.) Tim ___ 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
