On 2012/2/18 9:30, Julian Elischer wrote:
mine is too, yet it still has problems..
CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz
K8-class CPU)
Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17
Stepping = 6
Features=0xbfebfbff
Features2=0xce3bd
AMD
Giulio Ferro wrote:
> Thanks everybody again for your help with setting up a working
> kerberized nfsv4 system.
>
> I was able to user-mount a nfsv4 share with krb5 security, and I was
> trying to do the same as root.
>
> Unfortunately the patch I found here:
> http://people.freebsd.org/~rmacklem
On Friday 17 February 2012 06:28 am, David Xu wrote:
On 2012/2/17 16:06, Julian Elischer wrote:
On 2/16/12 11:41 PM, Julian Elischer wrote:
adding jkim as he seems to be the last person working with TSC.
On 2/16/12 6:42 PM, David Xu wrote:
On 2012/2/17 10:19, Julian Elischer wrote:
On 2/16/1
On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
> On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
>
> > On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
> >> On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
> >>
> >>> On Tue, Feb 14, 2012 at 09:38:18AM -05
Giulio Ferro wrote:
> Thanks everybody again for your help with setting up a working
> kerberized nfsv4 system.
>
> I was able to user-mount a nfsv4 share with krb5 security, and I was
> trying to do the same as root.
>
> Unfortunately the patch I found here:
> http://people.freebsd.org/~rmacklem
Latest version with additional checks for NTFS and FAT32, to be precise,
for NTFS filesystem with label "FAT" and for FAT filesystem with label "NTFS" ;)
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG="/var/log/automount.log"
STATE="/var/run/automount.state"
DATE
... even newer version, seems to have all 'problems' fixed now ;)
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG="/var/log/automount.log"
STATE="/var/run/automount.state"
DATEFMT="%Y-%m-%d %H:%M:%S"
__create_mount_point() { # /* 1=DEV */
MNT="/mnt/$( basename
On Fri, Feb 17, 2012 at 1:38 PM, Andriy Gapon wrote:
> And just in case:
> Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A
> September 7, 2011 says:
> [snip]
>> Two GPT Header structures are stored on the device: the primary and the
>> backup. The primary GPT Header mus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
on 17/02/2012 16:28 Hiroki Sato said the following:
> Andriy Gapon wrote in <4f3e3000.9000...@freebsd.org>:
>
> av> -BEGIN PGP SIGNED MESSAGE- av> Hash: SHA1 av> av> on 17/02/2012
> 09:04 Hiroki Sato said the following: av> > No, the issue is
On Fri, Feb 17, 2012 at 06:09:55PM +0100, Miroslav Lachman wrote:
> Pete French wrote:
> >
> >Should this not be the recommended way of doing things even for MBR
> >disks ? I have a lot of machines booting from gmirror, but we always
> >do it by mirroring MBR partitions (or GPT ones). I cant see wh
I already made some changes for the 'better' ...
Here is the latest version:
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG="/var/log/automount.log"
STATE="/var/run/automount.state"
DATEFMT="%Y-%m-%d %H:%M:%S"
__create_mount_point() { # /* 1=DEV */
MNT="/mnt/
I've been following the above mentioned thread because I
wasn't convinced by the new bsd installer on my latest installation. Now,
the problem that I am seeing is no longer the new installer but that I am
obsolete in modern freebsd disk partitioning options and reliability of
each. I've been doi
Am 14.02.2012 um 12:37 schrieb Alexander Leidinger:
> 1 FLOWTABLE
The last time I included this in a kernel it seemed to have odd effects on TCP
connections. Admittedly, that was probably two years or so ago, and I never
bothered to find out what was happening in detail. Is it safe now?
Ste
Hi,
I have finally made some effort on writing flexible yet very simple automounter
for FreeBSD desktop.
Feel free to submit me BUG reports ;)
It currently supports these file formats:
-- NTFS(rw) requires [port]sysutils/fusefs-ntfs[/port]
-- FAT/FAT32
-- exFAT requires [port]sysutils/fusefs-ex
On 2/17/12 3:28 AM, David Xu wrote:
On 2012/2/17 16:06, Julian Elischer wrote:
On 2/16/12 11:41 PM, Julian Elischer wrote:
adding jkim as he seems to be the last person working with TSC.
On 2/16/12 6:42 PM, David Xu wrote:
On 2012/2/17 10:19, Julian Elischer wrote:
On 2/16/12 5:56 PM, David
> Yes it does? Am I the only one person on the whole earth seeing the big
> difference in easy setup of mirroring two drives instead of many
> individual partitions?
Sorry, I wasnt suggesting that you should always mirror
the indiviudual partititons - just I happen to do that where
I am mixing Z
Pete French wrote:
I wasn't aware you could do that. I was only aware that it was the
other way around. That (my) misconception seems to also be relayed
by others such as Miroslav who said:
Should this not be the recommended way of doing things even for MBR
disks ? I have a lot of machines bo
Thanks everybody again for your help with setting up a working
kerberized nfsv4 system.
I was able to user-mount a nfsv4 share with krb5 security, and I was
trying to do the same as root.
Unfortunately the patch I found here:
http://people.freebsd.org/~rmacklem/rpcsec_gss.patch
fails to apply c
On Thursday 16 February 2012 08:55 pm, Julian Elischer wrote:
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950)
> ACPI-fast(900) dummy(-100)
> kern.timecounter.hardware: ACPI-fast
> kern.timecounter.stepwarnings: 0
>
> switching the machine from TSC_low to A
On Friday 17 February 2012 06:28 am, David Xu wrote:
> On 2012/2/17 16:06, Julian Elischer wrote:
> > On 2/16/12 11:41 PM, Julian Elischer wrote:
> >> adding jkim as he seems to be the last person working with TSC.
> >>
> >> On 2/16/12 6:42 PM, David Xu wrote:
> >>> On 2012/2/17 10:19, Julian Elisc
On 02/17/2012 16:21, Freddie Cash wrote:
[...]
The problem with mirroring partitions is that you thrash the disk
during the rebuild after replacing a failed disk. And the more
partitions you have, the worse it gets.
I guess that if you do per-slice mirroring you should turn off autosync, right
On Fri, 17 Feb 2012, Freddie Cash wrote:
On Fri, Feb 17, 2012 at 3:12 AM, Pete French wrote:
I wasn't aware you could do that. I was only aware that it was the
other way around. That (my) misconception seems to also be relayed
by others such as Miroslav who said:
Should this not be the rec
on 17/02/2012 16:28 Hiroki Sato said the following:
> Andriy Gapon wrote
> in <4f3e3000.9000...@freebsd.org>:
>
> av> -BEGIN PGP SIGNED MESSAGE-
> av> Hash: SHA1
> av>
> av> on 17/02/2012 09:04 Hiroki Sato said the following:
> av> > No, the issue is our gptloader assumes the backup hea
> The problem with mirroring partitions is that you thrash the disk
> during the rebuild after replacing a failed disk. And the more
> partitions you have, the worse it gets.
yes, this is true - actually I have had this on older
machiens, and have had to stop the rebuilds of each bit until
the ot
On Fri, Feb 17, 2012 at 3:12 AM, Pete French wrote:
>> I wasn't aware you could do that. I was only aware that it was the
>> other way around. That (my) misconception seems to also be relayed
>> by others such as Miroslav who said:
>
> Should this not be the recommended way of doing things even
On Fri, Feb 17, 2012 at 3:21 AM, Alexander Leidinger
wrote:
> Quoting Freddie Cash (from Tue, 14 Feb 2012 08:26:54
> -0800):
>
>> On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith wrote:
>>>
>>> On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
>>> > 1 IPSTEALTH -> cha
Andriy Gapon wrote
in <4f3e3000.9000...@freebsd.org>:
av> -BEGIN PGP SIGNED MESSAGE-
av> Hash: SHA1
av>
av> on 17/02/2012 09:04 Hiroki Sato said the following:
av> > No, the issue is our gptloader assumes the backup header is always located
av> > at the (physical) last sector while this
Quoting Freddie Cash (from Tue, 14 Feb 2012
08:26:54 -0800):
On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith wrote:
On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
> 1 IPSTEALTH -> changes ipfw module only?
I don't think this is specific to ipfw. From /sys/con
Quoting Nenhum_de_Nos (from Tue, 14 Feb
2012 10:49:56 -0200):
On Tue, February 14, 2012 08:31, Alexander Leidinger wrote:
Embedded devices are out of the scope of this, normally you do a lot
of other modifictions to such systems anyway, so a custom kernel
should be not a big problem.
I wi
On 2012/2/17 16:06, Julian Elischer wrote:
On 2/16/12 11:41 PM, Julian Elischer wrote:
adding jkim as he seems to be the last person working with TSC.
On 2/16/12 6:42 PM, David Xu wrote:
On 2012/2/17 10:19, Julian Elischer wrote:
On 2/16/12 5:56 PM, David Xu wrote:
On 2012/2/17 8:42, Julian
> I wasn't aware you could do that. I was only aware that it was the
> other way around. That (my) misconception seems to also be relayed
> by others such as Miroslav who said:
Should this not be the recommended way of doing things even for MBR
disks ? I have a lot of machines booting from gmirr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
on 17/02/2012 09:04 Hiroki Sato said the following:
> No, the issue is our gptloader assumes the backup header is always located
> at the (physical) last sector while this is not mandatory in the UEFI
> specification.
Are you sure?
Unified Extensible
on 17/02/2012 07:37 Freddie Cash said the following:
> Seems to me that we need a GEOM-aware loader
I am also adding a GEOM-aware BIOS/firmware to the wish-list.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailm
on 17/02/2012 03:55 Julian Elischer said the following:
>
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900)
> dummy(-100)
> kern.timecounter.hardware: ACPI-fast
> kern.timecounter.stepwarnings: 0
>
> switching the machine from TSC_low to ACP
On 2/16/12 11:41 PM, Julian Elischer wrote:
adding jkim as he seems to be the last person working with TSC.
On 2/16/12 6:42 PM, David Xu wrote:
On 2012/2/17 10:19, Julian Elischer wrote:
On 2/16/12 5:56 PM, David Xu wrote:
On 2012/2/17 8:42, Julian Elischer wrote:
Adding David Xu for his tho
35 matches
Mail list logo
