date:20121104

On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote:
 On 03.11.2012 13:48, Doug Hardie wrote:

 I didn't notice that journaling is on by default and now dump is
 failing.  The only way I can see to disable journaling requires that
 the file system be dismounted, or read-only.  This is a remote machine
 and journaling is on root.  Is there any other way that would not
 require me to make a long trip out to the site?

 This is a task for mfsBSD: http://mfsbsd.vx.sk

Hmm, I think you have to make a trip or get some kind of remote console 
over ip.
I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr as 
seperate partions
For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then 
mount -o rw /
For the /tmp /var and /usr filesystems this does not work bcause hey 
cannot be remounted ro while they are busy.


This e-mail message, including any attachment(s), is intended solely for the 
addressee or addressees. Any views or opinions presented herein are solely 
those of the author and do not necessarily represent those of OSE.

If you are not the intended recipient of this communication please return this 
e-mail message and the attachment(s) to the sender and delete and destroy all 
copies.

___
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: My freebsd partition changed by Windows chkdsk (Leslie Jensen)

2012-11-04 Thread Manish Jain



On 04-Nov-12 13:17, Leslie Jensen wrote:



Manish Jain 2012-11-02 19:18:


1) Boot from your FreeBSD CD/DVD, enter the slice editor and
change the type of your FreeBSD slice back to 165. Do not press Q.
Press W instead. Conform with Yes to the warning, and then press
Ctrl+Alt+Del to abort the installation.

2) Boot from your FreeBSD CD/DVD again, and run boot0cfg -B in an
emergency shell.

My legal disclaimer comes here, but do let me know if you get lucky

I hope my message sounds less cryptic now. I personally don't have
anything against running chkdsk or fixmbr, AS LONG AS I have backed
up the important sectors.

Regards

Manish Jain
bourne.ident...@hotmail.com

___
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



I've attached the disk to a running Freebsd system 8.3.

Which program do you reefer to when you write slice editor?

I do not need to be able to boot from the disk. I just need to be able
to read it and copy my /home to another disk.

Thanks

/Leslie




Hello Leslie,

I think you are unclear with FreeBSD terminology. What Windows calls 
primary partitions are called slices in FreeBSD. You can have a maximum
of 4 slices per disk, as I had mentioned earlier. One of the slices may 
optionally be marked as what Windows calls an extended partition. The 
extended partition can be broken up into many partitions (logical 
drives in Windows terminology). Your C: drive is a slice in FreeBSD 
terms. If you have a D: drive too, that - in all likelihood - is a 
partition in FreeBSD terminology.


FreeBSD's terminology is in general much clearer and a lot more mature 
than you would find on any other OS, particularly Windows.


The first step that you have to perform when installing FreeBSD is to 
enter the slice editor and create a slice for FreeBSD. When you press on 
Begin a standard installation, the slice editor is the first 
application that is automatically presented to you.


FreeBSD uses the term partition to refer to the divisions it creates 
inside its slice for the /, /usr, /var, /tmp filesystems.


Now I fail to understand what you mean by a running FreeBSD system. I 
thought your FreeBSD installation had been rendered unbootable by 
chkdsk. If you can indeed boot into FreeBSD successfully, then you 
shouldn't be having any problem copying out whatever data you want.


The steps I had suggested were meant to make your FreeBSD installation 
bootable. As long as your FreeBSD slice is marked as NTFS (filesystem ID 
7) instead of FFS (filesystem ID 165) in the MBR, no application or OS 
can read any data from that slice, at least AFAIK.



Regards

Manish Jain
+91-99620-10329
___
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: My freebsd partition changed by Windows chkdsk (Leslie Jensen)

2012-11-04 Thread Manish Jain

 Date: Sun, 4 Nov 2012 16:41:45 +0530
 From: bourne.ident...@hotmail.com
 To: les...@eskk.nu
 CC: freebsd-questions@freebsd.org
 Subject: Re: My freebsd partition changed by Windows chkdsk (Leslie Jensen)

 On 04-Nov-12 13:17, Leslie Jensen wrote:

  Manish Jain 2012-11-02 19:18:

  1) Boot from your FreeBSD CD/DVD, enter the slice editor and
  change the type of your FreeBSD slice back to 165. Do not press Q.
  Press W instead. Conform with Yes to the warning, and then press
  Ctrl+Alt+Del to abort the installation.

  2) Boot from your FreeBSD CD/DVD again, and run boot0cfg -B in an
  emergency shell.

  My legal disclaimer comes here, but do let me know if you get lucky

  I hope my message sounds less cryptic now. I personally don't have
  anything against running chkdsk or fixmbr, AS LONG AS I have backed
  up the important sectors.

  Regards

  Manish Jain
  bourne.ident...@hotmail.com

  ___
  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

  I've attached the disk to a running Freebsd system 8.3.

  Which program do you reefer to when you write slice editor?

  I do not need to be able to boot from the disk. I just need to be able
  to read it and copy my /home to another disk.

  Thanks

  /Leslie

 Hello Leslie,

 I think you are unclear with FreeBSD terminology. What Windows calls 
 primary partitions are called slices in FreeBSD. You can have a maximum
 of 4 slices per disk, as I had mentioned earlier. One of the slices may 
 optionally be marked as what Windows calls an extended partition. The 
 extended partition can be broken up into many partitions (logical 
 drives in Windows terminology). Your C: drive is a slice in FreeBSD 
 terms. If you have a D: drive too, that - in all likelihood - is a 
 partition in FreeBSD terminology.

 FreeBSD's terminology is in general much clearer and a lot more mature 
 than you would find on any other OS, particularly Windows.

 The first step that you have to perform when installing FreeBSD is to 
 enter the slice editor and create a slice for FreeBSD. When you press on 
 Begin a standard installation, the slice editor is the first 
 application that is automatically presented to you.

 FreeBSD uses the term partition to refer to the divisions it creates 
 inside its slice for the /, /usr, /var, /tmp filesystems.

 Now I fail to understand what you mean by a running FreeBSD system. I 
 thought your FreeBSD installation had been rendered unbootable by 
 chkdsk. If you can indeed boot into FreeBSD successfully, then you 
 shouldn't be having any problem copying out whatever data you want.

 The steps I had suggested were meant to make your FreeBSD installation 
 bootable. As long as your FreeBSD slice is marked as NTFS (filesystem ID 
 7) instead of FFS (filesystem ID 165) in the MBR, no application or OS 
 can read any data from that slice, at least AFAIK.

 Regards

 Manish Jain
 +91-99620-10329

Just in case you are not aware how to change the filesystem type in the slice 
editor,

highlight your FreeBSD slice and press T. Make sure you enter 165 as the 
filesystem

type, and then press W and confirm the change. Then press  Ctrl+Alt+Del and 
reboot.

Regards

Manish Jain

bourne.iden...@hotmail.com

___
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 9.1 and SU+J

2012-11-04 Thread RW

On Sun, 04 Nov 2012 11:44:28 +0100
Bas Smeelen wrote:

 On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote:
  On 03.11.2012 13:48, Doug Hardie wrote:
 
  I didn't notice that journaling is on by default and now dump is
  failing.  The only way I can see to disable journaling requires
  that the file system be dismounted, or read-only.  This is a
  remote machine and journaling is on root.  Is there any other way
  that would not require me to make a long trip out to the site?
 
  This is a task for mfsBSD: http://mfsbsd.vx.sk
 
 Hmm, I think you have to make a trip or get some kind of remote
 console over ip.
 I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr
 as seperate partions
 For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then 
 mount -o rw /
 For the /tmp /var and /usr filesystems this does not work bcause hey 
 cannot be remounted ro while they are busy.

