DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082009-10-23T17:28:21ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #1584 (In Progress): can't use ssh from jail: debug1: read_passphrase: can't o...https://bugs.dragonflybsd.org/issues/15842009-10-23T17:28:21Zcorecode
<p>When running ssh from a jail, I get:</p>
<p>debug1: read_passphrase: can't open /dev/tty: Device busy</p>
<p>can also repeat this:</p>
<ol>
<li>cat `tty`<br />cat: /dev/pts/4: Device busy</li>
</ol>
<p>outside:<br />% cat `tty`<br />^C</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1556 (New): many processes stuck in "hmrrcm", system unusablehttps://bugs.dragonflybsd.org/issues/15562009-10-04T01:19:29Zcorecode
<p>On chlamydia I have many processes stuck in "hmrrcm", making the system <br />unusable - can't open new shells, etc. After a minute or two the <br />situation seems to improve again.</p> DragonFlyBSD - Bug #1547 (In Progress): disklabel64 automatic sizinghttps://bugs.dragonflybsd.org/issues/15472009-10-02T20:18:02Zcorecode
<p>disklabel64 is a prime example for unintuitive behavior:</p>
<ul>
<li>it requires an arbitrary 4KB aligment on sizes and offset</li>
<li>size aligments seem to be enforced directly, but offset alignments are <br />not. offsets just show up as "ILLEGAL" when re-editing the label. no <br />complaint before</li>
<li>automatic sizing using "*" does not work:</li>
</ul>
<p>d: * * HAMMER</p>
<p>but then:<br />partition d: size out of bounds (4825292800)</p>
<p>the size is completely off, roughly by a factor of 10(!)</p>
<p>I had to do:</p>
<p>d: 4 * HAMMER</p>
<p>and then re-edit to make it read</p>
<p>d: * 4712200 HAMMER</p>
<ul>
<li>there is no way to change the display block size</li>
<li>there is no way to specify sector counts or byte counts in size/offset</li>
</ul> DragonFlyBSD - Bug #1538 (New): mountroot should probe file systemshttps://bugs.dragonflybsd.org/issues/15382009-09-28T01:48:34Zcorecode
<p>When mounting root from hammer, it is necessary to specify the file <br />system type in the vfs.root.mountfrom setting, otherwise the machine <br />will just be unhappy and issue the mountroot prompt (or rather, directly <br />go to ddb, see other bug report). This is very inconvenient and <br />irritating. The kernel should try all available file systems to mount root.</p>
<p>Possibly this should also be extended to mount itself, but this bug <br />report only deals with the mountroot issue.</p> DragonFlyBSD - Bug #1528 (In Progress): ktrace does not show proper return values for pipe(2)https://bugs.dragonflybsd.org/issues/15282009-09-24T15:58:42Zcorecode
<p>When ktracing a pipe syscall, the output is:</p>
<p>57705 a.out CALL pipe<br />57705 a.out RET pipe 3</p>
<p>However, the return value of pipe is 0, and the returned value for the <br />file descs is {3, 4}.</p> DragonFlyBSD - Bug #1475 (In Progress): kernel blocks with low memory and syscons setting a high ...https://bugs.dragonflybsd.org/issues/14752009-09-01T03:06:17Zcorecode
<p>I just booted with hw.physmem=32m. I have my allscreens_flags set to -h <br />4700 MODE_279. When processing the allscreens_flags in rc.d, the system <br />blocks (not hangs) while booting, ^T says "no controlling terminal". No <br />mode change occured. Same happened with 48m, just with a mode change, <br />so I suspect it to have worked for one screen but then not for another.</p> DragonFlyBSD - Bug #1474 (New): ithread 1 unexpectedly rescheduledhttps://bugs.dragonflybsd.org/issues/14742009-09-01T03:02:23Zcorecode
<p>Just had a hang during high swap activity. I kept pressing ^T to see <br />what is happening, suddenly the kernel said "ithread 1 unexpectedly <br />rescheduled". SMP 4-way system.</p> DragonFlyBSD - Bug #1469 (In Progress): Hammer history security concernhttps://bugs.dragonflybsd.org/issues/14692009-08-28T17:59:03Zcorecode
<p>Hammer history mounts allow access to deleted files.</p>
<p>This can be an issue if you realized that this data should not have been <br />available in the first place.</p>
<p>An alternate scenario is that group membership changed, and you don't <br />want the new group members to have access to past data.</p>
<p>I think we should address this in some sort in the release. One way is <br />to only allow the owner to access the snapshot, and ignore group/other <br />permissions on snapshots. This is probably very inconvenient, <br />especially for root owned system directories.</p>
<p>Another way would be to somehow combine current and past owner/flags, <br />but this is probably hard to reason about.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1442 (New): blocking SIGSEGV and triggering a segment violation produces an a...https://bugs.dragonflybsd.org/issues/14422009-07-28T20:05:09Zcorecode
<p>If a process blocks (or ignores?) SIGSEGV (or SIGFPE, SIGILL, SIGBUS, etc.) and<br />then triggers the associated signal without having a handler installed, the<br />process/thread will be stuck on the triggering instruction without any hope.</p>
<p>I think the kernel should detect such a situation (i.e. trap leading to<br />blocked/ignored signal without handler) and should kill the process.</p> DragonFlyBSD - Bug #1440 (New): ptrace/gdb doesn't work after process blocks SIGTRAPhttps://bugs.dragonflybsd.org/issues/14402009-07-28T20:01:56Zcorecode
<p>If a process blocks SIGTRAP, an attached debugger will not be able to break<br />again (same is true for SIGINT, for instance).</p>
<p>We should change the behavior so that the debugger will be able to see this<br />signal, or to change how a ptrace'd process gets suspended on trap exceptions.</p> DragonFlyBSD - Bug #1307 (In Progress): hammer tid -2 shows unexpected resulthttps://bugs.dragonflybsd.org/issues/13072009-03-06T21:58:25Zcorecode
<p>When using the HAMMER tid -2, 0xfffffffffffffffe, HAMMER will actually return<br />the second oldest file, not the latest nor the oldest. -1, -3, -4, etc. all<br />show the newest.</p> DragonFlyBSD - Bug #1198 (New): DDB loops panic in db_read_byteshttps://bugs.dragonflybsd.org/issues/11982009-01-05T22:50:04Zcorecode
<p>I have some panic which I can't debug because there is a flurry of panic<br />messages on my screen. The offender is:</p>
<p>sys/platform/pc32/i386/db_interface.c:208</p>
<p>I see that ddb uses longjmp, but seems that doesn't work here somehow.</p> DragonFlyBSD - Bug #781 (In Progress): fdisk uses wrong geometry on usb flash driveshttps://bugs.dragonflybsd.org/issues/7812007-08-21T17:27:04Zcorecode
<p>hey,</p>
<p>fdisk uses some stupid geometry like 1/0/1 on usb flash drives. umass however detects the geometry correctly; it seems this information is not correctly passed along.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #731 (New): system freeze on "slice too large"https://bugs.dragonflybsd.org/issues/7312007-07-15T20:11:05Zcorecode
<p>hey,</p>
<p>i've now had twice a nasty freeze (kind of) with something like this (hand transcribed):</p>
<p><code>dscheck(#ad/0x20021): slice too large 2/2</code><br />..</p>
<p>then vinum tells me that it put "build" down and continues:</p>
<p>fatal: build.p0.s0 read error, offset 33831591936 for 4096 bytes<br />build.p0.s0: user buffer offset 10209280000 for 4096 bytes</p>
<p>(more slice too large follow)</p>
<p>then, the namecache does</p>
<p>blocked on 0xd4fb7b58 "corecode"</p>
<p>and repeats it every 30 seconds or so. system is unoperable at this point.</p>
<p>breaking to the debugger works, but dumpsys does not work:</p>
<pre>
dumping to dev #ad/0x20023, blockno 2130432
dump failed, reason: area improper
</pre>
<p>i'm running:<br /><pre>
DragonFly sweatshorts.home.corecode.ath.cx 1.9.0-DEVELOPMENT DragonFly 1.9.0-DEVELOPMENT #14: Sun Jun 17 11:03:58 CEST 2007 corecode@sweatshorts.home.corecode.ath.cx:/usr/build/obj/usr/build/src/sys/SWEATSHORTS i386
</pre></p>
<p>i've attached relevant outputs.</p>
<p>thanks,<br /> simon</p> DragonFlyBSD - Bug #341 (New): Vinum erroneously repors devices as busyhttps://bugs.dragonflybsd.org/issues/3412006-10-05T22:58:36Zcorecode
<p>Most of the time vinum reports devices as busy when they are not. At least I<br />can't find a different way than to use stop -f.</p>