boot0cfg and gmirror again
Hi, all, Our hosting servers use a NanoBSD disk layout for rapid updates and - if necessary - fallback to the former working version of the system. I just tested the update from RELENG_6_3 to RELENG_7_2, because I was concerned about the one-way upgrade of the on disk data for gmirror. That part went great. We are, however, still struggling to autmatically switch the active partititon after dd'ing an update to the inactive one: new_server# uname -a FreeBSD new_server 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 30 14:49:14 CET 2009 r...@nanobsd.ka.punkt.de:/var/home/nanobsd/obj/rx100s5-hosting/usr/src/sys/GENERIC amd64 new_server# gmirror status NameStatus Components mirror/m0 COMPLETE ad4 ad6 new_server# fdisk /dev/mirror/m0 *** Working on device /dev/mirror/m0 *** parameters extracted from in-core disklabel are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16065, size 16418430 (8016 Meg), flag 0 beg: cyl 1/ head 0/ sector 1; end: cyl 1022/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16434495, size 16418430 (8016 Meg), flag 80 (active) beg: cyl 1023/ head 0/ sector 1; end: cyl 1020/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 32852925, size 455539140 (222431 Meg), flag 0 beg: cyl 1021/ head 0/ sector 1; end: cyl 704/ head 254/ sector 63 The data for partition 4 is: new_server# mount /dev/mirror/m0s2a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) That's the status of the system, now let's try to activate partition 1: new_server# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 new_server# boot0cfg -v -s1 /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found: "m0" boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Now, what? This was discussed here, already, and I got the impression that a solution was to be in RELENG_7: http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044487.html Tanks for any insight. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: boot0cfg and gmirror ...
Hi, all, > hd30# boot0cfg -s 2 -v /dev/mirror/m0 > boot0cfg: /dev/mirror/m0: Geom not found > boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Simple solution: don't use boot0cfg - use fdisk. I get the bogus (?) "Geom not found" message every time, but the active partition seems to be updated correctly. The only dicussion of this topic that I found dates back to 2005: http://freebsd.monkey.org/freebsd-current/200507/msg00156.html Still not quite sure about possible implications, but I am happy as long as it works. Any caveats? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
boot0cfg and gmirror ...
Hi, all, I know about the "foot shooting" prevention in geom(4) when trying to update the MBR of a mounted disk. I have a system with ad4 and ad6 mirrored and fdisk partitions residing on the mirror to be booted alterningly: hd30# gmirror status NameStatus Components mirror/m0 COMPLETE ad4 ad6 hd30# mount /dev/mirror/m0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) hd30# boot0cfg -v /dev/mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) OK, try to switch to slice 2: hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Known one, set debug flags and try again: hd30# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Er ... well, what now? Out of curiosity I tried: hd30# boot0cfg -s 2 -v /dev/ad4 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) hd30# boot0cfg -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) hd30# boot0cfg -s 2 -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) So, with the prevention removed it is possible to write to the single disks, but not to the mirror as a whole. Weird. Any ideas? What bad things can happen if I keep updating the MBRs of both individual disks seperately - besides bad karma and "See? I told you so!" in case I generate an inconsistent state? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