A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put
your tunefs commands at the bottom of fsck_start(), then do a reboot.
___
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: Dell H710 and H310 Raid Controller

2012-11-04 Thread Omer Faruk SEN

Hi,


Just tried 9.1-RC3 with R720 which has H710p( the only difference with H710
is 1 gb cache instead of 512mb ). It has recognized both H710p raid as
mfid0 and also network cards are recognized as bgeX (*BCM5720)* but network
cards times out (watchdog timeout) I think it is about
http://forums.freebsd.org/showthread.php?t=31769page=2

It seems right now only way to go with Rx20 Server models is to use Intel
cards (dell provides i350 chipset network interfaces as alternative)

PS: I really need your comments on R420 with H710 or R320 with H310 raid
controllers

Regads.


On Fri, Nov 2, 2012 at 4:10 PM, kpn...@pobox.com wrote:

 On Thu, Nov 01, 2012 at 07:46:45PM +0200, Omer Faruk SEN wrote:
  Hi,
 
  Can anyone in this list verify that both RAID controllers are supported
 on
  FreeBSD 8.3 or 9.1

 Negative on 8.3. I'm running a post-8.3-release 8.3-STABLE compiled after
 the new mfi driver went in.

  H710 has  LSISAS2208 dual-core PowerPC ROC
  H310 has LSISAS2008.
 
  I am planning to use these controllers on R420 and R320 Dell Servers. I
  would also like to get comments on these two platfoms and if there are
 any
  issues on FreeBSD 9.1 (I know it is RC2 right now)

 I've got an H710 in an R620. It works fine for me.

 Of course, my system is lightly loaded for the most part. The past couple
 of days I've had one client pounding on it via netatalk. It held up well
 considering ZFS performing really badly on a 96% full pool when writing
 a lot of data. But that's an outlier. Usually my system is lightly loaded.

 Make sure you turn off all power savings controls in the BIOS.
 --
 Kevin P. Nealhttp://www.pobox.com/~kpn/
On the community of supercomputer fans:
 But what we lack in size we make up for in eccentricity.
   from Steve Gombosi, comp.sys.super, 31 Jul 2000 11:22:43 -0600

___
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 9.1 and SU+J

On 11/04/2012 02:11 PM, RW wrote:
 On Sun, 04 Nov 2012 11:44:28 +0100
 Bas Smeelen wrote:

 On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote:
 On 03.11.2012 13:48, Doug Hardie wrote:

 I didn't notice that journaling is on by default and now dump is
 failing.  The only way I can see to disable journaling requires
 that the file system be dismounted, or read-only.  This is a
 remote machine and journaling is on root.  Is there any other way
 that would not require me to make a long trip out to the site?
 This is a task for mfsBSD: http://mfsbsd.vx.sk

 Hmm, I think you have to make a trip or get some kind of remote
 console over ip.
 I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr
 as seperate partions
 For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then
 mount -o rw /
 For the /tmp /var and /usr filesystems this does not work bcause hey
 cannot be remounted ro while they are busy.
 A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put
 your tunefs commands at the bottom of fsck_start(), then do a reboot.

Very nice :) Thanks a lot!
I tried this and can confirm it works.
_But_ not all partitions are soft updates without journaling now.
It didn't work for the / partition, I guess because / is mounted rw 
before /etc/rc.d/fsck is executed.
For the / partition I guess I will really have to be at the console 
starting single user, because mount -o ro en then disable with tunefs -j 
disable did not work either. See at the end of this mail.
I wonder if it even can be accomplished when booting single user, which 
I cannto test right now.

Doug, if you have more partitions than just / you could go ahead with 
the above solution, it worked for me. You can then at least dump data 
from your other partitions.

See below:

root@osebart:/usr/home/Freebee # mount
/dev/da0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/da0p3 on /tmp (ufs, local, journaled soft-updates)
/dev/da0p4 on /var (ufs, local, journaled soft-updates)
/dev/da0p5 on /usr (ufs, local, journaled soft-updates)

edit /etc/rc.d/fsck and added:

/sbin/tunefs -j disable /dev/da0p2
/sbin/tunefs -j disable /dev/da0p3
/sbin/tunefs -j disable /dev/da0p4
/sbin/tunefs -j disable /dev/da0p5

just before
}

load_rc_config $name
run_rc_command $1

at the end.

shutdown -r now and I have

root@osebart:/usr/home/Freebee # mount
/dev/da0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/da0p3 on /tmp (ufs, local, soft-updates)
/dev/da0p4 on /var (ufs, local, soft-updates)
/dev/da0p5 on /usr (ufs, local, soft-updates)

See below for mount -o ro

root@osebart:/usr/home/Freebee # mount -o ro /
root@osebart:/usr/home/Freebee # mount
/dev/da0p2 on / (ufs, local, read-only)
devfs on /dev (devfs, local, multilabel)
/dev/da0p3 on /tmp (ufs, local, soft-updates)
/dev/da0p4 on /var (ufs, local, soft-updates)
/dev/da0p5 on /usr (ufs, local, soft-updates)
root@osebart:/usr/home/Freebee # tunefs -j disable /dev/da0p2
Clearing journal flags from inode 4
tunefs: soft updates journaling cleared but soft updates still set.
tunefs: remove .sujournal to reclaim space

shutdown -r now but still

root@osebart:/usr/home/Freebee # mount
/dev/da0p2 on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/da0p3 on /tmp (ufs, local, soft-updates)
/dev/da0p4 on /var (ufs, local, soft-updates)
/dev/da0p5 on /usr (ufs, local, soft-updates)








This e-mail message, including any attachment(s), is intended solely for the 
addressee or addressees. Any views or opinions presented herein are solely 
those of the author and do not necessarily represent those of OSE.

If you are not the intended recipient of this communication please return this 
e-mail message and the attachment(s) to the sender and delete and destroy all 
copies.

___
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

config multiport serial card

2012-11-04 Thread s m

hello everybody

i have a moxa 4-port serial card and installed it on freebsd8.2
successfully. i have ttyu2-5 in /dev that are moxa ports.

my question is how i can use these ports? i add the following lines to ttys
file:
ttyu2 /usr/libexec/getty std.9600 vt100 on secure
ttyu3 /usr/libexec/getty std.9600 vt100 on secure
ttyu4 /usr/libexec/getty std.9600 dialup on secure
ttyu5 /usr/libexec/getty std.9600 dialup on secure

and restart my system. i connect another system to one of my moxa port by a
null modem cable and run putty in both side but i can't see any thing in
putty screens and leds on moxa card doesn't turn on.

please let me know if i should do some configuration else in order to my
ports work correctly. should i use another application instead of putty to
work with these ttyus?

thanks
sam
___
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 9.1 and SU+J

On 11/04/2012 03:00 PM, Bas Smeelen wrote:
 On 11/04/2012 02:11 PM, RW wrote:
 On Sun, 04 Nov 2012 11:44:28 +0100
 Bas Smeelen wrote:

 On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote:
 On 03.11.2012 13:48, Doug Hardie wrote:

 I didn't notice that journaling is on by default and now dump is
 failing.  The only way I can see to disable journaling requires
 that the file system be dismounted, or read-only.  This is a
 remote machine and journaling is on root.  Is there any other way
 that would not require me to make a long trip out to the site?

