Re: Weird regex behavior on 9.1-RELEASE on amd64 in 32-bit mode
Thanks for the quick answer! Konstantin Belousov writes: > -m32 does not work on stable. You need HEAD. So I should have better luck with a binary compiled on i386, right? -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Weird regex behavior on 9.1-RELEASE on amd64 in 32-bit mode
I noticed that scsh (which only runs in 32-bit mode) fails on amd64. I
narrowed it down to a regex malfunction (I think). This program:
snip
#include
#include
int
main(void)
{
regex_t r;
int status = regcomp(&r, "/afs", REG_EXTENDED);
size_t nmatch = 1 + r.re_nsub;
regmatch_t pmatch[32];
status = regexec(&r, "/afs/informatik", nmatch, pmatch, 0);
{
int i;
for(i = 0; i < nmatch; i--) {
printf("%d: %d - %d\n", i, (int) pmatch[i].rm_so, (int) pmatch[i].rm_eo);
}
}
return 0;
}
snip
This giveds me:
# gcc r.c
# ./a.out
0: 0 - 4
# gcc -m32 r.c
# ./a.out
0: 0 - 0
Is it me or is there a bug? Help would be much appreciated!
--
Regards,
Mike
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: After 7.3->8.1, moused on serial mouse draws 100% CPU
Ed Schouten writes:
> * Michael Sperber wrote:
>> select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
>> read(2,0xbfbfe4ed,1) ERR#35 'Resource temporarily
>> unavailable'
>
> Thanks for the debug info. Sorry for not asking this earlier, but can
> you also give me the output of `pstat -t` for cuau0?
This?
ttyu0 179200 1562 20160 1790 217 0 0 ICOolZ
--
Regards,
Mike
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to predict drive number change for 7.3->8.1 upgrade?
"Marat N.Afanasyev" writes: > you may try the following commands: > > sysctl kern.geom.debugflags=16 > > foreach fs (your-filesystems) > glabel label your-$fs-label your-$fs-device > end > > echo geom_label_load="YES" >> /boot/loader.conf > reboot > > and see if the labels appear in /dev/label Is this safe to do? The man page for glabel seems to imply that glabel should be used before newfs, and tunefs after newfs. -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to predict drive number change for 7.3->8.1 upgrade?
"Marat N.Afanasyev" writes: > Michael Sperber wrote: >> >> Oliver Fromme writes: >> >>> Michael Sperber wrote: >>> > I just upgraded my desktop system from 7.3 to 8.1, and the main hard >>> > drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the >>> > initial boot failed when trying to mount the root file system from ad6. >>> > >>> > The desktop system is now fixed, but I also have a rented server with >>> > only a serial console, and I worry that the upgrade is going to leave >>> me >>> > with a dead machine. Is there any way to predict how the drive number >>> > changes? (Why does it change at all?) If so, what's the proper way to >>> > tell the system the initial root device *before* rebooting? >>> >>> Remove "options ATA_STATIC_ID" from your kernel config >>> before building the new kernel and rebooting. Then your >>> first disk will be ad0, no matter what controller and >>> channel it is connected to. Be sure to update your >>> /etc/fstab file. >> >> Ah, excellent - that's what I was looking for. Thanks! >> > beware of drago^Wchanging of adX numbers each time you add/remove > drive ;) It's better to label filesystems, imho ;) This is a rented server, so I no drive will ever be removed or added. On the other hand, if I understand it correctly, I'll need to unmount the root partition in order to label it - right? -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to predict drive number change for 7.3->8.1 upgrade?
Oliver Fromme writes: > Michael Sperber wrote: > > I just upgraded my desktop system from 7.3 to 8.1, and the main hard > > drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the > > initial boot failed when trying to mount the root file system from ad6. > > > > The desktop system is now fixed, but I also have a rented server with > > only a serial console, and I worry that the upgrade is going to leave me > > with a dead machine. Is there any way to predict how the drive number > > changes? (Why does it change at all?) If so, what's the proper way to > > tell the system the initial root device *before* rebooting? > > Remove "options ATA_STATIC_ID" from your kernel config > before building the new kernel and rebooting. Then your > first disk will be ad0, no matter what controller and > channel it is connected to. Be sure to update your > /etc/fstab file. Ah, excellent - that's what I was looking for. Thanks! -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: After 7.3->8.1, moused on serial mouse draws 100% CPU
Ed Schouten writes:
> I should really get myself subscribed to sta...@...
>
> Anyway, Michael, can you attach truss to the process to see what it's
> actually doing (truss -p $pid)? I'm interested in a single `iteration'
> of what it's doing. Thanks!
The relevant bit is this, I think:
open("/dev/cuau0",O_RDWR|O_NONBLOCK,01001172450) = 2 (0x2)
ioctl(2,MOUSE_SETLEVEL,0x805004c)ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETLEVEL,0xbfbfe4cc) ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETHWINFO,0x8050088) ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETMODE,0x805009c) ERR#25 'Inappropriate ioctl
for device'
write(2,"moused: ",8)= 8 (0x8)
write(2,"PnP COM device rev 1.0 probe...",31)= 31 (0x1f)
write(2,"\n",1) = 1 (0x1)
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
ioctl(2,TIOCMSET,0xbfbfe4c4) = 0 (0x0)
nanosleep({0.24000 })= 0 (0x0)
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
write(2,"moused: ",8)ERR#5 'Input/output error'
write(2,"\n",1) ERR#5 'Input/output error'
write(2,"\n",1) ERR#5 'Input/output error'
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
ioctl(2,TIOCMSET,0xbfbfe4c4) = 0 (0x0)
nanosleep({0.24000 })= 0 (0x0)
ioctl(2,TIOCGETA,0xbfbfe2fc) = 0 (0x0)
ioctl(2,TIOCSETAW,0xbfbfe2fc)= 0 (0x0)
nanosleep({0.1 })= 0 (0x0)
ioctl(2,TIOCSETAW,0xbfbfe2fc)= 0 (0x0)
ioctl(2,TIOCFLUSH,0xbfbfe4c4)= 0 (0x0)
ioctl(2,TIOCMBIS,0xbfbfe4c4) = 0 (0x0)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
write(2,"\n",1) ERR#5 'Input/output error'
nanosleep({0.24000 })= 0 (0x0)
read(2,"3",1)= 1 (0x1)
write(2,"\n",1) ERR#5 'Input/output error'
read(2,"\b",1) = 1 (0x1)
write(2,"\n",1) ERR#5 'Input/output error'
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^A",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^Z",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"+",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"-",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,",",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^P",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^P",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^P",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^Q",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"<",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"<",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"-",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"/",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"5",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"3",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"%",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"<",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"0",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,".",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"0",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"\^P",1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,"&",1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0
Re: After 7.3->8.1, moused on serial mouse draws 100% CPU
Jeremy Chadwick writes: > Michael, in the meantime can you provide dmesg details that pertain to > your serial ports? uartXX devices would be sufficient, in addition the > device its attached to (e.g. acpi0, etc.). uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] acpi0: <080907 RSDT1802> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed > (Footnote: I wasn't even aware people still had/used serial mice any > more, given the popularity of PS/2, and now USB...) They don't make trackballs like the old Kensington models anymore :-) -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to predict drive number change for 7.3->8.1 upgrade?
Stefan Bethke writes: > Am 16.09.2010 um 11:05 schrieb Michael Sperber: > >> I just upgraded my desktop system from 7.3 to 8.1, and the main hard >> drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the >> initial boot failed when trying to mount the root file system from ad6. >> >> The desktop system is now fixed, but I also have a rented server with >> only a serial console, and I worry that the upgrade is going to leave me >> with a dead machine. Is there any way to predict how the drive number >> changes? (Why does it change at all?) If so, what's the proper way to >> tell the system the initial root device *before* rebooting? > > If you have a serial console, you can always enter the root device at > the prompt, so you can recover there. I know. But given the serial-console problems recently reported here, I was a bit reluctant to take the risk. > Long-term, the best option is to label your filesystems or partitions, > and use the label entries in fstab instead of the device names. I > don't remember what 7.3 offers in terms of labels, but glabel should > be available. Check tunefs if it offers the -L volname option, that's > even better. That sounds like a good idea. Thanks! -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How to predict drive number change for 7.3->8.1 upgrade?
I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
After 7.3->8.1, moused on serial mouse draws 100% CPU
After upgrading from 7.3 to 8.1, moused has started drawing 100% CPU (even when the mouse is not used). moused -d -f doesn't output anything suspicious - in particular, it does not display anything when the mouse is not moved. root10833 100.0 0.1 1732 1100 v0 R+ 10:51AM 8:47.62 /usr/sbin/moused -d -F 200 -A 1.5 -a 0.5 -p /dev/cuau0 -t auto -d -f FWIW, I was using the uart serial driver even on 7.3. (Maybe this is also the time to mention that mouse movement got much slower after the move to uart - that's why the -F -A -a settings are in there.) Any help would be much appreciated! -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrade FreeBSD 7.1 to 7.2
Robert Watson writes: > FWIW, the main problem I ran into with my 8.0 upgrade is that 8.0 uses > the uart(4) driver for serial ports, and sio(4), 7.2's default, has > been removed. They require mutually exclusive lines in device.hints > and different /etc/ttys lines. If you rely on a serial console, I > would recommend first switching 7.2 to using uart, pausing for a bit, > and then switching forward to 8 so that you separate the risks > associated with changing console drivers from those associated with > sliding a major kernel version. Could you briefly elaborate on how that's done with 7.x? I.e. is changing device.hints and /etc/ttys enough (what changes?), or do I need to recompile the kernel? (I'm a bit confused because both uart and sio seem to be in GENERIC, but I haven't been able to active uart through device.hints. I couldn't find anything on freebsd.org or the internets, either.) A few hints would be much appreciated! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd question
Andriy Gapon writes:
> on 28/02/2009 16:34 Kostik Belousov said the following:
>> On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
>>> I'm trying to make devd run an stty command whenever a USB serial device
>>> is attached. Unfortunately, $device-name is ucom[0-9] and the device
>>> names are /dev/cuaU[0-9] - how do I get the correct name in the device
>>> action? I haven't found a way to extract the number by itself, so I'm
>>> stuck with specifying a separate rule for each number, like so:
>>>
>>> attach 100 {
>>> device-name "ucom0";
>>> action "stty -f /dev/cuaU0.init raw";
>>> };
>>>
>>> Help would be much appreciated!
>>
>> There are some other notifications that are send through devctl when
>> cdev is created. They have system set to DEVFS, subsystem to CDEV,
>> and type CREATE. The data is the /dev node name. I am not sure how
>> to assign the action in the devd.
>
> A tested example:
> notify 1000 {
> match "system""DEVFS";
> match "subsystem" "CDEV";
> match "cdev" "^da[0-9]+$";
> action "echo 't120o3l32 b>c+f+16' > /dev/speaker";
> };
I'm probably not understanding this---but how is the device number
transferred from the "cdev" match to the "action" line?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
devd question
I'm trying to make devd run an stty command whenever a USB serial device
is attached. Unfortunately, $device-name is ucom[0-9] and the device
names are /dev/cuaU[0-9] - how do I get the correct name in the device
action? I haven't found a way to extract the number by itself, so I'm
stuck with specifying a separate rule for each number, like so:
attach 100 {
device-name "ucom0";
action "stty -f /dev/cuaU0.init raw";
};
Help would be much appreciated!
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mountd fails intermittently
Michael Sperber <[EMAIL PROTECTED]> writes: > I'm running 5.4-STABLE (about two weeks old), and have just set up an > NFS server for the first time. Remote mounts sometimes work fine, and > sometimes fail. > > The symptoms are that "showmount -e" sez > > showmount: can't do exports rpc > > and that "rpcinfo -u mountd" often works fine n times in a row, > and then stops working, like so: Turns out that mountd seems to be trying to do reverse DNS lookups, and when those block, the whole process locks up. I don't understand why, though: the servers listed in /etc/exports are by IP. Any ideas? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mountd fails intermittently
Oliver Fromme <[EMAIL PROTECTED]> writes: > Michael Sperber <[EMAIL PROTECTED]> wrote: > > Oliver Fromme <[EMAIL PROTECTED]> writes: > > > That looks like your rpcbind(8) process died. Can you > > > check that with ps? Also, are there any warnings or > > > errors reported in /var/log/messages? > > > > No, it's still running. It shows up in rpcinfo (as does nfsd), > > But mountd does not show up there? It shows up, too. It just doesn't respond to pings. > Now the one question is: What are the circumstances under > which the problem can be reproduced? :-) Of course I'm > aware that that's probably a tough question. It's pretty reproducible: A mount attempt from my one problematic client will do it. > 1. First of all, it might be helpful to see the contents > of your /etc/exports. To be honest, I don't think that > it is causing the problem, but you never know. /storage/disk1 192.168.1.100 > 2. Does your mountd log anything to /var/log/messages? > No. > 3. What flags are you using with rpcbind and mountd, rpcbind: no flags mountd: -r (but problem shows up without it, too) > if > any? What flags are you using with the mount command > line (i.e. anything unusual)? No flags: mount_nfs matt://storag/disk1 > 4. Please post the output from these commands (preferably > before failure and after failure, if possible): > # rpcinfo > # sockstat | egrep "mountd|rpc" Hrm. I see that just running these commands (on the server) pretty reliably puts it into failure mode. So here's the output from one run: program version netid addressserviceowner 104tcp 0.0.0.0.0.111 rpcbindsuperuser 103tcp 0.0.0.0.0.111 rpcbindsuperuser 102tcp 0.0.0.0.0.111 rpcbindsuperuser 104udp 0.0.0.0.0.111 rpcbindsuperuser 103udp 0.0.0.0.0.111 rpcbindsuperuser 102udp 0.0.0.0.0.111 rpcbindsuperuser 104tcp6 ::.0.111 rpcbindsuperuser 103tcp6 ::.0.111 rpcbindsuperuser 104udp6 ::.0.111 rpcbindsuperuser 103udp6 ::.0.111 rpcbindsuperuser 104local /var/run/rpcbind.sock rpcbindsuperuser 103local /var/run/rpcbind.sock rpcbindsuperuser 102local /var/run/rpcbind.sock rpcbindsuperuser 132udp 0.0.0.0.8.1nfssuperuser 133udp 0.0.0.0.8.1nfssuperuser 132udp6 ::.8.1 nfssuperuser 133udp6 ::.8.1 nfssuperuser 132tcp 0.0.0.0.8.1nfssuperuser 133tcp 0.0.0.0.8.1nfssuperuser 132tcp6 ::.8.1 nfssuperuser 133tcp6 ::.8.1 nfssuperuser 151udp 0.0.0.0.3.247 mountd superuser 153udp 0.0.0.0.3.247 mountd superuser 151tcp 0.0.0.0.2.99 mountd superuser 153tcp 0.0.0.0.2.99 mountd superuser 151udp6 ::.3.246 mountd superuser 153udp6 ::.3.246 mountd superuser 151tcp6 ::.2.98mountd superuser 153tcp6 ::.2.98mountd superuser root mountd 72379 4 udp4 *:1015*:* root mountd 72379 7 tcp4 *:611 *:* root mountd 72379 8 udp6 *:1014*:* root mountd 72379 9 tcp6 *:610 *:* root rpcbind54162 4 udp6 *:* *:* root rpcbind54162 7 stream /var/run/rpcbind.sock root rpcbind54162 8 udp6 *:111 *:* root rpcbind54162 9 udp6 *:642 *:* root rpcbind54162 10 tcp6 *:111 *:* root rpcbind54162 11 udp4 *:111 *:* root rpcbind54162 12 udp4 *:673 *:* root rpcbind54162 13 tcp4 *:111 *:* > 5. If all else fails, maybe tracing the mountd process > during a failing mount attempt might be helpful. > Personally I prefer strace (from the ports collection) > for the more useful output, but you can also use ktrace > which is in the base system. I'll try that somet
Re: mountd fails intermittently
Oliver Fromme <[EMAIL PROTECTED]> writes: > That looks like your rpcbind(8) process died. Can you > check that with ps? Also, are there any warnings or > errors reported in /var/log/messages? No, it's still running. It shows up in rpcinfo (as does nfsd), and rpcbind itself also replies to pings. In fact, I can usually temporarily fix the problem by killing and restarting mountd. (Not long enough to bring up my clients, though.) (kill -HUP doesn't help, btw.) Moreover, the one client I have that's managed to mount, works. Looking on the 'net, I can see quite a few other people had very similar problems, but nobody's ever posted a reliable fix. (Or anything other than "kill and restart.") Notably: http://www.freebsddiary.org/nfs.php -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mountd fails intermittently
I'm running 5.4-STABLE (about two weeks old), and have just set up an NFS server for the first time. Remote mounts sometimes work fine, and sometimes fail. The symptoms are that "showmount -e" sez showmount: can't do exports rpc and that "rpcinfo -u mountd" often works fine n times in a row, and then stops working, like so: ... Michael-Sperbers-Computer[105] rpcinfo -u matt mountd program 15 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3 program 15 version 2 is not available program 15 version 3 ready and waiting Michael-Sperbers-Computer[106] rpcinfo -u matt mountd program 15 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3 program 15 version 2 is not available program 15 version 3 ready and waiting Michael-Sperbers-Computer[107] rpcinfo -u matt mountd program 15 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3 program 15 version 2 is not available program 15 version 3 ready and waiting Michael-Sperbers-Computer[108] rpcinfo -u matt mountd program 15 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3 program 15 version 2 is not available program 15 version 3 ready and waiting Michael-Sperbers-Computer[109] rpcinfo -u matt mountd rpcinfo: RPC: Timed out program 15 version 0 is not available >From then on, it'll keep failing. ... and, of course, doing it from the machine I really want to be doing it from reliably switches it to failure mode. Any ideas on what I should do? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: No root crontab in 4.6-RELEASE?
>>>>> "Thomas" == Thomas Seck <[EMAIL PROTECTED]> writes: Thomas> * Michael Sperber [Mr. Preprocessor] ([EMAIL PROTECTED]): >> >>>>> "Thomas" == Thomas Seck <[EMAIL PROTECTED]> writes: >> Thomas> "[...] Cron also searches /etc/crontab...". Thomas> Thomas> The original poster obviously did not bother to read this document. Thomas> Failing to read documentation and posting false claims on a public Thomas> mailing list is a behaviour that drives me up the wall. >> >> That would be me, I guess. I never claimed there's no /etc/crontab >> file. I claimed there's no root crontab which, as some posters have >> noted, is something different. Thomas> Uh, oh. My mind thought of "the posting I originally replied to". Thomas> What my hands made of it is what was finally sent out. Sorry. No problem! >> On the 4.3 systems I have around here, there's a root crontab starting >> like this: >> # DO NOT EDIT THIS FILE - edit the master and reinstall. >> # (/tmp/adcrcln339/crontab installed on Mon Jun 11 20:53:28 2001) >> # (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.12.2.2 >2000/12/11 01:03:31 obrien Exp $) >> >> It's no big deal. I was just wondering where that came from and why >> I'm no longer seeing it. Thomas> I get your meaning. According to cvs, the behaviour of 'crontab -u root' Thomas> was changed in version 1.12.2.3 of crontab.c, committed 2001/05/03 to Thomas> RELENG_4. ... and here, finally, is the answer to my question. I never thought of looking at the history of crontab.c. Many thanks! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-RC1 is now available
I'm doing a net install. Through some network goof, it's stuck during DNS lookup. I press C-c, it says "User generated interrupt" on VT2. But it doesn't interrupt anything. Bug? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: adduser & NIS
> "Will" == Will Mitayai Keeso Rowe <[EMAIL PROTECTED]> writes: Will> hmm... maybe i could look into re-writing adduser so that it uses pw. Will> -Original Message- Will> From: Eric Ogren [mailto:[EMAIL PROTECTED]] Will> Sent: Monday, September 18, 2000 11:14 AM Will> To: Will Mitayai Keeso Rowe Will> Cc: Freebsd-Stable Will> Subject: Re: adduser & NIS Will> On Sun, Sep 17, 2000 at 06:53:41PM -0400, Will Mitayai Keeso Rowe wrote: >> Is there an adduser equivalent that is compatible with an NIS environment? Will> Hi there- Will> What do you mean by an adduser that's compatible with NIS? Just run Will> adduser on your NIS master, merge the change into the master.passwd file Will> you have in /var/yp, and remake the maps... Unfortunately, there's a race with yppasswdd this way. I have not been able to find a way around it. In principle, yppasswdd performs locking, but how it does this is undocumented, and there is no adduser client which respects the same type of locking. Depending on the size of your installation, it may or may not be a problem (it is here). -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: parallel printer & nlpt0
> "Michel" == Michel TALON <[EMAIL PROTECTED]> writes: Michel> On Thu, Jan 13, 2000 at 10:50:41PM +0100, Ronald Klop wrote: >> On Thu, 13 Jan 2000, Vivek Khera wrote: >> >> > > "RK" == Ronald Klop <[EMAIL PROTECTED]> writes: >> > >> > RK> On Thu, 13 Jan 2000, Vivek Khera wrote: >> > >> > >> A comment in GENERIC would also suffice, I think. >> > >> > RK> Hello, >> > >> > RK> Maybe it's good to make an update of the man pages also. >> > RK> Man lpt gives the info about the old lpt device (before ppbus was >> > RK> introduced). Man nlpt gives info about the current (3.x-STABLE) lpt >> > RK> device. Everything discussed in this thread is explained in that page. >> > >> > Actually, I was looking at the man page for ppc and it says nothing >> > about using "net" instead of "tty", so that probably could use an >> > update as well. The synopsis actually only lists the "tty" variant. >> > >> >> But looking at 'man plip' wil show you the net option. But I agree, net >> is an option to ppc, so it should also be mentioned in that man page. Michel> And moreover the significance of the flags tty and net is explained in Michel> man splnet. A reference to that page would be nice in man ppbus. I've read that, but how does this difference account for the printer problems people are having? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
