Re: Apparent fxp regression in FreeBSD 8.4-RC3
On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on an older Supermicro single CPU single core Xeon motherboard. [...] Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013 r...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 Your attached dmesg of -RC3 is not -RC3, it is 8-STABLE. At this point, there have been changes between the stable/8 and releng/8.4 branches enough say that the two have diverged, and the stable/8 code is _not_ what will be the 8.4-RELEASE. While your issue does concern me, it is still unclear that this is a problem with the upcoming 8.4-RELEASE. Can you please try upgrading to the releng/8.4 branch to see if this issue persists? Glen pgp4Ce8gCKnQz.pgp Description: PGP signature
Re: Apparent fxp regression in FreeBSD 8.4-RC3
Here is pciconf -lvbc under 8.3-RELEASE p8: hostb0@pci0:0:0:0: class=0x06 card=0x chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI hostb1@pci0:0:0:1: class=0x06 card=0x chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI em0@pci0:0:1:0: class=0x02 card=0x10018086 chip=0x10268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82545ep)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfeb6, size 131072, enabled bar [18] = type Memory, range 64, base 0xfeb0, size 262144, enabled bar [20] = type I/O Port, range 32, base 0xe000, size 64, enabled cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction vgapci0@pci0:0:6:0: class=0x03 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfd00, size 16777216, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 256, enabled bar [18] = type Memory, range 32, base 0xfebff000, size 4096, enabled cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 fxp0@pci0:0:7:0:class=0x02 card=0x10508086 chip=0x12298086 rev=0x10 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfebfd000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xe400, size 64, enabled bar [18] = type Memory, range 32, base 0xfeb8, size 131072, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 bge0@pci0:0:8:0:class=0x02 card=0x800914e4 chip=0x16a614e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5702X NetXtreme Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfebe, size 65536, enabled cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit hostb2@pci0:0:15:0: class=0x06 card=0x425515d9 chip=0x02031166 rev=0xa0 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'PCI to ISA Bridge (CSB6)' class = bridge subclass = HOST-PCI atapci0@pci0:0:15:1:class=0x01018a card=0x021211d9 chip=0x02131166 rev=0xa0 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB6/CSB6 PCI EIDE Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled ohci0@pci0:0:15:2: class=0x0c0310 card=0x425515d9 chip=0x02211166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OHCI Compliant USB Controller (OSB6)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfebfe000, size 4096, enabled isab0@pci0:0:15:3: class=0x060100 card=0x425515d9 chip=0x02271166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'PCI Bridge (CSB6)' class = bridge subclass = PCI-ISA ___ 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: FreeBSD Quarterly Status Report, January-March 2013
__ FreeNAS URL: http://www.FreeNAS.org/ Contact: Alfred Perlstein alf...@freebsd.org Contact: Josh Paetzel jpaet...@freebsd.org FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, and should end up as the last FreeNAS release based on FreeBSD 8.X It's currently the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). Open tasks: 1. The team is hard at work on getting a FreeBSD 9.X-based release of FreeNAS ready. Currently there are several nightly snapshots available. 2. Add HAST to the webinterface. 3. Migrate to NFSv4. 4. Integrate foundation sponsored kernel iSCSI target. Uhmm WHAT??? FreeNAS is not the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). NAS4Free has been doing it. ___ 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
Reinstalling boot blocks on a ZFS-only system
So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the release/boot from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using. What do people in the know do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty? Thanks. Happy for any information. - Chris ___ 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: Reinstalling boot blocks on a ZFS-only system
On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote: So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the release/boot from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using. What do people in the know do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty? The command is gpart bootcode, however I cannot be bothered to remember the syntax; I imagine it greatly depends on if you're using GPT vs. MBR, in addition to what your partition layout look like. Meaning: there is no universal standard, it depends entirely on how you set your stuff up. But the command is definitely gpart bootcode. Next, AFAIK there is no need to boot alternate media (CD etc.) to accomplish this. You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's safety measure / to permit writing to LBA 0; see GEOM(4) and search for the word foot. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Build GENERIC with IPX support
W dniu 2013-05-12 04:27, ill...@gmail.com pisze: I think you also have to have options LIBMCHAIN That helped, thanks! anyway, despite using ef(4) module, configuring IPX net number, I am unable to list my NetWare servers: # ncplogin Segmentation fault (core dumped) # I'm not sure whether IPX is still supported in FreeBSD? -- Marek Salwerowicz ___ 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: Build GENERIC with IPX support
It's supported as long as someone wants to use it and can help in at least diagnosing issues. So, if you have a segfault, run it inside gdb and report where its dying. Chances are things have just bitrotted a bit but not so much that it's worth killing. adrian On 12 May 2013 14:54, Marek Salwerowicz marek_...@wp.pl wrote: W dniu 2013-05-12 04:27, ill...@gmail.com pisze: I think you also have to have options LIBMCHAIN That helped, thanks! anyway, despite using ef(4) module, configuring IPX net number, I am unable to list my NetWare servers: # ncplogin Segmentation fault (core dumped) # I'm not sure whether IPX is still supported in FreeBSD? -- Marek Salwerowicz ___ 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 ___ 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: Reinstalling boot blocks on a ZFS-only system
On 2013-05-12 15:58, Jeremy Chadwick wrote:
On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote:
So, I've long known and it makes sense that when you're booted from a
ZFS volume, you can't mess with the boot-loader. And, I know a few
months ago I had a set of commands I would use when booted from a CD
that would initialize the network and copy the release/boot from
somewhere else so that I could install bootblocks and boot-loaders from
more recent code. Sadly, I didn't _record_ those commands I was using.
What do people in the know do when they want to update the bootblocks
of a ZFS-boot system? Or, have too few people followed this path so
far that they can boot UFS and do it with less difficulty?
The command is gpart bootcode, however I cannot be bothered to
remember the syntax; I imagine it greatly depends on if you're using
GPT
vs. MBR, in addition to what your partition layout look like. Meaning:
there is no universal standard, it depends entirely on how you set
your stuff up. But the command is definitely gpart bootcode.
Next, AFAIK there is no need to boot alternate media (CD etc.) to
accomplish this.
You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
safety measure / to permit writing to LBA 0; see GEOM(4) and search
for the word foot.
Assuming a freebsd-boot type partition, and GPT type partition scheme,
this is what I
use on my ZFS boot system:
$ cat bin/update_boot.sh
#!/bin/sh
for i in `seq 0 5`
do
echo Disk ${i}
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada${i}
done
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
___
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: Apparent fxp regression in FreeBSD 8.4-RC3
On Sun, 12 May 2013, Glen Barber wrote: On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on an older Supermicro single CPU single core Xeon motherboard. [...] Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013 r...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 Your attached dmesg of -RC3 is not -RC3, it is 8-STABLE. At this point, there have been changes between the stable/8 and releng/8.4 branches enough say that the two have diverged, and the stable/8 code is _not_ what will be the 8.4-RELEASE. While your issue does concern me, it is still unclear that this is a problem with the upcoming 8.4-RELEASE. Can you please try upgrading to the releng/8.4 branch to see if this issue persists? Glen I installed RELENG_8_4 using cvsup (yes, I'm planning on updating) and got 8.4-BETA; this had the same behavior as 8-STABLE. I tried booting the 8.3-RELEASE p8 kernel and got the same behavior, which makes me wonder if I had made some earlier mistake. I reinstalled 8.3-RELEASE p8 (world and kernel) from source and the system is now operating normally. The differences between the kernel file I'm using and GENERIC are that I have options for ipfirewall and the amd driver for the AMD 53C974 and do not have devices esp nor isci (revised amd and iscsi). I'm going to revise my kernel file to be more up-to-date and will test that. I'm not having problems with two other systems, one a Tyan S4882 with 4 single-core Opterons and a Tyan S2882 with two dual-core Opterons. Neither one uses the fxp driver; both are operating in x64 mode. Mike Squires mi...@siralan.org UN*X at home since 1986 ___ 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: Apparent fxp regression in FreeBSD 8.4-RC3
On Sun, May 12, 2013 at 09:50:18PM -0400, Michael L. Squires wrote: I installed RELENG_8_4 using cvsup (yes, I'm planning on updating) and got 8.4-BETA; this had the same behavior as 8-STABLE. Right. releng/8.4 is not exported to cvsup. Please update your tree with svn or svnup (net/svnup in ports). If 'uname -a' shows -BETA*, that is older than -PRERELEASE. Glen pgpA5WM5QrJt4.pgp Description: PGP signature
Re: Reinstalling boot blocks on a ZFS-only system
On May 12, 2013, at 16:58 , Jeremy Chadwick j...@koitsu.org wrote:
The command is gpart bootcode, however I cannot be bothered to
remember the syntax; I imagine it greatly depends on if you're using GPT
vs. MBR, in addition to what your partition layout look like. Meaning:
there is no universal standard, it depends entirely on how you set
your stuff up. But the command is definitely gpart bootcode.
Next, AFAIK there is no need to boot alternate media (CD etc.) to
accomplish this.
You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
safety measure / to permit writing to LBA 0; see GEOM(4) and search
for the word foot.
In the past, I've found I've been unable to install all of the bootblocks if I
boot from the ZFS root. When booting from a cd, the basic:
gpart bootcode -p ${bootdir}/zfsboot ${disk}
dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024
conv=notrunc,sync
works. But, if I boot from ZFS, then I can't dd anything into the front of the
drives. Right now, the problem after booting from the CD, is trying to mount
a read/write filesystem (mfs, or the like) so that I can scp the bootblocks
onto the
system and install them. BUt, I eventually found the command I'd lost. so I
think I'm alright. Thanks...
- Chris
___
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: Reinstalling boot blocks on a ZFS-only system
In article 20130512205837.ga69...@icarus.home.lan, j...@koitsu.org writes: You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's safety measure / to permit writing to LBA 0; see GEOM(4) and search for the word foot. If you have set up your partitioning properly (read: following the clearly recommended best practice on the wiki), there should never, ever be any reason to do this. (That is why it's called a DEBUG flag.) The necessary and sufficient invocation is: # gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX I have no idea how this works with MBR partitioning, but I would make one suggestion in that regard: DON'T. Whatever makes you think you want to do that, think harder and find another way. -GAWollman ___ 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: Reinstalling boot blocks on a ZFS-only system
On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote:
On May 12, 2013, at 16:58 , Jeremy Chadwick j...@koitsu.org wrote:
The command is gpart bootcode, however I cannot be bothered to
remember the syntax; I imagine it greatly depends on if you're using GPT
vs. MBR, in addition to what your partition layout look like. Meaning:
there is no universal standard, it depends entirely on how you set
your stuff up. But the command is definitely gpart bootcode.
Next, AFAIK there is no need to boot alternate media (CD etc.) to
accomplish this.
You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
safety measure / to permit writing to LBA 0; see GEOM(4) and search
for the word foot.
In the past, I've found I've been unable to install all of the bootblocks
if I
boot from the ZFS root. When booting from a cd, the basic:
gpart bootcode -p ${bootdir}/zfsboot ${disk}
dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024
conv=notrunc,sync
works. But, if I boot from ZFS, then I can't dd anything into the front of
the
drives. Right now, the problem after booting from the CD, is trying to mount
a read/write filesystem (mfs, or the like) so that I can scp the bootblocks
onto the
system and install them. BUt, I eventually found the command I'd lost. so I
think I'm alright. Thanks...
What does unable to install mean? What output/error do you get? I am
going to assume you get EPERM (Operation not permitted), which would be
caused by GEOM's preventive foot-shooting (keep reading).
Is there some reason you're sticking with the MBR scheme instead of GPT?
Taken from GEOM(4):
Both types of bootstrap code are used to boot from the GUID Partition Ta-
ble. First, a protective MBR is embedded into the first disk sector from
the /boot/pmbr image. It searches the GPT freebsd-boot partition (see
the PARTITION TYPES section) in the GPT and runs the next bootstrap stage
from it. The freebsd-boot partition should be smaller than 545 KB.
There are two variants of bootstrap code to write to this partition:
/boot/gptboot and /boot/gptzfsboot. /boot/gptboot is used to boot from
UFS. It searches freebsd-ufs GPT partitions and starts /boot/loader (the
third bootstrap stage) if found. The /boot/gptzfsboot is used to boot
from ZFS. It searches freebsd-zfs GPT partitions and starts
/boot/zfsloader if found.
So by moving to GPT you would relieve yourself of a lot of pain,
particularly that dd nonsense (which looks like it could seriously hurt
you, especially if you're doing it by hand by booting some CD). An
added bonus to using the GPT scheme is that you can align your
partitions easier for 4096-byte sector drives.
With GPT, I believe you'd use this, and only this:
sysctl kern.geom.debugflags=16
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${disk}
sysctl kern.geom.debugflags=0
(That also assumes the GPT freebsd-boot partition is what's comes first
on $disk (i.e. index 1), as it should be)
If you're using mirrors, you would need to do the gpart command for each
disk that is part of your mirror vdev; i.e. if ada0 and ada1 are a
mirror, issue the gpart command against ada0 and ada1, otherwise you may
find that if one of your disks dies you might not be able to boot from
the system.
All this comes from:
https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror
(You'll find the EPERM situation mentioned there too)
I should also note that if you do go with GPT, please use a larger
freebsd-boot partition size (512KBytes is ideal, not 64KBytes), because
the bootstraps are often 64KBytes these days.
http://www.wonkity.com/~wblock/docs/html/ssd.html
Good luck.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: Reinstalling boot blocks on a ZFS-only system
On Sun, May 12, 2013 at 11:14:20PM -0400, Garrett Wollman wrote: In article 20130512205837.ga69...@icarus.home.lan, j...@koitsu.org writes: You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's safety measure / to permit writing to LBA 0; see GEOM(4) and search for the word foot. If you have set up your partitioning properly (read: following the clearly recommended best practice on the wiki), there should never, ever be any reason to do this. (That is why it's called a DEBUG flag.) ... I'm in full agreement with you, but the irony is that you refer to the wiki, which I have intentionally ignored for years now because it's always wrong/always out of date/under scrutiny/do-not-care-to-debate. Case in point: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot 5. Install the Protected MBR (pmbr) and gptzfsboot loader Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 This may fail with an operation not permitted error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror 5. Install the Protected MBR (pmbr) and gptzfsboot loader to both drives Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad1 This may fail with an operation not permitted error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition 10. Install ZFS boot ... Install the boot1 stage: Fixit# dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 count=1 This may fail with an operation not permitted error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 The necessary and sufficient invocation is: # gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX I have no idea how this works with MBR partitioning, but I would make one suggestion in that regard: DON'T. Whatever makes you think you want to do that, think harder and find another way. I believe for MBR you'd need to refer to the slice, not the disk, i.e. ada0s1 (NOT THE PARTITION ada0s1a). I found this out long ago when doing the classic bsdlabel -B ada0 method of updating boot blocks only to find it bitch/complain and insist I use the slice. I haven't dared touch gpart for bootblock updates on any FreeBSD system I have access to, simply because the gpart syntax is long and could really screw you over if you make a typo. Plus, remembering which files to refer to in /boot is always spotty. Uh, do I use -b here or -p... Uh, do I use /boot/mbr or /boot/pmbr... err /boot is such a mess these days. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Reinstalling boot blocks on a ZFS-only system
In article 20130513032838.ga76...@icarus.home.lan, j...@koitsu.org write: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot 5. Install the Protected MBR (pmbr) and gptzfsboot loader Bug #1: Protective, not Protected. Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 This may fail with an operation not permitted error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 I suppose the bit that's missing here is: ...and then file a bug report, with severity serious and priority high, because this indicates that something is seriously broken in the kernel's implementation of GPT partitioning. The only way this step can fail (absent bugs) is if something (other than gpart) has either the whole-disk device or the partition 1 device open in exclusive mode, which is a can't happen condition at this stage in an installation. (Well, it can happen if the disk you are in the process of destroying has a still-mounted filesystem on it, which is what the code is supposed to prevent!) This little bit of cargo-culting used to be necessary for *MBR* and *bsdlabel* partitioning, before the days of gpart bootcode, to update the boot0 and embedded partition-boot (boot1) blocks while the filesystem was mounted, because the bsdlabel boot blocks are stored in the first 64k of the root filesystem. When using GPT, the boot blocks are stored in the boot partition, which doesn't have a mountable filesystem on it, so should never be open for write except when gpart bootcode is doing the deed. -GAWollman ___ 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: Apparent fxp regression in FreeBSD 8.4-RC3
On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on an older Supermicro single CPU single core Xeon motherboard. I know that 8.3-Release does not have this issue, but don't know when in the updates to that release the regression was introduced. I use the fxp driver to connect to a Motorola Surfboard cable modem, and immediately saw the following occur many times: May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 10 23:00:04 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25 5.255 May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP May 10 23:00:22 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163 May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 10 23:00:22 familysquires dhclient: New Broadcast Address (fxp0): 255.255.255.255 May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP repeated without end. If you assign static IP address, fxp(4) works? I reinsalled 8.3-Release p8 FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46: Sat May 11 00:05:26 EDT 2013 which ended the string up fxp up/down messages. This kernel has now operated for 24 hours without generating this error. There were several fxp(4)changes made since FreeBSD 8.3-RELEASE but I don't see any fxp(4) commits that may result in DHCP issue above. I recall there was a dhclient(8) change that makes dhclient track link state. Could you rebuild dhclient(8) and try again without that change(i.e. locally back out r247336)? I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from 8.3-Release p8, and can provide whatever else you need. This is not a critical issue for me. The system has an unused bge interface (replaced by an Intel em0 interface during a previous bout of a problem with the bge driver). Mike Squires mi...@siralan.org ___ 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