I guess I was a little off here, it actually worked for / also
See further below for the whole story
This was all done remote with ssh

$ mount
/dev/da0p2 on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/da0p3 on /tmp (ufs, local, soft-updates)
/dev/da0p4 on /var (ufs, local, soft-updates)
/dev/da0p5 on /usr (ufs, local, soft-updates)
$ su
Password:
root@osebart:/usr/home/Freebee # rm /.sujournal
root@osebart:/usr/home/Freebee # rm /var/.sujournal
root@osebart:/usr/home/Freebee # rm /tmp/.sujournal
root@osebart:/usr/home/Freebee # rm /usr/.sujournal
root@osebart:/usr/home/Freebee # uname -a
FreeBSD osebart.ose.nl 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct 1 
18:26:44 UTC 2012 
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

 This is a task for mfsBSD: http://mfsbsd.vx.sk

 Hmm, I think you have to make a trip or get some kind of remote
 console over ip.
 I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr
 as seperate partions
 For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then
 mount -o rw /
 For the /tmp /var and /usr filesystems this does not work bcause hey
 cannot be remounted ro while they are busy.
 A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put
 your tunefs commands at the bottom of fsck_start(), then do a reboot.
 Very nice :) Thanks a lot!
 I tried this and can confirm it works.
 _But_ not all partitions are soft updates without journaling now.
 It didn't work for the / partition, I guess because / is mounted rw
 before /etc/rc.d/fsck is executed.
 For the / partition I guess I will really have to be at the console
 starting single user, because mount -o ro en then disable with tunefs -j
 disable did not work either. See at the end of this mail.
 I wonder if it even can be accomplished when booting single user, which
 I cannto test right now.

 Doug, if you have more partitions than just / you could go ahead with
 the above solution, it worked for me. You can then at least dump data
 from your other partitions.

 See below:

 root@osebart:/usr/home/Freebee # mount
 /dev/da0p2 on / (ufs, local, journaled soft-updates)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0p3 on /tmp (ufs, local, journaled soft-updates)
 /dev/da0p4 on /var (ufs, local, journaled soft-updates)
 /dev/da0p5 on /usr (ufs, local, journaled soft-updates)

 edit /etc/rc.d/fsck and added:

 /sbin/tunefs -j disable /dev/da0p2
 /sbin/tunefs -j disable /dev/da0p3
 /sbin/tunefs -j disable /dev/da0p4
 /sbin/tunefs -j disable /dev/da0p5

 just before
 }

 load_rc_config $name
 run_rc_command $1

 at the end.

 shutdown -r now and I have

 root@osebart:/usr/home/Freebee # mount
 /dev/da0p2 on / (ufs, local, journaled soft-updates)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0p3 on /tmp (ufs, local, soft-updates)
 /dev/da0p4 on /var (ufs, local, soft-updates)
 /dev/da0p5 on /usr (ufs, local, soft-updates)

 See below for mount -o ro

 root@osebart:/usr/home/Freebee # mount -o ro /
 root@osebart:/usr/home/Freebee # mount
 /dev/da0p2 on / (ufs, local, read-only)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0p3 on /tmp (ufs, local, soft-updates)
 /dev/da0p4 on /var (ufs, local, soft-updates)
 /dev/da0p5 on /usr (ufs, local, soft-updates)
 root@osebart:/usr/home/Freebee # tunefs -j disable /dev/da0p2
 Clearing journal flags from inode 4
 tunefs: soft updates journaling cleared but soft updates still set.
 tunefs: remove .sujournal to reclaim space

 shutdown -r now but still

 root@osebart:/usr/home/Freebee # mount
 /dev/da0p2 on / (ufs, local, soft-updates)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0p3 on /tmp (ufs, local, soft-updates)
 /dev/da0p4 on /var (ufs, local, soft-updates)
 /dev/da0p5 on /usr (ufs, local, soft-updates)





This e-mail message, including any attachment(s), is intended solely for the 
addressee or addressees. Any views or opinions presented herein are solely 
those of the author and do not necessarily represent those of OSE.

If you are not the intended recipient of this communication please return this 
e-mail message and the attachment(s) to the sender and delete and destroy all 
copies.

___
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

Character set conversion, locales, UTF-8, etc

2012-11-04 Thread grarpamp

Hi. I think I'm looking for a character conversion tool.
I have a few thousand files in a hier. I believe an app, possibly a Java one,
created them while in en_US.US-ASCII mode, or perhaps some other
unidentified locale. Whatever it was, I think it took binary filename data,
interpreted it and wrote the interpretation to disk (instead of the
original binary).
So now any other app that looks at the disk under any locale gets the
names wrong.
So I think I need something to take some stdin from /bin/ls -w (in the
broken way
I have it on disk), let me fiddle with feeding it different locales to
until I see the
right binary representation again, and then emit the binary to stdout
so I can rename
the files back to binary on disk so that any future app can read the names under
it's own local locale.
Does that make sense? I'm very new to character sets and things.

As an aside, why does FreeBSD seem to default to the above locale
instead of say, en_US.UTF-8 ?
___
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: Dell H710 and H310 Raid Controller

2012-11-04 Thread Sean Bruno

On Sun, 2012-11-04 at 05:47 -0800, Omer Faruk SEN wrote:
 It seems right now only way to go with Rx20 Server models is to use
 Intel
 cards (dell provides i350 chipset network interfaces as alternative) 

The Broadcom 5720 support is in current right now.  It will not be in
9.1, but will be available in stable/9 soon-ish.

Sean


signature.asc
Description: This is a digitally signed message part

BIOS update saga - the end

2012-11-04 Thread Anton Shterenlikht

I can't find my original thread, so
starting a new one.

So I bought a spare laptop disk,
installed freedos on it, made
a usb memstick with HP BIOS updating
executable, and booted from it, only
to stop at:

The BIOS on your notebook PC can not be updated.
Refer to HP Customer Advisory C01457784

So I found this customer advisory
and there it is: WinBond customers
cannot update the BIOS [1].

So not only I am stuck with a broken
BIOS, but I can't update to a fixed
one either (nevermind the wasted hours
spent following HP instructions on
how to update the BIOS on my laptop!).

I quickly found another thread
where somebody claims that HP asked
for nearly 400 euros to update the
motherboard, to be able to update the BIOS! [2].

I was angry at HP for this initially,
then I started laughing. This is a ridiculous
situation.

Anyway, now I'm wondering - I wanted
to buy an HP laptop because I've used
quite a lot of Compaq/HP server gear and
it generally is/was of excellent quality.
And the manuals still are of very high quality too.
So I wonder, am I just unlucky,
or did I want a good quality too cheaply?

Anton

[1]
http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=encc=ustaskId=125prodSeriesId=3368540prodTypeId=321957objectID=c01457784

[2]
http://h30499.www3.hp.com/t5/Notebook-HP-ProBook-EliteBook/6715s-black-screen-problem/td-p/915244/page/5#.UJRCK1JvmnI
___
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 9.1 and SU+J

2012-11-04 Thread Doug Hardie


