Re: [UPDATE] Re: Update on ports on 10.0
On Thu, 27 Oct 2011 15:42:00 +0400 Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Erwin Lansing wrote on 27.10.2011 14:21: On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION100 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin About devel/libtool fix. Why to not update it to 2.4.2 where this was fixed upstream? I mean http://bugs.freebsd.org/162012 We probably need an other set of -exps for that, given how many ports depends on it, and I don't think we have the time for that before the release. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B ___ 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
AW:[PATCH] Default scrub interval to whole weeks
Hi, why 5 weeks and not 4? Shouldn't we add a variable for the weekday to make it more predictable? Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Xin LI delp...@delphij.net hat geschrieben:-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think it might be better if we set scrub interval to whole weeks (proposed changeset changes it to 5 weeks). The reason for this is to make it easier for system administrators to estimate when the scrub happens, for instance, if a scrub was done on Saturday, it always happen on Saturdays. On large zpools, scrub can consume a lot of time and I/O bandwidth, and having it happen on random weekday is not a good idea. 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.18 (FreeBSD) iQEcBAEBCAAGBQJOqaq+AAoJEATO+BI/yjfBNq8IALxm6vrtIIbnklv+WM9hc1ek Os3DpIf12UNA52v02Gglqz3fyuff4wQ4iHQBi1gvZRzEkY9pVTQgInFi2F5MlBxF DC474RLyOShS2SMBmHZQPxlRcGhG6e9OY75XLu0HzbPl3Ah7+HiPcckEgEZ7NjhL 3CKYikvaXerE+Iee+dzrhP9wN+JaG4/RjW4fvHCkWCuIcDemKyebUyqb1O+A35P0 lXjComE1SnYtJSjVWobgGJm9tgJ8CV8fPMd6KcEohwOdDoq6YSaesA1/CAYirZT7 i65FGpT7Eep3K6rV6XJvZUg2bMQcRL/HmqJekowHsMmxDZ8+lLQ001t5QU0jFY4= =9caN -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: HEADSUP: Call for FreeBSD Status Reports - 3Q/2011
On Sat, 15 Oct 2011 23:45:47 +0200, Daniel Gerzo wrote: Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2011 were due on October 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as soon as possible, so that we can compile the report in a timely fashion. I had a few requests to extend the deadline. If you have anything to submit for the upcoming status report (which would be very welcome!), please do so until Oct. 30th. Thank you. -- Kind regards Daniel ___ 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: umass(4) regression in 9.0-RC1.
On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote: On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: This is the root HUB. Can you also show the actual device? Sorry, it wasn't connected, here it goes: ugen0.2: USB2.0-CRW Generic at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x0bda idProduct = 0x0119 bcdDevice = 0x1981 iManufacturer = 0x0001 retrieving string failed iProduct = 0x0002 retrieving string failed iSerialNumber = 0x0003 retrieving string failed bNumConfigurations = 0x0001 Hi, The control request in question is mandatory according to the UMASS specification, and I wonder why it times out and all other control requests aswell. Could you try setting the no-synchronize cache quirk instead, and then plug your device. I'm sorry, but this problem needs further investigation before we can make a patch. --HPS ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
from Tom Evans tevans...@googlemail.com: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. How does one run mergemaster without running roughshod over existing configuration? I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Tom ___ 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: FreeBSD 9.0 amd64 RC1 and KDE4
On Thursday 27 October 2011 02:34:11 Mehmet Erol Sanliturk wrote: In a message previously I mentioned the KDE4 problem for 8.2 amd64 Release , but that message even did not receive a single reply . Things just may get lost, sorry. Install X . Install KDE4 . Login to console . Without an .xinitrc file , and unmodified /etc/ttys file , execute startx . ( Do not start KDE4 directly . ) In right xterm window of X , execute /usr/local/kde4/bin/startkde ( /usr/local/kde4/bin is not in path definition ) . Done. Then , I do not know , but , even this will supply much information about what is going problematic . Correction of first displayed errors and continuing in that way , will solve the problems one by one . I see several kinds of messages: - kcheckrunning not found in PATH... this can indeed be fixed, and I'll do it, but it's harmless; - logs of activity... they're expected; - the KSharedDataCache one, ensure this partition..., is harmless (I'll patch kdelibs to hide this as it's causing a lot of misunderstandings... and maybe I'll just make it work on 9.x and 10.x); - messages about Soprano/Akonadi/Virtuoso not being started... I guess it's because they still have to start, and sure enough they disappear after a while, and Akonadi/Nepomuk seem to work; - X errors... well, they're due to my driver. Apart from this, Plasma Desktop starts successfully, Amarok can play music... In short, my session is fully restored. Apart from KWin, but a kwin --replace would be needed for this. If KDE4 is starting directly , during waiting after display of hard disk symbol , discontinuation of X with Ctrl-Alt-F1 will reveal some messages , but last ones . Therefore , the above method is better than that second method . I don't understand what starting directly means. Anyway, if you see the same messages, there's nothing wrong here as well. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla COLORADO: Where they don't buy M M's, 'cause they're so hard to peel. signature.asc Description: This is a digitally signed message part.
panic: ffs_blkfree_cg: freeing free block
A panic occured while I was ``rm -rf''ing a large filedirectory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. ___ 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: make installworld fails on releng9
On Fri, Oct 28, 2011 at 05:59:57AM +0200, Marco Steinbach wrote: On Thu, 27 Oct 2011, Chuck Burns wrote: I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. I didn't see any mention of this little.. issue, in UPDATING, or in the - current mailing list (yes, I know, 9.0 is no longer technically, current, but since it isn't released yet, I figure it's close enough) I'm seeing this on head (226827, amd64), also. Just updated to 9.0-RC1 #2 r226827 sparc64, didn't see any problems. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
from Tom Evans tevans...@googlemail.com: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. Update: the fix didn't work, even though I have the necessary things in master.passwd. From the boot messages: Starting dbus. Unknown username polkit in message bus configuration file Unknown username haldaemon in message bus configuration file Unknown username avahi in message bus configuration file Unknown username pulse in message bus configuration file Failed to start message bus: Could not get UID and GID for username messagebus /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . From the boot messages: Starting dbus. Unknown username polkit in message bus configuration file Unknown username haldaemon in message bus configuration file Unknown username avahi in message bus configuration file Unknown username pulse in message bus configuration file Failed to start message bus: Could not get UID and GID for username messagebus /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Update: the fix didn't work, even though I have the necessary things in master.passwd. From the boot messages: Starting dbus. Unknown username polkit in message bus configuration file Unknown username haldaemon in message bus configuration file Unknown username avahi in message bus configuration file Unknown username pulse in message bus configuration file Failed to start message bus: Could not get UID and GID for username messagebus /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. ... I still can't login as any nonroot user, even though I see the lines in /etc/master.passwd, which I copied back from backup, and if I startx as root, there is no response to keyboard or mouse. How do I recover? Do I have to copy the whole BETA2 /etc and possibly run mergemaster -p again? How does one run mergemaster without running roughshod over existing configuration? I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Tom ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 28/10/2011 11:05, Thomas Mueller wrote: I still can't login as any nonroot user, even though I see the lines in /etc/master.passwd, which I copied back from backup, and if I startx as root, there is no response to keyboard or mouse. pwd_mkdb -p /etc/master.passwd Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 11:05 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . Did you re-run pwd_mkdb? How does one run mergemaster without running roughshod over existing configuration? So when mergemaster runs, it will ask you if you want to (i)nstall (d)elete or (m)erge the changes. If there are no additions to the file - eg new users or groups from the source - then you can just delete the update. If there are new users/groups, you need to merge them in. If you choose merge for /etc/group and /etc/master.passwd, it will show you the differences, and ask you to choose from the option on the left (your original file) or the right (the updated file) to merge them in. Cheers Tom PS Here is a log of me updating my /etc/group, as a new group 'hast' has been added that is not in my /etc/group *** Displaying differences between ./etc/group and installed version: --- /etc/group 2011-05-05 10:54:43.0 +0100 +++ ./etc/group 2011-10-28 11:39:54.0 +0100 @@ -1,11 +1,11 @@ -# $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ +# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # -wheel:*:0:root,tom +wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: -operator:*:5:root,tom +operator:*:5:root mail:*:6: bin:*:7: news:*:8: @@ -26,21 +26,7 @@ dialer:*:68: network:*:69: audit:*:77: -www:*:80:tom +www:*:80: +hast:*:845: nogroup:*:65533: nobody:*:65534: -tom:*:1001: -cyrus:*:60: -messagebus:*:556: -avahi:*:558: -polkit:*:562: -haldaemon:*:560: -pulse:*:563: -pulse-access:*:564: -pulse-rt:*:557: -gdm:*:92: -pgsql:*:70: -rabbitmq:*:135: -_sabnzbd:*:350: -squid:*:100: -webcamd:*:145:tom Use 'd' to delete the temporary ./etc/group Use 'i' to install the temporary ./etc/group Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again Default is to leave the temporary file to deal with by hand How should I deal with this? [Leave it for later] m # $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ |# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ %r wheel:*:0:root,tom| wheel:*:0:root %l operator:*:5:root,tom | operator:*:5:root %l www:*:80:tom | www:*:80: hast:*:845: %r tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom %l Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] v # $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # wheel:*:0:root,tom daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: operator:*:5:root,tom mail:*:6: bin:*:7: news:*:8: man:*:9: games:*:13: ftp:*:14: staff:*:20: sshd:*:22: smmsp:*:25: mailnull:*:26: guest:*:31: bind:*:53: proxy:*:62: authpf:*:63: _pflogd:*:64: _dhcp:*:65: uucp:*:66: dialer:*:68: network:*:69: audit:*:77: www:*:80: hast:*:845: nogroup:*:65533: nobody:*:65534: tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] As you can see, the new file contains
Re: gmirror failed with error 19.
On Tue, 2011-10-25 12:27 -0700, Garrett Cooper wrote: On Tue, Oct 25, 2011 at 11:15 AM, Martin Wilke m...@freebsd.org wrote: I face the same error since upgrade from 8.2 to 9.0RC1, is there any way to fix that? errno == 19 = ENODEV -- so the question is, what device is missing? I've got bitten by this as well when trying a source up- grade of a freshly installed 8.2-RELEASE system that had gmirror configured after installation according to the procedure in the Handbook. The 9.0-RC1 kernel drops to the mountroot prompt when booting with GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) ... Trying to mount root from ufs:/dev/mirror/gm0s1a [rw]... mountroot: waiting for device /dev/mirror/gm0s1a ... Mounting from ufs:/dev/mirror/gm0s1a failed with error 19. which can be circumvented by setting the loader tunable kern.geom.part.check_integrity=0. The only immediately obvious difference I could find is that gpart list reports the last sector of the mirror/gm0 device different from the 8.2 kernel (490350670 vs 490350608). gpart list output when running the 8.2-RELEASE kernel: http://arwen.shopkeeper.de/~sascha/gpart-82 vs 9.0-RC1: http://arwen.shopkeeper.de/~sascha/gpart-90 Image of the MBR: http://arwen.shopkeeper.de/~sascha/ada0-mbr.bin Cheers, -sascha ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Friday, October 28, 2011 4:43:28 am Thomas Mueller wrote: from Tom Evans tevans...@googlemail.com: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. How does one run mergemaster without running roughshod over existing configuration? I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Hmm, I did not know NetBSD had a util called etcupdate. However, the etcupdate in ports will work fine for FreeBSD. You do need to bootstrap it (see the notes in the manpage) once before you do a cvsup or svn up, but after that it should do 3-way merges to files rather easily. You can also see your local customizations via 'etcupdate diff'. -- John Baldwin ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: * Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d directories that can contain files that are auto-included. -- John Baldwin ___ 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: 9.0-RC1 panic in tcp_input: negative winow.
On Friday, October 28, 2011 1:46:07 am Pawel Jakub Dawidek wrote: On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote: On 10/26/11 22:53, John Baldwin wrote: The assertion would be triggered when the next packet arrives (as I said above). Try modifying your debugging output to also log if the ACK is delayed. I suspect it is not delayed until the last one. (Pushing out an ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case of an immediate ACK, rcv_nxt rcv_adv is only a transient condition all under a single lock invocation so never visible to other consumers of the protocol control block.) If that is what you see, then that confirms what I guessed above and I will likely just remove the assertion in tcp_input() and patch the timewait code to handle this case. Pawel, have you been able to confirm John's hypothesis? [...] Yeah, sorry. I moved the debug to the points where we drop the t_inpcb lock and I still see rcv_nxt being greater than rcv_adv: tcp_do_segment:2970 negative window: tp 0xfe00685ee3d0 rcv_nxt 1312878324 rcv_adv 1312878187 Yes, I still expect this. What I want to see is if 'delack' is always true in this case. This is just before the INP_WUNLOCK(tp-t_inpcb) under 'check_delack' label. I see this a lot (it was logged 545 times for 11 different tp pointers during 24h period). tcp_do_segment:3009 negative window: tp 0xfe005cfc6000 rcv_nxt 1442546453 rcv_adv 1442545722 This is just before calling tcp_output(). This one was logged 65 times for 3 different tp pointers. I placed a debug also after tcp_output() call, but it is not logged, so once we return from tcp_output() everything is fine. That is consistent with what I expect then, since in the delack case, tcp_output() isn't called. -- John Baldwin ___ 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: panic: ffs_blkfree_cg: freeing free block
On Fri, 28 Oct 2011, deeptec...@gmail.com wrote: A panic occured while I was ``rm -rf''ing a large filedirectory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. Do you know at which revision the kernel was or about from when? Consult uname -a. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: 9.0 RC1 linking problem with i386 libs on amd64
On 26/10/2011 16:39, Dimitry Andric wrote:
On 2011-10-26 15:32, Dominic Fandrey wrote:
I haven't tried to dig into this. Only unusual properties of the system
are my non-default MAKEOBJDIRPREFIX and the use of ccache.
# uname -a
FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST
2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC
amd64
# make -VCC -VCPUTYPE -VCFLAGS
/usr/local/bin/ccache clang
athlon64-sse3
-O2 -pipe -march=athlon64-sse3
How are you setting CC and/or CFLAGS, precisely? Depending on how you
do it, the settings might not be propagated correctly to the build32
stage.
Like that:
.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*}
CC=clang
CXX=clang++
CPP=clang-cpp
NO_WERROR=
WERROR=
.endif
I had hoped that the .ifdef construction from the wiki was dated. I
suppose it's emulating setting CC in the environment instead of in
the make/src.conf.
Also, if you force CFLAGS to have -march=athlon64-sse3, I'm not
sure if the build32 stage can even work correctly. Just specify
CPUTYPE, that should be enough.
That's what I do. I don't touch CFLAGS.
In any case, you can try out the attached patch, which should take care
of passing CC to the build32 stage correctly.
I tried CC?=, but that doesn't work, because apparently make always
initializes CC before parsing makefiles. I figure that means the
!defined(CC) clause in the .ifdef construction is never true and thus
obsolete.
I didn't try it, though. Your patch works for me.
I would really like to have this in head, and even stable/9. It makes
it possible to just set CC in make.conf, without .ifdef trickery. Works
nicely for clang, too. :)
Seconded!
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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: LSI 9240-8i (IBM M1015) MegaRaid support
Thank you Doug. I have another machine on the way, that i can use for testing. In the meantime, i got it to work with a reflashed controller, using the mps driver. I posted a howto to the forums http://forums.freebsd.org/showthread.php?t=27268 Best regards, Roberto Roberto de Iriarte writes: | Hi, | | Is there any expectancy of getting this piece of hardware (or it's IBM | silbing, the M1015) working in MegaRaid mode, without having to reflash | the card to IT mode. | | The reason of this request is that the UEFI Bios on the IBM XSeries | 3550M3 refuses to properly initialize the controller if reflashed with | the IT mode firmware, thus making it unusable. | | A search on LSI's website for a driver that supports 8-Stable or 9 did | not produce any results I have driver changes from LSI to support the 9240 and newer ThunderBolt based cards. I have the cards working but need to do a bunch more work to get this into shape to commit to FreeBSD. I also need to look at how they are dealing with their JBOD configuration and attachment. I have cards to test this stuff out but my time is limited to work on it. One thing I should start working on is merging in the LSI changes into the FreeBSD version since the LSI code drop has removed a bunch of features that the FreeBSD version has. Then I can have a smaller change. There are some architectural changes that I need to figure out. They started to use 64 bit addressing. Then there are style issues. Probably the best thing for me to do is add the new HW support to FreeBSD as a small diff then work on improving that and maybe others can also help with that. Doug A. ___ 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 ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, 28 Oct 2011, John Baldwin wrote: On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: * Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d directories that can contain files that are auto-included. Another idea is to let mergemaster call pw(8) to add remove users and groups instead of merging the files. It does not cover /etc/aliases though... But that is minor to this. =) /Bjorn ___ 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
smp_rendezvous runs with interrupts and preemption enabled on unicore systems
I'm seeing issues on a unicore systems running a derivative of FreeBSD
8.2-RELEASE if something calls mem_range_attr_set. It turns out that
the root cause is a bug in smp_rendezvous_cpus. The first part of
smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note
that smp_started is never set to 1 on a unicore system):
if (!smp_started) {
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
return;
}
The problem is that this runs with interrupts enabled, outside of a
critical section. My system runs with device_polling enabled with hz
set to 2500, so its quite easy to wedge the system by having a thread
run mem_range_attr_set. That has to do a smp_rendezvous, and if a
timer interrupt happens to go off half-way through the action_func and
preempt this thread, the system ends up deadlocked(although once it's
wedged, typing at the serial console stands a good chance of unwedging
the system. Go figure).
I know that smp_rendezvous was reworked substantially on HEAD, but by
inspection it looks like the bug is still present, as the
short-circuit behaviour is still there.
I am not entirely sure of the best way to fix this. Is it as simple
as doing a spinlock_enter before setup_func and a spinlock_exit after
teardown_func? It seems to boot fine, but I'm not at all confident
that I understand the nuances of smp_rendezvous to be sure that there
aren't side effects that I don't know about.
___
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
FreeBSD 9.0 BETA1 build kernel
Can't make buildkernel MAKE=make sh /usr/src/sys/conf/newvers.sh tinderbox cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel nvenetlib.o:(.bss+0x0): multiple definition of `array' tws_services.o:(.data+0x0): first defined here ld: Warning: size of symbol `array' changed from 3536 in tws_services.o to 400 in nvenetlib.o *** Error code 1 Stop in /usr/obj/usr/src/sys/tinderkernel. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # diff GENERIC tinderkernel 19c19 # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.553.2.6 2011/10/26 23:05:59 kensmith Exp $ --- # $FreeBSD: stable/9/sys/i386/conf/GENERIC 226405 2011-10-15 21:23:04Z kensmith $ 21,22c21,22 cpu I486_CPU cpu I586_CPU --- #cpu I486_CPU #cpu I586_CPU 24c24 ident GENERIC --- ident tinderbox 26c26 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols --- #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols 67,68d66 options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic 222c220 #device nve # nVidia nForce MCP on-board Ethernet Networking --- device nve # nVidia nForce MCP on-board Ethernet Networking 296c294 options USB_DEBUG # enable debug msgs --- #options USB_DEBUG # enable debug msgs 305c303 device ulpt # Printer --- #device ulpt # Printer 308c306 device urio # Diamond Rio 500 MP3 player --- #device urio # Diamond Rio 500 MP3 player 314c312 device uipaq # Some WinCE based devices --- #device uipaq # Some WinCE based devices 317c315 device uvisor # Visor and Palm devices --- #device uvisor # Visor and Palm devices 338,343c336,340 # sbp(4) works for some systems but causes boot failure on others #device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons --- device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons 346,351c343,348 device sound # Generic sound driver (required) device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_uaudio # USB Audio device snd_via8233 # VIA VT8233x Audio --- #device sound # Generic sound driver (required) #device snd_es137x # Ensoniq AudioPCI ES137x #device snd_hda # Intel High Definition Audio #device snd_ich # Intel, NVidia and other ICH AC'97 Audio #device snd_uaudio # USB Audio #device snd_via8233 # VIA VT8233x Audio ___ 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: smp_rendezvous runs with interrupts and preemption enabled on unicore systems
On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone ryst...@gmail.com wrote:
I'm seeing issues on a unicore systems running a derivative of FreeBSD
8.2-RELEASE if something calls mem_range_attr_set. It turns out that
the root cause is a bug in smp_rendezvous_cpus. The first part of
smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note
that smp_started is never set to 1 on a unicore system):
if (!smp_started) {
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
return;
}
The problem is that this runs with interrupts enabled, outside of a
critical section. My system runs with device_polling enabled with hz
set to 2500, so its quite easy to wedge the system by having a thread
run mem_range_attr_set. That has to do a smp_rendezvous, and if a
timer interrupt happens to go off half-way through the action_func and
preempt this thread, the system ends up deadlocked(although once it's
wedged, typing at the serial console stands a good chance of unwedging
the system. Go figure).
I know that smp_rendezvous was reworked substantially on HEAD, but by
inspection it looks like the bug is still present, as the
short-circuit behaviour is still there.
I am not entirely sure of the best way to fix this. Is it as simple
as doing a spinlock_enter before setup_func and a spinlock_exit after
teardown_func? It seems to boot fine, but I'm not at all confident
that I understand the nuances of smp_rendezvous to be sure that there
aren't side effects that I don't know about.
Looks like Max didn't have time to upstream this fix:
struct mtx smp_ipi_mtx;
+MTX_SYSINIT(smp_ipi_mtx, smp_ipi_mtx, smp rendezvous, MTX_SPIN);
...
static void
mp_start(void *dummy)
{
- mtx_init(smp_ipi_mtx, smp rendezvous, NULL, MTX_SPIN);
...
if (!smp_started) {
+ mtx_lock_spin(smp_ipi_mtx);
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
+ mtx_unlock_spin(smp_ipi_mtx);
return;
}
Cheers,
matthew
___
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: 9.0 RC1 linking problem with i386 libs on amd64
On 2011-10-28 16:41, Dominic Fandrey wrote:
...
Like that:
.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*}
CC=clang
CXX=clang++
CPP=clang-cpp
NO_WERROR=
WERROR=
.endif
I had hoped that the .ifdef construction from the wiki was dated. I
suppose it's emulating setting CC in the environment instead of in
the make/src.conf.
There are two different problems here. One is that src.conf is read
relatively late, and only when bsd.own.mk is included. Therefore,
src.conf is not the right place to put CC, CXX and so on.
The other problem is that the build32 stage uses environment variables
to override CC, CXX, AS and LD for its sub-make (see LIB32WMAKEENV in
Makefile.inc1), adding the necessary flags for 32-bit compilation.
However, since environment variables are in turn overridden by direct
assignments (like via reading make.conf), the 32-bit compilation flags
get lost when you specify any of CC, CXX, AS or LD in make.conf.
This latter problem is what my patch attempts to fix, while changing as
little as possible.
...
I tried CC?=, but that doesn't work, because apparently make always
initializes CC before parsing makefiles.
Yes, that is because make implicitly reads sys.mk, which either defines
CC directly, or through reading make.conf.
...
I didn't try it, though. Your patch works for me.
I would really like to have this in head, and even stable/9. It makes
it possible to just set CC in make.conf, without .ifdef trickery. Works
nicely for clang, too. :)
Seconded!
If there aren't any objections, I will commit it this weekend.
___
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: umass(4) regression in 9.0-RC1.
On Fri, Oct 28, 2011 at 09:11:42AM +0200, Hans Petter Selasky wrote: On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote: On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: This is the root HUB. Can you also show the actual device? Sorry, it wasn't connected, here it goes: ugen0.2: USB2.0-CRW Generic at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x0bda idProduct = 0x0119 bcdDevice = 0x1981 iManufacturer = 0x0001 retrieving string failed iProduct = 0x0002 retrieving string failed iSerialNumber = 0x0003 retrieving string failed bNumConfigurations = 0x0001 Hi, The control request in question is mandatory according to the UMASS specification, and I wonder why it times out and all other control requests aswell. Could you try setting the no-synchronize cache quirk instead, and then plug your device. I'm sorry, but this problem needs further investigation before we can make a patch. It wasn't immediately obvious for me how to set the no-synchronize cache quirk, but I think I found it: # usbconfig add_quirk UQ_MSC_NO_SYNC_CACHE And it seems to work: umass0: Generic USB2.0-CRW, class 0/0, rev 2.00/19.81, addr 2 on usbus0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus13 target 0 lun 0 da0: Generic- SD/MMC 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 30799MB (63076352 512 byte sectors: 255H 63S/T 3926C) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpU6OrpvyK5i.pgp Description: PGP signature
Re: gmultipath: act/act, path checking?
On 26.10.2011 12:09, Dennis Koegel wrote: are there any plans to have gmultipath support for active/active? Few days ago I've started from fixing some issues in gmultipath and already rewritten half of it while trying to make it usable. I expect to have something to present in a week or two. It will also include active/active mode support there, as at my present point required changes are minimal. -- Alexander Motin. ___ 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: FreeBSD 9.0 BETA1 build kernel
* Ruslan Yakovlev qu...@bk.ru, 20111028 17:45:
nvenetlib.o:(.bss+0x0): multiple definition of `array'
tws_services.o:(.data+0x0): first defined here
G! $#(*@!(*!@#
I think you can work around this by removing either nve or tws.
I guess problems like these are mainly caused by the fact that we often
forget to mark global variables as static, even though they ought to be.
If only GCC/Clang had a warning for that...
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
diff --git a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 97414f2..1306846 100644
--- a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2273,6 +2273,9 @@ def note_sentinel_here : Note
def warn_missing_prototype : Warning
no previous prototype for function %0,
InGroupDiagGroupmissing-prototypes, DefaultIgnore;
+def warn_missing_variable_declaration : Warning
+ no previous extern declaration for non-static variable %0,
+ InGroupDiagGroupmissing-variable-declaration, DefaultIgnore;
def err_redefinition : Errorredefinition of %0;
def err_definition_of_implicitly_declared_member : Error
definition of implicitly declared %select{default constructor|copy
diff --git a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp b/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
index 9d91a48..9a5fe21 100644
--- a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
+++ b/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
@@ -4002,6 +4002,11 @@ void Sema::CheckVariableDeclaration(VarDecl *NewVD,
Previous.addDecl(Pos-second);
}
+ if (Previous.empty() NewVD-getStorageClass() == SC_None
+ NewVD-hasGlobalStorage())
+Diag(NewVD-getLocation(),
+ diag::warn_missing_variable_declaration) NewVD;
+
if (T-isVoidType() !NewVD-hasExternalStorage()) {
Diag(NewVD-getLocation(), diag::err_typecheck_decl_incomplete_type)
T;
pgpn88f9sPMxm.pgp
Description: PGP signature
Re: 9.0 RC1 linking problem with i386 libs on amd64
On 28/10/2011 20:19, Dimitry Andric wrote:
On 2011-10-28 16:41, Dominic Fandrey wrote:
...
...
I had hoped that the .ifdef construction from the wiki was dated. I
suppose it's emulating setting CC in the environment instead of in
the make/src.conf.
There are two different problems here. One is that src.conf is read
relatively late, and only when bsd.own.mk is included. Therefore,
src.conf is not the right place to put CC, CXX and so on.
I use buildflags (sysutils/bsdadminscripts), hence all my build
configuration is included from the make.conf.
The other problem is that the build32 stage uses environment variables
to override CC, CXX, AS and LD for its sub-make (see LIB32WMAKEENV in
Makefile.inc1), adding the necessary flags for 32-bit compilation.
However, since environment variables are in turn overridden by direct
assignments (like via reading make.conf), the 32-bit compilation flags
get lost when you specify any of CC, CXX, AS or LD in make.conf.
This latter problem is what my patch attempts to fix, while changing as
little as possible.
An alternative is to pass __MAKE_CONF=/dev/null to the 32-bit stage.
That should also work in the environment, see make.conf(5)
DESCRIPTION§3.
I'm testing it now, just out of curiosity. One would probably have to
add a _WITHOUT_SRCCONF, to be src.conf compatible, too.
--- Makefile.inc1.orig 2011-10-28 22:00:20.0 +0200
+++ Makefile.inc1 2011-10-28 22:00:37.0 +0200
@@ -282,7 +282,8 @@
LIB32WMAKEENV= MACHINE=i386 MACHINE_ARCH=i386 \
MACHINE_CPU=i686 mmx sse sse2 \
LD=${LD} -m elf_i386_fbsd -Y P,${LIB32TMP}/usr/lib32 \
- AS=${AS} --32
+ AS=${AS} --32 \
+ __MAKE_CONF=/dev/null
.elif ${TARGET_ARCH} == powerpc64
.if empty(TARGET_CPUTYPE)
If there aren't any objections, I will commit it this weekend.
Thanks!
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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: 9.0 RC1 linking problem with i386 libs on amd64
On 2011-10-28 22:15, Dominic Fandrey wrote: ... This latter problem is what my patch attempts to fix, while changing as little as possible. An alternative is to pass __MAKE_CONF=/dev/null to the 32-bit stage. That should also work in the environment, see make.conf(5) The problem with this, is that you then skip *all* settings and logic in make.conf, which might not be what you want... The only variables that are specifically overridden for the build32 stage are CC, CXX, AS and LD, so those are the only ones whose value from make.conf needs to be 'ignored' in that stage. ___ 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
Adding disk firmware programming capability to camcontrol
Hi,
I have got code developed by Andre Albsmeier that is capable of
programming firmware of hard drives from several vendors and turned
it into a camcontrol command.
The posted patch (against RELENG_8_2) basically adds the following new
command to camcontrol:
camcontrol fwdownload [device id] [generic args] -f fw_image [-s]
I would appreciate it if FreeBSD experts in this area of code would
take the time to review this patch.
Thanks.
Nima Misaghian
Sandvine Incorporated
--- old/camcontrol.h2011-10-28 14:25:56.0 -0400
+++ camcontrol.h2011-10-28 14:26:02.0 -0400
@@ -40,6 +40,8 @@
int got;
};
+int fwdownload(struct cam_device *device, int argc, char **argv,
+ char *combinedopt, int verbose, int retry_count, int timeout);
void mode_sense(struct cam_device *device, int mode_page, int page_control,
int dbd, int retry_count, int timeout, u_int8_t *data,
int datalen);
--- old/camcontrol.c2011-10-28 14:25:56.0 -0400
+++ camcontrol.c2011-10-28 14:26:02.0 -0400
@@ -77,7 +77,8 @@
CAM_CMD_IDENTIFY= 0x0013,
CAM_CMD_IDLE= 0x0014,
CAM_CMD_STANDBY = 0x0015,
- CAM_CMD_SLEEP = 0x0016
+ CAM_CMD_SLEEP = 0x0016,
+ CAM_CMD_DOWNLOAD_FW = 0x0017
} cam_cmdmask;
typedef enum {
@@ -160,6 +161,7 @@
{idle, CAM_CMD_IDLE, CAM_ARG_NONE, t:},
{standby, CAM_CMD_STANDBY, CAM_ARG_NONE, t:},
{sleep, CAM_CMD_SLEEP, CAM_ARG_NONE, },
+ {fwdownload, CAM_CMD_DOWNLOAD_FW, CAM_ARG_NONE, f:s},
#endif /* MINIMALISTIC */
{help, CAM_CMD_USAGE, CAM_ARG_NONE, NULL},
{-?, CAM_CMD_USAGE, CAM_ARG_NONE, NULL},
@@ -4565,6 +4567,7 @@
camcontrol idle [dev_id][generic args][-t time]\n
camcontrol standby[dev_id][generic args][-t time]\n
camcontrol sleep [dev_id][generic args]\n
+camcontrol fwdownload [dev_id][generic args] -f fw_image [-s]\n
#endif /* MINIMALISTIC */
camcontrol help\n);
if (!verbose)
@@ -4595,6 +4598,7 @@
idlesend the ATA IDLE command to the named device\n
standby send the ATA STANDBY command to the named device\n
sleep send the ATA SLEEP command to the named device\n
+fwdownload program firmware of the named device with the given image
helpthis message\n
Device Identifiers:\n
bus:targetspecify the bus and target, lun defaults to 0\n
@@ -4664,7 +4668,10 @@
-wdon't send immediate format command\n
-ydon't ask any questions\n
idle/standby arguments:\n
--t arg number of seconds before respective state.\n);
+-t arg number of seconds before respective state.\n
+fwdownload arguments:\n
+-f fw_image path to firmware image file\n
+-srun in simulation mode\n);
#endif /* MINIMALISTIC */
}
@@ -4959,6 +4966,10 @@
combinedopt, retry_count,
timeout);
break;
+ case CAM_CMD_DOWNLOAD_FW:
+ error = fwdownload(cam_dev, argc, argv, combinedopt,
+ arglist CAM_ARG_VERBOSE, retry_count, timeout);
+ break;
#endif /* MINIMALISTIC */
case CAM_CMD_USAGE:
usage(1);
--- old/fwdownload.c2011-10-28 15:00:37.0 -0400
+++ fwdownload.c2011-10-28 14:26:02.0 -0400
@@ -0,0 +1,349 @@
+/*-
+ * Copyright (c) 2011 Sandvine Incorporated. All rights reserved.
+ * Copyright (c) 2002-2011 Andre Albsmeier an...@albsmeier.net
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer,
+ *without modification, immediately at the beginning of the file.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE
Adding disk firmware programming capability to camcontrol
Hi,
I have got code developed by Andre Albsmeier that is capable of
programming firmware of hard drives from several vendors and turned
it into a camcontrol command.
The posted patch (against RELENG_8_2) basically adds the following new
command to camcontrol:
camcontrol fwdownload [device id] [generic args] -f fw_image [-s]
I would appreciate it if FreeBSD experts in this area of code would
take the time to review this patch.
Thanks.
Nima Misaghian
Sandvine Incorporated
--- old/camcontrol.h2011-10-28 14:25:56.0 -0400
+++ camcontrol.h2011-10-28 14:26:02.0 -0400
@@ -40,6 +40,8 @@
int got;
};
+int fwdownload(struct cam_device *device, int argc, char **argv,
+ char *combinedopt, int verbose, int retry_count, int timeout);
void mode_sense(struct cam_device *device, int mode_page, int page_control,
int dbd, int retry_count, int timeout, u_int8_t *data,
int datalen);
--- old/camcontrol.c2011-10-28 14:25:56.0 -0400
+++ camcontrol.c2011-10-28 14:26:02.0 -0400
@@ -77,7 +77,8 @@
CAM_CMD_IDENTIFY= 0x0013,
CAM_CMD_IDLE= 0x0014,
CAM_CMD_STANDBY = 0x0015,
- CAM_CMD_SLEEP = 0x0016
+ CAM_CMD_SLEEP = 0x0016,
+ CAM_CMD_DOWNLOAD_FW = 0x0017
} cam_cmdmask;
typedef enum {
@@ -160,6 +161,7 @@
{idle, CAM_CMD_IDLE, CAM_ARG_NONE, t:},
{standby, CAM_CMD_STANDBY, CAM_ARG_NONE, t:},
{sleep, CAM_CMD_SLEEP, CAM_ARG_NONE, },
+ {fwdownload, CAM_CMD_DOWNLOAD_FW, CAM_ARG_NONE, f:s},
#endif /* MINIMALISTIC */
{help, CAM_CMD_USAGE, CAM_ARG_NONE, NULL},
{-?, CAM_CMD_USAGE, CAM_ARG_NONE, NULL},
@@ -4565,6 +4567,7 @@
camcontrol idle [dev_id][generic args][-t time]\n
camcontrol standby[dev_id][generic args][-t time]\n
camcontrol sleep [dev_id][generic args]\n
+camcontrol fwdownload [dev_id][generic args] -f fw_image [-s]\n
#endif /* MINIMALISTIC */
camcontrol help\n);
if (!verbose)
@@ -4595,6 +4598,7 @@
idlesend the ATA IDLE command to the named device\n
standby send the ATA STANDBY command to the named device\n
sleep send the ATA SLEEP command to the named device\n
+fwdownload program firmware of the named device with the given image
helpthis message\n
Device Identifiers:\n
bus:targetspecify the bus and target, lun defaults to 0\n
@@ -4664,7 +4668,10 @@
-wdon't send immediate format command\n
-ydon't ask any questions\n
idle/standby arguments:\n
--t arg number of seconds before respective state.\n);
+-t arg number of seconds before respective state.\n
+fwdownload arguments:\n
+-f fw_image path to firmware image file\n
+-srun in simulation mode\n);
#endif /* MINIMALISTIC */
}
@@ -4959,6 +4966,10 @@
combinedopt, retry_count,
timeout);
break;
+ case CAM_CMD_DOWNLOAD_FW:
+ error = fwdownload(cam_dev, argc, argv, combinedopt,
+ arglist CAM_ARG_VERBOSE, retry_count, timeout);
+ break;
#endif /* MINIMALISTIC */
case CAM_CMD_USAGE:
usage(1);
--- old/fwdownload.c2011-10-28 15:00:37.0 -0400
+++ fwdownload.c2011-10-28 14:26:02.0 -0400
@@ -0,0 +1,349 @@
+/*-
+ * Copyright (c) 2011 Sandvine Incorporated. All rights reserved.
+ * Copyright (c) 2002-2011 Andre Albsmeier an...@albsmeier.net
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer,
+ *without modification, immediately at the beginning of the file.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE
Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
On Fri, 2011-10-21 at 08:25 -0700, Penta Upa wrote: Attached is a test module (vmtest) and the makefile used. Uname output from the system is I only see a Makefile attached here. Can you attach the code you are using? Sean ___ 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: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. The posted patch (against RELENG_8_2) basically adds the following new command to camcontrol: camcontrol fwdownload [device id] [generic args] -f fw_image [-s] I would appreciate it if FreeBSD experts in this area of code would take the time to review this patch. This is awesome! I'm not a CAM expert, but I'll definitely take a look it this weekend. -Garrett ___ 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: Adding disk firmware programming capability to camcontrol
This is a good idea, except that it makes me really really nervous. I do not believe that fw downloads are generic enough to encapsulate. I've used camcontrol recently to tunnel an ATA command through mpt2 that does an ATA DOWNLOAD FW (mode 7), but that is only because it is a specific drive that I've validated works correctly. The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I'm very very nervous about putting it into camcontrol. ___ 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: gmultipath: act/act, path checking?
On 10/28/2011 12:37 PM, Alexander Motin wrote: On 26.10.2011 12:09, Dennis Koegel wrote: are there any plans to have gmultipath support for active/active? Few days ago I've started from fixing some issues in gmultipath and already rewritten half of it while trying to make it usable. I expect to have something to present in a week or two. It will also include active/active mode support there, as at my present point required changes are minimal. Free at last! Free at last! Free at last! ___ 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: Adding disk firmware programming capability to camcontrol
The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon ___ 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: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 3:40 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Fri, 28 Oct 2011, deeptec...@gmail.com wrote: I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. Do you know at which revision the kernel was or about from when? Of course. r226289. ___ 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: panic: ffs_blkfree_cg: freeing free block
With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? ___ 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: Adding disk firmware programming capability to camcontrol
The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon Hi Lyndon and group, I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the only protection needed (of course, that's only my opinion). I dont want to have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple Are you sure? if the magic token is not added on the command line, however. To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. IMHO Peg ___ 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: Adding disk firmware programming capability to camcontrol
On 10/28/11 3:43 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. Camcontrol is used pretty much exclusively by people who should understand the risks. and you have to be root. Unix's job is to reliably and efficiently deliver the bullet to your foot should you so desire. Put in some of these safety belts and add it I think.. --lyndon ___ 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 ___ 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: samba+zfs
On Thu, Oct 27, 2011 at 6:42 PM, Dan d...@sunsaturn.com wrote: Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs its taking over an hour to just mux in things like DTS english, where it was 15 minutes on beta3. Hi Dan, - Can you do more deterministic / scientific benchmarks? - Did you upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett ___ 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: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com deeptec...@gmail.com wrote: With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? Something stomped on the stack. What was the previous version of FreeBSD (major.minor.subminor, svn revision) at worked? Thanks, -Garrett ___ 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: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 4:37 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon Hi Lyndon and group, I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the only protection needed (of course, that's only my opinion). I don’t want to have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple Are you sure? if the magic token is not added on the command line, however. To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. Unfortunately not backs up their systems on a regular basis. Having an interactive prompt with a loud warning like many vendor tools provide today with a non-interactive override option is sufficient. That being said, camcontrol doesn't understand the concept of interactive vs non-interactive use, so it seems like its design would need to be redone if you go this route. Thanks, -Garrett ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 07:57, kama wrote: On Fri, 28 Oct 2011, John Baldwin wrote: On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: * Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d directories that can contain files that are auto-included. Agreed. Another idea is to let mergemaster call pw(8) to add remove users and groups instead of merging the files. I definitely would not be inclined to do it this way. The manner in which mergemaster works now is fine, it just requires the sysadmin to pay attention when doing the merge. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 11:16 AM, deeptec...@gmail.com deeptec...@gmail.com wrote: I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? On Sat, Oct 29, 2011 at 2:35 AM, Garrett Cooper yaneg...@gmail.com wrote: On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com deeptec...@gmail.com wrote: With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? Something stomped on the stack. More like: the release build doesn't have enough debug information in itself, and the release build is not debuggable at all using debug objects that have been built posteriorly. What was the previous version of FreeBSD (major.minor.subminor, svn revision) at worked? Not applicable. The panic occured, out of nowhere, on an r226289 kernel that has been working well and is still working well, with the exception of the panic. ___ 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
syslogd: Remote Logging busted?
I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to be logging the messages. They ARE making it to the system. Can someone look at bin/162135 which has all the details, including tcpdump to show that the messages are making it to the system. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 8:09 PM, Kevin Oberman kob6...@gmail.com wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? Here's a prime example (follow the white rabbit on this commit thread): http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026310.html . Cheers, -Garrett ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 20:09, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: syslogd: Remote Logging busted?
On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman l...@lerctr.org wrote: I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to be logging the messages. They ARE making it to the system. Can someone look at bin/162135 which has all the details, including tcpdump to show that the messages are making it to the system. Just to be clear, you are running tcpdump on borg, right? The statement This is from my Cable Modem: confuses me a bit. Assuming tcpdump is on borg, it is making past any firewall (pf or ipfw, at least). What about /etc/hosts.allow? I don't recall if it filters before or after pcap see packets. I used to have a diagram showing the sequence of processing this, but I can't seem to find it now. What does netstat -af inet | grep syslog show? Is syslogd actually listening? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: syslogd: Remote Logging busted?
On Fri, 28 Oct 2011, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman l...@lerctr.org wrote: I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to be logging the messages. They ARE making it to the system. Can someone look at bin/162135 which has all the details, including tcpdump to show that the messages are making it to the system. Just to be clear, you are running tcpdump on borg, right? The statement This is from my Cable Modem: confuses me a bit. Yes, the tcpdump is running on borg, and the source of the syslog packets is from my Cable Modem at 192.168.200.10. /etc/hosts.allow: # # hosts.allow access control file for tcp wrapped applications. # $FreeBSD: src/etc/hosts.allow,v 1.23 2006/08/29 09:20:48 ru Exp $ # # NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. #_ _ _ # | | __ __ __ _ _ __ ____ __ | | ___ | | # | _| \ \/ / / _` | | '_ ` _ \ | '_ \ | | / _ \ | | # | |___ | (_| | | | | | | | | |_) | | | | __/ |_| # |_| /_/\_\ \__,_| |_| |_| |_| | .__/ |_| \___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a First match wins basis. #ALL : ALL : allow # Wrapping sshd(8) is not normally a good idea, but if you # need to do it, here's how #sshd : .evil.cracker.example.com : deny # Protect against simple DNS spoofing attacks by checking that the # forward and reverse records for the remote host match. If a mismatch # occurs, access is denied, and any positive ident response within # 20 seconds is logged. No protection is afforded against DNS poisoning, # IP spoofing or more complicated attacks. Hosts with no reverse DNS # pass this rule. ALL : PARANOID : RFC931 20 : deny # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). ALL : localhost 127.0.0.1 : allow # Comment out next line if you build libwrap without IPv6 support. ALL : [::1] : allow #ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s #ALL : [fe80::%fxp0]/10 : allow #ALL : [fe80::]/10 : deny #ALL : [2001:db8:2:1:2:3:4:3fe1] : deny #ALL : [2001:db8:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers #sendmail : localhost : allow #sendmail : .nice.guy.example.com : allow #sendmail : .evil.cracker.example.com : deny #sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow #exim : .nice.guy.example.com : allow #exim : .evil.cracker.example.com : deny exim : ALL : allow # Rpcbind is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) #rpcbind : 192.0.2.32/255.255.255.224 : allow #rpcbind : 192.0.2.96/255.255.255.224 : allow rpcbind : ALL : deny # NIS master server. Only local nets should have access # (Since this is an RPC service, rpcbind needs to be considered) ypserv : localhost : allow #ypserv : .unsafe.my.net.example.com : deny #ypserv : .my.net.example.com : allow ypserv : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow #ftpd : .nice.guy.example.com : allow #ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a finger war. fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s tcpd\: %u@%h[%a] fingered me! root) \ : deny # The rest of the daemons are protected. #ALL : ALL \ # : severity auth.info \ # : twist /bin/echo You are not welcome to use %d from %h. # Added by SSHBlock [Sat Oct 22 00:10:49 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:52 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:55 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:58 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 8:24 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 20:09, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. An obvious problem that I managed overlook all of this time. And thanks for all of your shell code. Between mergemaster and portmaster you have saved many, many man-years of painful and error-prone effort. Do you dream in sh? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: bin/162135: remote syslog not logging
On 10/28/2011 11:01 PM, Stanislav Sedov wrote: On Fri, 28 Oct 2011 22:20:27 -0500 Larry Rosenmanl...@lerctr.org mentioned: See the options lines -a 192.168.200.0/24 And the Cable modem is sending to 514. Please, read the manpage description for the '-a' switch. The modem is sending to the port 514, it's true, but it's not using port 514 as a source. And you didn't specify the source service in the '-a' command line argument parameter. AHA! That's the issue. I changed the -a to: syslogd_flags=-n -a 192.168.200.0/24:* and we now get the messages logged. THANK YOU. ___ 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: syslogd: Remote Logging busted?
On Fri, Oct 28, 2011 at 8:37 PM, Larry Rosenman l...@lerctr.org wrote: On Fri, 28 Oct 2011, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman l...@lerctr.org wrote: I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to be logging the messages. They ARE making it to the system. Can someone look at bin/162135 which has all the details, including tcpdump to show that the messages are making it to the system. Just to be clear, you are running tcpdump on borg, right? The statement This is from my Cable Modem: confuses me a bit. Yes, the tcpdump is running on borg, and the source of the syslog packets is from my Cable Modem at 192.168.200.10. /etc/hosts.allow: [Comments elided] ALL : PARANOID : RFC931 20 : deny ALL : localhost 127.0.0.1 : allow ALL : [::1] : allow exim : localhost : allow exim : ALL : allow rpcbind : ALL : deny ypserv : localhost : allow ypserv : ALL : deny ftpd : localhost : allow ftpd : ALL : allow fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s tcpd\: %u@%h[%a] fingered me! root) \ : deny Several superfluous rules, but I can't see anything that would block 514. Assuming tcpdump is on borg, it is making past any firewall (pf or ipfw, at least). What about /etc/hosts.allow? I don't recall if it filters before or after pcap see packets. I used to have a diagram showing the sequence of processing this, but I can't seem to find it now. What does netstat -af inet | grep syslog show? Is syslogd actually listening? the netstat output: udp4 0 0 *.syslog *.* and sockstat | grep syslog: root syslogd 65128 4 dgram /var/run/log root syslogd 65128 5 dgram /var/run/logpriv root syslogd 65128 6 udp6 *:514 *:* root syslogd 65128 7 udp4 *:514 *:* OK. I'm baffled! I can't see anything that looks wrong, but I'll think about it a bit more. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 20:44, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 8:24 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 20:09, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. An obvious problem that I managed overlook all of this time. Well people try very hard not to introduce POLA'ish problems, but sometimes it's necessary, and sometimes it happens in spite of our best efforts (as Garrett pointed out). And thanks for all of your shell code. Between mergemaster and portmaster you have saved many, many man-years of painful and error-prone effort. You're welcome. :) Do you dream in sh? Well I probably will NOW, thanks a lot! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: syslogd: Remote Logging busted?
On Fri, 28 Oct 2011, Kevin Oberman wrote: OK. I'm baffled! I can't see anything that looks wrong, but I'll think about it a bit more. See my reply to Stas (cc'd to you). The issue is the damn cable modem is sending the packets from random source PORTS, so the -a entry needed a :* after the /24 to allow that. Now we're getting the log entries. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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: make installworld fails on releng9
On Thu, 27 Oct 2011, Chuck Burns wrote: I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. Are you running installworld in single-user mode? What is the value of kern.securelevel? -Ben Kaduk ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
pwd_mkdb -p /etc/master.passwd Cheers, Matthew Dr Matthew J Seaman MA, D.Phil. That did it! Now I can login as nonroot and startx. I found pwd_mkdb in my searching, but would not have known to use '-p'. I might have done pwd_mkdb /etc/master.passwd from Doug Barton do...@freebsd.org: Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. Doug That seems like a good idea, using -P option to be able to go back to something good if one screws up. From 'man mergemaster': The mergemaster utility is a Bourne shell script which is designed to aid you in updating the various configuration and other files associated with FreeBSD. It is HIGHLY recommended that you back up your /etc directory before beginning this process. So I could make a second backup of /etc before the second mergemaster invocation, after installworld. There are lots of files to merge/edit, and one can easily become tired and make mistakes. We're only human and not infallible. Tom ___ 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
