Re: freebsd-update upgrade -r 7.4-RELEASE-p12
Eduardo Morras wrote: [...] uname -a should give the correct answer. Has uname other utility than show information about the operating system implementation? No, and it must be accurate. That's what I thought, but when I asked about it here last year, I was told that this is the way things are; our expectations of uname are at fault. I believe if he were to compile his own kernel, it would say -p12. Suggestions were made for how to deal with it, but I don't know if they were ever followed up on. They wouldn't affect 7.x in any case. Start reading the thread here: http://lists.freebsd.org/pipermail/freebsd-questions/2012-May/240666.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. If your sources are in /usr/src, do this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
I wrote: The main problem this time is that I'm not so lucky with the password files, because for 8.4, freebsd-update has fetched new, stock .db files to put in /etc. Whoa, sorry, I misspoke here. freebsd-update asked me, after the merges, to approve unspecified differences in pwd.db and spwd.db. I assumed that it had fetched those files as part of the 8.4 distribution. But http://svnweb.freebsd.org/base/release/8.4.0/etc/ seems to indicate that's not what happened; only master.passwd was changed. I'm looking through the freebsd-update code now. I see it does actually do some special handling of master.passwd, but not until you do your 'freebsd-update install'. At that point, it will look at /etc/master.passwd and see if it's newer than /etc/pwd.db or /etc/spwd.db, and it will run pwd_mkdb. It doesn't use the -p flag, so I guess it doesn't care about passwd. This pwd_mkdb run didn't happen for me, though, since my 'freebsd-update install' run didn't actually put the new master.passwd file, or anything else, into /etc yet. I thought it would, but I don't understand it, really. So I don't see how it's supposed to work. To summarize: 1. I did the initial 'freebsd-update -r 8.4-RELEASE upgrade' 2. When prompted, I did all the merges it needed me to do by hand. 3. When prompted, I approved all the diffs. Two of the diffs were unspecified pwd.db spwd.db changes, which caused me some alarm. 4. I looked in the staging area and found that these were empty files. 5. I looked in /etc and nothing new had been placed there yet. 6. I did the 'freebsd-update install' and checked /etc again; still nothing. 7. Afraid of rebooting with bogus password database files staged, I generated proper pwd.db, spwd.db, and passwd files myself, and put them in the staging area. Next step, I think, is reboot, before another 'freebsd-update install' run. I'm worried something is still amiss, though, so I'm holding off for now. :( ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update percentage indicators - what are they, why are they so random?
Fetching 1 metadata files... 70.5% done. 70.5% 70.5% 74.2% 74.2% 81.7% 81.7% 70.5% I think this is a result of having -v in my GZIP environment variable. I always forget about my GZIP and BZIP2 variables. I should've known. So, never mind about that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
I'm using freebsd-update to upgrade my system to the latest minor version
(from 8.3-RELEASE to 8.4-RELEASE).
I'm surprised that the merge handling system isn't more robust. When
upgrading
the old way, from source, I was used to using mergemaster to handle any
merges that couldn't be done automatically.
But when using freebsd-update, it seems that any failed merges require that
you get dumped into an empty text editor for each file.
[...]
As I continue with this process, doing all the mergemaster tasks manually, I'm
finding that the situation is even worse than I first realized.
First, the relatively painless part. As I mentioned, after running
'freebsd-update -r 8.4-RELEASE upgrade', I had to deal with the un-mergeable
files.
Although mergemaster apparently isn't an option, its interactive merge
function is really just a front-end for sdiff, so I found that I could
replicate that part of its functionality by doing this in a separate window
(-w 100 because I use a 100-column terminal):
cd /var/db/freebsd-update/merge/8.4-RELEASE
find -X . -type f | xargs -n 1 -o -I % sh -c '{ echo Now processing %.
left=current, right=new, help=?; sdiff -d -w 100 -o ../new/% ../old/% %; }'
This populated my 'new' directory with merged files, so that (in the first
window) when I opened the text editor for each one, I only had to just give it
a once-over and exit the editor.
Among the diffs in this 8.3 to 8.4 upgrade were changes to /etc/master.passwd
and /etc/passwd, to add the 'auditdistd' and 'hast' users. As reported in
March 2012 [1] in relation to 8.x to 9.x upgrades, this won't work as
expected, because freebsd-update doesn't run pwd_mkdb after the master.passwd
update.
Now the real hurt begins; in the 8.3 to 8.4 upgrade, it's even worse.
Once I saved all the files in the editor, I was prompted to approve a diff for
each one. I had to answer y or the entire process aborts.
Among the changes I was asked to approve, besides visible diffs, were
unspecified differences in /etc/pwd.db and /etc/spwd.db, the binary files that
contain the password database. There's no choice but to answer y and
approve them, and I don't get any opportunity to rebuild them properly.
So apparently, freebsd-update wants to install new, stock password databases,
which are out-of-sync with my customized, merged master.passwd passwd files.
(And because of the way the freebsd-update system works, what I actually
approved were empty, 0-byte files, the result of the failed merges.)
What would happen if I just let it do this? Surely I wouldn't be able to log
in, after the reboot, right?
After approving the files (again, I had no choice!), I was presented with
lists of all the files that would be deleted, added, and modified. Sure
enough, bad /etc/pwd.db and /etc/spwd.db files were in the list.
At this point, the merge folders were now gone; I no longer had the new
master.passwd in a recognizable place. So I thought, OK, I'll run
'freebsd-update install' and hope that the new files end up in /etc. Then I
could just run 'pwd_mkdb -p /etc/master.passwd' to regenerate passwd, pwd.db
and spwd.db before my reboot.
But the 'freebsd-update install' didn't put them there yet; I guess that
doesn't happen till after the reboot. So they're still sitting in a staging
folder, now gzipped and with obfuscated names, indexed in a separate file.
Averting this disaster-in-the-making is not at all straightforward:
cd /var/db/freebsd-update
mkdir -m 0700 /tmp/oldpwdfiles
zcat files/`grep '^/etc/master\.passwd' install.LYQAJQ/INDEX-NEW | cut -d \| -f
7`.gz /tmp/oldpwdfiles/master.passwd
zcat files/`grep '^/etc/passwd' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/passwd
zcat files/`grep '^/etc/pwd\.db' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/pwd.db
zcat files/`grep '^/etc/spwd\.db' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/spwd.db
mkdir -m 0700 /tmp/newpwdfiles
pwd_mkdb -d /tmp/newpwdfiles -p /tmp/oldpwdfiles/master.passwd
gzip /tmp/newpwdfiles/*
mv /tmp/newpwdfiles/master.passwd.gz files/`grep '^/etc/master\.passwd'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/passwd.gz files/`grep '^/etc/passwd'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/pwd.db.gz files/`grep '^/etc/pwd\.db'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/spwd.db.gz files/`grep '^/etc/spwd\.db'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
rm -fr /tmp/oldpwdfiles /tmp/newpwdfiles
I'm really shocked that it came to this. Did I just overlook the
--no-surprises option in freebsd-update?
And now, before I reboot, I have to figure out how to handle the changes that
got made in /etc/mail ... ordinarily I'd run 'make all install restart' in
there. Not an option till after reboot, though. At least it's not crucial for
the reboot to work.
Again, this is something that mergemaster was really good for. But
Re: Should I be able to use mergemaster with freebsd-update?
On Tue, Jun 25, 2013, at 15:29, Eugene wrote: I do not quite understand. Is the freebsd-update upgrade process completely broken? IMHO it is partially broken; I'm not doing anything special. How broken it is depends on what's getting changed. Most of what the system is designed to do, it indeed does very well. It also overlaps some of the functionality of mergemaster in that it automatically merges as many files as it can, which is nice. Where it is under-designed and under-implemented is in its rudimentary handling of un-mergeable files, and in its total lack of support for the regeneration of /etc/*.db files (like the, uh, rather important password database) and sendmail aliases - things that you would handle via mergemaster in an ordinary, source-based upgrade, but which you must now figure out how to do by hand, without any guidance, and they really don't make it easy for you. When I upgraded from 8.1 to 8.3, I avoided the issue altogether by not really merging anything; when dumped into the empty text editor, I just loaded my old files and made no changes. In the Handbook, there's an assumption that people who do this will go back later and figure out what merges are needed, but the resources you need to do that don't exist; if you don't do the merge when prompted, you don't get a second chance. In fact, even if you do it when prompted, you need to get it right, or start the whole process over. My upgrade to 8.3 worked out OK because I got lucky; freebsd-update hadn't fetched new, stock password database files. The unmergeable files were all text files, nothing requiring anything to be regenerated. But this time around, for 8.3 to 8.4, I am trying to do everything I'm supposed to, actually merging when prompted. The fact that it's a *really* manual process is a pain, but as I mentioned, I found a way to at least run sdiff from another window, which made it a lot easier, although still more tedious than it should be. The main problem this time is that I'm not so lucky with the password files, because for 8.4, freebsd-update has fetched new, stock .db files to put in /etc. So, yes, I was able to merge master.passwd passwd, but that's not very helpful since the .db files won't be in sync with them. If allow my custom password database to be overwritten with these new, stock .db files, obviously that's bad. And because freebsd-update makes no special allowance for the .db files, it actually put a zero-byte file in the staging area instead of the real .db file (as if it were going to have me modify it with an editor). So if I proceed, my password database will actually be overwritten with an empty file, which I believe would be a disaster. The solution, I feel, is to: 1. make freebsd-update recognize files that most likely need to be regenerated instead of replaced - /etc/*.db, at least, if not also any other binary file, and some of the things that would be generated by 'make' in /etc/mail. The user should be informed that these files need to be regenerated, if there's no way to just regenerate them automatically when their companion source files have been updated or merged. 2. make freebsd-update run mergemaster on the unmergeable text files, instead of dumping the user into an empty text editor for each one. For each file that can't be automatically merged, mergemaster will give the user the opportunity to choose whether to keep the old file, replace it with the new file, interactively merge them via sdiff, or do nothing. It is also smart enough to realize that when certain files are being touched, such as /etc/master.passwd, /etc/mail/aliases, etc. you'll need to run pwd_mkdb, cap_mkdb, services_mkdb, or newaliases...and it will run those for you (or remind you to do it). For this to work, mergemaster would need some tweaking to deal with freebsd-update's staging area, and to not duplicate any of the work that freebsd-update does. I keep hoping that maybe there's some nuance of the process that I'm missing, and that all of this really is not a problem.. user error, or not reading the docs carefully enough, you know? But Mark Felder's comments seem to confirm that it's a real issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update percentage indicators - what are they, why are they so random?
I'm using freebsd-update to upgrade my system to the latest minor release. At a couple points in the process, I get weird status indicators (percentages) showing me that something is happening: Fetching 1 metadata files... 70.5% done. 70.5% 70.5% 74.2% 74.2% 81.7% 81.7% 70.5% Inspecting system... done. Sometimes these numbers are negative, and although not entirely random, they don't seem to follow any particular pattern... they don't creep up from 0 to 100, at least: Preparing to download files... done. -4.7% -8.4% -9.6% 35.4% 30.6% 30.5% 45.2% 43.4% 43.0% 68.1% 68.2% 68.2% 44.4% 43.0% 43.0% 72.0% 71.9% 71.9% 69.1% 69.0% 69.0% 72.0% 71.9% 71.9% 69.1% 69.0% 69.0% 52.2% 50.2% 49.9% 53.4% 56.8% 57.5% 59.0% 55.1% 56.0% 91.4% 94.5% 94.3% 90.4% 94.5% 94.3% 54.8% 54.6% 55.3% 28.8% 24.9% 24.2% 57.0% 53.3% 55.1% Attempting to automatically merge changes in files... done. What is the point of these numbers? Does everyone see them, or is it just me? Are they supposed to be on separate lines like this, or are they supposed to overwrite each other one line? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Should I be able to use mergemaster with freebsd-update?
I'm using freebsd-update to upgrade my system to the latest minor version (from 8.3-RELEASE to 8.4-RELEASE). I'm surprised that the merge handling system isn't more robust. When upgrading the old way, from source, I was used to using mergemaster to handle any merges that couldn't be done automatically. But when using freebsd-update, it seems that any failed merges require that you get dumped into an empty text editor for each file. It doesn't even tell you where the new file is so you can load it and compare it to the old one. After that, you're asked to approve every diff, but if you reject one, you don't get a chance to re-edit; the entire upgrade aborts and you have to start all over again. Since it wasn't obvious what to do, last time I upgraded, I just loaded all my old files and kept them as-is, without merging them. This time, I'm trying to actually take care of them when prompted. When I get dumped into the empty text editor, I suppose it's not too hard to figure out that the new file is in /var/db/freebsd-update/merge/8.4-RELEASE, but that's certainly not documented anywhere. It could at least be mentioned prior to being sent to the editor. The old file is mentioned, so why not the new? Regardless, when doing a manual merge by loading both files and consolidating them, or by copy-paste voodoo between terminal windows, it is far easier to screw up than mergemaster's method, at least in my experience. So I was thinking that when I get to this stage of the freebsd-update process, it would be nice to use mergemaster in a separate terminal window. I mean, I know where the new files are, and I know where I need the merged files to go, so it should be just a matter of invoking mergemaster with the right flags, right? Then when I'm dumped into a text editor, it won't be empty; I'll see the mergemaster-produced file, and can just give it a once-over. The handbook even mentions mergemaster as if it is an option: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html#freebsdupdate-config-file ...or at least, it suggests I read about it, for some reason. But I can't figure out how to get mergemaster to use freebsd-update's file locations. Here is what I tried: mergemaster -ciFv -m /var/db/freebsd-update/merge/8.4-RELEASE -D /var/db/freebsd-update/merge/new Here's what that results in, even if I add trailing slashes: make: don't know how to make distrib-dirs. Stop make: don't know how to make distrib-dirs. Stop *** FATAL ERROR: Cannot 'cd' to /var/db/freebsd-update/merge/8.4-RELEASE and install files to the temproot environment Any suggestions appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
Da Rock wrote: sysctl kern.version For me, that's the same info as in uname -a. Try this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
perl-after-upgrade mistakenly thinks nothing needs to be done
Hi all, I'm running 8.3-RELEASE and thought I'd update Perl from 5.12 to 5.16. Silly me. I updated my ports snapshot, and as per UPDATING, ran portmaster -o lang/perl5.16 lang/perl5.12 This went OK, so I then ran perl-after-upgrade, with and without -f. It scans the packages and finds everything it should, but insists nothing needs to be done, saying 0 moved, 0 modified, 0 adjusted for every one of them. At the end it says Fixed 0 packages (0 files moved, 0 files modified). Well of course this isn't right; all my modules are still sitting in the 5.12.4 directory and are not getting moved over to the 5.16.2 one. This naturally breaks everything depending on those modules. What's going wrong? Sorry if this is a novice question. Please let me know what I need to check. Thanks, Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: perl-after-upgrade mistakenly thinks nothing needs to be done
Thanks for the replies; I really appreciate it. Alexandre wrote: Have you followed steps described in perl-after-upgrade man page? $ man perl-after-upgrade Yes, except for the last step (deleting old CONTENTS backups), since the previous steps didn't seem to do what they should. As I said, perl-after-upgrade thinks there's nothing to do. It doesn't report any packages it can't handle. It handles them, but for some reason determines that they are OK, despite the fact that the modules are all still sitting in the old installation. Anton Shterenlikht wrote: Have you done portmaster 5-? If not, do it. I hadn't done that. (portmaster 5- doesn't work, but portmaster p5- does.) UPDATING makes mention of this, but I didn't understand that it was saying it was a required step. Specifically, this is what it says: - 20120630: AFFECTS: users of lang/perl* AUTHOR: s...@freebsd.org lang/perl5.16 is out. If you want to switch to it from, for example lang/perl5.12, that is: Portupgrade users: 0) Fix pkgdb.db (for safety): pkgdb -Ff 1) Reinstall new version of Perl (5.16): env DISABLE_CONFLICTS=1 portupgrade -o lang/perl5.16 -f perl-5.12.\* 2) Reinstall everything that depends on Perl: portupgrade -fr perl Portmaster users: portmaster -o lang/perl5.16 lang/perl5.12 Conservative: portmaster p5- Comprehensive (but perhaps overkill): portmaster -r perl- Note: If the perl- glob matches more than one port you will need to specify the name of the Perl directory in /var/db/pkg explicitly. The default version for Perl has also been changed from 5.12 to 5.14. - Because of the way the portupgrade section is numbered, I thought the portmaster section was giving me 3 options: regular, conservative, comprehensive -- not two steps (1. portmaster -o, then 2. choose either the conservative or comprehensive option). ...partly my reading comprehension failure, I guess. It makes no mention of perl-after-upgrade, though. My understanding is that perl-after-upgrade looks at what perl-dependent packages are installed. As I can see by its output, this includes not just the application packages like SpamAssassin and mrtg, but their requisite Perl module packages as well, like HTML::Parser. Then, as these packages are found, perl-after-upgrade moves things from the old Perl installation over to the new, and does some other cleanup. Maybe that's a flawed assumption, because it seems rather weird to me that before running perl-after-upgrade, I'm expected to *first* to do a *full upgrade or reinstall* of the modules. Isn't that exactly what we're trying to avoid by running perl-after-upgrade? Nothing in the perl-after-upgrade man page suggests this is necessary; in fact, the intro implies the opposite. After this is done, how much have you got left under 5.12.4? Not much of anything, just a man page, a few mrtg .pm files... Naturally, running perl-after-upgrade at this point yields the same results as before (0 moved, 0 modified, 0 adjusted for everything). But this time, that's the expected output, I believe, given that I just reinstalled everything. I guess I'm just completely confused about what perl-after-upgrade was actually supposed to do, so it's difficult to suggest documentation updates. At the very least, though, maybe change UPDATING to clarify that the portmaster steps are a sequence, and mention perl-after-upgrade. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update not updating reported patchlevel
I installed 8.2-RELEASE when it was new, and have been just using freebsd-update since then. I run freebsd-update whenever there are new critical patches. But for some reason, my system's reported patchlevel number hasn't updated since p3. For example, with this latest OpenSSL security update, running 'freebsd-update fetch' says (among other things) The following files will be updated as part of updating to 8.2-RELEASE-p7 and WARNING: FreeBSD 8.2-RELEASE-p3 is approaching its End-of-Life date. It is strongly recommended that you upgrade to a newer release within the next 2 months. So apparently it really thinks I'm at -p3, when I know I'm at -p6, and was at -p5 before that, and -p4 before that. The fact that the latest update only included the OpenSSL files confirms that the relevant files have been getting updated when I 'freebsd-update install'. But 'uname -r' continues to return 8.2-RELEASE-p3. Rebooting doesn't help. Is there something I need to do in order to bump the reported patchlevel? I thought this was supposed to happen automatically, since I didn't have to do anything to get it up to -p3. Thanks, Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: null bytes after ANSI sequences in color 'ls' output
OK, so the null bytes are correct for vt100 and should've always been there,
and the fact that they've suddenly showed up in FreeBSD 6.3 is basically a
feature.
Setting NCURSES_NO_PADDING has no effect, so 'ls' apparently does just use
termcap features.
Following Dan Nelson's advice to switch TERM to xterm-color only changes the
behavior slightly: rather than getting 2 trailing ESC[m sequences followed by
8 null bytes, I get 1 ESC[m followed by a single 0x0F byte, which shows up as
^O when piped through less.
After reading a bit more about ANSI codes at
http://bjh21.me.uk/all-escapes/all-escapes.txt, I see that the trailing codes
are just variations on a 'reset' theme.
ESC[36m = cyan text
ESC[39;49m = default text; default background
ESC[m = same as ESC[0m
ESC[0m = default rendition, canceling any preceding ESC[foom
ESC[0m;10m = default rendition; default font
Ctrl-O in xterm = string command/capability 'ae' ('End alternative character
set')
Now, I thought I'd try terminal type 'linux' as well. This changes things a
bit: I now get ESC[0;10m at the end, which means reset to default rendition,
with the default font. It has no padding bytes or odd control chars, so I can
use this with 'less -R'.
In summary, 'ls -dG Mail | less' yields the following:
with TERM=vt100-color
ESC[36mMailESC[39;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@
with TERM=xterm-color (or just xterm; they're aliases):
ESC[36mMailESC[39;49mESC[m^O
with TERM=linux:
ESC[36mMailESC[39;49mESC[0;10m
So I guess as long as I use 'less -R', which is the only way to reliably use
'less' to page ANSI color output, I'm going to have to use TERM=linux, or else
add another pipe to filter out the offending characters, like 'tr -d \000'.
I think I'm going to opt for the latter, for now, because I seem to recall
some weirdness with SecureCRT's linux emulation.
Thanks for the speculation and assistance! You got me on the right track.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
null bytes after ANSI sequences in color 'ls' output
After I upgraded 6.2-STABLE (Feb 2007-ish) to 6.3-STABLE (last week), my colorized 'ls -G' output is now plagued with 8 null bytes following each ANSI sequence. I normally pipe my output to 'less -R' so ANSI sequences pass through while other control characters are converted to visible ones. This worked great until now. Now I see '^@' for each null. It's not a new feature of less, so I assume it's ls or curses throwing in the nulls. For example, I'm getting output like this if I use 'ls -G | less': ESC[36mMailESC[39;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ It's the '^@'s that are unexpected, although the repeated ESC[m pairs are also mysterious since they seem to have no purpose. If I use 'ls -G | less -R', then the ANSI sequences pass through as they should, but I still get the nulls. Questions: Is this is reproducible? Should I file a PR? FWIW, my tcsh TERM environment variable is vt100-color. I'm using SecureCRT with vt100 emulation and ANSI color. Thanks, Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non-English character support
Alex Teslik wrote: I was also wondering why there is no en_US.UTF8 in /usr/share/locale? Any guidence is much appreciated. I am using FreeBSD 4.10-RELEASE-p5. In FreeBSD 4.x, the UTF-8 locale support files have to be installed from the ports collection. cd /usr/ports/misc/utf8locale make install You'll need to do this after each OS upgrade (unless you go to 5.x, under which you should remove the port entirely). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_create: correct usage?
mdff wrote: i'm trying to create packages on freebsd-5.4-RELEASE. can anyone tell me how to define a packinglist for pkg_create with the ability to remove the directories after pkg_delete and not getting complaints if they are not empty? if i specify @dirrm dir in the packinglist, i get these errors, if some packages share a specific directory: # pkg_delete packname pkg_delete: unable to completely remove directory '/usr/local/lib' pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) br... This question might be better to ask on [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Procedure for migrating user accounts to new system ?
Nelis Lamprecht wrote: To answer my own posting. Simply copy(keeping correct permissions) /etc/passwd, /etc/master.passwd and /etc/group to the new system making sure you have a backup of the original if anything goes wrong. Then run pwd_mkdb -p /etc/passwd which will update /etc/pwd.db, spwd.db. I then rsync'ed all home directories and all is well. I would add (as this just came up with one of my users today) that you will probably also want to copy /var/cron/tabs to the new system, lest everyone lose their crontabs. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux move to FreeBSD
Bob Hall wrote: The belief that guys with red skin, horns, pointy tails, and pitchforks represent the devil is a European superstition, not a Christian doctrine. There's no support for it in the Bible or the writings of the church fathers. There is also no support, except among BSD fans, for horned, pointy-tailed, red-skinned creatures with pitchforks representing anything other than a li'l devil. Saying it represents an invisible, oft-benevolent 'daemon' has very little credibility when the mascot was clearly intended to look like what two-thirds of humanity would recognize as _el diablo_, albeit an awfully harmless, cartoony one. I think I will give one of my favorite input control devices, the 'mouse', a mascot. It'll look a lot like this guy: http://images.google.com/images?q=mickey%20mouse ...but if anyone complains I'll just tell them it's clearly not an animate rodent, but is rather a stylized, anthropomorphic interpretation of a computer accessory. I'm sure the lawyers at Disney will see my point of view. Hey, if it works for Beastie the daemon... On a more serious note, am I the only one who has been getting hiccups of freebsd-questions mail from last year? I just got a bunch of traffic (including one of the previous incarnations of this abysmal Beastie logo non-debate) from late December, all posts that I had seen before. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
installworld failure - osreldate.h
Hi all, Any idea what would be causing this during a routine upgrade of FreeBSD 4.10-STABLE (Dec 1 2004) to today's STABLE? newvers.sh has a 'touch version' in it, but I don't see how that could ever produce 'not found'. -- Installing everything.. -- cd /usr/src; make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h; echo '#error osreldate.h must not be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld failure - osreldate.h
Mike Brown wrote: Hi all, Any idea what would be causing this during a routine upgrade of FreeBSD 4.10-STABLE (Dec 1 2004) to today's STABLE? newvers.sh has a 'touch version' in it, but I don't see how that could ever produce 'not found'. (and my system clock is OK; I just ran ntpdate again to be sure. I also ran adjkerntz -i) -- Installing everything.. -- cd /usr/src; make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h; echo '#error osreldate.h must not be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld processes failing (was Re: installworld failure)
Mike Brown wrote: (and my system clock is OK; I just ran ntpdate again to be sure. I also ran adjkerntz -i) Never mind; I have bigger problems. The 'touch: not found' I see now is related to the just-now-noticed fact that my buildworld had failed for some reason. Subsequent attempts to run buildworld are failing as well, at random places. /var/log/messages indicates processes involved in the build are dumping core. === gnu/usr.bin/groff/font/devutf8 /usr/obj/usr/src/gnu/usr.bin/groff/font/devutf8 created for /usr/src/gnu/usr.bin/groff/font/devutf8 *** Signal 10 Memory issues? I upgraded the motherboard and RAM on this system. The old one had 384 MB, the new one has 512 MB. In my old kernel (still running at the moment), I had MAXMEM set based on the 384 figure. I'm occasionally seeing memory paging related errors and I'm guessing it's because of the bad value, hence my desire to upgrade the OS with no MAXMEM setting this time. Unfortunately I am apparently unable to do something so memory-intensive as building world with things being unstable, and my old RAM was bad and is long gone, so I'm not sure what to do, short of installing from scratch :/ -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mailinglist privacy: MY NAME ALL OVER GOOGLE!
Anthony Atkielski wrote: It _is_ the fault of the mailing list manager that posts are being archived without the permission of mailing-list members. Members must be required to explicitly grant permission when they subscribe. Even if they did, there is no way for the mailing list software or the administrators of the list to know who is receiving the messages or whether those addresses correspond to individual human beings. The list is just a list of addresses. It is quite possible, even likely, that at least one or two of the addresses subscribed to this very list are archiving every post, or perhaps reflecting the posts to email users on another network. In short, if you don't want it public, don't post it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
sorry for late post on MY NAME ALL OVER blah blah
Sorry; didn't notice as I was catching up on email that it was a dead thread already, and that I was replying to a known troll. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Beastie logo *is* a li'l devil, ya gotta admit
Anthony Atkielski wrote: Bob Johnson writes: I work in an office largely populated by born-again Christians, and some of them very definitely object to the BSD logo. Even after I explained the daemon thing, they still didn't think BSD should use The Devil as its logo. It doesn't help that some people use devil and daemon interchangeably. Daemons were originally morally neutral entities; the Devil (or devils in generally) have been mostly evil creatures throughout history. Of course, Judeo-Christian tradition turned daemons into fundamentally evil creatures (instead of just metaphysical helpers), too. All of these people who try to rationalize that daemons are actually benign, helpful creatures and that it was the nasty bad religious nuts who associated them with malevolence seem to be overlooking the fact that the mascot's red color, pitchfork, spiked tail, and pointy ears are hallmarks of the modern/wrong interpretation of what a daemon is: a li'l devil, so to speak. It seems a bit absurd to suggest that the original artists were trying to represent the metaphysical helpers. The mascot is clearly a toned-down, cartoony rendition of the fundamentally-evil end of the supernatural, like Casper the Friendly Ghost, or the kind of devil that sits on Jerry the Mouse's shoulder and suggests mischievous things to do to Tom the Cat. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAJOR DISFUNCTION! Computer reboots instead of booting FreeBSD!
My computer (HP Compaq DC7100) refuses to boot to FreeBSD. It enters the MBR, I then select FreeBSD in the bootloader and the computer reboots! What kind of behavior is this, and why won't it give FreeBSD a chance? I had the same symptom on different hardware. If I watched closely, I could see a kernel error message appear very briefly before the reboot. I tried various things and posted here about it, but could not get past it, and no one offered any help. Disabling ACPI made zero difference. I didn't understand why it would boot fine on the miniinst CD to do the install, but wouldn't boot from the HD (an ordinary ATA one, at that). The problem went away when I gave up on FreeBSD 5.3 and installed FreeBSD 4.10 instead. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No latin characters :(
Mário Gamito wrote: Hi again, I did everything just as you told me. When i type a latin letter like á, etc., i get a greek letter :( Internally, your á is probably byte 0xE1, as that is how it is defined by the ISO-8859-1 character map, and I assume that it's being interpreted correctly on the input side. If this byte is interpreted for output/display according to another character map, then you will see some other character that you didn't intend. For example, if it looks like ß (Latin small letter sharp s, which is used when writing the German language), then the byte is being interpreted according to CP437. If you tell us what character you get, it may help. We also need to know what you are using for display. Anything you can tell us about your setup, and how *we* can reproduce your results... There are so many possible points of failure, and you have not told us enough. Are you using the console (using hardware text modes), or are you doing this via an X Window session and a terminal window, or are you SSHing in and looking at everything through a Windows or Mac OS X environment? If you're not doing this at the console, then what SSH or terminal app are you using and how do you have it configured? In what are you typing the non-ASCII characters -- a shell? a text editor? Which one? All of these things make a difference. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stuck at gettext....
Zachary Huang wrote: but still I got stuck here when installing the /usr/ports/emulators/linux_base. It appears that the patch for freebsd did not work for gettext... now what do I do? pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-stable/All/linux_base-7.1_7.tgz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: JDK14 fails to install
Daniel Bye wrote: This has come up several times recently. The Linux Sun JDK (which is used to bootstrap the build of the native JDK) requires that the Linux procfs system is available. Add this to your /etc/fstab: linprocfs /compat/linux/proc linprocfs rw 0 0 and then, as root: kldload linprocfs mount /compat/linux/proc You can then restart the build of the native JDK. FYI, this is mentioned in the linux-sun-jdk* ports' pkg-message files. Once the native JDK is built and installed, you can remove the Linux one, and you will no longer need to mount the linprocfs. Does this also apply to the linux-blackdown-jdk* ports/packages? I tried installing the linux-blackdown-jdk14 package last night but I could not run the VM; it complained of a missing file in /proc. -Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.3-RELEASE kernel boot problems
First the system specs: * Motherboard: SuperMicro 370SED (manuf. in 2000; see [1]) * CPU: Intel Pentium III 933 MHz * RAM: 384 MB (128 MB PC100; 256 MB PC133) * network: * Linksys LNE100TX Etherfast 10/100 (device dc0) * Linksys LNE100TX Etherfast 10/100 (device dc1; unused for now) * video: integrated * storage: * built-in primary IDE controller * primary master: 24x CD-ROM (unknown manuf.) * built-in secondary IDE controller: disabled in BIOS * Maxtor Ultra/ATA 100 PCI IDE controller: * primary master: Maxtor 80 GB ATA/133 DiamondMax Plus 9 (new) using entire disk for FreeBSD slice; geometry is OK. partitions: ad4s1a150 MB / ad4s1b768 MB swap ad4s4d8 GB/var ad4s1e7 GB/usr ad4s1f 61 GB/milo (misc) * primary slave: Maxtor 60 GB ATA/100 (DiamondMax Plus 60) * secondary master: Maxtor 30 GB (DiamondMax VL40) * secondary slave: none Now for my problem: If I install FreeBSD 4.10 from a miniinst CD-R on this system, it works great, no problems. If I install FreeBSD 5.3 from a miniinst CD-R on the same system with no hardware changes, the CD boots up fine (no need to disable ACPI), it fails to make it through the boot process; it just keeps rebooting. More on that in a sec. It also fails to install if all of the following are true: - partitions were set up already from a previous install; - in the slice editor I just re-entered the mount points (they come up as asterisks each time sysinstall is run... I assume that's normal?) - the newfs flag is NOT set on each partition Under these circumstances, the install process freezes at the first fsck_ffs operation (Doing fsck_ffs -y /mnt/dev/ad4s1f which is my /milo partition) ...and no key combos can get out of it. I thought it maybe just took a while but after 30 minutes I decided it was dead. OK, anyway, so if I set newfs on the partitions, then the base distribution installs OK. I can set up the network and root user password, enable SSH and inetd, and then let it boot... BSP CPU.Microcode OK Searching for Boot Record from CDROM..Not Found Searching for Boot Record from Floppy..Not Found Searching for Boot Record from SCSI..Not Found ...and then I get a stack dump that I can't copy here because it disappears as the system automatically reboots right away. If I press a key during the boot, before /boot/loader runs, I can enter 0:ad(0,a) /boot/kernel/kernel -p The result is a rapidly twirling - that then slows and then freezes. A cold reboot is then needed. Same effect when using -sv or -C. I have also tried putting in a different drive (an old 5 GB Seagate instead of the 80 GB Maxtor) and installing to that. For some reason, it doesn't automatically reboot after printing the kernel stack dump, but otherwise there's no change in behavior. I tried using an old 5 GB Seagate drive instead of the Maxtor 80 GB. I tried using a different drive cable. I tried disconnecting all drives other than the boot drive. I have tried setting the partition active and not modifying the MBR. I have also tried using UFS1 instead of UFS2 on all partitions. I have tried using the FreeBSD boot loader. No difference in any case. Twirl twirl twirl freeze. Help? Thanks, Mike [1] http://www.supermicro.com/manuals/motherboard/810/MNL-0618.pdf ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
