documentation: daily(8)
Synopsis: daily(8) is inaccurate regarding /altroot Category: documentation Environment: System : OpenBSD 5.6 Details : OpenBSD 5.6 (GENERIC) #310: Fri Aug 8 00:14:24 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 Description: Regarding root filesystem backup, the daily(8) man page says The mount directory /altroot must exist, ... This is not accurate. All the other specified requirements are indeed necessary for proper functioning, but an /altroot directory is not required. The backup takes place just fine without it. How-To-Repeat: Configure things as specified, then run 'mv /etc/altroot /etc/altroot.not ; sh /etc/daily' and you will see that the backup happens just fine. Fix: Modify the documentation to be consistent with the script's actual functioning, or modify the script to actually require the existence of an /altroot directory.
Re: documentation: daily(8)
On Fri, Dec 12, 2014 at 06:50:41PM -0700, flesheno...@gmail.com wrote: Synopsis:daily(8) is inaccurate regarding /altroot Category:documentation Environment: System : OpenBSD 5.6 Details : OpenBSD 5.6 (GENERIC) #310: Fri Aug 8 00:14:24 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 Description: Regarding root filesystem backup, the daily(8) man page says The mount directory /altroot must exist, ... This is not accurate. All the other specified requirements are indeed necessary for proper functioning, but an /altroot directory is not required. The backup takes place just fine without it. How-To-Repeat: Configure things as specified, then run 'mv /etc/altroot /etc/altroot.not ; sh /etc/daily' and you will see that the backup happens just fine. Fix: Modify the documentation to be consistent with the script's actual functioning, or modify the script to actually require the existence of an /altroot directory. /altroot or /etc/altroot? jmc
[PATCH] FUSE doesn't handle timeouts in fb_queue
If a fuse file system takes too long to process an operation then
fb_queue times out and fuse gets very unhappy. It should keep
waiting.
Here's the patch.
Index: fusebuf.c
===
RCS file: /cvs/src/sys/miscfs/fuse/fusebuf.c,v
retrieving revision 1.10
diff -u -p -r1.10 fusebuf.c
--- fusebuf.c 3 Dec 2014 23:00:49 - 1.10
+++ fusebuf.c 14 Dec 2014 11:34:58 -
@@ -55,7 +55,10 @@ fb_queue(dev_t dev, struct fusebuf *fbuf
fuse_device_queue_fbuf(dev, fbuf);
- if ((error = tsleep(fbuf, PWAIT, fuse msg, TSLEEP_TIMEOUT * hz))) {
+ while ((error = tsleep(fbuf, PWAIT, fuse msg,
+ TSLEEP_TIMEOUT * hz)) == EWOULDBLOCK);
+
+ if (error) {
fuse_device_cleanup(dev, fbuf);
return (error);
}
[PATCH] Add support for -d option to libfuse
The -d option prevents fuse clients from detaching from the terminal and
running in the background. This is of course useful when debugging. The
following patch adds support for this option and also ensures that the
FUSE_DEBUG environment variable turns on debug output for clients that
don't call fuse_parse_cmdline.
Tested on amd64 with ntfs-3g, sshfs and fuse-exfat.
Index: libfuse/fuse.c
===
RCS file: /cvs/src/lib/libfuse/fuse.c,v
retrieving revision 1.24
diff -u -p -r1.24 fuse.c
--- libfuse/fuse.c 20 May 2014 13:32:22 - 1.24
+++ libfuse/fuse.c 14 Dec 2014 22:45:40 -
@@ -40,6 +40,7 @@ enum {
KEY_HELP_WITHOUT_HEADER,
KEY_VERSION,
KEY_MAXREAD,
+ KEY_FOREGROUND,
KEY_STUB
};
@@ -51,7 +52,7 @@ static struct fuse_opt fuse_core_opts[]
FUSE_OPT_KEY(--version, KEY_VERSION),
FUSE_OPT_KEY(max_read=, KEY_MAXREAD),
FUSE_OPT_KEY(debug, KEY_STUB),
- FUSE_OPT_KEY(-d, KEY_STUB),
+ FUSE_OPT_KEY(-d, KEY_FOREGROUND),
FUSE_OPT_KEY(-f, KEY_STUB),
FUSE_OPT_KEY(-s, KEY_STUB),
FUSE_OPT_KEY(use_ino, KEY_STUB),
@@ -264,8 +265,11 @@ fuse_new(struct fuse_chan *fc, unused st
}
int
-fuse_daemonize(unused int foreground)
+fuse_daemonize(int foreground)
{
+ if (foreground)
+ return 0;
+
#ifdef DEBUG
return (daemon(0,1));
#else
@@ -370,6 +374,9 @@ ifuse_process_opt(void *data, const char
}
max_read = res;
break;
+ case KEY_FOREGROUND:
+ opt-foreground = 1;
+ break;
case FUSE_OPT_KEY_NONOPT:
if (opt-mp == NULL) {
opt-mp = realpath(arg, opt-mp);
@@ -406,7 +413,7 @@ ifuse_process_opt(void *data, const char
}
int
-fuse_parse_cmdline(struct fuse_args *args, char **mp, int *mt, unused int *fg)
+fuse_parse_cmdline(struct fuse_args *args, char **mp, int *mt, int *fg)
{
struct fuse_core_opt opt;
@@ -424,6 +431,7 @@ fuse_parse_cmdline(struct fuse_args *arg
*mp = strdup(opt.mp);
*mt = 0;
+ *fg = opt.foreground;
return (0);
}
Index: libfuse/fuse_opt.c
===
RCS file: /cvs/src/lib/libfuse/fuse_opt.c,v
retrieving revision 1.11
diff -u -p -r1.11 fuse_opt.c
--- libfuse/fuse_opt.c 8 Oct 2014 04:50:10 - 1.11
+++ libfuse/fuse_opt.c 14 Dec 2014 22:45:40 -
@@ -334,6 +334,9 @@ fuse_opt_insert_arg(struct fuse_args *ar
char *this_arg, *next_arg;
int i;
+#ifdef DEBUG
+ ifuse_debug_init();
+#endif
if (name == NULL)
return (-1);
Index: libfuse/fuse_private.h
===
RCS file: /cvs/src/lib/libfuse/fuse_private.h,v
retrieving revision 1.10
diff -u -p -r1.10 fuse_private.h
--- libfuse/fuse_private.h 28 Apr 2014 13:08:34 - 1.10
+++ libfuse/fuse_private.h 14 Dec 2014 22:45:40 -
@@ -72,6 +72,7 @@ struct fuse_config {
struct fuse_core_opt {
char *mp;
+ int foreground;
};
struct fuse {
Re: At boot startup, black screen
I reinstalled it with the last snapshots. Installation process using http method: OK At startup, i get the black screen after this line: npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 Noway to connect from an other computer: no pings and no ssh; So init doesnt start /etc/rc (so no dmesg.boot in /var/run) The only way i found, is to make screenshots : http://snag.gy/lnqUE.jpg http://snag.gy/aQg7a.jpg http://snag.gy/9eRyC.jpg http://snag.gy/ruCob.jpg http://snag.gy/Fk6zI.jpg http://snag.gy/TEcWt.jpg Hope this will help to debug. 2014-12-12 20:12 GMT+04:00 Theo de Raadt dera...@cvs.openbsd.org: Synopsis:At boot startup, black screen, need to disable acpi using UKC OpenBSD 5.6-current (GENERIC.MP) #609: Thu Dec 11 21:36:32 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz (GenuineIntel 686-class) 3.06 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC real mem = 3144695808 (2999MB) avail mem = 3080982528 (2938MB) User Kernel Config UKC disqbl\^H \^H\^H \^H\^H \^Hable acpi 492 acpi0 disabled UKC di\^H \^H\^H \^Hquit Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/30/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.6 @ 0xfbac0 (45 entries) bios0: vendor Dell Inc. version A02 date 11/30/2009 bios0: Dell Inc. Inspiron 580 acpi at bios0 function 0x0 not configured mpbios0 at bios0: Intel MP Specification 1.4 A major problem. You have now disabled acpi. Now your machine is using mpbios. And that means everything changes. Your dmesg is now useless to us. Everything before the acpi line is uninteresting and uninformative, but everything after the mpbios line influenced by MPBIOS, so it is not very useful either. One day you guys are going to stop following the 'disable acpi' recipe, but until then the replies will remain the same: What you just submitted as a bug report is useless. A 'disable acpi' dmest does not help find the problem. What you should have done is get the machine setup well enough that you can login from remote in the failing configuration, then collect the information. -- ==wma
