Re: ZFS Boot Menu
06.10.2013 08:54, Teske, Devin wrote: On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: 29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. Cool; to start with, do you have a virtual appliance software like VMware or VirtualBox? Experience with generating ZFS pools in said software? VirtualBox/Qemu, Qemu is able to emulate boot to serial for example. And yes I tried working with ZFS in VMs. I think that we may have something to test next month. Right now, we're working on the ability of bsdinstall(8) to provision Boot on ZFS as a built-in functionality. That sounds cool. -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS Boot Menu
29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem
11.07.2013 17:43, Reid Linnemann написав(ла): So recently I was trying to transfer a root-on-ZFS zpool from one pair of disks to a single, larger disk. As I am wont to do, I botched the transfer up and decided to destroy the ZFS filesystems on the destination and start again. Naturally I was up late working on this, being sloppy and drowsy without any coffee, and lo and behold I issued my 'zfs destroy -R' and immediately realized after pressing [ENTER[ that I had given it the source's zpool name. oops. Fortunately I was able to interrupt the procedure with only /usr being destroyed from the pool and I was able to send/receive the truly vital data in my /var partition to the new disk and re-deploy the base system to /usr on the new disk. The only thing I'm really missing at this point is all of the third-party software configuration I had in /usr/local/etc and my apache data in /usr/local/www. You can try to experiment with zpool hidden flags. Look at this command: zpool import -N -o readonly=on -f -R /pool pool It will try to import pool in readonly mode so no data would be written on it. It also doesn't mount anything on import so if any fs is damaged you have less chances triggering a coredump. Also zpool import has a hidden -T switch that gives you ability to select transaction that you want to try to restore. You'll need a list of available transaction though: zdb -ul vdev This one when given a vdev lists all uberblocks with their respective transaction ids. You can take the highest one (it's not the last one) and try to mount pool with: zpool import -N -o readonly=on -f -R /pool -F -T transaction_id pool Then check available filesystems. -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpufreq not working as module on i386/amd64
04.07.2013 08:37, Jia-Shiun Li wrote: ok anyone can help test and review this patch? It will allow cpufreq to be removed from kernel conf, loaded and function correctly as kernel module. I've tested it ok on my own i5-3450. Works here at AMD X4 750K: # kldload cpufreq Jul 4 16:00:11 ar1l0u kernel: hwpstate0: Cool`n'Quiet 2.0 on cpu0 # sysctl -a | grep cpufreq debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 # kldunload cpufreq Jul 4 16:48:26 ar1l0u kernel: hwpstate0: detached -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
19.11.2012 14:34, Ivan Voras wrote: On 17/11/2012 22:48, Chris Rees wrote: (and is GPL btw) Since we're discussing it, Mercurial is BSDL-ed, and apparently has proper crypto signing using GPG: http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F :%s/BSD/LGP/ http://mercurial.selenic.com/about/ -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Hi all. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857 This PR is rather old. I just had submitted new test case, now in plain c. It doesn't work exactly like python version, but the result is the same: clang test.c cat test.c | ./a.out -1 916 0 0 0 -1 0 32768 0 0 ./a.out test.c -1 916 0 0 0 - and here we have a complete hang in [kqread]. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Konstantin Belousov wrote:
This PR is rather old. I just had submitted new test case, now in plain c.
It doesn't work exactly like python version, but the result is the same:
clang test.c
cat test.c | ./a.out
-1 916 0 0 0
-1 0 32768 0 0
./a.out test.c
-1 916 0 0 0
- and here we have a complete hang in [kqread].
And what is your expectation ?
The vnode filter never returns EOF when current file position at the end
of file. It is documented that read filter returns when file offset if not
at the end of file, thats all. In fact, EV_EOF is returned on forced unmount.
I do not see a bug in kqueue.
On the other hand, your C code has at least two things that I cannot
understand. First, EV_EOF is output flag, it makes absolutely no sense
to set it in command.Second, it is mistery for me what do you check with
if (kev.flags 15 == 1) {
test.
EV_EOF on line 19 actually slipped by my fault, original source omits
that one. It doesn't change anything.
EV_EOF = 1 15 = 32768. And it _is_ returned when file is feed with
the pipe.
So you mean this is just my false assumption that EOF _should_ occur on
stdin? And it actually occurs only if source is a process which can send
EOF?
--
Sphinx of black quartz judge my vow.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Konstantin Belousov wrote:
So you mean this is just my false assumption that EOF _should_ occur on
stdin? And it actually occurs only if source is a process which can send
EOF?
'Source' cannot be a process. Read filter on pipes can return EV_EOF.
Read filter on vnodes (read: regular files) does not return EV_EOF,
except in situation that is created by manual intervention of
administrator.
This keeps me puzzled. How then I can tell that file at stdin is already
at EOF? You mean I should treat stdin like normal vnode-backed file?
off_t pos = 0, endpos;
lseek(fileno(stdin), 0, SEEK_END);
endpos = ftell(stdin);
lseek(fileno(stdin), 0, SEEK_SET);
... and then later check it with:
if(endpos != -1) {
pos += kev.data;
if(pos = endpos) {
printf(end reached\n);
return(0);
}
}
Is this a correct way to detect EOF? I'm letting besides that I should
also detect vnode changes and update max file size accordingly.
It should have been clear from my previous response.
Please excuse me, I'm a bit new to this things...
--
Sphinx of black quartz judge my vow.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Wojciech Puchar wrote: Personally I think that the kernel boot time is the killer here and the work should go there and second on the rc system. exactly what i wrote. rc.d subsystem is quick, and anyway in special cases just delete in and write all needed startup in /etc/rc i assume it is embedded system - in which boot time is very important. PS: nothing wrong in having an OS that boots faster, performs better is more stable than others :). This is something I would like to see as an improvement. Wouldn't you ? of course i do! Do you have USB in that system? The problem is deeper, I'm using minimalized kernel without USB and greatest hang is 3 or so seconds after Timecounters tick every 1.000 msec just before ada0 appears. And I have already tried modularized ada - results are the same. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
Varuna wrote: Hello Folks, Noticed a strange issue with the creation / update of /etc/resolv.conf. The details of the system that I noticed the issue on is: Version : FreeBSD 8.0 Patch level: not patched Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011 r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386 I generally have a static IP 192.168.98.6 (via rc.conf) for my Beastie. The contents of my /etc/resolv.conf is as follows: domain eudaemonicsystems.net nameserver 208.67.222.222 nameserver 208.67.220.220 nameserver 4.2.2.2 No matter how many times I reboot the system, the resolv.conf does not get overwritten when configured with a static IP. 1. Since 9.0 we already have resolveconf(8) for this. 2. Empty dhclient.conf means default configuration, you can make your own, refusing nameserver updates coming from DHCP. 3. You can always chflags noschg any precious file. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Root on ZFS GPT and boot to ufs partition
Andrey Fesenko wrote: System install for manual http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot only + freebsd-ufs (ada0p2) uname -a FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r229812: Mon Jan 9 19:08:10 MSK 2012 andrey@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 gpart show =34 625142381 ada0 GPT (298G) 34128 1 freebsd-boot (64k) 162 26621952 2 freebsd-ufs (12G) 266221148388608 3 freebsd-swap (4.0G) 35010722 590131693 4 freebsd-zfs (281G) boot code MBR (pmbr) and gptzfsboot loader In the old loader was F1,F2,F3 new no :( Is there a way to boot system freebsd-ufs (ada0p2) `gpart set -a bootonce -i 2 ada0` should do. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Recommended amount of swap
05.09.2011 22:48, Dan Nelson написав(ла): In the last episode (Sep 05), Sean Hamilton said: What is the state of the art for the recommended amount of swap in FreeBSD? Both normal systems with 512 MB - 8 GB of RAM, and large database systems with around 128 - 256 GB. I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used, and if it is used, you're just going to thrash your swap device. If you have 128GB of RAM and need to swap to disk, you desperately need more RAM, not swap :) My +1 to wishlist, I want OpenOffice to not trash memory when reading large xlsx files. Mem: 1937M Active, 243M Inact, 672M Wired, 98M Cache, 9412K Free Swap: 36G Total, 21G Used, 15G Free, 59% Inuse, 252K In PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1912 arcade5 451 23311M 1721M ucond 0 66:07 55.37% /usr/local/openoffice.org-3.3.0/openoffice.org3/program/so Different things happens. When I hardly need some swap I think about: 0. More RAM. 1. Spare flash or SSD. 2. Another disk. 3. Touching disk sizes. Also please note that system that uses at least 1G of swap actively (I don't mean tmp/mdfs or long running non active processes) is dripping slime and therefor is useless and should be upgraded. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
02.05.2010 10:25, Yuri wrote:
Having tried clang++ I have a feeling that it's not quite ready to be a
generic c++ compiler.
It crashes a lot, fails on many quite simple c++ patterns. Very immature.
Don't you feel it's too early to start project like you are going to
given the state of clang with c++?
This is just a question of time. Two month ago was the time after three
month ago. And clang proceeds rapidly.
You will just keep stumbling upon various problems with various ports
and maybe will make 30% of c++ ports build with it at best.
Let me spit out my own stats on ports. I have 574 ports installed, E17,
xfce, postgresql etc.
1. 23% of _my_ ports doesn't require any compiler. They are fonts,
script, meta-ports etc.
2. 60% of _my_ ports compiles and works with current devel/clang.
This means I have only something like 17% ports to deal with.
Above this ports major breakages were:
1. __dso not found after link. Some symbols seems to be omitted from
libraries and linking of plugins fails badly.
2. Assembler errors. Xorg has some in x11-servers/xorg-server
x11-drivers/xf86-video-vesa x11-drivers/xf86-video-ati, everything else
compiles and works.
3. Big bunch of compile errors or config errors. This means incorrectly
written code, like not correctly declaring variables. This also means
some automake stupidities like testing c++ compiler with c style code -
for example clang++ refuses to compile int main(void) {}.
4. Some ports specify that thay need at least gcc 3.3.
5. Some ports needs --dumpspecs.
And only small number of ports really require some real investigations.
audio/libmad - distorted sound
lang/python26 - compiling any gir dumps core
textproc/expat2 - dbus dumps core at launch
I think there are more. For example on clang-compiled ports gtk apps
have problems with rendering final frame, but this is not a gtk failure,
rather some lib gtk depends on.
And this all data is not current. It's one month old. Since then
dumpspecs was implemented. And maybe some other problems begone - I just
have not enough time to look at this thoroughly.
--
Sphinx of black quartz judge my vow.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unprivileged user can't set sticky bit on a file; why?
Nate Eldredge wrote: I came across this when trying to rsync some files which had the sticky bit set on the remote side. (It's the historical Unix archive from tuhs.org; the files in question are part of an unpacked V7 UNIX installation, for which the sticky bit of course had meaning. :-) ) It's annoying that this makes rsync fail; it messes up my mirroring script. You can ask rsync to change file attributes on the fly with the --chmod option. Just my 2c. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
llvm/clang early test
Hi all. Does anyone tried to build world with clang (devel/llvm-devel)? I just have tested clang on some code from our tree, gzip and bzip2 for example. Well... it works. Gzip compiled with clang become faster, bzip2 don't... Right now I'm playing with world making it compile with clang. If anyone doing the same thing we can share some thoughts and patches... -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