On 4 November 2012, at 07:04, Bas Smeelen wrote:

 On 11/04/2012 03:00 PM, Bas Smeelen wrote:
 On 11/04/2012 02:11 PM, RW wrote:
 On Sun, 04 Nov 2012 11:44:28 +0100
 Bas Smeelen wrote:
 
 On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote:
 On 03.11.2012 13:48, Doug Hardie wrote:
 
 I didn't notice that journaling is on by default and now dump is
 failing.  The only way I can see to disable journaling requires
 that the file system be dismounted, or read-only.  This is a
 remote machine and journaling is on root.  Is there any other way
 that would not require me to make a long trip out to the site?
 
 I guess I was a little off here, it actually worked for / also
 See further below for the whole story
 This was all done remote with ssh
 
 $ mount
 /dev/da0p2 on / (ufs, local, soft-updates)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0p3 on /tmp (ufs, local, soft-updates)
 /dev/da0p4 on /var (ufs, local, soft-updates)
 /dev/da0p5 on /usr (ufs, local, soft-updates)
 $ su
 Password:
 root@osebart:/usr/home/Freebee # rm /.sujournal
 root@osebart:/usr/home/Freebee # rm /var/.sujournal
 root@osebart:/usr/home/Freebee # rm /tmp/.sujournal
 root@osebart:/usr/home/Freebee # rm /usr/.sujournal
 root@osebart:/usr/home/Freebee # uname -a
 FreeBSD osebart.ose.nl 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct 1 
 18:26:44 UTC 2012 
 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

I can't get that to work on i386.  Here is /etc/rc.d/fsck:

fi

echo Ready for tunefs
/sbin/tunefs -j disable /dev/da0p2
}

load_rc_config $name
run_rc_command $1




reboot computer and here is the output from messages:




Nov  4 14:07:19 Router kernel: Ready for tunefs
Nov  4 14:07:19 Router kernel: Clearing journal flags from inode 4
Nov  4 14:07:19 Router kernel: tunefs: soft updates journaling cleared but soft 
updates still set.
Nov  4 14:07:19 Router kernel: tunefs: remove .sujournal to reclaim space
Nov  4 14:07:19 Router kernel: Mounting local file systems:.



and the output from mount:

Router# mount
/dev/da0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)



Journaled is still on after 2 reboots.

Router# uname -a
FreeBSD Router 9.1-RC2 FreeBSD 9.1-RC2 #0 r241133: Tue Oct  2 17:11:45 UTC 2012 
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

-- Doug

___
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: before new version

2012-11-04 Thread C-S

 Date: Sat, 3 Nov 2012 17:20:26 -0500
 From: ajtiM lum...@gmail.com
 To: Polytropon free...@edvax.de
 Cc: freebsd-questions@freebsd.org
 Subject: Re: before new version
 Message-ID: 201211031720.27182.lum...@gmail.com
 Content-Type: Text/Plain;  charset=iso-8859-1

 On Saturday 03 November 2012 14:11:22 you wrote:

  BTW: packages are almost all the time outdated.

 The packages in the RELEASE directory and on the installation
 media meet the frozen ports tree (frozen _prior_ to the release
 date), so yes, they are a bit outdated, but they are considered
 mostly stable and usable when in use with what is distributed.
 On the server, both _those_ packages _and_ those in Latest/ (which
 are periodically built from the advancing ports tree after the
 release date) are often considered not _that_ current as if you
 would use CVS or SVN to obtain the bleeding edge latest ports
 tree and build from source.

 I didn't complain about bleeding edge sofware which we anywhere don't
 have
 (Gimp, Xorg, LibreOffice and all dependencies for those applications and
 more
 and more which I don't use and I don't need) but I complain about freezing
 ports too early before new release came out and after that rebuilt 5000
 ports
 for example just because png new version is coming out. Or am I wrong?

 So yes, you could say what you said. :-)

 Mitja

 http://www.redbubble.com/people/lumiwa

Your complaint seems to be unfair to me as this is the first time -- as
far as I remember -- that the ports freeze was implemented only for RC2
but not already for RC1. So, the tree is certainly not frozen too
early.

C-S

___
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

Why PostgreSQL doesn't start with shared_buffers=6GB ?

2012-11-04 Thread Yuri


When I am setting shared_buffers=6GB in postgresql.conf it fails to start:
DETAIL:  Failed system call was shmget(key=5432001, size=6612361216, 03600).
even though kern.ipc.shmmax is set to ~7GB:
$ sysctl -a | grep shm
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 0
kern.ipc.shmall: 1310720
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 70
kern.features.sysv_shm: 1
kern.features.posix_shm: 1

There are 17GB free memory as reported by top(1).

Why shmget fails despite kern.ipc.shmmax is being high enough?
Experimentally I found that shared_buffers=5GB also fails but 4GB 
succeeds. Is there another system limit on shmem besides kern.ipc.shmmax ?


9.1-RC3 and64

Yuri
___
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

Questions about dump/restore to/from DVD media


I would like to make a backup of one of my systems using dump(8) in order
to be sure that I get everything, including all of the obscure file attribute
bits.

I would like to make this backup to a _minimal_ number of DVD+R disks.

What's the proper procedure for this?

In the dump(8) man page, I see the following example:

  /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

There are several problems with this example, as far as I am concerned.

First I have no particular interest in, or need for _either_ an ISO 9660
_or_ a UDF file system on my backup media.  And in fact, that seems to me
as if it is likely to be an utter waste of (precious) space on the backup
media.  Can't I just put the output of the dump command _directly_ onto
the output DVD+R media?  If so, how would I do this?  Would a command
such as the following work?

   /sbin/dump -0u  -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u

If not, why not?  (I  already know for sure that I can _read_ everything
off of a DVD+R using just dd, so it seems logical that I should likewise
be able to write an entire CD using just dd, but I suspect that there may
be more to it that this, since I've never seen any references or examples
anywhere of anybody writing either CDs or DVDs using dd.)

Actually, I just noticed in the dump manpage the -f option.  So would this
work in place of the above command line?

   /sbin/dump -0u  -L -C16 -B4589840 -f /dev/acd0 /u

And if THAT works, then can dump properly sense the actual end-of-media on
/dev/acd0, so that the -B option can just be ommitted?

Another issue is that I most definitely want to use an absolute minimum
of DVD+Rs to store the dump.  So I am wondering how I might be able to
wedge gzip into this whole process.  Could I do something like this?  If
not, why not?

   /sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u

Lastly, I want to make a backup of one entire _system_... not just one of
the several partitions that compose that system.  How exactly can I do
this?  I mean sure, I can back up each partition separately, using dump,
one at a time, but if I do that then the logical implication would seem
to be that on the last DVD+R used to make a backup of each of the partitions,
there could possibly be a lot of unused/wasted space which could have been
used to store the first part of the dump for the next partition in turn.
Is there any way to effectively deal with _this_ issue?


Regards,
rfg
___
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: Questions about dump/restore to/from DVD media

On Sun, 04 Nov 2012 16:56:58 -0800, Ronald F. Guilmette wrote:
 
 I would like to make a backup of one of my systems using dump(8) in order
 to be sure that I get everything, including all of the obscure file attribute
 bits.

That eliminates at least some tools. I have been using a similar
idea in the past to make a backup of a system using multiple CD-Rs
and I think cpio or pax, but only for data files that do not come
with the whole range of special attributes. Oh wait, it was afio,
on FreeBSD 4...



 I would like to make this backup to a _minimal_ number of DVD+R disks.

