Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 01 Nov 2014 15:21:48 +0100 Dag-Erling Sm〓rgrav d...@des.no wrote: Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Sm〓rgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. Looks fixed now, but what confused me is that r273919 modifies etc/rc.d/geli. I've not configured GELI neither in head VM nor stable/10 host. And what MORE confused me are that... *In first reboot (after installworld and mergemaster) at r273922, mfsvar problem appeared. (/var/db/ports looked empty.) At the moment, r273619:OK - r273876:NG - r273902:NG - r273922:NG. *Manfred's workaround helped in following reboot [no other change]. (And sent my previous mail.) *Noticed that r273919 should fix above by your reply, backed out Manfred's workaround [no other change] and rebooted, can't reproduce the mfsvar problem anymore! (With some rebooting test, and updating to r273958.) For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). Confirmed r273957 and r273958 fixes this. Thanks! DES -- Dag-Erling Sm〓rgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Looks fixed now, but what confused me is that r273919 modifies etc/rc.d/geli. I've not configured GELI neither in head VM nor stable/10 host. Yes, it breaks the cycle in the rcorder graph. Whether you use geli or not is irrelevant; the script still runs. *Noticed that r273919 should fix above by your reply, backed out Manfred's workaround [no other change] and rebooted, can't reproduce the mfsvar problem anymore! Yes, that was the idea. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 01 Nov 2014 01:33:09 +0100 Dag-Erling Sm〓rgrav d...@des.no wrote: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. VirtualBox VM [head, r273922, amd64] on stable/10 host [r273847, amd64]. In my case, /var is NOT a mount point (root only partition, mounted rw), but empty mfsvar is forcibly used without Manfred's workaround in multi user mode. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? For me, it takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. DES -- Dag-Erling Sm〓rgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- 青木 知明 [Tomoaki AOKI] junch...@dec.sakura.ne.jp mxe02...@nifty.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Smørgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 2014-11-01 at 15:21 +0100, Dag-Erling Smørgrav wrote: Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Smørgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 2014-11-01 at 15:59 +0100, Dag-Erling Smørgrav wrote: Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? We've been over this, I stressed again and again that we have an absolute requirement to start up reliably when there is NO ENTROPY. Saved entropy is great, if you've got some saved. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. -- Ian VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. How about you take a ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 1 Nov 2014 18:03+0100, Dag-Erling Smørgrav wrote: Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. How about you take a ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. Sirs, please control your temper, at least while on a public mailing list. What good does the file /entropy do if boot up is delayed everytime during Writing entropy file:? (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On 01.11.2014 21:26, Trond Endrestøl wrote: What good does the file /entropy do if boot up is delayed everytime during Writing entropy file:? Probably some entropy is needed before saved file is loaded. As raw guessing of alternative solution it is possible to make some part of previously saved entropy as kld module always loaded with the kernel. -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver pgpq78x9cSl2E.pgp Description: OpenPGP digital signature
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
At 12:20 PM 10/31/2014, O. Hartmann wrote: On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver With r273911 on amd64, after fresh build installworld. Upon reboot all of a sudden /var is mounted mfs. needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc I had to change the following in rc.conf to get system to work again. varmfs=AUTO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=AUTO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=YES# Clean the /var directory CHANGED TO : varmfs=NO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=NO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=NO# Clean the /var directory Not why all of a sudden /var/ was mounted mfs. Maybe something to do with the new random stuff, I did a mergemaster before rebooting Not sure if this is related to your problem Manfred || n...@pozo.com || || || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31.10.2014 21:35, Martin MATO a écrit : Le 31.10.2014 21:00, Manfred Antar a écrit : At 12:20 PM 10/31/2014, O. Hartmann wrote: On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver With r273911 on amd64, after fresh build installworld. Upon reboot all of a sudden /var is mounted mfs. needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc I had to change the following in rc.conf to get system to work again. varmfs=AUTO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=AUTO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=YES# Clean the /var directory CHANGED TO : varmfs=NO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=NO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=NO# Clean the /var directory Not why all of a sudden /var/ was mounted mfs. Maybe something to do with the new random stuff, I did a mergemaster before rebooting Not sure if this is related to your problem Manfred || n...@pozo.com || || || Same things here. It appears that the ld-elf.so.hints files are not generated ( ldconfig not executed at boot); well at least in my case. executing manually a 'service ldconfig start' generate them. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On 31.10.14 22:23, Dag-Erling Smørgrav wrote: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. +1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. [zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT @(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
At 02:44 PM 10/31/2014, Andreas Tobler wrote: On 31.10.14 22:23, Dag-Erling Smørgrav wrote: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. +1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. [zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT @(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 Andreas FreeBSD 11.0-CURRENT #0 r273905: Fri Oct 31 06:15:56 PDT 2014 11.0-CURRENT No corruption here, during the last few days i was getting sysctl-random error during boot. So today I did a buildworld installworld buildkernel installkernel, and mergemaster . some of the /etc/rc.d/random files were updated. Reboot Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. I noticed one thing during boot: Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. || n...@pozo.com || || || ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. find /usr/tests/ /usr/tests/ /usr/tests/bin /usr/tests/bin/chown /usr/tests/bin/chown/chown-f_test /usr/tests/bin/chown/Kyuafile /usr/tests/bin/date /usr/tests/bin/date/Kyuafile /usr/tests/bin/date/format_string_test /usr/tests/bin/mv /usr/tests/bin/mv/legacy_test /usr/tests/bin/mv/Kyuafile /usr/tests/bin/pax /usr/tests/bin/pax/legacy_test /usr/tests/bin/pax/Kyuafile /usr/tests/bin/pkill /usr/tests/bin/pkill/pgrep-F_test /usr/tests/bin/pkill/pgrep-LF_test /usr/tests/bin/pkill/pgrep-P_test /usr/tests/bin/pkill/pgrep-U_test /usr/tests/bin/pkill/pgrep-_g_test /usr/tests/bin/pkill/pgrep-_s_test /usr/tests/bin/pkill/pgrep-g_test /usr/tests/bin/pkill/pgrep-i_test /usr/tests/bin/pkill/pgrep-j_test /usr/tests/bin/pkill/pgrep-l_test /usr/tests/bin/pkill/pgrep-n_test /usr/tests/bin/pkill/pgrep-o_test /usr/tests/bin/pkill/pgrep-q_test /usr/tests/bin/pkill/pgrep-s_test /usr/tests/bin/pkill/pgrep-t_test /usr/tests/bin/pkill/pgrep-v_test /usr/tests/bin/pkill/pgrep-x_test /usr/tests/bin/pkill/pkill-F_test /usr/tests/bin/pkill/pkill-LF_test /usr/tests/bin/pkill/pkill-P_test /usr/tests/bin/pkill/pkill-U_test /usr/tests/bin/pkill/pkill-_g_test /usr/tests/bin/pkill/pkill-g_test /usr/tests/bin/pkill/pkill-i_test /usr/tests/bin/pkill/pkill-j_test /usr/tests/bin/pkill/pkill-s_test /usr/tests/bin/pkill/pkill-t_test /usr/tests/bin/pkill/pkill-x_test /usr/tests/bin/pkill/Kyuafile /usr/tests/bin/sh /usr/tests/bin/sh/builtins /usr/tests/bin/sh/builtins/alias.0 /usr/tests/bin/sh/builtins/alias.0.stdout /usr/tests/bin/sh/builtins/alias.1 /usr/tests/bin/sh/builtins/alias.1.stderr /usr/tests/bin/sh/builtins/alias3.0 /usr/tests/bin/sh/builtins/alias3.0.stdout /usr/tests/bin/sh/builtins/alias4.0 /usr/tests/bin/sh/builtins/break1.0 /usr/tests/bin/sh/builtins/break2.0 /usr/tests/bin/sh/builtins/break2.0.stdout /usr/tests/bin/sh/builtins/break3.0 /usr/tests/bin/sh/builtins/break4.4 /usr/tests/bin/sh/builtins/break5.4 /usr/tests/bin/sh/builtins/break6.0 /usr/tests/bin/sh/builtins/builtin1.0 /usr/tests/bin/sh/builtins/case1.0 /usr/tests/bin/sh/builtins/case2.0 /usr/tests/bin/sh/builtins/case3.0 /usr/tests/bin/sh/builtins/case4.0 /usr/tests/bin/sh/builtins/case5.0 /usr/tests/bin/sh/builtins/case6.0 /usr/tests/bin/sh/builtins/case7.0 /usr/tests/bin/sh/builtins/case8.0 /usr/tests/bin/sh/builtins/case9.0 /usr/tests/bin/sh/builtins/case10.0 /usr/tests/bin/sh/builtins/cd1.0 /usr/tests/bin/sh/builtins/case11.0 /usr/tests/bin/sh/builtins/case12.0 /usr/tests/bin/sh/builtins/case13.0 /usr/tests/bin/sh/builtins/case14.0 /usr/tests/bin/sh/builtins/case15.0 /usr/tests/bin/sh/builtins/case16.0 /usr/tests/bin/sh/builtins/case17.0 /usr/tests/bin/sh/builtins/case18.0 /usr/tests/bin/sh/builtins/case19.0 /usr/tests/bin/sh/builtins/cd2.0 /usr/tests/bin/sh/builtins/cd3.0 /usr/tests/bin/sh/builtins/cd4.0 /usr/tests/bin/sh/builtins/cd5.0 /usr/tests/bin/sh/builtins/cd6.0 /usr/tests/bin/sh/builtins/cd7.0 /usr/tests/bin/sh/builtins/cd8.0 /usr/tests/bin/sh/builtins/command1.0 /usr/tests/bin/sh/builtins/command2.0 /usr/tests/bin/sh/builtins/command3.0 /usr/tests/bin/sh/builtins/command3.0.stdout /usr/tests/bin/sh/builtins/command4.0 /usr/tests/bin/sh/builtins/command5.0 /usr/tests/bin/sh/builtins/command5.0.stdout /usr/tests/bin/sh/builtins/command6.0 /usr/tests/bin/sh/builtins/command6.0.stdout /usr/tests/bin/sh/builtins/dot1.0 /usr/tests/bin/sh/builtins/command7.0 /usr/tests/bin/sh/builtins/command8.0 /usr/tests/bin/sh/builtins/command9.0 /usr/tests/bin/sh/builtins/command10.0 /usr/tests/bin/sh/builtins/command11.0 /usr/tests/bin/sh/builtins/command12.0 /usr/tests/bin/sh/builtins/dot2.0 /usr/tests/bin/sh/builtins/dot3.0 /usr/tests/bin/sh/builtins/dot4.0 /usr/tests/bin/sh/builtins/eval1.0 /usr/tests/bin/sh/builtins/eval2.0 /usr/tests/bin/sh/builtins/eval3.0 /usr/tests/bin/sh/builtins/eval4.0 /usr/tests/bin/sh/builtins/eval5.0 /usr/tests/bin/sh/builtins/eval6.0 /usr/tests/bin/sh/builtins/exec1.0 /usr/tests/bin/sh/builtins/exec2.0 /usr/tests/bin/sh/builtins/exit1.0
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The problem should have been corrected by r273919. Please update your system and update /etc/ with mergemaster. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUVBaIAAoJEJW2GBstM+nsDHIP/jEgsdtn8ZWbwSHCh8RBXhM7 rr7wdRXcti0h8G0htXTaWWrEaJ1Y7LKGVBjqrUqTJU/g7mRha/p2BrEsYMGBwFbT uqPDYIiHvfVIDH6wAO5qi1CvPG8UhsGG3IV+RXEazeBFlNUA50ZRhyhYtvuywoWw 9izOCtc1y3pEuR3i7Ybpors6oulyYWIpd/tuafkVWmhrLblvCLNv6wrmwxAcXtNN UC92bvH320nqA49AC1jAD0zrZ5uc6fPBgcSXi1SZvmnuxnODRrV/O0yD67fUHKtm 59x7woa4tMaVNtP+eQ2QSZv75oko5HmZqfAV4urTQjfb44wDj42uFOKN8WHmMNbe RxZ/b7dhbU9BMKhnf117IIg2P96o2Hj9jwBN6+PaPoPw2UGSgiJf7/bf3RnEZCoM TISlyv3fAvbNg7yuGAZsm8onjUPIfjlriOUhUeiKzNDhQDRW8eKWDPEio8IapyJW wYLtNPjARYUfIswAVMRn5NuNzjqloPKLjXf2YOtREb/c3K1UZMRLTc98zPhJ7za+ 6EzIe/CuY7X55ajwK8Fqmqh/G3TiaSomwiVzZrtl2ggdeXsMsWfeaV0E9gtspVwb Qaprmo1Qx/vZUhHPy8L/OHqvCF39z4RC4N/4ryc7gt5gpW9jkeWzyYvGD/wCdV7b bHxbVZR+Ukuz2B4aUFH5 =J3ap -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Am Fri, 31 Oct 2014 22:23:28 +0100 Dag-Erling Smørgrav d...@des.no schrieb: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES r273800 was the last (obviously) working on one box, r273872 seems to have the problem: /var/log/messages:Oct 30 05:53:45 0.2 gate kernel: FreeBSD 11.0-CURRENT #0 r273800: Tue Oct 28 21:24:08 CET 2014 /var/log/messages:Oct 31 05:32:25 0.2 gate kernel: FreeBSD 11.0-CURRENT #1 r273872: Thu Oct 30 22:32:59 CET 2014 /var/log/messages:Oct 31 19:59:55 0.2 gate kernel: FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 r273746: Mon Oct 27 21:43:42 CET 2014 is the one I'm sure it worked flawless. I did the past two days daily builds. pgpp1KfU39tUM.pgp Description: OpenPGP digital signature
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Oct 31, 2014, at 15:35, Martin MATO martin.m...@orange.fr wrote: Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ... the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? MK_TESTS has been yes by default for some time. This isn’t unexpected… I did however fix a faux pas I accidentally introduced in r273803 in r273810, which may have resulted in more files being installed under /usr/tests . the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. Cheers! -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 23:35, Martin MATO a écrit : Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. find /usr/tests/ /usr/tests/ /usr/tests/bin /usr/tests/bin/chown ... snip... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Reverted back userland AND kernel to r273863 and all things working as before for me. otherwise keeping the last revision kernel and reverting back the operating system to r273863 results in crashes, coredumps and filesystem corruption. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
O. Hartmann ohart...@zedat.fu-berlin.de writes: r273800 was the last (obviously) working on one box, r273872 seems to have the problem: Are you sure? If I understand Manfred correctly, r273905 was running fine for him. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
