Re: munin related
On Mon, 7 Oct 2013 19:57+0200, Laszlo Danielisz wrote: Yep killing nscd help me to get out of this trouble. I have long suspected nscd to reinitialise the timers whenever an entry is requested while still held in the cache, be it a positive or a negative result. As such the only reasonable solution is to never cache negative results (TTL=0) and keep the positive TTL relatively short, say no more than 60 minutes. Can someone more knowledgeable on nscd internals confirm my suspicion? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ 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: failed to create gmirror with the handbook instructions
Thanks very much. Please could I make a suggestion that this be included in the handbook page? On 8 Oct 2013 01:31, Warren Block wbl...@wonkity.com wrote: On Tue, 8 Oct 2013, Andy Zammy wrote: Hi, I used the second section of the handbook (20.4) to create a gmirror. In my particular setup I had a 1GB /, 6GB swap, 1GB /tmp and the rest of the 1TB drive was left for /usr I had to deviate from the handbook when it came to running the dump + restore commands, as the dump failed due to an issue with the journalling. To get around this problem, I dropped into single user mode, so I could remount root as read-only. The dump commands then worked. It specified in the handbook to restart the machine, and boot from ada1. It was at this point that I noticed something wasn't quite right. There was a spew of 'not found/no such file or directory' messages. These were all trying to reference libs and binaries that live in /usr. I boot into single user mode, and upon checking the other partitions, I notice that /tmp and /usr are empty, apart from a .snap file, and the restoresymtable file. Please could someone help me troubleshoot this problem? Let me know if you need any more info, and I'll post it up asap. dump does not work reliably on filesystems with SUJ enabled. Turn off SUJ on the filesystems to be dumped by booting in single-user mode and running tunefs -j disable /dev/ada0whatever Do each filesystem, then use dump. ___ 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
mpt problem on a Supermicro motherboard (FreeBSD 9.2 amd64)
Colleagues, I have several Supermicro-based servers with the mpt RAID adapter: # mptutil show adapter mpt0 Adapter: Board Name: UNUSED Board Assembly: Chip Name: C1068E Chip Revision: UNUSED RAID Levels: none # The problem is, I cannot configure any RAIDs (please see output below) from FreeBSD. If I configure volumes from BIOS setup, FreeBSD still sees them as separate physical discs. What am I doing wrong? I cannot use gmirror with these servers because a) if no MPT RAID is configured in BIOS setup, it cannot boot from HDD and b) if an MPT RAID *is* configured in BIOS setup, it occupies the last sector and prevents GEOM from working with these drives. Any help please? (or redirect me to a more appropriate maillist). # mptutil clear Are you sure you wish to clear the configuration on mpt0? [y/N] y mpt0: Configuration cleared # mptutil show volumes mpt0 Volumes: Id SizeLevel Stripe State Write-Cache Name # mptutil show drives mpt0 Physical Drives: da0 ( 558G) ONLINE HITACHI HUS156060VLS600 A760 SCSI-6 bus 0 id 0 da1 ( 558G) ONLINE HITACHI HUS156060VLS600 A760 SCSI-6 bus 0 id 1 da2 ( 558G) ONLINE HITACHI HUS156060VLS600 A760 SCSI-6 bus 0 id 2 da3 ( 558G) ONLINE HITACHI HUS156060VLS600 A760 SCSI-6 bus 0 id 3 # # mptutil create raid1 -v da2,da3 mptutil: Reading config page header failed: Invalid configuration page Added drive da2 with PhysDiskNum 0 mptutil: Reading config page header failed: Invalid configuration page # # mptutil show volumes mpt0 Volumes: Id SizeLevel Stripe State Write-Cache Name # -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: 9.1 - 9.2 upgrade
On 5 October 2013, at 05:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 21:49:18 -0700, Doug Hardie wrote: On 4 October 2013, at 20:03, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: On 4 October 2013, at 19:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 Have you verified in /etc/freebsd-update.conf that src is definitely part of what should be updated? System is not bootable - can't verify anything… Does the system (or better, its enclosure, software-wise) allow booting a rescue system or an emergency media, such as a FreeBSD v9 live system? Yes - but there is no one there who can successfully be told how to run it. Not even inserting a USB stick (with the FreeBSD memstick data) or a CD? We have serious communications issues - they want to use back slashes and have no idea what a slash is. Maybe that is the result of many years of administration on Windows PCs. :-) Even if you tell them which key to use, they know better and use a back slash cause thats what Windoze uses. Uh... knowing better would disqualify them as maintainers of a server installation. The inability to learn (or even to read and follow instructions) is a dangerous thing. The disk should be in the mail to me now. I will be able to work with it when it arrives. Okay, that's also a possible alternative. To be honest, that's the first time I hear about this procedure. But doable. The file /etc/freebsd-update.conf should contain the line Components src world kernel if you want to make sure the source is properly updated, along with the world and kernel (GENERIC). As indicated before, I don't think all the source got updated. The kernel showed 9.2 after recompilation. However UPDATING was not updated. Thats as much as I could check before. I assume that this could be possible by inconsistently updated sources. It would be a good start to remove /usr/src and download the sources of the correct version via SVN _or_ freebsd-update again. Before the next installation attempt, /usr/obj should be removed as well, just to be sure. Step 5: reboot Attention: Into single-user mode. Not possible since the system is located over 100 miles away. Everything has to be done via remote console. Does this mean SSH only or do you have a _real_ console transmission by which you can access the system _prior_ to the OS providing the SSH access? I'm mentioning this because the traditional approach requires (few) steps done in the single-user mode where no SSH connectivity is provided in the normal way… I have a telnet box that has serial connections to the console ports. That approach has been used without any issues since FreeBSD 2.5. I do disable all ports during the process via an reduced rc.conf file. A serial console should also work, but even though I've been using serial consoles (and _real_ serial terminals), one thing I'm not sure about: Is it possible to interrupt (!) the boot process at an early stage to get to the loader prompt and boot into single user mode from there? Ok boot -s If not, do you have the beastie menu (or whatever it is called today) enabled to go to SUM to perform the make installworld step? Anyway, if you can install everything is required with the disk at home, and then send it back to that datacenter (according to your characterization, the quotes are deserved), that should solve the problems and make sure everything works as intended. The Thick Plottens… I received the drives and installed them on a working system. The failed system is structured with a single partition for the system and another for swap. For some unknown reason, the BIOS got left configured to boot the extra disk if its powered up. That turns out to be handy. I can boot a working system with the corrupt drive powered off. Booting from the corrupt drive yields the normal hardware info followed by the Beastie image and immediately by a multitude of lines (repeated many times): Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 639kB/1037824kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: I was able to capture these by using a serial console connected to another computer. The lines only appear on the serial console once. They scroll by on the real console many time - all too fast to read anything. Then after a few seconds of that, the screen goes black, and the system reboots. The cycle then repeats… Pressing any key does nothing. I even filled the keyboard buffer with spaces
Re: NAT: Handbook vs mailing list
Olivier Nicole wrote: [snip] The mailing list message linked above suggests that the handbook information is the old way and that the correct way is to set ipfw_enable and natd_enable in rc.conf. Then /etc/rc.d/ipfw will load ipfw.ko, and if natd_enable is set, will invoke /etc/rc.d/natd, which loads ipdivert.ko at the right time. From what you copied/explained, natd_enable will load ipdivert.ko and the handbook suggests that you load ipdivert.ko, so either way the module will be loaded. I'd go with the ipfw_enable and natd_enable as it may also do other needed things than just loading a kernel module. +1 on this. It is also present in the /etc/defaults/rc.conf this way as well (of course, use /etc/rc.conf for override customization). The original situation referred to early in the mailing-list content was a timing related problem where the ipdivert module would fail, even after ipfw loading _did_ succeed. Most of the 'old way' is a holdover from before the init system brought in the rc.subr startup scripts (imported from netbsd if memory serves). There have been a couple of hiccups along the way concerning the order things are started. For example, it doesn't really work to start a dhcp client prior to successful network initiate completion. Over time the rc.subr system has evolved and been cleaned up. A long time ago I eschewed running mergemaster when doing source-based upgrades. Just didn't like it and it never seemed like not doing it hurt anything. For quite some time I never experienced any problem with this approach. However, this eventually did bite me in the rump in a very bad way! :-) When running mergemaster while upgrading to a new release you may see these scripts being updated. So they are continuing to evolve, and a lot of this is to start up and configure things as the system comes up in a 'correct' and coherent order. So imho the Handbook is a wee bit outdated. -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
install packages with pkg_add(1) into another file system
Hello, I have prepared a boot-able USB-key (to be exactly a disk image of it) the usual way: # dd if=/dev/zero of=da0 bs=8m count=1868 # mdconfig -a -t vnode -f da0 md0 # fdisk -I md0 # fdisk -B md0 # bsdlabel -w md0s1 auto # bsdlabel -B md0s1 # bsdlabel -e md0s1 # edit the disk label and change partition a from unused to 4.2BSD # newfs /dev/md0s1a # mount /dev/md0s1a /mnt # cd /usr/src now we can install world an kernel: # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt ... I have compiled ~800 ports (Xorg and KDE4) and after this I've created packages of all the installed ports with pkg_create(1); the resulting .tgz files are all as well copied to the image into /mnt/PKGDIR. So far so good. Now I want install the packages as well into the image in /mnt. What would be the best method for this? Run pkg_add with the flag --chroot chrootdir, or use chroot(8) directly? Or any other idea? Thanks in advance All this is with 10-CURRENT (base and ports). matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: munin related
Not a bad idea. From: Mark Felder f...@freebsd.org To: freebsd-questions@freebsd.org Sent: Monday, October 7, 2013 8:35 PM Subject: Re: munin related On Mon, Oct 7, 2013, at 12:57, Laszlo Danielisz wrote: Dear Dan, Yep killing nscd help me to get out of this trouble. Thank you very much! Some day it might be feasible to tie a hook into pkg that clears the uid/gid cache in nscd when trying to install packages so this isn't a problem. ___ 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-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: munin related
On Tue, Oct 8, 2013, at 1:15, Trond Endrestøl wrote: On Mon, 7 Oct 2013 19:57+0200, Laszlo Danielisz wrote: Yep killing nscd help me to get out of this trouble. I have long suspected nscd to reinitialise the timers whenever an entry is requested while still held in the cache, be it a positive or a negative result. As such the only reasonable solution is to never cache negative results (TTL=0) and keep the positive TTL relatively short, say no more than 60 minutes. Can someone more knowledgeable on nscd internals confirm my suspicion? I'm not that guy, but I do remember watching this closely on the mailing lists a while back. I can't deploy nscd because of negative cache issues and I don't think this patch in this thread was ever committed. I haven't had time to investigate, though. http://freebsd.1045724.n5.nabble.com/PATCH-Fix-for-negative-cacheing-problem-in-NSCD-td5722843.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: install packages with pkg_add(1) into another file system
On Tue, Oct 8, 2013, at 6:16, Matthias Apitz wrote: So far so good. Now I want install the packages as well into the image in /mnt. What would be the best method for this? Run pkg_add with the flag --chroot chrootdir, or use chroot(8) directly? Or any other idea? Thanks in advance All this is with 10-CURRENT (base and ports). pkg_add and all of the old pkgtools do not exist in 10-CURRENT anymore. Are you running a build of 10-CURRENT before they were removed? ___ 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: install packages with pkg_add(1) into another file system
El día Tuesday, October 08, 2013 a las 07:58:06AM -0500, Mark Felder escribió: On Tue, Oct 8, 2013, at 6:16, Matthias Apitz wrote: So far so good. Now I want install the packages as well into the image in /mnt. What would be the best method for this? Run pkg_add with the flag --chroot chrootdir, or use chroot(8) directly? Or any other idea? Thanks in advance All this is with 10-CURRENT (base and ports). pkg_add and all of the old pkgtools do not exist in 10-CURRENT anymore. Are you running a build of 10-CURRENT before they were removed? No. The r255948 was built on a clean, empty environment but with $ cat /etc/src.conf WITH_PKGTOOLS=yes matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: install packages with pkg_add(1) into another file system
On Tue, Oct 8, 2013, at 8:07, Matthias Apitz wrote: El día Tuesday, October 08, 2013 a las 07:58:06AM -0500, Mark Felder escribió: On Tue, Oct 8, 2013, at 6:16, Matthias Apitz wrote: So far so good. Now I want install the packages as well into the image in /mnt. What would be the best method for this? Run pkg_add with the flag --chroot chrootdir, or use chroot(8) directly? Or any other idea? Thanks in advance All this is with 10-CURRENT (base and ports). pkg_add and all of the old pkgtools do not exist in 10-CURRENT anymore. Are you running a build of 10-CURRENT before they were removed? No. The r255948 was built on a clean, empty environment but with $ cat /etc/src.conf WITH_PKGTOOLS=yes Ok, I won't question your needs for pkg_* as you seem to be aware of what you're doing :-) When you use pkg_* or pkg with their built-in chroot options it seems that it executes those tools within those chroots instead of setting the chroot as a destination for the installation. So if you wanted to use --chroot I think you have to make sure the packages are available inside the chroot. Perhaps there's some sort of DESTDIR option for the package installation? I've been searching but have had no luck yet. I'll ask around. It might be more reliable to do something like nullfs mount the packages into the chroot and do the installation completely within the chroot. ___ 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: 9.1 - 9.2 upgrade
On 10/08/2013 4:27 am, Doug Hardie wrote: On 5 October 2013, at 05:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 21:49:18 -0700, Doug Hardie wrote: On 4 October 2013, at 20:03, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: On 4 October 2013, at 19:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 Have you verified in /etc/freebsd-update.conf that src is definitely part of what should be updated? System is not bootable - can't verify anything… Does the system (or better, its enclosure, software-wise) allow booting a rescue system or an emergency media, such as a FreeBSD v9 live system? Yes - but there is no one there who can successfully be told how to run it. Not even inserting a USB stick (with the FreeBSD memstick data) or a CD? We have serious communications issues - they want to use back slashes and have no idea what a slash is. Maybe that is the result of many years of administration on Windows PCs. :-) Even if you tell them which key to use, they know better and use a back slash cause thats what Windoze uses. Uh... knowing better would disqualify them as maintainers of a server installation. The inability to learn (or even to read and follow instructions) is a dangerous thing. The disk should be in the mail to me now. I will be able to work with it when it arrives. Okay, that's also a possible alternative. To be honest, that's the first time I hear about this procedure. But doable. The file /etc/freebsd-update.conf should contain the line Components src world kernel if you want to make sure the source is properly updated, along with the world and kernel (GENERIC). As indicated before, I don't think all the source got updated. The kernel showed 9.2 after recompilation. However UPDATING was not updated. Thats as much as I could check before. I assume that this could be possible by inconsistently updated sources. It would be a good start to remove /usr/src and download the sources of the correct version via SVN _or_ freebsd-update again. Before the next installation attempt, /usr/obj should be removed as well, just to be sure. Step 5: reboot Attention: Into single-user mode. Not possible since the system is located over 100 miles away. Everything has to be done via remote console. Does this mean SSH only or do you have a _real_ console transmission by which you can access the system _prior_ to the OS providing the SSH access? I'm mentioning this because the traditional approach requires (few) steps done in the single-user mode where no SSH connectivity is provided in the normal way… I have a telnet box that has serial connections to the console ports. That approach has been used without any issues since FreeBSD 2.5. I do disable all ports during the process via an reduced rc.conf file. A serial console should also work, but even though I've been using serial consoles (and _real_ serial terminals), one thing I'm not sure about: Is it possible to interrupt (!) the boot process at an early stage to get to the loader prompt and boot into single user mode from there? Ok boot -s If not, do you have the beastie menu (or whatever it is called today) enabled to go to SUM to perform the make installworld step? Anyway, if you can install everything is required with the disk at home, and then send it back to that datacenter (according to your characterization, the quotes are deserved), that should solve the problems and make sure everything works as intended. The Thick Plottens… I received the drives and installed them on a working system. The failed system is structured with a single partition for the system and another for swap. For some unknown reason, the BIOS got left configured to boot the extra disk if its powered up. That turns out to be handy. I can boot a working system with the corrupt drive powered off. Booting from the corrupt drive yields the normal hardware info followed by the Beastie image and immediately by a multitude of lines (repeated many times): Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 639kB/1037824kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: I was able to capture these by using a serial console connected to another computer. The lines only appear on the serial console once. They scroll by on the real console many time - all too fast to read anything. Then after a few seconds of that, the screen goes black, and the system reboots. The cycle then repeats… Pressing any key does nothing. I even filled the keyboard buffer with spaces hoping to stop boot, but nothing seems to stop
Re: install packages with pkg_add(1) into another file system
El día Tuesday, October 08, 2013 a las 08:12:31AM -0500, Mark Felder escribió: No. The r255948 was built on a clean, empty environment but with $ cat /etc/src.conf WITH_PKGTOOLS=yes Ok, I won't question your needs for pkg_* as you seem to be aware of what you're doing :-) When you use pkg_* or pkg with their built-in chroot options it seems that it executes those tools within those chroots instead of setting the chroot as a destination for the installation. So if you wanted to use --chroot I think you have to make sure the packages are available inside the chroot. Perhaps there's some sort of DESTDIR option for the package installation? I've been searching but have had no luck yet. I'll ask around. It might be more reliable to do something like nullfs mount the packages into the chroot and do the installation completely within the chroot. Meanwhile I did: # cp -Rp ~guru/PKGDIR/mnt # PKG_PATH=/PKGDIR # export PKG_PATH # chroot /mnt pkg_add xorg-7.7 # chroot /mnt pkg_add kde-4.10.5 # chroot /mnt pkg_add vim-7.3.1314 ... # chroot /mnt pkg_info | wc -l 654 which went fine without any errors (only the normal messages about creation of users, etc.); I will test the resulting image and report back. matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: Where is pkg repository for 9.2-RELEASE (amd64)?
Use PACKAGESITE=http://pkg-test.freebsd.org/pkg-test-${ABI}/latest
That's the kit that will form the official FreeBSD package repository;
it just lacks the crypto bits for signing the packages, which is why
it's calling itself 'pkg-test'
Oh -- there isn't an A record in the DNS for pkg-test.freebsd.org --
look up a SRV record for _http._tcp.pkg-test.freebsd.org instead.
Well, I still have no idea what the address of the server is.
Could someone post it (i.e. 123.456.789.123 or alike)?
After having it set as PACKAGESITE, I assume running pkg, pkg2ng,
pkg update, pkg upgrade -fy enough?
Best regards all
Zoran
___
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: Where is pkg repository for 9.2-RELEASE (amd64)?
On Tue, Oct 8, 2013, at 10:58, Zoran Kolic wrote:
Use PACKAGESITE=http://pkg-test.freebsd.org/pkg-test-${ABI}/latest
That's the kit that will form the official FreeBSD package repository;
it just lacks the crypto bits for signing the packages, which is why
it's calling itself 'pkg-test'
Oh -- there isn't an A record in the DNS for pkg-test.freebsd.org --
look up a SRV record for _http._tcp.pkg-test.freebsd.org instead.
Well, I still have no idea what the address of the server is.
Could someone post it (i.e. 123.456.789.123 or alike)?
# dig _http._tcp.pkg-test.freebsd.org SRV
; DiG 9.9.3-P2 _http._tcp.pkg-test.freebsd.org SRV
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 8634
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_http._tcp.pkg-test.freebsd.org. INSRV
;; ANSWER SECTION:
_http._tcp.pkg-test.freebsd.org. 120 IN SRV 10 10 80
pkg1.nyi.freebsd.org.
;; ADDITIONAL SECTION:
pkg1.nyi.freebsd.org. 3600IN A 96.47.72.120
pkg1.nyi.freebsd.org. 3600IN 2610:1c1:1:6300::16:78
;; Query time: 374 msec
;; SERVER: 192.168.93.251#53(192.168.93.251)
;; WHEN: Tue Oct 08 11:24:41 CDT 2013
;; MSG SIZE rcvd: 144
After having it set as PACKAGESITE, I assume running pkg, pkg2ng,
pkg update, pkg upgrade -fy enough?
Best regards all
Depends. Where are your other installed packages from? I'd probably
re-install all of them from the pkg-test repository just to be safe.
___
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: Where is pkg repository for 9.2-RELEASE (amd64)?
Yeah!!! 96.47.72.120 works! Thanks! Depends. Where are your other installed packages from? I'd probably re-install all of them from the pkg-test repository just to be safe. I installed 9.1 on new node and compiled from ports. It took a long time, which I want to avoid right now. Here is what I consider as steps for 9.2: freebsd-update upgrade -r 9.2-RELEASE freebsd-update install nextboot -k GENERIC freebsd-update install portsnap fetch portsnap extract do all pkg steps freebsd-update install kernel rebuild reboot I might be making some misunderstandings in order of this? Best regards Zoran ___ 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: 9.1 - 9.2 upgrade
On 8 October 2013, at 06:22, dweimer dwei...@dweimer.net wrote: On 10/08/2013 4:27 am, Doug Hardie wrote: On 5 October 2013, at 05:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 21:49:18 -0700, Doug Hardie wrote: On 4 October 2013, at 20:03, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: On 4 October 2013, at 19:08, Polytropon free...@edvax.de wrote: On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 Have you verified in /etc/freebsd-update.conf that src is definitely part of what should be updated? System is not bootable - can't verify anything… Does the system (or better, its enclosure, software-wise) allow booting a rescue system or an emergency media, such as a FreeBSD v9 live system? Yes - but there is no one there who can successfully be told how to run it. Not even inserting a USB stick (with the FreeBSD memstick data) or a CD? We have serious communications issues - they want to use back slashes and have no idea what a slash is. Maybe that is the result of many years of administration on Windows PCs. :-) Even if you tell them which key to use, they know better and use a back slash cause thats what Windoze uses. Uh... knowing better would disqualify them as maintainers of a server installation. The inability to learn (or even to read and follow instructions) is a dangerous thing. The disk should be in the mail to me now. I will be able to work with it when it arrives. Okay, that's also a possible alternative. To be honest, that's the first time I hear about this procedure. But doable. The file /etc/freebsd-update.conf should contain the line Components src world kernel if you want to make sure the source is properly updated, along with the world and kernel (GENERIC). As indicated before, I don't think all the source got updated. The kernel showed 9.2 after recompilation. However UPDATING was not updated. Thats as much as I could check before. I assume that this could be possible by inconsistently updated sources. It would be a good start to remove /usr/src and download the sources of the correct version via SVN _or_ freebsd-update again. Before the next installation attempt, /usr/obj should be removed as well, just to be sure. Step 5: reboot Attention: Into single-user mode. Not possible since the system is located over 100 miles away. Everything has to be done via remote console. Does this mean SSH only or do you have a _real_ console transmission by which you can access the system _prior_ to the OS providing the SSH access? I'm mentioning this because the traditional approach requires (few) steps done in the single-user mode where no SSH connectivity is provided in the normal way… I have a telnet box that has serial connections to the console ports. That approach has been used without any issues since FreeBSD 2.5. I do disable all ports during the process via an reduced rc.conf file. A serial console should also work, but even though I've been using serial consoles (and _real_ serial terminals), one thing I'm not sure about: Is it possible to interrupt (!) the boot process at an early stage to get to the loader prompt and boot into single user mode from there? Ok boot -s If not, do you have the beastie menu (or whatever it is called today) enabled to go to SUM to perform the make installworld step? Anyway, if you can install everything is required with the disk at home, and then send it back to that datacenter (according to your characterization, the quotes are deserved), that should solve the problems and make sure everything works as intended. The Thick Plottens… I received the drives and installed them on a working system. The failed system is structured with a single partition for the system and another for swap. For some unknown reason, the BIOS got left configured to boot the extra disk if its powered up. That turns out to be handy. I can boot a working system with the corrupt drive powered off. Booting from the corrupt drive yields the normal hardware info followed by the Beastie image and immediately by a multitude of lines (repeated many times): Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 639kB/1037824kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: I was able to capture these by using a serial console connected to another computer. The lines only appear on the serial console once. They scroll by on the real console many time - all too fast to read anything. Then after a few seconds of that, the screen goes black, and the system reboots. The cycle then repeats… Pressing any key does nothing. I even filled the
Re: failed to create gmirror with the handbook instructions
This is actually trickier than it first looked. First I got into single user mode by supplying 'shutdown now', but the tunefs commands all failed with the following: #tunefs -j disable /dev/ada0s1a Clearing journal flags from inode 4 tunefs: Failed to write journal inode: Operation not permitted tunefs: soft updates journalling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space tunefs: /dev/ada0s1a: failed to write superblock I tried the dump command on the off-chance, and it failed with the original errors. Is there anything you can recommend? I then noticed you specified to boot into single user more, so I restarted the machine, with only ada0 attached. Because the handbook wants me to use the mirror/gm0sX devices, I swapped my fstab file back to the original. The boot loader now only seems to recognise the mirror/gm0 nodes, the original ada0sX are gone (though ada0 still shows up). I'm not sure if it's acceptable to do the dump by booting the 1st hard drive using the mirror/gm0, and then dump to the 2nd hard drive by mounting what will be ada1sX. Is this okay to do? On 8 October 2013 01:31, Warren Block wbl...@wonkity.com wrote: On Tue, 8 Oct 2013, Andy Zammy wrote: Hi, I used the second section of the handbook (20.4) to create a gmirror. In my particular setup I had a 1GB /, 6GB swap, 1GB /tmp and the rest of the 1TB drive was left for /usr I had to deviate from the handbook when it came to running the dump + restore commands, as the dump failed due to an issue with the journalling. To get around this problem, I dropped into single user mode, so I could remount root as read-only. The dump commands then worked. It specified in the handbook to restart the machine, and boot from ada1. It was at this point that I noticed something wasn't quite right. There was a spew of 'not found/no such file or directory' messages. These were all trying to reference libs and binaries that live in /usr. I boot into single user mode, and upon checking the other partitions, I notice that /tmp and /usr are empty, apart from a .snap file, and the restoresymtable file. Please could someone help me troubleshoot this problem? Let me know if you need any more info, and I'll post it up asap. dump does not work reliably on filesystems with SUJ enabled. Turn off SUJ on the filesystems to be dumped by booting in single-user mode and running tunefs -j disable /dev/ada0whatever Do each filesystem, then use dump. ___ 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: failed to create gmirror with the handbook instructions
I On 8 October 2013 01:31, Warren Block wbl...@wonkity.com wrote: On Tue, 8 Oct 2013, Andy Zammy wrote: Hi, I used the second section of the handbook (20.4) to create a gmirror. In my particular setup I had a 1GB /, 6GB swap, 1GB /tmp and the rest of the 1TB drive was left for /usr I had to deviate from the handbook when it came to running the dump + restore commands, as the dump failed due to an issue with the journalling. To get around this problem, I dropped into single user mode, so I could remount root as read-only. The dump commands then worked. It specified in the handbook to restart the machine, and boot from ada1. It was at this point that I noticed something wasn't quite right. There was a spew of 'not found/no such file or directory' messages. These were all trying to reference libs and binaries that live in /usr. I boot into single user mode, and upon checking the other partitions, I notice that /tmp and /usr are empty, apart from a .snap file, and the restoresymtable file. Please could someone help me troubleshoot this problem? Let me know if you need any more info, and I'll post it up asap. dump does not work reliably on filesystems with SUJ enabled. Turn off SUJ on the filesystems to be dumped by booting in single-user mode and running tunefs -j disable /dev/ada0whatever Do each filesystem, then use dump. ___ 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: failed to create gmirror with the handbook instructions
On Tue, 8 Oct 2013, Andy Zammy wrote: This is actually trickier than it first looked. First I got into single user mode by supplying 'shutdown now', but the tunefs commands all failed with the following: #tunefs -j disable /dev/ada0s1a Clearing journal flags from inode 4 tunefs: Failed to write journal inode: Operation not permitted tunefs: soft updates journalling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space tunefs: /dev/ada0s1a: failed to write superblock I tried the dump command on the off-chance, and it failed with the original errors. Is there anything you can recommend? I then noticed you specified to boot into single user more, so I restarted the machine, with only ada0 attached. Because the handbook wants me to use the mirror/gm0sX devices, I swapped my fstab file back to the original. The boot loader now only seems to recognise the mirror/gm0 nodes, the original ada0sX are gone (though ada0 still shows up). I don't know what would do that. The device nodes on the original drive should be untouched until it is added back to the mirror. What does gpart show ada0s1 show? Did you make a backup of the original drive first? Is there an entry for vfs.root.mountfrom in /boot/loader.conf? I'm not sure if it's acceptable to do the dump by booting the 1st hard drive using the mirror/gm0, and then dump to the 2nd hard drive by mounting what will be ada1sX. Is this okay to do? Sorry, I don't quite understand the question. The mirror will not be usable until a good copy of the original drive is made to it. ___ 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: failed to create gmirror with the handbook instructions
# gpart show ada0s1 gpart: No such geom: ada0s1 By the way, this is after a restart of the machine. There's nothing to back up, I'm installing a fresh os, so I just install on one drive, plug the other in, and start following the handbook instructions for this method. So the only thing in loader.conf is geom_mirror_load=YES. I'll rephrase the question: given that the handbook originally wanted me to dump from ada0s1 to the mounted mirror/gm0s1 (which was ada1 at the time), and I cannot do this, would it be enough to dump from mirror/gm0s1 (which is what ada0 is now mounted as), to ada1s1 (even though this *should* be the other way around, it's equivalent as far as i can see, isn't it?)? On 8 October 2013 22:59, Warren Block wbl...@wonkity.com wrote: On Tue, 8 Oct 2013, Andy Zammy wrote: This is actually trickier than it first looked. First I got into single user mode by supplying 'shutdown now', but the tunefs commands all failed with the following: #tunefs -j disable /dev/ada0s1a Clearing journal flags from inode 4 tunefs: Failed to write journal inode: Operation not permitted tunefs: soft updates journalling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space tunefs: /dev/ada0s1a: failed to write superblock I tried the dump command on the off-chance, and it failed with the original errors. Is there anything you can recommend? I then noticed you specified to boot into single user more, so I restarted the machine, with only ada0 attached. Because the handbook wants me to use the mirror/gm0sX devices, I swapped my fstab file back to the original. The boot loader now only seems to recognise the mirror/gm0 nodes, the original ada0sX are gone (though ada0 still shows up). I don't know what would do that. The device nodes on the original drive should be untouched until it is added back to the mirror. What does gpart show ada0s1 show? Did you make a backup of the original drive first? Is there an entry for vfs.root.mountfrom in /boot/loader.conf? I'm not sure if it's acceptable to do the dump by booting the 1st hard drive using the mirror/gm0, and then dump to the 2nd hard drive by mounting what will be ada1sX. Is this okay to do? Sorry, I don't quite understand the question. The mirror will not be usable until a good copy of the original drive is made to it. ___ 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: 9.1 - 9.2 upgrade
Doug Hardie wrote: The Thick Plottens… I received the drives and installed them on a working system. The failed system is structured with a single partition for the system and another for swap. For some unknown reason, the BIOS got left configured to boot the extra disk if its powered up. That turns out to be handy. I can boot a working system with the corrupt drive powered off. Booting from the corrupt drive yields the normal hardware info followed by the Beastie image and immediately by a multitude of lines (repeated many times): Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 639kB/1037824kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: I was able to capture these by using a serial console connected to another computer. The lines only appear on the serial console once. They scroll by on the real console many time - all too fast to read anything. Then after a few seconds of that, the screen goes black, and the system reboots. The cycle then repeats… Pressing any key does nothing. I even filled the keyboard buffer with spaces hoping to stop boot, but nothing seems to stop it. I checked and the freebsd-update.conf include world sys and src. I rebuild everything after removing /obj just for grins and giggles. I have installed the kernel and world using DESTDIR to put it on the corrupt drive. Same messages again. I now have the corrupt drive mounted on /mnt and am trying to update the src again. Using: freebsd-update -b /mnt fetch updated files list show /usr/src/sys… and updating to 9.1-RELEASE-p7 freebsd-update -b /mnt install This is running slower than molasses in January. Its run for almost 30 minutes and only 3 files have been updated. There must be network issues between me and the server. I'll let it run tonight but I am going to crash now. Long day. More tomorrow. -- Doug Have you checked the dmesg output, specifically to see if there are any disk errors, perhaps the hard drive is about dead. If you are planning to rebuild world and kernel form source, why not just use svn or extract the source from the 9.2-RELEASE disk onto the system. There are no hardware errors logged. The drive is only a couple months old. Smart drive status is good. I tried downloading the src with: svn co https://svn0.us-west.FreeBSD.org/base/releng/9.2 /mnt/usr/src I didn't get Release 9.2. The first entry in UPDATING is: 20130705: hastctl(8)'s `status' command output changed to terse one-liner format. Scripts using this should switch to `list' command or be rewritten. There is an entry earlier for Release 9.1. but no entry for Release 9.2. ___ 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 Hello Doug, Here is a more recent version of the file on svn: http://svnweb.freebsd.org/base/stable/9/UPDATING?revision=255900view=markup Earlier today I also checked out base for releng/9.2 from the same mirror, svn0.us-west. My UPDATING file is outdated too. Time of the last entry is 20130705. The mirror told me that I had checked out revision 256150. When running freebsd-update upgrade -r RELEASE-9.2 last night it gave : WARNING: This system is running a customcl kernel, which is not a kernel configuration distributed as part of FreeBSD 9.1-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running /usr/sbin/freebsd-update install. That might have been expected, but I have read on this list that freebsd-update will sometimes automatically replace a custom kernel with a generic, and in /etc/freebsd-update.conf I had the line: Components src world kernel . HTH, Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.org -- ___ 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: failed to create gmirror with the handbook instructions
On Tue, 8 Oct 2013, Andy Zammy wrote: Thanks very much. Please could I make a suggestion that this be included in the handbook page? Please do not top-post, it makes replies more difficult. I have added a warning about SUJ to the top of the gmirror section in the Handbook. ___ 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: failed to create gmirror with the handbook instructions
On Tue, 8 Oct 2013, Andy Zammy wrote: # gpart show ada0s1 gpart: No such geom: ada0s1 By the way, this is after a restart of the machine. There's nothing to back up, I'm installing a fresh os, so I just install on one drive, plug the other in, and start following the handbook instructions for this method. So the only thing in loader.conf is geom_mirror_load=YES. I'll rephrase the question: given that the handbook originally wanted me to dump from ada0s1 to the mounted mirror/gm0s1 (which was ada1 at the time), and I cannot do this, would it be enough to dump from mirror/gm0s1 (which is what ada0 is now mounted as), to ada1s1 (even though this *should* be the other way around, it's equivalent as far as i can see, isn't it?)? There is not much point in dumping from the mirror to another drive. The dump/restore is how the single drive is copied to the mirror. On a fresh install, use the Shell mode of the installer to set up the mirror, then install directly to it. There are some instructions on mountpoints in the bsdinstall man page. This will avoid the lag of waiting for the second drive to sync. ___ 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: failed to create gmirror with the handbook instructions
Andy Zammy wrote: # gpart show ada0s1 gpart: No such geom: ada0s1 By the way, this is after a restart of the machine. There's nothing to back up, I'm installing a fresh os, so I just install on one drive, plug the other in, and start following the handbook instructions for this method. So the only thing in loader.conf is geom_mirror_load=YES. [snip] Since you are beginning to reinstall from scratch, please allow/forgive a small interjection from some of my recent experience with this. Warren is more knowledgeable on this than I am, and I have followed many of his instructions in the past. With the shift towards GPT and away from the old DOS mbr/partition table stuff of the past, the current Handbook pages reflect this. The central point of contention arises from the fact that GPT, GEOM (gmirror), and many hardware RAID controllers require to claim the very last sector of a drive to store their metadata. Obviously, the effect of this collision is a whoever wrote last wrote best - so you can't use combinations of things that all want this sector. The most simple gmirroring is to slice an entire drive, with partitions contained within. The very end of the drive must NOT have any file system on it, and this is usually the case by default as most of the time slicing/partitioning leaves a little free space at the end anyway. This will not work with GPT; only with the old DOS compatible mbr and disklabel scheme. In order to use GPT and gmirror together you gmirror individual partitions (as opposed to the slice) , e.g. gmirror will write its metadata at the end of each partition leaving the very last sector at the end of the drive for GPT. This is what the content on the relevant Handbook pages reflects. More complicated, but allows for the demise of the ancient DOS/mbr partitioning. Notice that if you combine GPT and a hardware RAID controller card the same collision problem noted previously can still happen. If you utilize the BIOS on the controller card for anything it will save its metadata on the last drive sector. When not faced with terabyte sized humongous volumes and the huge amount of time an fsck will consume, the old DOS way with disklabel is still an option that works. The main reason for the journaling is to sidestep waiting for a very long fsck on a huge volume to run to completion before finishing a boot into a cleaned up/repaired file system. If your drive volume is small this is not so much a problem. Indeed my old gateway/firewall/IDS router box I did the old DOS/mbr scheme with gmirror (the old single-slice entire drive and mirror the drive) as the pair of drives are ancient 74GB Raptors. On my web/database test box I did go the GPT and SUJ+journaling route but am not using any mirroring here (yet). I have not experienced any problems with dump - but I also do not use the -L switch. It will show an error/warning about not dumping a live file system this way but I go ahead and do it anyway. IIRC the dump problem you may be seeing may be related to drive snapshotting. The caveat is I can sort of 'get away' with it as my boxen are largely quiescent, but would hesitate to do this on something like a public web/database box that was continually being hammered with lots of traffic. Just tossing out some ideas for your perusal and consideration. The way I used the old DOS/mbr and disklabel scheme on my router machine is very simple, quick to do, and has survived a few power outages now with no data loss (other than the time it takes to rebuild which it does automagically on boot). On the 74GB Raptors this rebuild takes about twenty minutes. Your situation and needs may force you in a different direction. Hence, the proverbial YMMV applies. FWIW. Now for to finally get around to purchasing a new UPS to replace the old one that went up in smoke and died horribly... -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: 9.1 - 9.2 upgrade
On Tue, 8 Oct 2013 11:20:40 -0700, Doug Hardie wrote: I tried downloading the src with: svn co https://svn0.us-west.FreeBSD.org/base/releng/9.2 /mnt/usr/src I didn't get Release 9.2. The first entry in UPDATING is: 20130705: hastctl(8)'s `status' command output changed to terse one-liner format. Scripts using this should switch to `list' command or be rewritten. There is an entry earlier for Release 9.1. but no entry for Release 9.2. You could try downloading and extracting the src distribution: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.2-RELEASE/src.txz -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: 9.1 - 9.2 upgrade
Polytropon wrote: On Tue, 8 Oct 2013 11:20:40 -0700, Doug Hardie wrote: I tried downloading the src with: svn co https://svn0.us-west.FreeBSD.org/base/releng/9.2 /mnt/usr/src I didn't get Release 9.2. The first entry in UPDATING is: 20130705: hastctl(8)'s `status' command output changed to terse one-liner format. Scripts using this should switch to `list' command or be rewritten. There is an entry earlier for Release 9.1. but no entry for Release 9.2. You could try downloading and extracting the src distribution: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.2-RELEASE/src.txz Yes, that might have been simpler. Knew there had to be some other way. :) -- c...@sdf.org SDF Public Access UNIX System - http://sdf.org -- ___ 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: failed to create gmirror with the handbook instructions
I tried creating the mirror before the install. As the drives are now mirrored, the installer picked up on the face that there are two gm0 nodes - one on each hard drive. I installed onto ada0's gm0 node. After it reboots, the bootloader stops at the manual prompt. From what I can see that's not dissapeared up the screen, it tried and failed to mount from mirror/gm0s1a with error 19. I had to mount from ada0s1a in order for the boot to get further, but as it's been installed to boot from gm0s1x, it stops after it mounts /. After having checked my partition setup many times at this point, I know for a fact there's a rather large 500MB section free at the end of my hard drives with this partition set up. Is there any reason I can't just install as normal, do a 'gmirror label gm0 ada0', and then do a 'gmirror insert gm0 ada1', before changing my fstab to use mirror/gm0? I can't see why dumping and restoring is necessary, it's just manually doing what gmirror is there for in the first place. Correct me if I'm wrong :) On 9 October 2013 00:11, Warren Block wbl...@wonkity.com wrote: On Tue, 8 Oct 2013, Andy Zammy wrote: # gpart show ada0s1 gpart: No such geom: ada0s1 By the way, this is after a restart of the machine. There's nothing to back up, I'm installing a fresh os, so I just install on one drive, plug the other in, and start following the handbook instructions for this method. So the only thing in loader.conf is geom_mirror_load=YES. I'll rephrase the question: given that the handbook originally wanted me to dump from ada0s1 to the mounted mirror/gm0s1 (which was ada1 at the time), and I cannot do this, would it be enough to dump from mirror/gm0s1 (which is what ada0 is now mounted as), to ada1s1 (even though this *should* be the other way around, it's equivalent as far as i can see, isn't it?)? There is not much point in dumping from the mirror to another drive. The dump/restore is how the single drive is copied to the mirror. On a fresh install, use the Shell mode of the installer to set up the mirror, then install directly to it. There are some instructions on mountpoints in the bsdinstall man page. This will avoid the lag of waiting for the second drive to sync. ___ 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
Geli and ZFS
* * -- There are few different ways to set-up geli with ZFS. I just want to get some opinions (benefits and disadvantages) about the below two options *First option*: (most commonly encountered set-up) Have geli on the block device and ZFS on top of the geli provider. * Second option:* Create a ZFS Volume on a block device, then create geli provider on top of the ZFS volume, and finally, ZFS datasets on top. Generally, it's recommended to let ZFS manage the whole disk if possible, so I was wondering if the second option is better. I will be using couple of 3TB HDDs mirrored for data and want to encrypt them. I am hoping someone with an in-depth understanding of ZFS will be able to offer some insight. -- Kind regards, Yudi ___ 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
