stable/11 -r326142 (e.g.): "cat /dev/null | zstd --stdout" gets "/usr/bin/zstd: Undefined symbol "stat@FBSD_1.5"
# cat /dev/null | zstd --stdout /usr/bin/zstd: Undefined symbol "stat@FBSD_1.5" # freebsd-version -ku 11.1-STABLE 11.1-STABLE # uname -apKU FreeBSD FBSDFS 11.1-STABLE FreeBSD 11.1-STABLE r326142 amd64 amd64 1101506 1101506 It was built from source: # svnlite info /usr/src/ Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/11 Relative URL: ^/stable/11 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 326142 Node Kind: directory Schedule: normal Last Changed Author: ae Last Changed Rev: 326142 Last Changed Date: 2017-11-23 20:42:21 -0800 (Thu, 23 Nov 2017) # svnlite status /usr/src/ # (So, no changes.) /usr/src/lib/libc/sys/Symbol.map has: FBSD_1.0 { . . . socket; socketpair; stat; statfs; swapoff; swapon; . . . So 1.0 vs. 1.5 for some reason. Note: Using /rescue/zstd avoids this issue. === Mark Millard markmi at dsl-only.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: /etc/rc: cannot create /dev/null: Operation not supported
On 2015-07-18 18:29, James Gritton wrote: On 2015-07-17 11:26, Per olof Ljungmark wrote: On 2015-07-17 01:41, James Gritton wrote: On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation not supported ... I have done the procedure several times before but never saw this one before and don't know how to get around it. Ideas anyone? Any recent changes that can show up like the above? Thanks! If it's trying to create /dev/null, I assume that the jail's /dev isn't mounted when /etc/rc is running. Do you have mount.devfs set in the jail.conf, or jail_foo_devfs_enable in rc.conf (depending on your configuration)? For that matter, can you tell if the jail's /dev is mounted? Yes, it's mounted. Because I can set up jails with an identical procedure on other boxes we run I suspect something is wrong with the install so I am starting from scratch with this one. While doing that, I am trying to sort another problem, namely to boot zfs on root on a HP Proliant with a P410 controller, but that is another story. You know, if it was easy it would not be interesting... Thanks! So maybe a little late since you're starting over, but another possibility is the devfs ruleset. If something went wrong in setting that up, you could well have a devfs mounted that shows no devices. True, although I did check the rulesets. However, since this is a box that will go into production I did not want to take any chances in case we missed something that might show up in other places later. ___ 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: jail: /etc/rc: cannot create /dev/null: Operation not supported
On 2015-07-17 11:26, Per olof Ljungmark wrote: On 2015-07-17 01:41, James Gritton wrote: On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation not supported ... I have done the procedure several times before but never saw this one before and don't know how to get around it. Ideas anyone? Any recent changes that can show up like the above? Thanks! If it's trying to create /dev/null, I assume that the jail's /dev isn't mounted when /etc/rc is running. Do you have mount.devfs set in the jail.conf, or jail_foo_devfs_enable in rc.conf (depending on your configuration)? For that matter, can you tell if the jail's /dev is mounted? Yes, it's mounted. Because I can set up jails with an identical procedure on other boxes we run I suspect something is wrong with the install so I am starting from scratch with this one. While doing that, I am trying to sort another problem, namely to boot zfs on root on a HP Proliant with a P410 controller, but that is another story. You know, if it was easy it would not be interesting... Thanks! So maybe a little late since you're starting over, but another possibility is the devfs ruleset. If something went wrong in setting that up, you could well have a devfs mounted that shows no devices. - Jamie ___ 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: jail: /etc/rc: cannot create /dev/null: Operation not supported
On 2015-07-17 01:41, James Gritton wrote: On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation not supported ... I have done the procedure several times before but never saw this one before and don't know how to get around it. Ideas anyone? Any recent changes that can show up like the above? Thanks! If it's trying to create /dev/null, I assume that the jail's /dev isn't mounted when /etc/rc is running. Do you have mount.devfs set in the jail.conf, or jail_foo_devfs_enable in rc.conf (depending on your configuration)? For that matter, can you tell if the jail's /dev is mounted? - Jamie Yes, it's mounted. Because I can set up jails with an identical procedure on other boxes we run I suspect something is wrong with the install so I am starting from scratch with this one. While doing that, I am trying to sort another problem, namely to boot zfs on root on a HP Proliant with a P410 controller, but that is another story. You know, if it was easy it would not be interesting... Thanks! ___ 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: jail: /etc/rc: cannot create /dev/null: Operation not supported
On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation not supported ... I have done the procedure several times before but never saw this one before and don't know how to get around it. Ideas anyone? Any recent changes that can show up like the above? Thanks! If it's trying to create /dev/null, I assume that the jail's /dev isn't mounted when /etc/rc is running. Do you have mount.devfs set in the jail.conf, or jail_foo_devfs_enable in rc.conf (depending on your configuration)? For that matter, can you tell if the jail's /dev is mounted? - Jamie ___ 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
jail: /etc/rc: cannot create /dev/null: Operation not supported
FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation not supported ... I have done the procedure several times before but never saw this one before and don't know how to get around it. Ideas anyone? Any recent changes that can show up like the above? Thanks! //per ___ 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: /dev/null
On Fri, Oct 06, 2006 at 08:36:05PM +0200, Ivan Voras wrote: Roland Smith wrote: Are you sure that you have no rulesets? Yup. The command devfs rule showsets shows nothing. This is on somewhat old RELENG_6. Weird. I assume that the system created the rulesets that I see on my machine, because I surely didn't. My machine is amd64, in case that makes any difference. So if you don't see them, I'd say that there is something wrong. I'm assuming that you've run devfs as root, otherwise you get an error. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpPsblnq3g0j.pgp Description: PGP signature
Re: /dev/null
Brent Casavant wrote: Not with FreeBSD in particular. However, from time to time I've run across a piece of software that makes bad assumptions about deleting various input or output files. If run as root, the program/library might accidentally delete a character special device such as /dev/null. Hmm, that's... inconvenient. I usually support root-almighty thing, but allowing deletion from dynamically populated /dev seems counterproductive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/null
On Fri, Oct 06, 2006 at 10:03:11AM +0200, Ivan Voras wrote: Brent Casavant wrote: Not with FreeBSD in particular. However, from time to time I've run across a piece of software that makes bad assumptions about deleting various input or output files. If run as root, the program/library might accidentally delete a character special device such as /dev/null. Hmm, that's... inconvenient. I usually support root-almighty thing, but allowing deletion from dynamically populated /dev seems counterproductive. The command 'devfs rule -s 2 apply 100' should fix it, I think. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpVCbt8lcOTt.pgp Description: PGP signature
Re: /dev/null
Roland Smith wrote: The command 'devfs rule -s 2 apply 100' should fix it, I think. ? If I read devfs(8) correctly, this should apply rule 100 of ruleset 2. Since I have no rulesets or rules, it doesn't work. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/null
On Fri, Oct 06, 2006 at 06:09:09PM +0200, Ivan Voras wrote: Roland Smith wrote: The command 'devfs rule -s 2 apply 100' should fix it, I think. ? If I read devfs(8) correctly, this should apply rule 100 of ruleset 2. Since I have no rulesets or rules, it doesn't work. :) Are you sure that you have no rulesets? I've made only one ruleset in /etc/devfs.rules, with the number 10. However, when I do have more rulesets: # devfs rule showsets 1 2 3 4 10 I guess these (except 10) are made during system startup or are system defaults. They are: # devfs rule -s 1 show 100 hide # devfs rule -s 2 show 100 path null unhide 200 path zero unhide 300 path crypto unhide 400 path random unhide 500 path urandom unhide # devfs rule -s 3 show 100 path ptyp* unhide 200 path ptyq* unhide 300 path ptyr* unhide 400 path ptys* unhide 500 path ptyP* unhide 600 path ptyQ* unhide 700 path ptyR* unhide 800 path ptyS* unhide 900 path ttyp* unhide 1000 path ttyq* unhide 1100 path ttyr* unhide 1200 path ttys* unhide 1300 path ttyP* unhide 1400 path ttyQ* unhide 1500 path ttyR* unhide 1600 path ttyS* unhide 1700 path fd unhide 1800 path fd/* unhide 1900 path stdin unhide 2000 path stdout unhide 2100 path stderr unhide # devfs rule -s 4 show 100 include 1 200 include 2 300 include 3 HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpjHpt2wFFBk.pgp Description: PGP signature
Re: /dev/null
Roland Smith wrote: Are you sure that you have no rulesets? Yup. The command devfs rule showsets shows nothing. This is on somewhat old RELENG_6. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
/dev/null
Hi All From someday I've some very strange thing sometime my /dev/null just vanish. Anyone have this problem ? I'm running FreeBSD RELENG_6 Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 i?me ?tage, plateau D, bureau 10 Heure local/Local time: Fri Oct 6 00:40:33 CEST 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/null
On Fri, 6 Oct 2006, Albert Shih wrote: From someday I've some very strange thing sometime my /dev/null just vanish. Anyone have this problem ? Not with FreeBSD in particular. However, from time to time I've run across a piece of software that makes bad assumptions about deleting various input or output files. If run as root, the program/library might accidentally delete a character special device such as /dev/null. Not that *I* would have ever written such code, mind you. (whistles innocently) Brent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why the mode of /dev/null is changed after system reboot?
On Mon, Nov 01, 2004 at 09:19:12AM +0800, Iva Hesy wrote: I have a gateway running FreeBSD 4.10-p3. Normally, the mode of /dev/null should be 666, but recently, I find that its mode is changed to 600 automatically after reboot, I have checked all /etc/rc* and /usr/local/etc/rc.d/*, but I can't get anything that led to it...:-( Probably a local error. Try changing scripts to #!/bin/sh -x and carefully watch (or log) the boot process. Start with any local scripts you have since it's most likely to be a problem there. Kris pgpM1lvdAkgJS.pgp Description: PGP signature
Re: Why the mode of /dev/null is changed after system reboot?
On Mon, 2004-11-01 at 09:30 -0800, Kris Kennaway wrote: On Mon, Nov 01, 2004 at 09:19:12AM +0800, Iva Hesy wrote: I have a gateway running FreeBSD 4.10-p3. Normally, the mode of /dev/null should be 666, but recently, I find that its mode is changed to 600 automatically after reboot, I have checked all /etc/rc* and /usr/local/etc/rc.d/*, but I can't get anything that led to it...:-( Probably a local error. Try changing scripts to #!/bin/sh -x and carefully watch (or log) the boot process. Start with any local scripts you have since it's most likely to be a problem there. Kris Actually I have found this happening on my 4.10 boxen as well. I thought it was some one-time glitch and just chmodded the thing back. Didn't even think about it until I saw this post. I will try to see if I can catch the circumstances surrounding it if it happens again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why the mode of /dev/null is changed after system reboot?
On Mon, Nov 01, 2004 at 02:49:48PM -0500, Sven Willenberger wrote: On Mon, 2004-11-01 at 09:30 -0800, Kris Kennaway wrote: On Mon, Nov 01, 2004 at 09:19:12AM +0800, Iva Hesy wrote: I have a gateway running FreeBSD 4.10-p3. Normally, the mode of /dev/null should be 666, but recently, I find that its mode is changed to 600 automatically after reboot, I have checked all /etc/rc* and /usr/local/etc/rc.d/*, but I can't get anything that led to it...:-( Probably a local error. Try changing scripts to #!/bin/sh -x and carefully watch (or log) the boot process. Start with any local scripts you have since it's most likely to be a problem there. Kris Actually I have found this happening on my 4.10 boxen as well. I thought it was some one-time glitch and just chmodded the thing back. Didn't even think about it until I saw this post. I will try to see if I can catch the circumstances surrounding it if it happens again. It could be a port doing this at startup, but we still need more debugging.. Kris pgpR0wgaJKS5D.pgp Description: PGP signature
Re: Why the mode of /dev/null is changed after system reboot?
On Mon, 1 Nov 2004, Sven Willenberger wrote: SW I have a gateway running FreeBSD 4.10-p3. Normally, the mode of SW /dev/null should be 666, but recently, I find that its mode is changed SW to 600 automatically after reboot, I have checked all /etc/rc* and SW /usr/local/etc/rc.d/*, but I can't get anything that led to it...:-( SW SW Probably a local error. Try changing scripts to #!/bin/sh -x and SW carefully watch (or log) the boot process. Start with any local SW scripts you have since it's most likely to be a problem there. SW SW Actually I have found this happening on my 4.10 boxen as well. I thought SW it was some one-time glitch and just chmodded the thing back. Didn't SW even think about it until I saw this post. I will try to see if I can SW catch the circumstances surrounding it if it happens again. I remember I stepped into this once or twice in the past. Bad umask at mergemaster/MAKEDEV time possibly? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why the mode of /dev/null is changed after system reboot?
It could be a port doing this at startup, but we still need more debugging.. Kris I think that sshd2 does this. because I installed it only recently... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why the mode of /dev/null is changed after system reboot?
No, it just happened after system reboot...:-) If I chmod it to 666it will re-chmod it to 600 after system reboot. On Tue, 2 Nov 2004 09:08:15 +0300 (MSK), Dmitry Morozovsky [EMAIL PROTECTED] wrote: I remember I stepped into this once or twice in the past. Bad umask at mergemaster/MAKEDEV time possibly? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Why the mode of /dev/null is changed after system reboot?
I have a gateway running FreeBSD 4.10-p3. Normally, the mode of /dev/null should be 666, but recently, I find that its mode is changed to 600 automatically after reboot, I have checked all /etc/rc* and /usr/local/etc/rc.d/*, but I can't get anything that led to it...:-( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
/dev/null permission change from 4.3 - 4.4...
Howdy. This question was originally framed as a why doesn't uptime work for users in 4.4, when it used to in 4.3, but after looking into things further, it's now a why is /dev/null set to mod 0600? On a 4.3 system that I have, the perms on dev/null are 666. I've chmod'ed all of my boxen back to 0666, but... I'm curious as to why this happened and the rationale behind the change. I've observed this difference on at least 15 other 4.4 systems. What gives? -sc PS Build processes was: cd /usr/src make update make world make kernel KERNCONF=KERNNAME mergemaster -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: /dev/null permission change from 4.3 - 4.4...
On Sun, 23 Sep 2001 at 17:52:13 -0700, Sean Chittenden wrote: Howdy. This question was originally framed as a why doesn't uptime work for users in 4.4, when it used to in 4.3, but after looking into things further, it's now a why is /dev/null set to mod 0600? On a 4.3 system that I have, the perms on dev/null are 666. I've chmod'ed all of my boxen back to 0666, but... I'm curious as to why this happened and the rationale behind the change. I've observed this difference on at least 15 other 4.4 systems. What gives? Hmm, it's still marked with the sign of the beast here. $ ls -l /dev/null crw-rw-rw- 1 root wheel2, 2 Sep 23 07:47 /dev/null $ uname -a FreeBSD athalon 4.4-STABLE FreeBSD 4.4-STABLE #9: Sun Sep 23 07:40:24 SAST 2001 root@athalon:/usr/obj/usr/src/sys/ATHALON i386 $ -- Piet Delport [EMAIL PROTECTED] Today's subliminal thought is: PGP signature
Re: /dev/null permission change from 4.3 - 4.4...
On Sun, Sep 23, 2001 at 05:52:13PM -0700, Sean Chittenden wrote: Howdy. This question was originally framed as a why doesn't uptime work for users in 4.4, when it used to in 4.3, but after looking into things further, it's now a why is /dev/null set to mod 0600? On a 4.3 system that I have, the perms on dev/null are 666. Something must have gone wrong..it's still supposed to be 666, and is on my machines. Kris PGP signature