If you think you can add compression to your files (if it makes
sense), it should be incorporated to the command.



 What's the proper procedure for this?
 
 In the dump(8) man page, I see the following example:
 
   /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u
 
 There are several problems with this example, as far as I am concerned.
 
 First I have no particular interest in, or need for _either_ an ISO 9660
 _or_ a UDF file system on my backup media.  And in fact, that seems to me
 as if it is likely to be an utter waste of (precious) space on the backup
 media.  Can't I just put the output of the dump command _directly_ onto
 the output DVD+R media? 

I think this command exactly does this. Your idea is correct: There
is no need for ISO-9660 or UDF on backup media as it will not be
mounted, but processed with the proper restore tool.

The command growisofs -Z /dev/cd0=file will record the file like
an image to the media. In most cases, that would be an ISO-9660 file
system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered
file stuff.iso). In _this_ case, the input data is read directly from
file descriptor 0, stdin. Whatever appears there, it will be written
to the media. Here it is dump's output data stream.



 If so, how would I do this?  Would a command
 such as the following work?
 
/sbin/dump -0u  -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u
 
 If not, why not? 

As far as I know, direct device access for writing does not work here.
There are some operating systems that support an approach like this
(IRIX for example, if I remember correctly), but FreeBSD doesn't.

Depending on your OS version, acd0 != cd0 might appear, being different
in access method, i. e. ATAPI vs. ATAPICAM (SCSI over ATA).



 Actually, I just noticed in the dump manpage the -f option.  So would this
 work in place of the above command line?
 
/sbin/dump -0u  -L -C16 -B4589840 -f /dev/acd0 /u
 
 And if THAT works, then can dump properly sense the actual end-of-media on
 /dev/acd0, so that the -B option can just be ommitted?

I've never tried if /dev/acd0 (or /dev/cd0 for the reason mentioned
above) would be able to start a writing session by receiving data
in that kind of way. The -f option is typically used to send data to
files, or to - to hand them to another program or pipeline. It seems
that doing so for devices (and causing the _physical_ devices to do
something with it) is not possible.



 Another issue is that I most definitely want to use an absolute minimum
 of DVD+Rs to store the dump.  So I am wondering how I might be able to
 wedge gzip into this whole process.  Could I do something like this?  If
 not, why not?
 
/sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u

Taking the initial approach of

/sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

it could be something like this:

/sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u

Not tested, just an idea. Just check how -P interacts with /dev/fd/0
and - for stdin _within_ the pipe command.



 Lastly, I want to make a backup of one entire _system_... not just one of
 the several partitions that compose that system.  How exactly can I do
 this? 

At least not with dump. The dump utility operates on file systems,
this means it takes partitions as input. Whatever is _one_ partition
can be processed per step. Maybe you could concatenate runs of
dump of all the present partitions; however it will be a bit more
complicated to restore them using the restore program, which reads
file system dumps and outputs the data to initialized and mounted
file systems.



 I mean sure, I can back up each partition separately, using dump,
 one at a time, but if I do that then the logical implication would seem
 to be that on the last DVD+R used to make a backup of each of the partitions,
 there could possibly be a lot of unused/wasted space which could have been
 used to store the first part of the dump for the next partition in turn.

Yes, that is quite possible. In this case, using dd would maybe be
better. You would use it to copy the whole disk containing all the
partitions, add gzip, break it into multi-volume parts and then
record it to DVD+R.



 Is there any way to effectively deal with _this_ issue?

Not per se, but I think all the required parts are in the system,
it's just the

Re: Character set conversion, locales, UTF-8, etc

On Sun, 4 Nov 2012 13:36:58 -0500, grarpamp wrote:
 As an aside, why does FreeBSD seem to default to the above locale
 instead of say, en_US.UTF-8 ?

FreeBSD's file system does not default to any locale, as far as I
know. The system is agnostic to what the characters in the file
name mean or what symbol they should represent. It's up to the
console font and terminal emulator and font display what you can
see on your screen. In text mode, this is limited and typically
restricted to the fonts included with the system, having to meet
the proper LC_ settings (e. g. de_DE.ISO8859-1 plus iso-8x8/14/16
if you want german characters like umlauts and eszett). There is
no real UTF-8 support on the console. For example, files with
chinese characters will show up as ??. In X, with
a different than expected locale, funny characters will
typically appear, like A~.1/4..X° upside-down question mark. :-)

That being said, it's up to the application programs (and if it's
just the terminal emulator displaying the output of ls) to deal
with multibyte sequences. They are _valid_ in file names. The
many problems they cause should make programmers pay attention
on if and how to use them. :-)

There isn't much you can do on file system level except renaming
the files: write a program that reads the file names according
to the preferred interpretation and write new names for them,
being more portable (e. g. by translating problematic characters
into such that are less problematic).




-- 
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

AoE vblade reporting size 0

2012-11-04 Thread FBSD UG

Hello,


I'm trying to export a disk on FreeBSD 9.0-R4
over AoE (ATA over Ethernet) using vblade from
ports.

I run this as root:
# vblade 1 1 em0 /dev/ada1

and the system returns this:

  ioctl returned -1
  0 bytes
  pid 2629: e1.1, 0 sectors O_RDWR


The drive nicely shows up on OSX and Linux as
e1.1 but is has size 0 bytes and thus unusable.

Has anyone successfully export a disk using AoE
on FreeBSD that can shed some light on what I might
be doing wrong? How do i get it to export the disk
as 230 GB, the size of the disk?

thanks in advance,

Arno Beekman
___
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: Questions about dump/restore to/from DVD media

2012-11-04 Thread Mehmet Erol Sanliturk

On Sun, Nov 4, 2012 at 4:56 PM, Ronald F. Guilmette
r...@tristatelogic.comwrote:


 I would like to make a backup of one of my systems using dump(8) in order
 to be sure that I get everything, including all of the obscure file
 attribute
 bits.

 I would like to make this backup to a _minimal_ number of DVD+R disks.

 What's the proper procedure for this?

 In the dump(8) man page, I see the following example:

   /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

 There are several problems with this example, as far as I am concerned.

 First I have no particular interest in, or need for _either_ an ISO 9660
 _or_ a UDF file system on my backup media.  And in fact, that seems to me
 as if it is likely to be an utter waste of (precious) space on the backup
 media.  Can't I just put the output of the dump command _directly_ onto
 the output DVD+R media?  If so, how would I do this?  Would a command
 such as the following work?

/sbin/dump -0u  -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u

 If not, why not?  (I  already know for sure that I can _read_ everything
 off of a DVD+R using just dd, so it seems logical that I should likewise
 be able to write an entire CD using just dd, but I suspect that there may
 be more to it that this, since I've never seen any references or examples
 anywhere of anybody writing either CDs or DVDs using dd.)

 Actually, I just noticed in the dump manpage the -f option.  So would this
 work in place of the above command line?

/sbin/dump -0u  -L -C16 -B4589840 -f /dev/acd0 /u

 And if THAT works, then can dump properly sense the actual end-of-media on
 /dev/acd0, so that the -B option can just be ommitted?

 Another issue is that I most definitely want to use an absolute minimum
 of DVD+Rs to store the dump.  So I am wondering how I might be able to
 wedge gzip into this whole process.  Could I do something like this?  If
 not, why not?

/sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u

 Lastly, I want to make a backup of one entire _system_... not just one of
 the several partitions that compose that system.  How exactly can I do
 this?  I mean sure, I can back up each partition separately, using dump,
 one at a time, but if I do that then the logical implication would seem
 to be that on the last DVD+R used to make a backup of each of the
 partitions,
 there could possibly be a lot of unused/wasted space which could have been
 used to store the first part of the dump for the next partition in turn.
 Is there any way to effectively deal with _this_ issue?


 Regards,
 rfg





Assume one file will NOT be copied more than ONE DVD , i.e. , each file
will be completely recorded on one DVD :

http://en.wikipedia.org/wiki/Cutting_stock_problem


Thank you very much .

Mehmet Erol Sanliturk
___
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: Questions about dump/restore to/from DVD media

2012-11-04 Thread Da Rock

On 11/05/12 11:18, Polytropon wrote:
 On Sun, 04 Nov 2012 16:56:58 -0800, Ronald F. Guilmette wrote:
 I would like to make a backup of one of my systems using dump(8) in order
 to be sure that I get everything, including all of the obscure file attribute
 bits.
 That eliminates at least some tools. I have been using a similar
 idea in the past to make a backup of a system using multiple CD-Rs
 and I think cpio or pax, but only for data files that do not come
 with the whole range of special attributes. Oh wait, it was afio,
 on FreeBSD 4...



 I would like to make this backup to a _minimal_ number of DVD+R disks.
 If you think you can add compression to your files (if it makes
 sense), it should be incorporated to the command.



 What's the proper procedure for this?

 In the dump(8) man page, I see the following example:

   /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

 There are several problems with this example, as far as I am concerned.

 First I have no particular interest in, or need for _either_ an ISO 9660
 _or_ a UDF file system on my backup media.  And in fact, that seems to me
 as if it is likely to be an utter waste of (precious) space on the backup
 media.  Can't I just put the output of the dump command _directly_ onto
 the output DVD+R media? 
 I think this command exactly does this. Your idea is correct: There
 is no need for ISO-9660 or UDF on backup media as it will not be
 mounted, but processed with the proper restore tool.

 The command growisofs -Z /dev/cd0=file will record the file like
 an image to the media. In most cases, that would be an ISO-9660 file
 system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered
 file stuff.iso). In _this_ case, the input data is read directly from
 file descriptor 0, stdin. Whatever appears there, it will be written
 to the media. Here it is dump's output data stream.



 If so, how would I do this?  Would a command
 such as the following work?

/sbin/dump -0u  -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u

 If not, why not? 
 As far as I know, direct device access for writing does not work here.
 There are some operating systems that support an approach like this
 (IRIX for example, if I remember correctly), but FreeBSD doesn't.

 Depending on your OS version, acd0 != cd0 might appear, being different
 in access method, i. e. ATAPI vs. ATAPICAM (SCSI over ATA).



 Actually, I just noticed in the dump manpage the -f option.  So would this
 work in place of the above command line?

/sbin/dump -0u  -L -C16 -B4589840 -f /dev/acd0 /u

 And if THAT works, then can dump properly sense the actual end-of-media on
 /dev/acd0, so that the -B option can just be ommitted?
 I've never tried if /dev/acd0 (or /dev/cd0 for the reason mentioned
 above) would be able to start a writing session by receiving data
 in that kind of way. The -f option is typically used to send data to
 files, or to - to hand them to another program or pipeline. It seems
 that doing so for devices (and causing the _physical_ devices to do
 something with it) is not possible.



 Another issue is that I most definitely want to use an absolute minimum
 of DVD+Rs to store the dump.  So I am wondering how I might be able to
 wedge gzip into this whole process.  Could I do something like this?  If
 not, why not?

/sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u
 Taking the initial approach of

 /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

 it could be something like this:

 /sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u

 Not tested, just an idea. Just check how -P interacts with /dev/fd/0
 and - for stdin _within_ the pipe command.



 Lastly, I want to make a backup of one entire _system_... not just one of
 the several partitions that compose that system.  How exactly can I do
 this? 
 At least not with dump. The dump utility operates on file systems,
 this means it takes partitions as input. Whatever is _one_ partition
 can be processed per step. Maybe you could concatenate runs of
 dump of all the present partitions; however it will be a bit more
 complicated to restore them using the restore program, which reads
 file system dumps and outputs the data to initialized and mounted
 file systems.



 I mean sure, I can back up each partition separately, using dump,
 one at a time, but if I do that then the logical implication would seem
 to be that on the last DVD+R used to make a backup of each of the partitions,
 there could possibly be a lot of unused/wasted space which could have been
 used to store the first part of the dump for the next partition in turn.
 Yes, that is quite possible. In this case, using dd would maybe be
 better. You would use it to copy the whole disk containing all the
 partitions, add gzip, break it into multi-volume parts and then
 record it to DVD+R.



 Is there any way to effectively deal with _this_ issue?
 Not per se, but I

Re: Questions about dump/restore to/from DVD media


In message caogwamvoncti7akmtjw0+caastfhfae5gw+pkmh+4ldr00-...@mail.gmail.com
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote:

Assume one file will NOT be copied more than ONE DVD , i.e. , each file
will be completely recorded on one DVD :

http://en.wikipedia.org/wiki/Cutting_stock_problem

The problem you cited is an interesting one, but I do not believe that
it is at all relevant to the current discussion for the simple reason
that this cutting problem is based on the assmption that one thing
(e.g. a cut piece of paper) cannot be spread across two or more of the
available units of raw material (e.g. a standard roll of paper).

I'm sure that is true for paper, but as regards to FreeBSD partition
backups, these have always been allowed to cross output volume boundaries,
I think, e.g. spilling off the end of one backup tape and onto the beginning
of the next backup tape.


Regards,
rfg
___
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: Questions about dump/restore to/from DVD media


In message 20121105021817.fc5bff1b.free...@edvax.de, 
Polytropon free...@edvax.de wrote:

 I would like to make this backup to a _minimal_ number of DVD+R disks.

If you think you can add compression to your files (if it makes
sense), it should be incorporated to the command.

Yes.  There really ought to be a -z option integrated into both dump and
restore commands.

The command growisofs -Z /dev/cd0=file will record the file like
an image to the media. In most cases, that would be an ISO-9660 file
system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered
file stuff.iso). In _this_ case, the input data is read directly from
file descriptor 0, stdin. Whatever appears there, it will be written
to the media.

Ah!  OK.  I see now.  Thank you.


 If so, how would I do this?  Would a command
 such as the following work?
 
/sbin/dump -0u  -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u
 
 If not, why not? 

As far as I know, direct device access for writing does not work here.

Yes, apparently not.  Bit I _did_ just find something rather interesting
in this context.  Look at this:

http://sg.danny.cz/sg/ddpt.html

I have no idea why it isn't already in the ports tree.

I'll probably try it out and see if it works.

 Another issue is that I most definitely want to use an absolute minimum...

Taking the initial approach of

/sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u

it could be something like this:

/sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u

Yes.  I see.  That makes sense.

But as I said (above) to make this really work right, dump  restore really
need to have -z options, and do the zipping/unzipping internally.  Only
if this were available could dump properly deal with end-of-media on any
given output volume, I think.

 Lastly, I want to make a backup of one entire _system_... not just one of
 the several partitions that compose that system.  How exactly can I do
 this? 

