Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
> On Sep 26, 2020, at 5:24 PM, Rodney W. Grimes > wrote: > > >> >> On Sep 26, 2020, at 1:22 PM, Warner Losh wrote: >>> >>> >>> >>> I am the wrong person to answer that question. >>> >>> In this case, things have not become lame. For instance, the names >>> ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are >>> removed. Same for ru.freebsd.org and ftp4.ru. >>> I'm merely pointing out that changing ftp.CC.freebsd.org usually >>> requires contacting the person(s) maintaining the CC.freebsd.org zone, >>> which is usually not the project. >>> >>> It's usually people associated with the project in some way, but who might >>> not be as responsive as cluster admin. These domains have been delegated, >>> so we have to get the delegated admin to make the changes, which can take a >>> bit of time to chase down and doesn't lend itself to easy / automated >>> coping with this situation. >>> >> >> Just a spitball idea here, but maybe we should consider not embedding these >> lists of mirror URLs into the binaries. It seems pretty straight-forward >> that the list evolves over time, and that evolution is not tightly coupled >> with the updating of the binaries. It sounds like the pkg and >> freebsd-update infrastructure use DNS TXT and/or SRV records to point to the >> metadata needed to construct a mirror URL list dynamically. Maybe something >> similar can be done for bsdconfig? If it?s not a crazy idea, is there >> anyone who would be interested in helping me write a proposal over at arch@? > > 100% behind that idea! Especially since it seems the project has lost > (some) control over its DNS space, which IMHO, is still an issue, if > the people whom DNS zones have been deligated to are not responsive > that should also Words of agreement don’t help at the moment, though i appreciate your enthusiasm. Would you he able to help write a proposal for the arch@ mailing list? Thanks, Scott ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
> > > On Sep 26, 2020, at 1:22 PM, Warner Losh wrote: > > > > > > > > I am the wrong person to answer that question. > > > > In this case, things have not become lame. For instance, the names > > ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are > > removed. Same for ru.freebsd.org and ftp4.ru. > > I'm merely pointing out that changing ftp.CC.freebsd.org usually > > requires contacting the person(s) maintaining the CC.freebsd.org zone, > > which is usually not the project. > > > > It's usually people associated with the project in some way, but who might > > not be as responsive as cluster admin. These domains have been delegated, > > so we have to get the delegated admin to make the changes, which can take a > > bit of time to chase down and doesn't lend itself to easy / automated > > coping with this situation. > > > > Just a spitball idea here, but maybe we should consider not embedding these > lists of mirror URLs into the binaries. It seems pretty straight-forward > that the list evolves over time, and that evolution is not tightly coupled > with the updating of the binaries. It sounds like the pkg and freebsd-update > infrastructure use DNS TXT and/or SRV records to point to the metadata needed > to construct a mirror URL list dynamically. Maybe something similar can be > done for bsdconfig? If it?s not a crazy idea, is there anyone who would be > interested in helping me write a proposal over at arch@? 100% behind that idea! Especially since it seems the project has lost (some) control over its DNS space, which IMHO, is still an issue, if the people whom DNS zones have been deligated to are not responsive that should also be fixed. > Thanks, > Scott -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk wrote: > > > On Sat, Sep 26, 2020 at 11:55 AM Warner Losh wrote: > > > >> And there's the rub: how did this file come to exist? I'm certain it isn't > >> booting or shutting down the system based on when devfs is mounted (before > >> init) and unmounted (it's not done by the shutdown scripts). Now, it's > >> always possible there's a hole in my understanding of the sequence of > >> events. But given the examination of code, it's crazy to think this could > >> be created by anything but some weird bug. That's why a step-by-step from > >> scratch guide is needed. Im happy to look into it, but I need a bit more > >> to > >> go on. Some others have run dumps, nfs exports, so far I see 4 file system report, I see these infrequently, so I would not consider these 4 file systems to be a very large data set. > >> > >> > > I don't think it's terribly complicated; either set up a multi-boot system > > or > > pull the physical drive with / from one machine, and mount it while booted > > into a different environment. Then, chroot into it and do ... just about > > anything. > > If you didn't mount devfs before chrooting, then you get a file /dev/null > > (and some > > really confused errors from, e.g., buildworld!). This is not the situation that I am reporting. > > I think there's two different things that are being talked about here. > Let's not confuse the two. > > The first is making the build system not depend on /dev/null. You'll find > that's hard to do if you and try to do it since /dev/null is used about 200 > times in the current build system in about a dozen different ways. Some are > easy, most are a bit tricky since you can't just close stdout/stderr > because then any files opened by the program will get those FDs and > printf/fprint(stderr, will collide. This dependency won't be fixed any > time soon, though I could add a seatbelt to buildworld/buildkernel that > ensures that /dev/null is a character device. > > The second is a report that /dev/null is created all the time through Correction, I never stated "all the time". I stated I have seen this on SOME analysis of disk pulled from running systems. Let me add to that these driver are only ever mounted Readonly, as what is going on is a forensics state post mortem of the system. These are not jails, some may be VM images, but even in the VM cases these are raw disk images that are never mounted read/write. It is possible that a cdrom or nfs boot was done during the life time of the node(s) with a chroot into a root file system mounted some place else. > normal means before devfs can be mounted. However, several people have > looked and found no evidence on their system. This means there's something > special / unique to Rod's setup that's generating them (assuming it isn't a > simple chroot without devfs). What that is, and how they come to be, hasn't > been explained in enough detail to reproduce. That's what people are asking > Rod about: how do we get there? How did it happen? Once we know those > answers, we can fix it. Problem is these are being found in after the fact analysis, so "getting there" is going to be hard. I'll try to collect better data such as inode contents and dates and see if I can correlate that to system install time, or some time during the systems life time. Given what kib, and ian have said I am starting to suspect that this may be occuring during the install process, the dates on the null inode and a find of the oldest inode on the disk should correlate that next time I see one of these. If I could easily reroduce it we would not be having this conversation, it would of been fixed. > Warner -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r366189 - head/sys/fs/nfsserver
Author: rmacklem
Date: Sat Sep 26 23:05:38 2020
New Revision: 366189
URL: https://svnweb.freebsd.org/changeset/base/366189
Log:
Bjorn reported a problem where the Linux NFSv4.1 client is
using an open_to_lock_owner4 when that lock_owner4 has already
been created by a previous open_to_lock_owner4. This caused the NFS server
to reply NFSERR_INVAL.
For NFSv4.0, this is an error, although the updated NFSv4.0 RFC7530 notes
that the correct error reply is NFSERR_BADSEQID (RFC3530 did not specify
what error to return).
For NFSv4.1, it is not obvious whether or not this is allowed by RFC5661,
but the NFSv4.1 server can handle this case without error.
This patch changes the NFSv4.1 (and NFSv4.2) server to handle multiple
uses of the same lock_owner in open_to_lock_owner so that it now correctly
interoperates with the Linux NFS client.
It also changes the error returned for NFSv4.0 to be NFSERR_BADSEQID.
Thanks go to Bjorn for diagnosing this and testing the patch.
He also provided a program that I could use to reproduce the problem.
Tested by:b...@cebitec.uni-bielefeld.de (Bjorn Fischer)
PR: 249567
Reported by: b...@cebitec.uni-bielefeld.de (Bjorn Fischer)
MFC after:3 days
Modified:
head/sys/fs/nfsserver/nfs_nfsdstate.c
Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c
==
--- head/sys/fs/nfsserver/nfs_nfsdstate.c Sat Sep 26 21:47:11 2020
(r366188)
+++ head/sys/fs/nfsserver/nfs_nfsdstate.c Sat Sep 26 23:05:38 2020
(r366189)
@@ -1870,14 +1870,20 @@ tryagain:
}
if (!error)
nfsrv_getowner(>ls_open, new_stp, );
- if (lckstp)
+ if (lckstp) {
/*
-* I believe this should be an error, but it
-* isn't obvious what NFSERR_xxx would be
-* appropriate, so I'll use NFSERR_INVAL for now.
+* For NFSv4.1 and NFSv4.2 allow an
+* open_to_lock_owner when the lock_owner already
+* exists. Just clear NFSLCK_OPENTOLOCK so that
+* a new lock_owner will not be created.
+* RFC7530 states that the error for NFSv4.0
+* is NFS4ERR_BAD_SEQID.
*/
- error = NFSERR_INVAL;
- else
+ if ((nd->nd_flag & ND_NFSV41) != 0)
+ new_stp->ls_flags &= ~NFSLCK_OPENTOLOCK;
+ else
+ error = NFSERR_BADSEQID;
+ } else
lckstp = new_stp;
} else if (new_stp->ls_flags&(NFSLCK_LOCK|NFSLCK_UNLOCK)) {
/*
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
> On Sep 26, 2020, at 1:22 PM, Warner Losh wrote: > > > > I am the wrong person to answer that question. > > In this case, things have not become lame. For instance, the names > ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are > removed. Same for ru.freebsd.org and ftp4.ru. > I'm merely pointing out that changing ftp.CC.freebsd.org usually > requires contacting the person(s) maintaining the CC.freebsd.org zone, > which is usually not the project. > > It's usually people associated with the project in some way, but who might > not be as responsive as cluster admin. These domains have been delegated, so > we have to get the delegated admin to make the changes, which can take a bit > of time to chase down and doesn't lend itself to easy / automated coping with > this situation. > Just a spitball idea here, but maybe we should consider not embedding these lists of mirror URLs into the binaries. It seems pretty straight-forward that the list evolves over time, and that evolution is not tightly coupled with the updating of the binaries. It sounds like the pkg and freebsd-update infrastructure use DNS TXT and/or SRV records to point to the metadata needed to construct a mirror URL list dynamically. Maybe something similar can be done for bsdconfig? If it’s not a crazy idea, is there anyone who would be interested in helping me write a proposal over at arch@? Thanks, Scott ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r366188 - head/sys/mips/include
Author: jhibbits
Date: Sat Sep 26 21:47:11 2020
New Revision: 366188
URL: https://svnweb.freebsd.org/changeset/base/366188
Log:
Check for the only 32-bit MIPS ABIs we support, rather than !n64
There may be additional 64-bit ABIs supported, so use a positive check rather
than a negative check.
Suggested by: imp
MFC after:1 week
Sponsored by: Juniper Networks, Inc
Modified:
head/sys/mips/include/elf.h
Modified: head/sys/mips/include/elf.h
==
--- head/sys/mips/include/elf.h Sat Sep 26 21:45:33 2020(r366187)
+++ head/sys/mips/include/elf.h Sat Sep 26 21:47:11 2020(r366188)
@@ -105,7 +105,7 @@ typedef struct {/* Auxiliary vector entry on initial
int a_type; /* Entry type. */
union {
int a_val; /* Integer value. */
-#ifndef __mips_n64
+#if defined(__mips_o32) || defined(__mips_n32)
void*a_ptr; /* Address. */
void(*a_fcn)(void); /* Function pointer (not used). */
#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020, 1:50 PM Benjamin Kaduk wrote: > On Sat, Sep 26, 2020 at 12:35 PM Warner Losh wrote: > >> >> >> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk >> wrote: >> >>> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh wrote: >>> And there's the rub: how did this file come to exist? I'm certain it isn't booting or shutting down the system based on when devfs is mounted (before init) and unmounted (it's not done by the shutdown scripts). Now, it's always possible there's a hole in my understanding of the sequence of events. But given the examination of code, it's crazy to think this could be created by anything but some weird bug. That's why a step-by-step from scratch guide is needed. Im happy to look into it, but I need a bit more to go on. >>> I don't think it's terribly complicated; either set up a multi-boot >>> system or >>> pull the physical drive with / from one machine, and mount it while >>> booted >>> into a different environment. Then, chroot into it and do ... just >>> about anything. >>> If you didn't mount devfs before chrooting, then you get a file >>> /dev/null (and some >>> really confused errors from, e.g., buildworld!). >>> >> >> I think there's two different things that are being talked about here. >> Let's not confuse the two. >> >> > I agree there are two different things going on here. My apologies for > using buildworld as an example of "something that writes to /dev/null" when > any other example would have done just as well. > > >> The first is making the build system not depend on /dev/null. You'll find >> that's hard to do if you and try to do it since /dev/null is used about 200 >> times in the current build system in about a dozen different ways. Some are >> easy, most are a bit tricky since you can't just close stdout/stderr >> because then any files opened by the program will get those FDs and >> printf/fprint(stderr, will collide. This dependency won't be fixed any >> time soon, though I could add a seatbelt to buildworld/buildkernel that >> ensures that /dev/null is a character device. >> >> The second is a report that /dev/null is created all the time through >> normal means before devfs can be mounted. However, several people have >> looked and found no evidence on their system. This means there's something >> special / unique to Rod's setup that's generating them (assuming it isn't a >> simple chroot without devfs). What that is, and how they come to be, hasn't >> been explained in enough detail to reproduce. That's what people are asking >> Rod about: how do we get there? How did it happen? Once we know those >> answers, we can fix it. >> >> > I was reading the thread differently than that. In particular, I saw > observations that some people had a file /dev/null on their root > filesystem, and speculation that it appeared during early boot or > shutdown. In particular, I did not see specific reports that it was > created during early shutdown, just speculation. Such speculation has > since been thoroughly debunked, but the observations of a /dev/null file > remain. It is easy to get such a /dev/null file on your root filesystem, > you just have to arrange for that filesystem to not actually *be* the root > filesystem when the file is created. So ... "nothing to see here"? > Yes. The file is presented, but no scenario has been given to create it. So, if there is a common way to get this file, that would be good to know.. Even if the answer is something like bsdinstall has a bug, or something like that... Warner -Ben > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020 at 12:35 PM Warner Losh wrote: > > > On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk wrote: > >> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh wrote: >> >>> And there's the rub: how did this file come to exist? I'm certain it >>> isn't >>> booting or shutting down the system based on when devfs is mounted >>> (before >>> init) and unmounted (it's not done by the shutdown scripts). Now, it's >>> always possible there's a hole in my understanding of the sequence of >>> events. But given the examination of code, it's crazy to think this could >>> be created by anything but some weird bug. That's why a step-by-step from >>> scratch guide is needed. Im happy to look into it, but I need a bit more >>> to >>> go on. >>> >>> >> I don't think it's terribly complicated; either set up a multi-boot >> system or >> pull the physical drive with / from one machine, and mount it while booted >> into a different environment. Then, chroot into it and do ... just about >> anything. >> If you didn't mount devfs before chrooting, then you get a file /dev/null >> (and some >> really confused errors from, e.g., buildworld!). >> > > I think there's two different things that are being talked about here. > Let's not confuse the two. > > I agree there are two different things going on here. My apologies for using buildworld as an example of "something that writes to /dev/null" when any other example would have done just as well. > The first is making the build system not depend on /dev/null. You'll find > that's hard to do if you and try to do it since /dev/null is used about 200 > times in the current build system in about a dozen different ways. Some are > easy, most are a bit tricky since you can't just close stdout/stderr > because then any files opened by the program will get those FDs and > printf/fprint(stderr, will collide. This dependency won't be fixed any > time soon, though I could add a seatbelt to buildworld/buildkernel that > ensures that /dev/null is a character device. > > The second is a report that /dev/null is created all the time through > normal means before devfs can be mounted. However, several people have > looked and found no evidence on their system. This means there's something > special / unique to Rod's setup that's generating them (assuming it isn't a > simple chroot without devfs). What that is, and how they come to be, hasn't > been explained in enough detail to reproduce. That's what people are asking > Rod about: how do we get there? How did it happen? Once we know those > answers, we can fix it. > > I was reading the thread differently than that. In particular, I saw observations that some people had a file /dev/null on their root filesystem, and speculation that it appeared during early boot or shutdown. In particular, I did not see specific reports that it was created during early shutdown, just speculation. Such speculation has since been thoroughly debunked, but the observations of a /dev/null file remain. It is easy to get such a /dev/null file on your root filesystem, you just have to arrange for that filesystem to not actually *be* the root filesystem when the file is created. So ... "nothing to see here"? -Ben ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk wrote: > On Sat, Sep 26, 2020 at 11:55 AM Warner Losh wrote: > >> And there's the rub: how did this file come to exist? I'm certain it isn't >> booting or shutting down the system based on when devfs is mounted (before >> init) and unmounted (it's not done by the shutdown scripts). Now, it's >> always possible there's a hole in my understanding of the sequence of >> events. But given the examination of code, it's crazy to think this could >> be created by anything but some weird bug. That's why a step-by-step from >> scratch guide is needed. Im happy to look into it, but I need a bit more >> to >> go on. >> >> > I don't think it's terribly complicated; either set up a multi-boot system > or > pull the physical drive with / from one machine, and mount it while booted > into a different environment. Then, chroot into it and do ... just about > anything. > If you didn't mount devfs before chrooting, then you get a file /dev/null > (and some > really confused errors from, e.g., buildworld!). > I think there's two different things that are being talked about here. Let's not confuse the two. The first is making the build system not depend on /dev/null. You'll find that's hard to do if you and try to do it since /dev/null is used about 200 times in the current build system in about a dozen different ways. Some are easy, most are a bit tricky since you can't just close stdout/stderr because then any files opened by the program will get those FDs and printf/fprint(stderr, will collide. This dependency won't be fixed any time soon, though I could add a seatbelt to buildworld/buildkernel that ensures that /dev/null is a character device. The second is a report that /dev/null is created all the time through normal means before devfs can be mounted. However, several people have looked and found no evidence on their system. This means there's something special / unique to Rod's setup that's generating them (assuming it isn't a simple chroot without devfs). What that is, and how they come to be, hasn't been explained in enough detail to reproduce. That's what people are asking Rod about: how do we get there? How did it happen? Once we know those answers, we can fix it. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On Sat, Sep 26, 2020 at 12:54 PM Niclas Zeising wrote: > On 2020-09-26 20:28, Rodney W. Grimes wrote: > >> On 2020-09-26 20:12, Rodney W. Grimes wrote: > Author: zeising (doc,ports committer) > Date: Sat Sep 26 16:27:09 2020 > New Revision: 366186 > URL: https://svnweb.freebsd.org/changeset/base/366186 > > Log: > bsdconfig, bsdinstall: Prune dead mirrors > > Prune dead mirrors from the list of mirrors in bsdconfig and > bsdinstall. > All these return NXDOMAIN when trying to resolve them. > >>> > >>> This seems like the wrong place to fix it, as this does > >>> nothing for all the "shipped" releases that contain the > >>> old values. Shouldnt these all just be CNAMED in dns > >>> to a nearest replacement resource? > >>> > >>> > >> > >> Considering that we don't actually have control of the subdomans > >> (CC.freebsd.org) ourselves, that is trickier than it might sound. > > > > How can freebsd.org NOT have ultimate control over deligations? > > If things have become "lame" in a deligated zone the deligation > > can and should be pulled and replaced with local data. > > > > This is cc.freebsd.org, not freebsd.org.cc! > > I am the wrong person to answer that question. > > In this case, things have not become lame. For instance, the names > ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are > removed. Same for ru.freebsd.org and ftp4.ru. > I'm merely pointing out that changing ftp.CC.freebsd.org usually > requires contacting the person(s) maintaining the CC.freebsd.org zone, > which is usually not the project. > It's usually people associated with the project in some way, but who might not be as responsive as cluster admin. These domains have been delegated, so we have to get the delegated admin to make the changes, which can take a bit of time to chase down and doesn't lend itself to easy / automated coping with this situation. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020 at 10:02:10AM -0700, Rodney W. Grimes wrote: > > > On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > > > I was under the impression from previous reading and kib's response > > > > that this is a complete non-issue, there's no way you can go > > > > multi-user without a mounted /dev and we go to somewhat great > > > > lengths to make sure we're good. > > > > > > Though kib can assert that, it does not change the fact that I > > > frequently find /dev/null FILES on unmounted root file systems. > > > > > > But lets not mix the 2 separate things of boot time /dev dependency > > > and build time /dev dependency. > > > > If you look in sys/kern/vfs_mountroot.c you can see that the code to > > mount /dev is invoked unconditionally as the first step of mounting > > root, and that all the calls it makes to get devfs mounted have their > > results checked with KASSERTs. > > > > That's pretty strong evidence that devfs is mounted before rc scripts > > run. That creates a situation where you are making an extraordinary > > claim, so you need to provide extraordinary evidence to support it. A > > sequence of actions that allows others to recreate the situation would > > do the trick. > > I have provided ways one can look for this file in > other messages of the threads. A dump of a UFS root > can show it up, and iirc you can find it in a > zfs send of a boot dataset. > > > > > (A question that occurs to me: could it be that the files you've seen > > got created at shutdown after devfs was unmounted, rather than at > > startup? I don't know enough about the shutdown sequence to know > > whether that's possible.) > > Its not "the files" it is "a file, /dev/null". And yes, it could > be very possible that it is during shutdown. Sadly the files is > usually of 0 length so leave little clue as to what is creating them. Out of curiosity I checked it on 3 of my machines, oldest of them was installed in 2014 and had numerous issues with boot and shutdown meantime. Roots are on UFS, and everywhere I see solo% sudo dump -0 -f - / | (cd /tmp && restore -i -f -) ~ DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 0 dump: Sat Sep 26 22:07:39 2020 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/nda0p2 (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 785484 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] restore > cd /dev restore > ls ./dev: restore > quit DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. So for me the question how do you get your /dev/null on root is open. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020 at 11:55 AM Warner Losh wrote: > And there's the rub: how did this file come to exist? I'm certain it isn't > booting or shutting down the system based on when devfs is mounted (before > init) and unmounted (it's not done by the shutdown scripts). Now, it's > always possible there's a hole in my understanding of the sequence of > events. But given the examination of code, it's crazy to think this could > be created by anything but some weird bug. That's why a step-by-step from > scratch guide is needed. Im happy to look into it, but I need a bit more to > go on. > > I don't think it's terribly complicated; either set up a multi-boot system or pull the physical drive with / from one machine, and mount it while booted into a different environment. Then, chroot into it and do ... just about anything. If you didn't mount devfs before chrooting, then you get a file /dev/null (and some really confused errors from, e.g., buildworld!). -Ben ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Sat, Sep 26, 2020 at 11:02 AM Rodney W. Grimes wrote: > > > On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > > > I was under the impression from previous reading and kib's response > > > > that this is a complete non-issue, there's no way you can go > > > > multi-user without a mounted /dev and we go to somewhat great > > > > lengths to make sure we're good. > > > > > > Though kib can assert that, it does not change the fact that I > > > frequently find /dev/null FILES on unmounted root file systems. > > > > > > But lets not mix the 2 separate things of boot time /dev dependency > > > and build time /dev dependency. > > > > If you look in sys/kern/vfs_mountroot.c you can see that the code to > > mount /dev is invoked unconditionally as the first step of mounting > > root, and that all the calls it makes to get devfs mounted have their > > results checked with KASSERTs. > > > > That's pretty strong evidence that devfs is mounted before rc scripts > > run. That creates a situation where you are making an extraordinary > > claim, so you need to provide extraordinary evidence to support it. A > > sequence of actions that allows others to recreate the situation would > > do the trick. > > I have provided ways one can look for this file in > other messages of the threads. A dump of a UFS root > can show it up, and iirc you can find it in a > zfs send of a boot dataset. > You've not provided a step-by-step way to recreate the issue leading to the /dev/null file, however. Absent that, it's going to be really hard to fix it. > (A question that occurs to me: could it be that the files you've seen > > got created at shutdown after devfs was unmounted, rather than at > > startup? I don't know enough about the shutdown sequence to know > > whether that's possible.) > > Its not "the files" it is "a file, /dev/null". And yes, it could > be very possible that it is during shutdown. Sadly the files is > usually of 0 length so leave little clue as to what is creating them. > And there's the rub: how did this file come to exist? I'm certain it isn't booting or shutting down the system based on when devfs is mounted (before init) and unmounted (it's not done by the shutdown scripts). Now, it's always possible there's a hole in my understanding of the sequence of events. But given the examination of code, it's crazy to think this could be created by anything but some weird bug. That's why a step-by-step from scratch guide is needed. Im happy to look into it, but I need a bit more to go on. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-26 20:28, Rodney W. Grimes wrote: On 2020-09-26 20:12, Rodney W. Grimes wrote: Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. This seems like the wrong place to fix it, as this does nothing for all the "shipped" releases that contain the old values. Shouldnt these all just be CNAMED in dns to a nearest replacement resource? Considering that we don't actually have control of the subdomans (CC.freebsd.org) ourselves, that is trickier than it might sound. How can freebsd.org NOT have ultimate control over deligations? If things have become "lame" in a deligated zone the deligation can and should be pulled and replaced with local data. This is cc.freebsd.org, not freebsd.org.cc! I am the wrong person to answer that question. In this case, things have not become lame. For instance, the names ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are removed. Same for ru.freebsd.org and ftp4.ru. I'm merely pointing out that changing ftp.CC.freebsd.org usually requires contacting the person(s) maintaining the CC.freebsd.org zone, which is usually not the project. Regards -- Niclas Zeising ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
> On 2020-09-26 20:12, Rodney W. Grimes wrote: > >> Author: zeising (doc,ports committer) > >> Date: Sat Sep 26 16:27:09 2020 > >> New Revision: 366186 > >> URL: https://svnweb.freebsd.org/changeset/base/366186 > >> > >> Log: > >>bsdconfig, bsdinstall: Prune dead mirrors > >> > >>Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. > >>All these return NXDOMAIN when trying to resolve them. > > > > This seems like the wrong place to fix it, as this does > > nothing for all the "shipped" releases that contain the > > old values. Shouldnt these all just be CNAMED in dns > > to a nearest replacement resource? > > > > > > Considering that we don't actually have control of the subdomans > (CC.freebsd.org) ourselves, that is trickier than it might sound. How can freebsd.org NOT have ultimate control over deligations? If things have become "lame" in a deligated zone the deligation can and should be pulled and replaced with local data. This is cc.freebsd.org, not freebsd.org.cc! > I do not oppose that change, but I'm not doing the work to chase all the > subdomain DNS admins down to try to fix it. Nor should you, this should be a clusteradm/domain administration person that should already working to keep the projects DNS data up to date and reliable. > This change cleans out some old mirrors for the 12.2 release, so that > people installing 12.2 (and later stuff) won't have the installer > complain when they accidentally pick a nonexistent mirror. > I believe that the proper way to fix this is to just use the FreeBSD CDN > even for these downloads (basically, go straight to > download.freebsd.org, or at least have that as the preferred option), > but I haven't gotten around to that. > Regards > -- > Niclas Zeising > -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-26 20:12, Rodney W. Grimes wrote: Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. This seems like the wrong place to fix it, as this does nothing for all the "shipped" releases that contain the old values. Shouldnt these all just be CNAMED in dns to a nearest replacement resource? Considering that we don't actually have control of the subdomans (CC.freebsd.org) ourselves, that is trickier than it might sound. I do not oppose that change, but I'm not doing the work to chase all the subdomain DNS admins down to try to fix it. This change cleans out some old mirrors for the 12.2 release, so that people installing 12.2 (and later stuff) won't have the installer complain when they accidentally pick a nonexistent mirror. I believe that the proper way to fix this is to just use the FreeBSD CDN even for these downloads (basically, go straight to download.freebsd.org, or at least have that as the preferred option), but I haven't gotten around to that. Regards -- Niclas Zeising ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
> Author: zeising (doc,ports committer) > Date: Sat Sep 26 16:27:09 2020 > New Revision: 366186 > URL: https://svnweb.freebsd.org/changeset/base/366186 > > Log: > bsdconfig, bsdinstall: Prune dead mirrors > > Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. > All these return NXDOMAIN when trying to resolve them. This seems like the wrong place to fix it, as this does nothing for all the "shipped" releases that contain the old values. Shouldnt these all just be CNAMED in dns to a nearest replacement resource? > Reviewed by:emaste > Approved by:emaste > MFC after: 3 days > Differential Revision: https://reviews.freebsd.org/D26535 > > Modified: > head/usr.sbin/bsdconfig/share/media/ftp.subr > head/usr.sbin/bsdinstall/scripts/mirrorselect > > Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr > == > --- head/usr.sbin/bsdconfig/share/media/ftp.subr Sat Sep 26 14:44:58 > 2020(r366185) > +++ head/usr.sbin/bsdconfig/share/media/ftp.subr Sat Sep 26 16:27:09 > 2020(r366186) > @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() > ' IPv6 $msg_japan''ftp2.jp.freebsd.org' > ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' > ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' > - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' > '$msg_primary''ftp1.freebsd.org' > ' $msg_primary #2''ftp2.freebsd.org' > ' $msg_primary #3''ftp3.freebsd.org' > @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() > ' $msg_primary #12' 'ftp12.freebsd.org' > ' $msg_primary #13' 'ftp13.freebsd.org' > ' $msg_primary #14' 'ftp14.freebsd.org' > - '$msg_armenia''ftp1.am.freebsd.org' > '$msg_australia' 'ftp.au.freebsd.org' > ' $msg_australia #2' 'ftp2.au.freebsd.org' > ' $msg_australia #3' 'ftp3.au.freebsd.org' > @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() > '$msg_brazil' 'ftp2.br.freebsd.org' > ' $msg_brazil #3' 'ftp3.br.freebsd.org' > ' $msg_brazil #4' 'ftp4.br.freebsd.org' > - '$msg_canada' 'ftp.ca.freebsd.org' > '$msg_china' 'ftp.cn.freebsd.org' > '$msg_czech_republic' 'ftp.cz.freebsd.org' > '$msg_denmark''ftp.dk.freebsd.org' > - '$msg_estonia''ftp.ee.freebsd.org' > '$msg_finland''ftp.fi.freebsd.org' > '$msg_france' 'ftp.fr.freebsd.org' > ' $msg_france #3' 'ftp3.fr.freebsd.org' > @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() > ' $msg_germany #2''ftp2.de.freebsd.org' > ' $msg_germany #4''ftp4.de.freebsd.org' > ' $msg_germany #5''ftp5.de.freebsd.org' > - ' $msg_germany #6''ftp6.de.freebsd.org' > ' $msg_germany #7''ftp7.de.freebsd.org' > ' $msg_germany #8''ftp8.de.freebsd.org' > '$msg_greece' 'ftp.gr.freebsd.org' > ' $msg_greece #2' 'ftp2.gr.freebsd.org' > '$msg_ireland''ftp3.ie.freebsd.org' > - '$msg_israel' 'ftp.il.freebsd.org' > '$msg_japan' 'ftp.jp.freebsd.org' > ' $msg_japan #2' 'ftp2.jp.freebsd.org' > ' $msg_japan #3' 'ftp3.jp.freebsd.org' > @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() > '$msg_korea' 'ftp.kr.freebsd.org' > ' $msg_korea #2' 'ftp2.kr.freebsd.org' > '$msg_latvia' 'ftp.lv.freebsd.org' > - '$msg_lithuania' 'ftp.lt.freebsd.org' > '$msg_netherlands''ftp.nl.freebsd.org' > ' $msg_netherlands #2''ftp2.nl.freebsd.org' > '$msg_new_zealand''ftp.nz.freebsd.org' > '$msg_norway' 'ftp.no.freebsd.org' > '$msg_poland' 'ftp.pl.freebsd.org' > - ' $msg_poland #2' 'ftp2.pl.freebsd.org' > '$msg_russia' 'ftp.ru.freebsd.org' > ' $msg_russia #2' 'ftp2.ru.freebsd.org' > - ' $msg_russia #4' 'ftp4.ru.freebsd.org' > ' $msg_russia #5' 'ftp5.ru.freebsd.org' > ' $msg_russia #6' 'ftp6.ru.freebsd.org' > '$msg_slovak_republic''ftp.sk.freebsd.org' > @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() > '$msg_south_africa' 'ftp.za.freebsd.org' > ' $msg_south_africa #2'
Re: svn commit: r365643 - head/bin/cp
> On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > > I was under the impression from previous reading and kib's response > > > that this is a complete non-issue, there's no way you can go > > > multi-user without a mounted /dev and we go to somewhat great > > > lengths to make sure we're good. > > > > Though kib can assert that, it does not change the fact that I > > frequently find /dev/null FILES on unmounted root file systems. > > > > But lets not mix the 2 separate things of boot time /dev dependency > > and build time /dev dependency. > > If you look in sys/kern/vfs_mountroot.c you can see that the code to > mount /dev is invoked unconditionally as the first step of mounting > root, and that all the calls it makes to get devfs mounted have their > results checked with KASSERTs. > > That's pretty strong evidence that devfs is mounted before rc scripts > run. That creates a situation where you are making an extraordinary > claim, so you need to provide extraordinary evidence to support it. A > sequence of actions that allows others to recreate the situation would > do the trick. I have provided ways one can look for this file in other messages of the threads. A dump of a UFS root can show it up, and iirc you can find it in a zfs send of a boot dataset. > > (A question that occurs to me: could it be that the files you've seen > got created at shutdown after devfs was unmounted, rather than at > startup? I don't know enough about the shutdown sequence to know > whether that's possible.) Its not "the files" it is "a file, /dev/null". And yes, it could be very possible that it is during shutdown. Sadly the files is usually of 0 length so leave little clue as to what is creating them. > -- Ian -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. Reviewed by: emaste Approved by: emaste MFC after:3 days Differential Revision:https://reviews.freebsd.org/D26535 Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr head/usr.sbin/bsdinstall/scripts/mirrorselect Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr == --- head/usr.sbin/bsdconfig/share/media/ftp.subrSat Sep 26 14:44:58 2020(r366185) +++ head/usr.sbin/bsdconfig/share/media/ftp.subrSat Sep 26 16:27:09 2020(r366186) @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() ' IPv6 $msg_japan''ftp2.jp.freebsd.org' ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' '$msg_primary''ftp1.freebsd.org' ' $msg_primary #2''ftp2.freebsd.org' ' $msg_primary #3''ftp3.freebsd.org' @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() ' $msg_primary #12' 'ftp12.freebsd.org' ' $msg_primary #13' 'ftp13.freebsd.org' ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_armenia''ftp1.am.freebsd.org' '$msg_australia' 'ftp.au.freebsd.org' ' $msg_australia #2' 'ftp2.au.freebsd.org' ' $msg_australia #3' 'ftp3.au.freebsd.org' @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() '$msg_brazil' 'ftp2.br.freebsd.org' ' $msg_brazil #3' 'ftp3.br.freebsd.org' ' $msg_brazil #4' 'ftp4.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' '$msg_china' 'ftp.cn.freebsd.org' '$msg_czech_republic' 'ftp.cz.freebsd.org' '$msg_denmark''ftp.dk.freebsd.org' - '$msg_estonia''ftp.ee.freebsd.org' '$msg_finland''ftp.fi.freebsd.org' '$msg_france' 'ftp.fr.freebsd.org' ' $msg_france #3' 'ftp3.fr.freebsd.org' @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() ' $msg_germany #2''ftp2.de.freebsd.org' ' $msg_germany #4''ftp4.de.freebsd.org' ' $msg_germany #5''ftp5.de.freebsd.org' - ' $msg_germany #6''ftp6.de.freebsd.org' ' $msg_germany #7''ftp7.de.freebsd.org' ' $msg_germany #8''ftp8.de.freebsd.org' '$msg_greece' 'ftp.gr.freebsd.org' ' $msg_greece #2' 'ftp2.gr.freebsd.org' '$msg_ireland''ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' '$msg_japan' 'ftp.jp.freebsd.org' ' $msg_japan #2' 'ftp2.jp.freebsd.org' ' $msg_japan #3' 'ftp3.jp.freebsd.org' @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() '$msg_korea' 'ftp.kr.freebsd.org' ' $msg_korea #2' 'ftp2.kr.freebsd.org' '$msg_latvia' 'ftp.lv.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' '$msg_netherlands''ftp.nl.freebsd.org' ' $msg_netherlands #2''ftp2.nl.freebsd.org' '$msg_new_zealand''ftp.nz.freebsd.org' '$msg_norway' 'ftp.no.freebsd.org' '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' '$msg_russia' 'ftp.ru.freebsd.org' ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' ' $msg_russia #5' 'ftp5.ru.freebsd.org' ' $msg_russia #6' 'ftp6.ru.freebsd.org' '$msg_slovak_republic''ftp.sk.freebsd.org' @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() '$msg_south_africa' 'ftp.za.freebsd.org' ' $msg_south_africa #2' 'ftp2.za.freebsd.org' ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' '$msg_sweden' 'ftp.se.freebsd.org'
