Re: proper newfs options for SSD disk
El día Sunday, June 17, 2012 a las 09:16:12PM -0600, Warren Block escribió: > On Sat, 16 Jun 2012, Matthias Apitz wrote: > > > OK, but I wanted to have most of the space of the 4 GB SSD encrypted > > with geli(8); so I should make there some slice containing /boot > > (unencrypted) and a second slice which later will contain my HOME and > > encrypted; wrong? > > That's correct: http://forums.freebsd.org/showthread.php?t=29652 Thanks for the pointers and the comments from you and Wojciech; I'm attaching below what I have planned as the exactly procedure now and would thank in advance for any comments; one remaining question is, how could I attache the geli(8) crypted file system during boot (via rc.conf) but using a passphrase which should be asked and typed in on boot? is this somehow possible? Thanks matthias $Id:$ current disk layout of EeePC: Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s1a3.7G568M3.1G15%/ /dev/ada1s1a 14G8.7G5.8G60%/usr/local future disk layout. /dev/ada0p1freebsd-boot /dev/ada0p2freebsd-ufs /boot 256 Mbyte /dev/ada0p3freebsd-ufs /private 3.5 GByte (geli encrypted) /dev/ada1p1freebsd-boot /dev/ada1p2freebsd-ufs /14.0 GByte (/ /usr /var ... all in one file system and unencrypted) commands: # gpart destroy -F ada0 # gpart create -s gpt ada0 # gpart add -t freebsd-boot -s 512k ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 # gpart add -t freebsd-ufs -b 1m -s 256m ada0 # gpart add -t freebsd-ufs ada0 # gpart destroy -F ada1 # gpart create -s gpt ada1 # gpart add -t freebsd-boot -s 512k ada1 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada1 # gpart add -t freebsd-ufs -b 1m ada1 this allows as well at the beginning to boot the system from ada1 (must be done manually from BIOS); later we will copy over /boot from ada1p2 to ada0p2 (see below); create on ada0 the future /boot and /privae file systems and on ada1 the future / root file system; and mount the last as /mnt # newfs /dev/ada0p2 # newfs /dev/ada0p3 # newfs /dev/ada1p2 # mount /dev/ada1p2 /mnt start the mouse daemon (only for cut&paste: # /etc/rc.d/moused onestart install the system (user land and kernel) from /usr/src to /mnt: # cd /usr/src # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt create the future /etc/fstab to mount / as root fs: # echo /dev/ada1p2 / ufs rw 1 1 > /mnt/etc/fstab configure some basic services in future /etc/rc.conf: # cat < /mnt/etc/rc.conf tmpmfs="YES" tmpsize="128m" wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" ifconfig_bge0="DHCP" ifconfig_em0="DHCP" hostname=aurora.Sisis.de sshd_enable="YES" moused_enable="YES" keymap="german.iso" EOF create at least one unpriv user to be able to SSH into the new system later: # chroot /mnt /usr/sbin/adduser unmount the new / and reboot: # umount /mnt # reboot after reboot system should now come up from ada1 and we copy over the /boot to ada0p2 # mount /dev/ada0p2 /mnt # cp -Rp /boot /mnt # echo 'geom_eli_load="YES"' > /mnt/boot/loader.conf # echo 'vfs.root.mountfrom="ufs:ada1p2"'>> /mnt/boot/loader.conf # umount /mnt # reboot should now boot by itself from ada0 and mount the tootfs from ada1p2; later we will use /dev/ada0p3 for the geli(8) encrypted file system and we will mount this as /private; my $HOME should be /private/home -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: proper newfs options for SSD disk
future disk layout. /dev/ada0p1freebsd-boot /dev/ada0p2freebsd-ufs /boot 256 Mbyte /dev/ada0p3freebsd-ufs /private 3.5 GByte (geli encrypted) over 200 MB wasted for /boot. what do you want to but there? except this it is all right. /dev/ada1p1freebsd-boot /dev/ada1p2freebsd-ufs /14.0 GByte (/ /usr /var ... all in one file system and unencrypted) nonsense here. why partitions AT ALL? just /dev/ada1 - /, no partitions commands: # gpart destroy -F ada0 # gpart create -s gpt ada0 # gpart add -t freebsd-boot -s 512k ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 # gpart add -t freebsd-ufs -b 1m -s 256m ada0 # gpart add -t freebsd-ufs ada0 i cannot help here as i am not really gpart user. i use bsdlabel everywhere for now. # newfs /dev/ada0p2 # newfs /dev/ada0p3 don't waste space, read newfs manual and add good options. on flash disks don't fear to use smallest (4KB) block size and smallest (512) fragment size. on any disk don't overallocate inodes as newfs do. You know how many files you have so i can't help you. newfs -i 16384 means over 1% locked space, on hard disks i usually use -i 65536 and it still result in most inodes unused. on small flash disks 16384 or 32768 is usually fine but YOU know how much files you store. on private system do not fear -m 0, even more on flash media where fragmentation doesn't hurt. and you definitely forgot -U option. REALLY - read out newfs manual carefully and make optimal filesystem layout every time. newfs defaults are certainly non optimal, but universal and mostly safe. # newfs /dev/ada1p2 # mount /dev/ada1p2 /mnt start the mouse daemon (only for cut&paste: # /etc/rc.d/moused onestart # echo /dev/ada1p2 / ufs rw 1 1 > /mnt/etc/fstab rw,noatime always worth using, definitely on flash disks. the rest is quite complex for me. i would rather back up all your existing filesystem to something external, make new partitioning and restore. ___ 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)
On 06/19/2012 12:39 AM, Wojciech Puchar wrote: > - delay at rc.d scripts - there are some delays inserted. > >> The latter item is the only place where making changes to rc.d is going >> to help, and only then by parellelizing, and even then you are not >> really going to gain much since most things at boot time are serial. > > grep sleep /etc/rc.d/* usr/local/etc/rc.d/* > >> >> So while talk of how to get your favorite boot-time manager into FreeBSD >> may be entertaining, it's not likely to be productive, and almost > > it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. ___ 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)
On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao wrote: > On 06/19/2012 12:39 AM, Wojciech Puchar wrote: >> - delay at rc.d scripts - there are some delays inserted. >> >>> The latter item is the only place where making changes to rc.d is going >>> to help, and only then by parellelizing, and even then you are not >>> really going to gain much since most things at boot time are serial. >> >> grep sleep /etc/rc.d/* usr/local/etc/rc.d/* >> >>> >>> So while talk of how to get your favorite boot-time manager into FreeBSD >>> may be entertaining, it's not likely to be productive, and almost >> >> it is unimportant as FreeBSD don't crash. > > OpenRC init scripts lack such delays. They store dependency information, > which enables OpenRC to start them as soon as their dependencies are ready. Assuming that the hacks aren't working around other issues, like routes not already being available for a certain period of time, e.g. defaultroute, etc (which doesn't work 100% of the time, e.g. static gateways and mounting NFS shares). This is something that launchd, systemd, upstart, etc handle (because they either have more knowledge of the system or it's been coded into the files that execute the jobs/services), or alternatively the services need to fail more gracefully (this is more difficult -- but not impossible -- to code). Even OpenRC in gentoo doesn't handle this, unless things have changed dramatically since I used Gentoo ~2 years ago... Thanks! -Garrett ___ 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)
On Tue, 19 Jun 2012 01:04:47 -0400 Richard Yao wrote: > On 06/19/2012 12:39 AM, Wojciech Puchar wrote: > > - delay at rc.d scripts - there are some delays inserted. > > > >> The latter item is the only place where making changes to rc.d is > >> going to help, and only then by parellelizing, and even then you > >> are not really going to gain much since most things at boot time > >> are serial. > > > > grep sleep /etc/rc.d/* usr/local/etc/rc.d/* > > > >> > >> So while talk of how to get your favorite boot-time manager into > >> FreeBSD may be entertaining, it's not likely to be productive, and > >> almost > > > > it is unimportant as FreeBSD don't crash. > > OpenRC init scripts lack such delays. They store dependency > information, which enables OpenRC to start them as soon as their > dependencies are ready. That's not the reason for the sleeps. FreeBSD sorts the scripts into dependency order and runs them sequentially, so there's no reason to sleep waiting for a dependency script to complete. The sleeps exist for a variety of reasons. Just looking at the grep can be a bit misleading. Not all of the scripts are going to be used, the sleep is not always relevant to startup, in some case it's in a code path that's not typically taken. One thing that I think could be easily improved is that the polling delays could be changed from 1 second to 0.1 seconds. If there's a reason for rc scipts needing to be portable, there could be a polling delay function with a "fast polling" option in defaults/rc.conf. ___ 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: proper newfs options for SSD disk
On Tue, 19 Jun 2012, Matthias Apitz wrote: El día Sunday, June 17, 2012 a las 09:16:12PM -0600, Warren Block escribió: On Sat, 16 Jun 2012, Matthias Apitz wrote: OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? That's correct: http://forums.freebsd.org/showthread.php?t=29652 Thanks for the pointers and the comments from you and Wojciech; I'm attaching below what I have planned as the exactly procedure now and would thank in advance for any comments; one remaining question is, how could I attache the geli(8) crypted file system during boot (via rc.conf) but using a passphrase which should be asked and typed in on boot? is this somehow possible? When set up like that link, it does ask for the passphrase on startup.___ 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)
On 06/19/2012 07:20 AM, Garrett Cooper wrote: > On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao wrote: >> On 06/19/2012 12:39 AM, Wojciech Puchar wrote: >>> - delay at rc.d scripts - there are some delays inserted. >>> The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. >>> >>> grep sleep /etc/rc.d/* usr/local/etc/rc.d/* >>> So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost >>> >>> it is unimportant as FreeBSD don't crash. >> >> OpenRC init scripts lack such delays. They store dependency information, >> which enables OpenRC to start them as soon as their dependencies are ready. > > Assuming that the hacks aren't working around other issues, like > routes not already being available for a certain period of time, e.g. > defaultroute, etc (which doesn't work 100% of the time, e.g. static > gateways and mounting NFS shares). > This is something that launchd, systemd, upstart, etc handle > (because they either have more knowledge of the system or it's been > coded into the files that execute the jobs/services), or alternatively > the services need to fail more gracefully (this is more difficult -- > but not impossible -- to code). Even OpenRC in gentoo doesn't handle > this, unless things have changed dramatically since I used Gentoo ~2 > years ago... > Thanks! > -Garrett It works for me. I suggest you try Gentoo FreeBSD in a jail: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail ___ 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: how to turn my computer into a TV
On Mon, Jun 18, 2012 at 11:56 PM, Wojciech Puchar wrote: >> >> An old Pentium 4 3ghz can decode HD with plenty of cpu resources to >> spare so unless a person using something older than that, they've >> certainly got "modern" cpu power. > > actually even intel atom D525 is OK if decoder can be multithreaded. I have a few Atom systems but they all use vdpau for decoding and I never bothered to see how just the Atom holds up on it's own for decoding. :) ___ 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)
On 6/18/2012 9:39 PM, Wojciech Puchar wrote: >> The latter item is the only place where making changes to rc.d is going >> to help, and only then by parellelizing, and even then you are not >> really going to gain much since most things at boot time are serial. > > grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. In the ports' scripts we tend to be more forgiving, but I've worked with several maintainers to apply more effective solutions where there is a good reason to wait for a dependent service to actually be running. This also brings up a good point, any new rc-alike solution we consider must have support for scripts in ports that is at least as robust as what we have now. Doug -- This .signature sanitized for your protection ___ 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)
On 6/18/2012 4:05 PM, Richard Yao wrote: > Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD > in a jail, install regular FreeBSD in another jail and do your own > performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Doug -- This .signature sanitized for your protection ___ 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: how to turn my computer into a TV
I have a few Atom systems but they all use vdpau for decoding and I never bothered to see how just the Atom holds up on it's own for decoding. :) didn't have 1920x1080 video but 1366x768 MPEG4 plays smooth ___ 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)
grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. ___ 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)
On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar wrote: >>> grep sleep /etc/rc.d/* usr/local/etc/rc.d/* >> >> Sleeps in /etc tend to be there for good reasons, and new ones are >> vigorously scrutinized. If you see any that you think are dubious, feel >> free to mention them on freebsd-rc@. > > I don't say they are not needed but that they exist. > anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. Thanks, -Garrett ___ 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)
sorry i was wrong /etc/rc.d/defaultroute use sleep to wait for dhclient only. On Tue, 19 Jun 2012, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. Thanks, -Garrett ___ 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)
On 06/19/2012 12:50 PM, Doug Barton wrote: > On 6/18/2012 4:05 PM, Richard Yao wrote: >> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD >> in a jail, install regular FreeBSD in another jail and do your own >> performance comparisons. > > Bt! Thanks for playing. :) You're the one proposing the change, > YOU get to do the performance comparisons. If you want a rough idea of > what I personally would consider to be a robust test, don't hesitate to > ask. I'm sure others would have ideas as well. > > Doug > Would you elaborate on what you consider to be a robust test? I really have no idea. ___ 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)
On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote: > On 06/19/2012 12:50 PM, Doug Barton wrote: >> On 6/18/2012 4:05 PM, Richard Yao wrote: >>> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD >>> in a jail, install regular FreeBSD in another jail and do your own >>> performance comparisons. >> >> Bt! Thanks for playing. :) You're the one proposing the change, >> YOU get to do the performance comparisons. If you want a rough idea of >> what I personally would consider to be a robust test, don't hesitate to >> ask. I'm sure others would have ideas as well. > > Would you elaborate on what you consider to be a robust test? I really > have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Thanks, -Garrett ___ 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)
On 06/19/2012 04:12 PM, Garrett Cooper wrote: > On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote: >> On 06/19/2012 12:50 PM, Doug Barton wrote: >>> On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. >>> >>> Bt! Thanks for playing. :) You're the one proposing the change, >>> YOU get to do the performance comparisons. If you want a rough idea of >>> what I personally would consider to be a robust test, don't hesitate to >>> ask. I'm sure others would have ideas as well. >> >> Would you elaborate on what you consider to be a robust test? I really >> have no idea. > > It might be an ok smoke test, but it's hardly a realistic > test/comparison as the pseudo startup for a jail and a real system > aren't close to being the same (this is in part because of how jails > function). > Thanks, > -Garrett Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. ___ 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)
On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote: > On 06/19/2012 04:12 PM, Garrett Cooper wrote: >> On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote: >>> On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: > Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD > in a jail, install regular FreeBSD in another jail and do your own > performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. >>> >>> Would you elaborate on what you consider to be a robust test? I really >>> have no idea. >> >> It might be an ok smoke test, but it's hardly a realistic >> test/comparison as the pseudo startup for a jail and a real system >> aren't close to being the same (this is in part because of how jails >> function). > > Would you elaborate on what you consider to be acceptable? Honestly, I > am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett ___ 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)
On 06/19/2012 06:17 PM, Garrett Cooper wrote: > On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote: >> On 06/19/2012 04:12 PM, Garrett Cooper wrote: >>> On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: > On 6/18/2012 4:05 PM, Richard Yao wrote: >> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD >> in a jail, install regular FreeBSD in another jail and do your own >> performance comparisons. > > Bt! Thanks for playing. :) You're the one proposing the change, > YOU get to do the performance comparisons. If you want a rough idea of > what I personally would consider to be a robust test, don't hesitate to > ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. >>> >>> It might be an ok smoke test, but it's hardly a realistic >>> test/comparison as the pseudo startup for a jail and a real system >>> aren't close to being the same (this is in part because of how jails >>> function). >> >> Would you elaborate on what you consider to be acceptable? Honestly, I >> am not certain if you will appreciate any tests unless you do them yourself. > > Change /etc/rc to use OpenRC in the base system. > -Garrett That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. People can use Gentoo FreeBSD in jails (or on physical hardware) to do comparisons. If they like it, Gentoo's developers are willing to help, but you cannot expect us to do your work for you. That would be like asking the Clang developers to replace your system compiler or the Illumos developers to replace your file system. FreeBSD's developers need to be the ones to import OpenRC into FreeBSD's base system, not us. We will just fix problems you encounter and collaborate on improvements. That is what every other upstream does. ___ 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)
On Tue, Jun 19, 2012 at 3:45 PM, Richard Yao wrote: > On 06/19/2012 06:17 PM, Garrett Cooper wrote: >> On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote: >>> On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote: > On 06/19/2012 12:50 PM, Doug Barton wrote: >> On 6/18/2012 4:05 PM, Richard Yao wrote: >>> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD >>> in a jail, install regular FreeBSD in another jail and do your own >>> performance comparisons. >> >> Bt! Thanks for playing. :) You're the one proposing the change, >> YOU get to do the performance comparisons. If you want a rough idea of >> what I personally would consider to be a robust test, don't hesitate to >> ask. I'm sure others would have ideas as well. > > Would you elaborate on what you consider to be a robust test? I really > have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). >>> >>> Would you elaborate on what you consider to be acceptable? Honestly, I >>> am not certain if you will appreciate any tests unless you do them yourself. >> >> Change /etc/rc to use OpenRC in the base system. >> -Garrett > > That is already done in Gentoo FreeBSD, or do you want me to do the work > for you to integrate OpenRC in the base system? > > I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate > OpenRC into FreeBSD would be an inefficient use of my time. Not only > would I fail to gain any improvements on my systems, but I would divert > development time from things that do benefit me. > > People can use Gentoo FreeBSD in jails (or on physical hardware) to do > comparisons. If they like it, Gentoo's developers are willing to help, > but you cannot expect us to do your work for you. That would be like > asking the Clang developers to replace your system compiler or the > Illumos developers to replace your file system. > > FreeBSD's developers need to be the ones to import OpenRC into FreeBSD's > base system, not us. We will just fix problems you encounter and > collaborate on improvements. That is what every other upstream does. No. I'm saying that this is what would need to be done to qualify it and it would need to be run with the base system and a series of rc scripts in ports. In order for things to ultimately be committed, things would need to be regression tested enough that FreeBSD developers would be confident with the end-result. And yes, there would need to be a conversion plan, documentation update, and the full nine yards for whatever's done with an rc replacement, as this would impact a lot of folks and projects. Thanks, -Garrett ___ 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)
On Tue, 19 Jun 2012 11:03:31 -0700 Garrett Cooper wrote: > On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar > wrote: > >>> grep sleep /etc/rc.d/* usr/local/etc/rc.d/* > >> > >> Sleeps in /etc tend to be there for good reasons, and new ones are > >> vigorously scrutinized. If you see any that you think are dubious, > >> feel free to mention them on freebsd-rc@. > > > > I don't say they are not needed but that they exist. > > anyway i don't understand sleep 1 after setting default route. > > Probably working around annoying races in the driver / network / > routing stack. Please see my previous reply. There are a few sleeps where some action is performed and and then a fixed sleep is done, but this is one of the ones where the sleep is in a while loop - a full second seems a bit long. ___ 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: cleaning /usr/obj before copying it to USB key
On 6/11/12 8:34 AM, Matthias Apitz wrote: Thanks for the hints concerning find(1) usage. I was wondering if there is nothing like # make install-clean or # make remove-tempfiles Thanks matthias I missed the beginning of this thread, but if you're talking about doing a 'make buildworld' and 'make installworld', then note that there is also a target for /usr/src called 'make cleanworld'. This will clean up the files from 'make buildworld', but would not clean up files in /usr/obj which were created by other things (such as ports, for instance). The subject says "before copying to USB key". Another thing you could do is build up an 'rsync' command with the appropriate set of options such that /usr/obj is not copied to your USB key. I don't know if that option makes sense for what you are trying to do. Another thing you could do is to set the environment variable MAKEOBJDIRPREFIX before you do buildworld and installworld, so that those are not using /usr/obj at all. This is a little trickier to do right, and you'll regret it if you do not set the variable in all the situations that you want to. But it might be another option for you. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: cleaning /usr/obj before copying it to USB key
El día Tuesday, June 19, 2012 a las 07:43:46PM -0400, Garance A Drosehn escribió: > On 6/11/12 8:34 AM, Matthias Apitz wrote: > > Thanks for the hints concerning find(1) usage. I was wondering if there > > is nothing like > > > > # make install-clean > > or > > # make remove-tempfiles > > > > Thanks > > > > matthias > > > I missed the beginning of this thread, but if you're talking about doing yes :-) > a 'make buildworld' and 'make installworld', then note that there is also > a target for /usr/src called 'make cleanworld'. This will clean up the > files from 'make buildworld', but would not clean up files in /usr/obj > which were created by other things (such as ports, for instance). I was looking for a way to remove all temp. files in /usr/obj, but after this it must still be possible to do 'make installworld' and 'make installkernel'; just to reduce the amount of files to copy over to the USB key; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ 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"
MAGIC with HP KVM - someone will help?
i am not sure if it is related at all to FreeBSD, but maybe someone here know the solution. Anyway it is somewhat FreeBSD related for sure as you will see from description. I bought used IP 16 port KVM connected to few servers, in between them FreeBSD 8 server running on Dell PowerEdge T110. As this KVM have PS/2 connectors to keyboard and mouse i added USB to dual-PS/2 converter. So: 1)when KVM is used locally with plugged monitor, keyboard and mouse everything is fine. 2)when it is used remotely before FreeBSD is booted or after successful multiuser boot everything is fine. 3)when kernel boots and waits for GELI password, and i SLOOOWLY type it (at most one keypress per second) over remote KVM connection - everything is fine. 4)when i type the password faster keyboard locks. you have to turn off server and on again to recover. Please don't laught from 3 and 4 as it is true, tested several times. The problem happens ONLY at FreeBSD but before mounting root, when geli ask for password. And it is serious as ability to enter geli password is the main reason for this KVM to be installed! And really not forgetting to type password very slowly isn't easy. Any idea what it is and how to fix it. It really looks like magic. ___ 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"