At least not with dump. The dump utility operates on file systems,
this means it takes partitions as input. Whatever is _one_ partition
can be processed per step.

Well, this is entirely sub-optimal.

(I hate to say it, because in general I loath  despise Windows, but even
Windows has a built-in facility for making a single backup of an _entire_
system, and in a single step, *and*, I presume in a space-efficient manner.)

___
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: Questions about dump/restore to/from DVD media

On Sun, 04 Nov 2012 18:37:43 -0800, Ronald F. Guilmette wrote:
 
 In message 20121105021817.fc5bff1b.free...@edvax.de, 
 Polytropon free...@edvax.de wrote:
 
  I would like to make this backup to a _minimal_ number of DVD+R disks.
 
 If you think you can add compression to your files (if it makes
 sense), it should be incorporated to the command.
 
 Yes.  There really ought to be a -z option integrated into both dump and
 restore commands.

Depending on _what_ kind of compression (gzip, bzip2, 7zip, xz etc.)
there might be many of them. If utilizing the capabilities of
libarchive is possible, it would be a nice option.



  Another issue is that I most definitely want to use an absolute minimum...
 
 Taking the initial approach of
 
 /sbin/dump -0u  -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u
 
 it could be something like this:
 
 /sbin/dump -0u  -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u
 
 Yes.  I see.  That makes sense.
 
 But as I said (above) to make this really work right, dump  restore really
 need to have -z options, and do the zipping/unzipping internally.  Only
 if this were available could dump properly deal with end-of-media on any
 given output volume, I think.

The problem is that delegating compression to a sub-task would
imply that dump cannot precisely adjust its output to match the
media size (as the limit is now defined by how good the compression
works). Instead an additional step would be required to make sure
that a new media for the _compressed_ data stream is requested
when it exceeds a certain limit. Additionally restore would have
to use a comparable method of chaining the multiple volumes,
as it requires operator attention and action.



  Lastly, I want to make a backup of one entire _system_... not just one of
  the several partitions that compose that system.  How exactly can I do
  this? 
 
 At least not with dump. The dump utility operates on file systems,
 this means it takes partitions as input. Whatever is _one_ partition
 can be processed per step.
 
 Well, this is entirely sub-optimal.

It depends on how you did layout your system. Using dump + restore
means to operate on partitions. Make the system one partition - deal
with one partition. Make many partitions - need to deal with them
individually.



 (I hate to say it, because in general I loath  despise Windows, but even
 Windows has a built-in facility for making a single backup of an _entire_
 system, and in a single step, *and*, I presume in a space-efficient manner.)

That would be a task for dd. :-)


-- 
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: Questions about dump/restore to/from DVD media


In message 50971b88.40...@herveybayaustralia.com.au, 
Da Rock freebsd-questi...@herveybayaustralia.com.au wrote:

Also, you may have considered this already (or not :) ), but you are
using a direct write to backup your system, and then considering
compression on top of that. CD/DVD filesystems incorporate some parity
to allow for defects and scratches, so growisofs might be best to use to
ensure some integrity to your data.

Minimising your space may be good, but a single bit could render all
your efforts for nought- especially given the compression leaves no room
for error ;)

I'm not sure if the error detection/correction on DVDs... either -Rs
or +Rs... is a function of the _filesystem_.  In fact I don't believe
that it is, but I could be wrong.

Google for this:

DVD+R error correction

and there are plenty of references.  The ones that I read in the past
seemed to suggest that the error detection/correction is a fundamental
aspect of how data gets written to both -R and +R disks, totally independent
of whether the data being written was organized into any type of filesystem
or none at all.

In fact, part of the reason that I only use DVD+Rs these days is because
I read something that said that something like 1/4 of every block of data
on DVD-R disks is not even covered by any error correction code AT ALL.

Ah, yes... here is one such reference:

 http://adterrasperaspera.com/blog/2006/10/30/how-to-choose-cddvd-archival-media

The DVD-R specification states that for every 192 bits, 64 of them are
not protected under any scheme, 24 of them are protected by 24 bits of
parity, and the last 56 bits are protected by another 24 bits of parity.
This weird (to put it mildly) scheme allows you to easily scramble or
lose 25% of the data that is required to read your disk! This information
is almost more important than the actual data burned on the disc itself.

The DVD+R specification, however, states that for every 204 bits of
information, it is split into four blocks of 52 bits containing 1 sync
bit to prevent misreading because of phase changes, 31 bits of data,
and a 20 bit parity (that protects all 32 bits of data)...


Regards,
rfg
___
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: Questions about dump/restore to/from DVD media


In message 20121105035233.e3c4ae8a.free...@edvax.de, 
Polytropon free...@edvax.de wrote:

 But as I said (above) to make this really work right, dump  restore really
 need to have -z options, and do the zipping/unzipping internally.  Only
 if this were available could dump properly deal with end-of-media on any
 given output volume, I think.

The problem is that delegating compression to a sub-task would
imply that dump cannot precisely adjust its output to match the
media size (as the limit is now defined by how good the compression
works).

Correct.  We have both just said the exact same thing in different ways.

In order to have _compression_ of the dump data _and_ still be able to
divide the (post-compression) data into nice proper 2KB chunks (as required
for DVD+/-R writing) the compression step itself would need to be integrated
into the dump program itself (and then, for symmetry, if for no other
reason, into restore as well).

Using dump + restore
means to operate on partitions. Make the system one partition - deal
with one partition. Make many partitions - need to deal with them
individually.

Good point.

 (I hate to say it, because in general I loath  despise Windows, but even
 Windows has a built-in facility for making a single backup of an _entire_
 system, and in a single step, *and*, I presume in a space-efficient manner.)

That would be a task for dd. :-)

Sorry?  I am not following you.

How could dd ever substitute for the intelligence of dump(8), and specifically
how could it avoid copying of blocks that are ``in'' the filesystem but which
are not currently _allocated_ by the filesystem?

(I am also not persuaded the dd could handle multiple partitions any better
that dump(8) currently does... which is to say not at all, really.)


Regards,
rfg
___
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: Questions about dump/restore to/from DVD media

On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote:
 
 In message 20121105035233.e3c4ae8a.free...@edvax.de, 
 Polytropon free...@edvax.de wrote:
 
  But as I said (above) to make this really work right, dump  restore really
  need to have -z options, and do the zipping/unzipping internally.  Only
  if this were available could dump properly deal with end-of-media on any
  given output volume, I think.
 
 The problem is that delegating compression to a sub-task would
 imply that dump cannot precisely adjust its output to match the
 media size (as the limit is now defined by how good the compression
 works).
 
 Correct.  We have both just said the exact same thing in different ways.
 
 In order to have _compression_ of the dump data _and_ still be able to
 divide the (post-compression) data into nice proper 2KB chunks (as required
 for DVD+/-R writing) the compression step itself would need to be integrated
 into the dump program itself (and then, for symmetry, if for no other
 reason, into restore as well).

Chunk size _and_ media size matter (as dump would have to know
when the media is expected to be nearly-full _with_ compression)
because the operator will be required to deal with multi-volume
media (next DVD).



  (I hate to say it, because in general I loath  despise Windows, but even
  Windows has a built-in facility for making a single backup of an _entire_
  system, and in a single step, *and*, I presume in a space-efficient 
  manner.)
 
 That would be a task for dd. :-)
 
 Sorry?  I am not following you.
 
 How could dd ever substitute for the intelligence of dump(8), and specifically
 how could it avoid copying of blocks that are ``in'' the filesystem but which
 are not currently _allocated_ by the filesystem?

