Re: how do people play with different versions of DBSD on the same system?
On Sat, 24 Sep 2005 06:30:49 -0400, Erik Wikström [EMAIL PROTECTED] wrote: When superVFS is in place, would we be able to have a /release, /preview, /development, and mount them over / at boot-time? Would it not be easier to install one instance of each and use the same /home for all of them, that would probably work even for multiple BSDs. My impression is (correct me if I'm wrong) that the main differences between DEVELOPMENT, PREVIEW, and RELEASE are in the kernel, libraries, and toolchain, in that order. Userland changes are pretty minor. Having to download, build, rebuild, configure, reconfigure the other 95% is a pain. -- Bob Bagwill
Dfly 1.2 + Qemu don't cooperate
Hi, I'm trying to install dfly via qemu in Arch Linux. I'm using the latest stable (1.2) of dfly. Unfortunately, during the install, I get an error about connecting to port (pid 608) when trying to enter the bsd installer (ncurses) and I'm thrown back into console. Has anyone installed dfly on qemu and if so what's the procedure that I'd have to go through? Which release of dfly should I use? Latest CVS Snapshot? Qemu works fine for other things like NetBSD and I'll be trying FreeBSD 5.4 soon, but I'd like to get past this hurdle with the dfly install. Are there special parameters you have to run with qemu as you boot from the cdrom (image)? Thanks a lot. Help is appreciated. Vivek
nvidia driver error
help!! did a make install in the dfports and got the following. nv-kernel.o nvidia_ctl.o nvidia_dev.o nvidia_linux.o nvidia_os.o nvidia_os_pci.o nvidia_os_registry.o nvidia_pci.o nvidia_subr.o nvidia_sysctl.o ld -Bshareable -o nvidia.ko nvidia.kld install -o root -g wheel -m 555 nvidia.ko /modules === lib === lib/libGL === lib/libnvidia-tls === lib/libGLcore === lib/libXvMCNVIDIA === lib/compat === lib/compat/libGL *** Error code 71 Stop in /usr/dfports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113/lib/compat/libGL. *** Error code 1 Stop in /usr/dfports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113/lib/compat. *** Error code 1 Stop in /usr/dfports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113/lib. *** Error code 1 Stop in /usr/dfports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113. *** Error code 1 Stop in /usr/dfports/x11/nvidia-driver.
Re: how do people play with different versions of DBSD on the same system?
Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? Do you install them on separate disks? Separate slices? Separate partitions? If you want to avoid having separate /etc's, /var's, and /home's, what's the most elegant way to do it? The most 'elegant' way is to NOT AVOID having separate ones They need to be allowed to differ! - partition and slice your media into many (preferably equal sized) portions. - install an appropriate boot manager. - install each new entire system into a single slice, with the whole fs on the same slice, directly under '/' - IOW, label only one swap, same one each time - and one '/' mountpoint, different one each time. - On each install, do not touch any of the other slices, and do not let /etc/fstab mount them, either. - use the BM to change 'personality' - manually mount/umount the 'foreign' slices only if/as/when you need to move data between and among them - including 'cloning' an entire slice to another. Far safer than sharing /home, /usr, /var /etc /whatever and trying to remember what matches whatever A separate partition or HDD can be mounted as a common storage / applications area, but should not have any OS-related files or needed resources on it. HTH, Bill Hacker
Re: how do people play with different versions of DBSD on the same system?
Bob Bagwill wrote: On Sat, 24 Sep 2005 06:30:49 -0400, Erik Wikström [EMAIL PROTECTED] wrote: When superVFS is in place, would we be able to have a /release, /preview, /development, and mount them over / at boot-time? Would it not be easier to install one instance of each and use the same /home for all of them, that would probably work even for multiple BSDs. Sometimes. But mail services, to name one, often use /home, and never for 100% of what they read and write. Best if each OS install is fully self-contained, shares only 'non-OS sensitive' app/data storage. True of CP/M 1.X 2X, MPM, CCP/M, DOS, OS/2, and so on as well.. ;-) Give 'em their own toybox. My impression is (correct me if I'm wrong) that the main differences between DEVELOPMENT, PREVIEW, and RELEASE are in the kernel, libraries, and toolchain, in that order. Userland changes are pretty minor. Having to download, build, rebuild, configure, reconfigure the other 95% is a pain. Perhaps so, but a highly 'automated' pain. Start the cvsup and make scripts, go relax. The alternative is too often trying to locate what unexpectedly changed off in some seldom-visited corner... and will change again, differently, next cycle. Any 'modern' OS is too big to keep the whole thing in view, and space is cheap. YMMV, Bill Hacker
Re: how do people play with different versions of DBSD on the same system?
Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? I just use VMWare. Currently I have 1.2.x-RELEASE and 1.3.x-PREVIEW installed in VMWare, although I only have PREVIEW fired up at the moment. It's not the best way to run DragonFlyBSD, but since I don't have enough machines lying around to install on then I have to deal with what I have.
Re: how do people play with different versions of DBSD on the same system?
Bill Hacker wrote: How are people playing with different versions of DBSD on the same system? Do you install them on separate disks? Separate slices? Separate partitions? If you want to avoid having separate /etc's, /var's, and /home's, what's the most elegant way to do it? The most 'elegant' way is to NOT AVOID having separate ones They need to be allowed to differ! [classical way of doing it] Or just use vmware *EG*
Re: how do people play with different versions of DBSD on the same system?
On Mon, 26 Sep 2005 13:25:40 -0700 walt [EMAIL PROTECTED] wrote: Bill Hacker wrote: Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? [...] - partition and slice your media into many (preferably equal sized) portions... I like to point out at every opportunity that DragonFlyBSD is the *only* BSD which can load the kernel from an extended DOS partition, e.g. /dev/ad0s5a. (This is because of our local modifications to /boot/loader which (so far) have eluded the other BSD's.) I have NetBSD installed on an extended partition, so I kind of doubt your claim :P I don't know if the DFly installer will permit installation to an extended partition/slice, however, because I haven't tried it. It doesn't. -Chris
Re: Dfly 1.2 + Qemu don't cooperate
Vivek Ayer wrote: Hi, I'm trying to install dfly via qemu in Arch Linux. I'm using the latest stable (1.2) of dfly. Unfortunately, during the install, I get an error about connecting to port (pid 608) when trying to enter the bsd installer (ncurses) and I'm thrown back into console. Has anyone installed dfly on qemu and if so what's the procedure that I'd have to go through? Which release of dfly should I use? Latest CVS Snapshot? Qemu works fine for other things like NetBSD and I'll be trying FreeBSD 5.4 soon, but I'd like to get past this hurdle with the dfly install. Are there special parameters you have to run with qemu as you boot from the cdrom (image)? Thanks a lot. Help is appreciated. I have had this happen as well. Generally if the loopback adaptor is not initialized correctly this could happen. Another thing for you to try is to bring up a network interface before running the installer. IE: login as root and setup a interface with an ip then logout and log back in with installer. Scott
Re: how do people play with different versions of DBSD on the same system?
Chris Pressey wrote: On Mon, 26 Sep 2005 13:25:40 -0700 walt [EMAIL PROTECTED] wrote: Bill Hacker wrote: Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? [...] - partition and slice your media into many (preferably equal sized) portions... I like to point out at every opportunity that DragonFlyBSD is the *only* BSD which can load the kernel from an extended DOS partition, e.g. /dev/ad0s5a. (This is because of our local modifications to /boot/loader which (so far) have eluded the other BSD's.) I have NetBSD installed on an extended partition, so I kind of doubt your claim :P Wow, that's Big News :o) How did you accomplish it? Has NetBSD imported our loader patches? (OpenBSD has been telling everyone (for many years) to 'f*-off-and- submit-patches' if their bootloader sucks -- which it does, IMHO.)
