[Bug 187015] [panic] make_dev_credv: bad si_name (error=17, si_name=agpgart)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187015 --- Comment #5 from Tatsuki Makino tatsuki_mak...@hotmail.com --- 10.1-BETA1 r271727 couldn't be booted. But It could be booted after typing below on loader prompt set hint.agp.0.disabled=1 boot-conf -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193740] New: fetch(3) HTTP netrc support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193740 Bug ID: 193740 Summary: fetch(3) HTTP netrc support Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: tgyu...@gmail.com It would be useful, if fetch(3) whould use the netrc file for HTTP basic authentication too, not just for ftp. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 187315] unzip(1): base unzip does not recognize *.zip archives from dropbox.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187315 --- Comment #1 from Ross McKelvie r...@exitzero.uk --- I have also seen this behaviour on FreeBSD 10.0-RELEASE-p7 with http://downloads.sourceforge.net/project/edk2/OVMF/OVMF-IA32-r15214.zip and http://downloads.sourceforge.net/project/edk2/OVMF/OVMF-X64-r15214.zip; distfiles for proposed ports submitted in bug 192012. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193743] New: RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193743 Bug ID: 193743 Summary: RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: ohart...@zedat.fu-berlin.de Running FreeBSD 11.0-CURRENT (11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64) on a Lenovo ThinkPad Edge E540 laptop, CPU: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (2494.28-MHz K8-class CPU), the built-in LAN adaptor doen't work correctly as it doesn't get up automatically. Symptoms: After booting the system, the OS does recognise the NIC properly and initializes the hardware. But then, the NIC is dead or down - no connection. Carrier is active. Sometimes - sporadically - DHCP offers/requests where fullfilled, but then the NIC is dead. Solution: After the box and NIC is up, turning the NIC down and then up and waiting a second or two makes the NIC working as expected. This phenomenon occurs on different types of switches (Netgear, HP Procurve, Cisco). The hardware reveals itself to the OS as re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE and miibus0: MII bus on re0 rgephy0: RTL8251 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow pciconf -lbcev: [...] re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled bar [20] = type Memory, range 64, base 0xf1d0, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 ecap 001e[178] = unknown 1 PCI-e errors = Correctable Error Detected Corrected = Receiver Error -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193743] RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193743
--- Comment #1 from Guido Falsi madpi...@freebsd.org ---
I reported a similar issue some time ago, this is the relevant thread on
n...@freebsd.org:
http://lists.freebsd.org/pipermail/freebsd-net/2013-September/036645.html
Some patches were tried at the time but the problem was not solved.
I'm currently working around this with a startup script doing:
start_cmd=ifconfig ${refix_if} tso
(tso is already on by default, just touching the flag wakes up the adapter).
My machine is a Fujitsu siemens tower Esprimo PH300 E85+.
pciconf -lbcev:
re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0xd000, size 256, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xf2104000, size
4096, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xf210, size
16384, enabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1)
speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 01000401
PCI-e errors = Correctable Error Detected
Unsupported Request Detected
Corrected = Advisory Non-Fatal Error
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193601] em0: link state changed to DOWN / UP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193601 --- Comment #2 from free...@opensauce.de --- (In reply to Eric Joyner from comment #1) Hi, Thanks for taking the time! Do the link UP/DOWN messages generally occur after ~15 minutes, or does the time between initializing the adapter and those messages vary? weird! Now they have stopped just as quick as they started! Grepping through my logs I can see that I had this problem between Sept. 8 - 13 (my oldest logfile goes back to the 6th). Here are the first few entries from /var/log/messages: (IP's hostnames redacted) Sep 8 04:04:49 domus afpd[93184]: afp_alarm: reconnect timer expired, goodbye Sep 8 04:04:49 domus afpd[93184]: Disconnected session terminating Sep 8 08:18:06 domus kernel: em0: link state changed to DOWN Sep 8 08:18:09 domus kernel: em0: link state changed to UP Sep 8 08:18:09 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 8 14:07:24 domus ntpd[886]: bind() fd 31, family AF_INET6, port 123, scope 0, addr :::::, mc Sep 8 14:07:24 domus ntpd[886]: unable to create socket on em0 (176) for :::::#123 Sep 8 15:03:15 domus kernel: em0: link state changed to DOWN Sep 8 15:03:19 domus kernel: em0: link state changed to UP Sep 8 15:03:19 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 8 18:56:33 domus kernel: em0: link state changed to DOWN Sep 8 18:56:37 domus kernel: em0: link state changed to UP Sep 8 18:56:37 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 8 21:10:26 domus ntpd[886]: bind() fd 32, family AF_INET6, port 123, scope 0, addr :::::: Sep 8 21:10:26 domus ntpd[886]: unable to create socket on em0 (182) for :::::::#123 Sep 8 21:10:26 domus ntpd[886]: bind() fd 32, family AF_INET6, port 123, scope 0, addr :::::: Sep 8 21:10:26 domus ntpd[886]: unable to create socket on em0 (183) for :::::::#123 Sep 8 21:11:54 domus kernel: em0: link state changed to DOWN Sep 8 21:11:57 domus kernel: em0: link state changed to UP Sep 8 21:11:57 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' and here the last few entries: Sep 13 19:32:52 domus kernel: em0: link state changed to DOWN Sep 13 19:32:56 domus kernel: em0: link state changed to UP Sep 13 19:32:56 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 13 19:34:10 domus kernel: em0: link state changed to DOWN Sep 13 19:34:14 domus kernel: em0: link state changed to UP Sep 13 19:34:14 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 13 19:37:54 domus kernel: em0: link state changed to DOWN Sep 13 19:37:57 domus kernel: em0: link state changed to UP Sep 13 19:37:57 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 13 19:39:39 domus kernel: em0: link state changed to DOWN Sep 13 19:39:43 domus kernel: em0: link state changed to UP Sep 13 19:39:43 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 13 19:40:04 domus rpc.statd: Failed to contact host backups.home: RPC: Port mapper failure - RPC: Timed out Sep 13 19:40:18 domus kernel: em0: link state changed to DOWN Sep 13 19:40:49 domus kernel: em0: link state changed to UP Sep 13 19:40:49 domus devd: Executing '/etc/rc.d/dhclient quietstart em0' Sep 13 19:42:04 domus rpc.statd: Failed to contact host laptop.home: RPC: Port mapper failure - RPC: Timed out Sep 13 20:44:04 domus rpc.statd: Failed to contact host backups.home: RPC: Port mapper failure - RPC: Timed out Sep 13 20:46:05 domus rpc.statd: Failed to contact host laptop.home: RPC: Port mapper failure - RPC: Timed out Sep 13 21:48:05 domus rpc.statd: Failed to contact host backups.home: RPC: Port mapper failure - RPC: Timed out Sep 13 21:50:05 domus rpc.statd: Failed to contact host laptop.home: RPC: Port mapper failure - RPC: Timed out Sep 13 22:52:05 domus rpc.statd: Failed to contact host backups.home: RPC: Port mapper failure - RPC: Timed out Sep 13 22:54:05 domus rpc.statd: Failed to contact host laptop.home: RPC: Port mapper failure - RPC: Timed out Sep 13 23:56:05 domus rpc.statd: Failed to contact host backups.home: RPC: Port mapper failure - RPC: Timed out Sep 13 23:58:05 domus rpc.statd: Failed to contact host laptop.home: RPC: Port mapper failure - RPC: Timed out Sep 14 00:07:24 domus afpd[80087]: Login by steve (AFP3.3) Here's a quick summary of how often it occurred: drops max / day / hour Sep 8: 5 1 Sep 9: 26 6 Sep 10: 58 7 Sep 11: 273 18 Sep 12: 620 38 Sep 13: 453 33 No configuration changes took place at either end - although I did reboot a few times in the hopes of shaking out some cobwebs. And as the log shows, there wasn't even a reboot around the time it stopped. Do you send IPv4 or IPv6 traffic, specific UDP/TCP traffic like NFS, or does the adapter idle until the link starts flapping? Yes, I use both. I actually tried to set up
[Bug 193745] New: [uefi] fresh install of 2014-09-08 10.1-beta1 snapshot boots but has no console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193745 Bug ID: 193745 Summary: [uefi] fresh install of 2014-09-08 10.1-beta1 snapshot boots but has no console Product: Base System Version: 10.1-BETA1 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: d...@skunkwerks.at Created attachment 147441 -- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147441action=edit dmesg_from_imac13-4_20140909_10.1beta1 # Objective Boot to FreeBSD and see the console during boot on UEFI-only Apple iMac. # Expected Result beautiful lines of console bliss scroll merrily past until the joyous login prompt appears; all celebrate. # Actual Result loader.efi gets us to: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Start @ 0x802d89c0 ... And then no further activity (flickering, output, anything) is seen. However the system successfully boots and dmesg is attached. The method of installation was slightly unconventional, using an existing OpenZFS-on-OSX zpool and manually setting up zfs mountpoints before running the normal CD-based installation, using http://ftp.at.freebsd.org/pub/FreeBSD/snapshots/amd64/10.1-PRERELEASE/ from 2014-09-08. # Configs: ## EFI FAT partition - refind 0.8.3 - /EFI/FREEBSD/loader.efi copied from FreeBSD /boot/loader.efi - /EFI/boot copied from FreeBSD /boot (includes kernel modules etc) - loader.conf as follows: ``` kern.geom.label.disk_ident.enable=0 kern.geom.label.gptid.enable=0 kern.vty=vt zfs_load=YES vfs.root.mountfrom=zfs:zroot/root ``` at the console, OK show ... console=efi if that's of use. Setting `kern.vty=vt` or not makes no difference. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193745] [uefi] fresh install of 2014-09-08 10.1-beta1 snapshot boots but has no console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193745 Dave Cottlehuber d...@skunkwerks.at changed: What|Removed |Added Keywords||uefi, vt -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193745] [uefi] fresh install of 2014-09-08 10.1-beta1 snapshot boots but has no console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193745 Ed Maste ema...@freebsd.org changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|ema...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193748] New: Userland support for libzfs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193748 Bug ID: 193748 Summary: Userland support for libzfs Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: sms...@gmail.com Currently to compile against libzfs, or libzfs_core you need to have the entire kernel source available. Compiling against it is also a pain as many kernel only types seem to leak through or are present and shouldn't have to be. There should be a port for zfs-devel or something similar with the required headers need to link compile against libzfs, or libzfs_core. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193748] Userland support for libzfs and libzfs_core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193748 Sean Sill sms...@gmail.com changed: What|Removed |Added Summary|Userland support for libzfs |Userland support for libzfs ||and libzfs_core -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193749] New: ZFS libzpool_core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193749 Bug ID: 193749 Summary: ZFS libzpool_core Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: sms...@gmail.com Adding support to create zpools from an interface close to libzfs_core would reduce need to rely on the unstable libzfs. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193269] panic: kdb_switch: did not reenter debugger (from sysctl debug.kdb.enter=1 w/ i915kms)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193269 --- Comment #4 from commit-h...@freebsd.org --- A commit references this bug: Author: dumbbell Date: Thu Sep 18 14:38:21 UTC 2014 New revision: 271769 URL: http://svnweb.freebsd.org/changeset/base/271769 Log: vt(4): Merge several bug fixes and improvements SVN revisions in this MFC: 269779 270705 270706 271180 271250 271253 271682 271684 Detailed commit list: r269779: fbd: Fix a bug where vt_fb_attach() success would be considered a failure vt_fb_attach() currently always returns 0, but it could return a code defined in errno.h. However, it doesn't return a CN_* code. So checking its return value against CN_DEAD (which is 0) is incorrect, and in this case, a success becomes a failure. The consequence was unimportant, because the caller (drm_fb_helper.c) would only log an error message in this case. The console would still work. Approved by:nwhitehorn r270705: vt(4): Add cngrab() and cnungrab() callbacks They are used when a panic occurs or when entering a DDB session for instance. cngrab() forces a vt-switch to the console window, no matter if the original window is another terminal or an X session. However, cnungrab() doesn't vt-switch back to the original window currently. r270706: drm: Don't taskqueue vt-switch if under DDB/panic situation If DDB is active, we can't use a taskqueue thread to switch away from the X window, because this thread can't run. Reviewed by:ray@ Approved by:ray@ r271180: vt_vga: vd_setpixel_t and vd_drawrect_t are noop in text mode r271250: vt(4): Change the terminal and buffer sizes, even without a font This fixes a bug where scroll lock would not work for tty #0 when using vt_vga's textmode. The reason was that this window is created with a static 256x100 buffer, larger than the real size of 80x25. Now, in vt_change_font() and vt_compute_drawable_area(), we still perform operations even of the window has no font loaded (this is the case in textmode here vw-vw_font == NULL). One of these operation resizes the buffer accordingly. In vt_compute_drawable_area(), we take the terminal size as is (ie. 80x25) for the drawable area. The font argument to vt_set_border() is removed (it was never used) and the code now uses the computed drawable area instead of re-doing its own calculation. Reported by:Harald Schmalzbauer h.schmalzbauer_omnilan.de Tested by:Harald Schmalzbauer h.schmalzbauer_omnilan.de r271253: pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active This fixes a panic in the i915 driver when one uses debug.kdb.enter=1 under vt(4). PR:193269 Reported by:emaste@ Submitted by:avg@ r271682: vt(4): Fix a LOR which occurs during a call to vt_upgrade() Reported by:kib@ Review:https://reviews.freebsd.org/D785 Reviewed by:ray@ Approved by:ray@ r271684: vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative Review:https://reviews.freebsd.org/D789 Reviewed by:nwhitehorn Approved by:nwhitehorn Approved by:re (gjb) Changes: _U stable/10/ stable/10/sys/dev/drm2/drm_fb_helper.c stable/10/sys/dev/fb/fbd.c stable/10/sys/dev/vt/hw/efifb/efifb.c stable/10/sys/dev/vt/hw/fb/vt_early_fb.c stable/10/sys/dev/vt/hw/fb/vt_fb.c stable/10/sys/dev/vt/hw/fb/vt_fb.h stable/10/sys/dev/vt/hw/vga/vt_vga.c stable/10/sys/dev/vt/vt.h stable/10/sys/dev/vt/vt_core.c stable/10/sys/kern/kern_synch.c stable/10/sys/kern/subr_terminal.c stable/10/sys/powerpc/ps3/ps3_syscons.c stable/10/sys/sys/terminal.h -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 192463] vt and vt_vga, when two fonts are loaded, boarder not cleared
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192463 Jean-Sébastien Pédron dumbb...@freebsd.org changed: What|Removed |Added Status|Needs Triage|In Discussion CC||dumbb...@freebsd.org --- Comment #1 from Jean-Sébastien Pédron dumbb...@freebsd.org --- I believe this issue is fixed in HEAD and stable/10. Do you confirm this? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193595] bsdinstall should enable UEFI booting if booted from UEFI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193595 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: allanjude Date: Thu Sep 18 17:03:53 UTC 2014 New revision: 271790 URL: http://svnweb.freebsd.org/changeset/base/271790 Log: MFC r271563: Make the root-on-zfs part of the installer warn a user who booted the installer via UEFI that we do not support booting ZFS via UEFI yet PR:193595 Approved by:re (gjb), nwhitehorn Sponsored by:ScaleEngine Inc. Changes: _U stable/10/ stable/10/usr.sbin/bsdinstall/scripts/zfsboot -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 187315] unzip(1): base unzip does not recognize *.zip archives from dropbox.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187315
oli...@beefrankly.org changed:
What|Removed |Added
CC||oli...@beefrankly.org
--- Comment #2 from oli...@beefrankly.org ---
Some time ago I checked out the bug and tried to contact the author, but did
not get response...maybe he did not get it...here is a copy of the mail...
---
Hello des,
I contact you because you are the main author of
the /usr/src/usr.bin/unzip utility if I got it correct.
Well I took a glimpse into this PR bin/187315 and could need some
advice.
unzip(1) uses libarchive(3) for working with the archives.
To determine the filetype, there is a function called
archive_entry_filetype() in libarchive. As this function uses
the file acl.mode as input, it fails if an entry has no file mode and
returns a filetype of 0x0.
As the implementation of unzip expects to get a filetype of either
a regular file or a directory, it checks for that. And so
that sanity check for S_ISREG and S_ISDIR fails and the program skips
the entry.
unzip.c
/* I don't think this can happen in a zipfile.. */
if (!S_ISDIR(filetype) !S_ISREG(filetype)) {
warningx(skipping non-regular entry '%s', pathname);
ac(archive_read_data_skip(a));
free(pathname);
return;
}
The cause of this may be that dropbox creates the zipfile for you
on-the-fly. That means streaming it out of a database directly into a
zipfile. In this special circumstance, where there is no file and the
file comes from stdin, it is allowed by ZIP file archive standard to
keep the external file attribute 0x0. (see [1] 4.4.15 external file
attributes). As I understand it, the libarchive code uses this field for
filetype check.
I think that is what happens here (at least in the dropbox-file the
filetype is returned zero for all files and directories). I can
reproduce the error like that:
$ echo testtext | python -c import
sys
import
zipfile
z =
zipfile.ZipFile(sys.argv[1],'w')
z.writestr(sys.argv[2],sys.stdin.read())
z.close()
test.zip testfile1
$ unzip -l test.zip
Archive: test.zip
Length Date TimeName
9 03-16-14 00:47 testfile1
$ unzip test.zip
Archive: test.zip
unzip: skipping non-regular entry 'testfile1'
$ /usr/local/bin/unzip test.zip
Archive: test.zip
extracting: testfile1
$ cat testfile1
testtext
$
for a correct file zipinfo shows (example):
Unix file attributes (100744 octal):-rwxr--r--
Unix file attributes (040744 octal):drwxr--r--
for dropbox or above example:
Unix file attributes (000600 octal):?rw---
recognize the questionmark where filetype should be (=0x00).
The extraction seems to work correctly if we remove that sanity check
for S_ISDIR and S_ISREG. But as the program uses the information for
program flow that may be a problem.
As more and more archives are generated on the fly, maybe that issue
will get more serious.
Maybe you can give me a hint if it's okay to remove that sanity check
or if you want to keep it.
[1] https://www.pkware.com/documents/casestudies/APPNOTE.TXT
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193755] New: security update via freebsd-update does not install properly on 9.2-RELEASE, missing /usr/sbin/lwresd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193755 Bug ID: 193755 Summary: security update via freebsd-update does not install properly on 9.2-RELEASE, missing /usr/sbin/lwresd Product: Base System Version: 9.2-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: free...@dreamchaser.org On a 9.2-RELEASE system, on 2014-09-16 did freebsd-update fetch freebsd-update install and got: Installing updates...ln: ///usr/sbin/lwresd: no such file or directory done Aside from the main issue that the update does not install properly, it is not clear from the output whether one needs to do a rollback at this point. I would hope the update process rolls everything done up to that point back. $ uname -a FreeBSD breakaway.dreamchaser.org 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193756] New: /etc/rc.conf syslogd_flags ignored on boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193756 Bug ID: 193756 Summary: /etc/rc.conf syslogd_flags ignored on boot Product: Base System Version: 10.1-BETA1 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: conf Assignee: freebsd-bugs@FreeBSD.org Reporter: mi...@mikej.com Setting syslogd_flags= or syslogd_flags=value in /etc/rc.conf is ignored on boot and instead you get the default flag value -s as defined in /etc/defaults/rc.conf. Other init scripts that I tested behave as expected and honor their _flags in /etc/rc.conf Killing syslogd process killall -9 syslogd and restarting with /etc/rc.d/syslogd start set flags as expected -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193757] New: correct pid for syslogd not written to /var/run/syslog.pid on boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193757 Bug ID: 193757 Summary: correct pid for syslogd not written to /var/run/syslog.pid on boot Product: Base System Version: 10.1-BETA1 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: conf Assignee: freebsd-bugs@FreeBSD.org Reporter: mi...@mikej.com On initial system boot the correct running PID for syslogd is not written to /var/run/syslogd Stopping the process with killall -9 syslogd and then starting with /etc/rc.d/syslogd start correctly writes the correct pid to /var/run/syslog.pid -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193758] New: either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 Bug ID: 193758 Summary: either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade Product: Base System Version: 8.4-STABLE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: m...@exonetric.com On June 29, I updated an amd64 system with a GPT ZFS root, to FreeBSD 8.4-RELEASE-p13 #0 r268016: Sun Jun 29 12:58:11 UTC 2014 I rebooted and this worked without issue. On Sep 9, 2014, I upgraded both pools to the latest for 8.4-RELEASE and so the version property no longer applies. $ zpool get version NAME PROPERTY VALUESOURCE pool0 version -default pool1 version -default $ zpool status pool: pool0 state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM pool0 ONLINE 0 0 0 da0p3 ONLINE 0 0 0 errors: No known data errors pool: pool1 state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM pool1 ONLINE 0 0 0 da1p1 ONLINE 0 0 0 errors: No known data errors $ gpart show = 34 312477629 da0 GPT (149G) 341281 freebsd-boot (64k) 162 671088642 freebsd-swap (32G) 67109026 2453686373 freebsd-zfs (117G) = 34 312477629 da1 GPT (149G) 34 3124776291 freebsd-zfs (149G) I applied the recommended update to gptzfsboot and the pmbr as follows gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 On Sep. 16, I rebooted the system to find that it no longer booted and the system froze right after the first / symbol. I.e. the spinner did not spin. Even CTRL-ALT-DEL was insufficient to break it out of the frozen state, a reset or power cycle was required. We used a bootable 8.4 USB image to get access to the system after it became clear there was no way to boot from the internal drives. Using the fixit shell, we determined the pools were intact and undamaged and reapplied the bootcode again from the USB image as a speculative measure, all to no effect. The underlying block devices are 3ware RAID controller volumes as follows: $ egrep da[01] /var/run/dmesg.boot da0 at twa0 bus 0 scbus0 target 0 lun 0 da0: AMCC 9650SE-4LP DISK 3.08 Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 152577MB (312477696 512 byte sectors: 255H 63S/T 19450C) da1 at twa0 bus 0 scbus0 target 1 lun 0 da1: AMCC 9650SE-4LP DISK 3.08 Fixed Direct Access SCSI-5 device da1: 100.000MB/s transfers da1: 152577MB (312477696 512 byte sectors: 255H 63S/T 19450C) At this point, we've configured a USB stick to handle the boot phase and so that's the workaround, but this seems like quite an extreme failure mode for gptzfsboot that could probably do with some attention. I've not yet attempted to replicate this on any other system and here's the CPU/RAM for this one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 17716740096 (16896 MB) avail memory = 16535756800 (15769 MB) It's a TYAN Tempest i5100X S5375 motherboard with the following dmidecode details for the BIOS: Vendor: American Megatrends Inc. Version: 080014 Release Date: 01/30/2008 So, where is the boot process likely to have hung if it was so early and what does it mean if CTRL-ALT-DEL is ineffective? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193756] /etc/rc.conf syslogd_flags ignored on boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193756 --- Comment #2 from mi...@mikej.com --- FreeBSD charon 10.1-BETA1 FreeBSD 10.1-BETA1 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193595] bsdinstall should enable UEFI booting if booted from UEFI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193595 Nathan Whitehorn nwhiteh...@freebsd.org changed: What|Removed |Added Status|Needs Triage|Issue Resolved Resolution|--- |FIXED --- Comment #11 from Nathan Whitehorn nwhiteh...@freebsd.org --- Fix made and MFCed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193759] New: Wrong behaviour of IFS='|' set in /bin/sh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193759
Bug ID: 193759
Summary: Wrong behaviour of IFS='|' set in /bin/sh
Product: Base System
Version: 10.0-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs@FreeBSD.org
Reporter: michip...@gmail.com
Using IFS to set positional parameters as in
IFS='|' set -- $line
displays erratic behaviour. In the script below, the expected output is
A-1-2
B-1-2
C-1-2
but the first splitting is handled specially and we get
A|1|2--
B-1-2
C-1-2
8
mock()
{
cat EOF
A|1|2
B|1|2
C|1|2
EOF
}
demonstrate()
{
while read line; do
IFS='|' set -- $line
printf '%s-%s-%s\n' $1 $2 $3
done
}
mock | demonstrate
8
Note that splitting twice fixes the output.
8
demonstrate2()
{
while read line; do
# The following line has been intentionally duplicated
IFS='|' set -- $line
IFS='|' set -- $line
printf '%s-%s-%s\n' $1 $2 $3
done
}
mock | demonstrate2
8
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 --- Comment #1 from m...@exonetric.com --- This forum posting sounds very close to what I found. https://forums.freebsd.org/viewtopic.php?t=42419 So I'll also point out I have the following in /boot.config -hD 115200 Obviously the serial console worked fine with the prior version of gptzfsboot (from 8.2) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 155757] problems with setfib(1) behavior
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155757 Alan Somers asom...@freebsd.org changed: What|Removed |Added CC||asom...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|asom...@freebsd.org --- Comment #1 from Alan Somers asom...@freebsd.org --- vmiszczak, it looks like you encountered several bugs that I've recently fixed. The net route appeared in the wrong fib due to PR 187549. Ping failed, in the first case, probably due to PR 167947. Please retest using CURRENT, stable/10 greater than 267193, stable/9 greater than 271825, or 10.1-BETA1. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193761] New: [PATCH] Add error return to minidumpsys(), use in dumpsys()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193761 Bug ID: 193761 Summary: [PATCH] Add error return to minidumpsys(), use in dumpsys() Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: conrad.me...@isilon.com Created attachment 147460 -- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147460action=edit (Applies to CURRENT with -p0.) Passing errors up the stack is good. Related to bug 192036. Sponsored by:EMC / Isilon storage division -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
[Bug 193762] New: [cc_cdg] crash after change net.inet.tcp.cc.cdg.smoothing_factor
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193762 Bug ID: 193762 Summary: [cc_cdg] crash after change net.inet.tcp.cc.cdg.smoothing_factor Product: Base System Version: 10.1-BETA1 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: i...@mail.ua Hello, FreeBSD 10.1-BETA1 r271827. 1) # kldload cc_cdg 2) # sysctl net.inet.tcp.cc.algorithm=cdg 3) # sysctl net.inet.tcp.cc.cdg.smoothing_factor=0 After that system works 5-10 sec, freezes and restarts. I could reproduce it on my server and desktop. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