It cannot. :-)

With dd, you could copy a disk including all aspects of the
present slices and partitions (including file attributes and
partitioning data, even boot elements), but it would maybe
require a subsequent read and compare step to make sure
that everything went well.



 (I am also not persuaded the dd could handle multiple partitions any better
 that dump(8) currently does... which is to say not at all, really.)

It can - depending on what device you're reading from.

Examples:

dd if=/dev/ad0s1a   - the root partition
dd if=/dev/ad0s1- the 1st slice
dd if=/dev/ad0  - the whole disk

However, dd is very much bare metal and cannot handle multiple
volumes and compression natively. It would be neccessary to have
all those functionalities scripted additionally.




-- 
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: Questions about dump/restore to/from DVD media

2012-11-04 Thread Da Rock

On 11/05/12 14:14, Polytropon wrote:
 On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote:
 In message 20121105035233.e3c4ae8a.free...@edvax.de, 
 Polytropon free...@edvax.de wrote:

 But as I said (above) to make this really work right, dump  restore really
 need to have -z options, and do the zipping/unzipping internally.  Only
 if this were available could dump properly deal with end-of-media on any
 given output volume, I think.
 The problem is that delegating compression to a sub-task would
 imply that dump cannot precisely adjust its output to match the
 media size (as the limit is now defined by how good the compression
 works).
 Correct.  We have both just said the exact same thing in different ways.

 In order to have _compression_ of the dump data _and_ still be able to
 divide the (post-compression) data into nice proper 2KB chunks (as required
 for DVD+/-R writing) the compression step itself would need to be integrated
 into the dump program itself (and then, for symmetry, if for no other
 reason, into restore as well).
 Chunk size _and_ media size matter (as dump would have to know
 when the media is expected to be nearly-full _with_ compression)
 because the operator will be required to deal with multi-volume
 media (next DVD).



 (I hate to say it, because in general I loath  despise Windows, but even
 Windows has a built-in facility for making a single backup of an _entire_
 system, and in a single step, *and*, I presume in a space-efficient 
 manner.)
 That would be a task for dd. :-)
 Sorry?  I am not following you.

 How could dd ever substitute for the intelligence of dump(8), and 
 specifically
 how could it avoid copying of blocks that are ``in'' the filesystem but which
 are not currently _allocated_ by the filesystem?
 It cannot. :-)

 With dd, you could copy a disk including all aspects of the
 present slices and partitions (including file attributes and
 partitioning data, even boot elements), but it would maybe
 require a subsequent read and compare step to make sure
 that everything went well.



 (I am also not persuaded the dd could handle multiple partitions any better
 that dump(8) currently does... which is to say not at all, really.)
 It can - depending on what device you're reading from.

 Examples:

   dd if=/dev/ad0s1a   - the root partition
   dd if=/dev/ad0s1- the 1st slice
   dd if=/dev/ad0  - the whole disk

 However, dd is very much bare metal and cannot handle multiple
 volumes and compression natively. It would be neccessary to have
 all those functionalities scripted additionally.
For reference, if one did backup the whole slice/disk using dd and then
compressed the data, would that effectively compress all those
'unallocated' nodes?
___
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

general ports config question

2012-11-04 Thread Gary Aitken

I've been wanting gimp 2.8.0 (now 2.8.2) for a bit and as it's been slow to 
show up in the ports collection, thought I would see about building it.
Unfortunately, I don't know squat about the process but figured trying it 
would help slow my brain from atrophying at its currently rapidly accelerating 
pace.

Not wanting to disrupt the current environment (gimp 2.6 built from ports), 
I wanted to build 2.8 someplace else.  
Since gimp-2.8.2 requires babl-0.1.10, I thought I'd start there.

It's not clear to me what params or environment variables to set
prior to running ./configure to generate a Makefile which will cause it to
use newly built stuff in preference, 
but still find installed stuff if necessary
and then install in a different place.

Just doing ./configure and then make craps out with 
  Making all in babl
  Makefile, line 959: Missing dependency operator
which is a line which says:
  -include $(INTROSPECTION_MAKEFILE)
which is defined empty

Looking at the installed version of babl (babl-0.1.6), 
this and other symbols are all defined to be something out of /usr/local
which leads me to think I'm missing something pretty basic.

hints?

Thanks,

Gary
___
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: Booting 2nd(!) FreeBSD installation sitting on same disk

2012-11-04 Thread Andre Albsmeier

On Sat, 03-Nov-2012 at 23:34:48 +0100, jb wrote:
 Andre Albsmeier Andre.Albsmeier at siemens.com writes:
 
  ... 
  However, when pressing F3, the system of slice 2(!) is  
  loaded. This is due to the fact that boot1 always loads
  the first active FreeBSD slice ;-(.
  ... 
  Is there no chance to actually honour the fact that F3 was
  pressed and boot from slice 3 without updating the MBR before?
 
 I do not know the story of active slice in FreeBSD, but I know that neither
 Windows nor Linux require active partitions (in their jargon) to boot from any
 more.

If course FreeBSD doesn't rely on being started from an active
slice. Otherwise playing with currdev in loader wouldn't work.
It is just boot1 which causes the problem since it always searches
the MBR partition (slice) table for the first active FreeBSD slice
and if it doesn't find one it starts over again and searches for
any FreeBSD slice.

The problem is that boot1 doesn't get the information which F-key
was pressed in boot0 directly. It does only in case you allow a
write-back of the MBR using -o update with boot0cfg.

I made an ugly hack for this by patching boot1 code of slice 3
in a way that it actually searches for IN(!)active partitions in
its first pass:

--- sys/boot/i386/boot2/boot1.S.ORI 2012-09-23 22:07:16.0 +0200
+++ sys/boot/i386/boot2/boot1.S 2012-11-05 07:16:29.0 +0100
@@ -151,7 +151,11 @@
jne main.3  # No
jcxz main.5 # If second pass
testb $0x80,(%si)   # Active?
+#ifdef AA_SKIP_ACTIVE_BSDSLICE
+   jz main.5   # No
+#else
jnz main.5  # Yes
+#endif
 main.3:add $0x10,%si   # Next entry
incb %dh# Partition
cmpb $0x1+PRT_NUM,%dh   # In table?


Since this code only sits in boot1 of slice 3 it just applies to
slice 3.

The proper fix would be to pass the information about the key pressed
in boot0 to boot1 directly via registers of by whatever means...

-Andre
___
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: Questions about dump/restore to/from DVD media

2012-11-04 Thread Robert Bonomi

 Date: Mon, 05 Nov 2012 15:42:45 +1000
 From: Da Rock freebsd-questi...@herveybayaustralia.com.au
 Subject: Re: Questions about dump/restore to/from DVD media

 On 11/05/12 14:14, Polytropon wrote:
 For reference, if one did backup the whole slice/disk using dd and then 
 compressed the data, would that effectively compress all those
 'unallocated' nodes?

NO.  The unallocated' blocks still have whatever data was in them.

*IF* you copy /dev/zero to a new file, to fill the disk, then rm
-that- file, the compression will be higher.  'How much' depends on
how empty the disk is.

___
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 9.1 and SU+J