dump-users

Re: [Dump-users] Re: st driver's buffer corrupting multivolume dumps

[Eric J. <eje...@sw...>]

Hi Brent,

Thanks very much for posting this.  One request for clarification:

Do those options need to be cleared before *writing* the dump, or only
when trying restore the dump?  I suspect the former, but wanted to
check. 

Also (and please forgive my ignorance of this topic), is there a
straightforward way to see what options are set for the drive already?
It wasn't obvious in the 'mt' man page.  Finally, I assume that these
options would need to be set/cleared after each reboot, but not in
between?

Thanks very much,

Eric

[Dump-users] Re: st driver's buffer corrupting multivolume dumps

[Brent B. <br...@ke...>]

Since some of you said to write back if I found a solution...

After much searching, I did finally find the way to make multivolume 
archives reliable instead of corrupting at the end-of-tape points.  It 
was back in the archives of this list, but was only mentioned there once 
and never again, so...

mt stclearoptions async-writes buffer-writes

I did this, and a 'restore -C' verified good across a 4-volume set of 
tapes.  It makes me wonder if this problem is actually the reason that 
Amanda can't span tapes -- perhaps the developers never did get around 
this issue with the st tape driver, and gave up.  (Officially, the word 
on Amanda is that you can't -- is this the only thing stopping them?)

-- 
+ Brent A. Busby,   UNIX Systems Admin	 +   "It's like being	+
+ James Franck / Enrico Fermi Institute	 +    blindsided by a	+
+     The University of Chicago		 +    flying dwarf..."	+

[Dump-users] This one will go crazy on Wend

[Nigel G. <dr...@eb...>]

St ock Alert
iPackets International, Inc.
Global Developer and Provider of a Wide Range of Wireless and Communications
Solutions for Selected Enterprises Including Mine-Safety (Source: News
1/3/06)
OTC: IPKL

Price: .35

Huge PR For Wednesday is Underway on IPKL. Short/Day Trading Opportunity for
You? Sometimes it is Bang-Zoom on These Small st ocks..As Many of You may
Know


Recent News: Go Read the Full Stories Now!

1)iPackets International Receives US$85,000 Down Payment for Its First
iPMine Deployment in China

2)iPackets International Attends Several Mining Trade Shows and Receives
Tremendous Response for Its iPMine Mine-Safety Product


Watch This One Trade on Wednesday! Radar it Right Now..
_______________



Information within this email contains 4rward l00 king sta tements within
meaning of Section 27A of the Sec urities Act of nineteen thirty three and
Section 21B of the Se curities Exchange Act of nineteen thirty four. Any
statements that express or involve discussions with respect to predictions,
expectations, beliefs, plans, projections, objectives, goals, assumptions
future events or performance are not statements of historical fact and may
be 4rward 1o0king statements. 4rward looking statements are based on
ex pectations, es timates and pr ojections at the time the statements are
that involve a number of risks and uncertainties which could cause actual
results or events to differ materially from those presently
featured Com pany is not a reporting company under the SEC Act of 1934 and
there is limited information available on the company. The Co-mpany has a
nominal ca sh position.It is an operating company. The company is going to
need financing. If that financing does not occur, the company may not be
able to continue as a going concern in which case you could lose your
in-vestment. The pu blisher of this new sletter does not represent that the
information contained in this  mes sage states all material facts or does
not omit a material fact necessary to make the statements therein not
misleading. All information provided within this e_ mail pertaining to
in-vesting, st 0cks, se curities must be understood as information provided
and not inv estment advice. Remember a thorough due diligence effort,
including a review of a company's filings when available, should be
completed  prior to in_vesting. The pub lisher of this news letter advises
all readers and subscribers to seek advice from a registered professional
securities representative before deciding to trade in st0cks featured
this e mail. None of the material within this report shall be construed as
any kind of in_vestment advice or solicitation. Many of these com panies
on the verge of bankruptcy. You can lose all your mony by inv esting in
st 0ck. The publisher of this new sletter is not a registered in-vestment
advis0r. Subscribers should not view information herein as legal, tax,
accounting or inve stment advice. In com pliance with the Securities Act of
nineteen thirty three, Section 17(b),The publisher of this newsletter is
contracted to receive fifteen th0 usand d0 l1ars from a third party, not an
off icer, dir ector or af filiate shar eh0lder for the ci rculation of this
report. Be aware of an inherent conflict of interest resulting from such
compensation due to the fact that this is a paid advertisement and is not
without bias. All factual information in this report was gathered from
public sources, including but not limited to  Co mpany Press Releases. Use
of the information in this e mail constitutes your acceptance of these
terms.

[Dump-users] news

[Everett H. <pfq...@pa...>]

KOKO PETROLEUM (KKPT) - THIS STOCK IS UNDISCOVERED S T O C K GEM

Current Price: 1.20

Symbol - KKPT

Watch out the stock go crazy tomorrow morning

KOKO Petroleum, Inc. (KKPT) issued an update on its working interest investment in two wells in the prolific Barnett Shale Play located in northern Texas.

Under the terms of the participation agreement with Rife Energy Operating, Inc. (the program's operator), KOKO Petroleum has acquired a minority working interests (approx. 10%) in the drilling and completion of two wells; the Boyd #1 and the Inglish #2 both of which have been drilled but not yet completed. The operator is in the process of setting casing on the Inglish 2 and the Boyd is awaiting a sufficient water supply to start the completion.

Due to the heavy influx of major operators in the area (Encana and XTO), scheduling completions and any other types of oil field services has been very difficult. Operators in the area have had to schedule well completions three to four months in advance. This coupled with the fact that Northern Texas has experienced a major drought causing serious shortfalls of local water. Rife, as an alternative, has drilled a water well, which was the source of drilling water for the Inglish 2 and Boyd 1. Rife has five wells that have been drilled and are awaiting completions.

The Barnett Shale is the largest natural gas play in Texas. It is presently producing 900 MMCF of gas per day and is considered one of the largest U.S. domestic natural gas plays with sizable, remaining resource potential. The first Barnett Shale wells were drilled and completed in the early 1980s by Mitchell Energy of Houston, Texas. According to an in-depth 2004 sector report on the Barnett Shale, developed by Morgan Stanley (MWD), the Barnett Shale play is estimated to hold reserves in the non-core area that could be as high as 150 BCF per 1,000 acres. The report estimated that because of the amount of gas available in the area, successful wells in the Barnett Shale should be economically viable in almost any gas price environment.
"The well logs are very encouraging, as were the wells they offset. Our operator is very resourceful and we should have these wells completed by the end of the year," says Ted Kozub, President of KOKO Petroleum, Inc.

On the Corsicana front, KOKO and its Partner have applied for the drilling permits to commence the first 15 Nacatoch wells, casing is being delivered to the site and drilling will commence upon receipt of the permits.

[Dump-users] Re: fridge emancipationist

[Candyce V. <can...@va...>]

=20
http://www.houwarni.com
=20
V
P
A
M
V
X
C
L
S
A
r
m
e
i
a
i
e
o
L
o
b
r
A
n
A
v
m
i
p
i
i
G
a
L
i
a
U
e
e
d
R
x
i
t
=20
M
c
n
i
A
=20
S
r
=20
=20
i
=20
a
=20
=20
=20
a
=20
=20
a
=20
=20
=20
=20
=20
=20
=20
 $8
 $6
 $6
 $9
 $6
 $1
 $9
 $9
 $7
5.45
4.95
8.00
9.95
9.95
23.45
9.95
9.95
5.95
=20
=20
=20
second confessional from the left. I walked over and pulled the curtain
and there you were. Dead. I thought youd just been killed and everything
was happening so fast. Carlos had to be there! He was within my reach,
my gun-or maybe I was within his. I raced around like a maniac and
finally I saw him! Out in the street in his priestly black clothes-I saw
him, I knew it was him because he saw me and started to run through the
traffic. And then I lost him, I lost him! ... But I had a card to play.
You. I passed the word-Laviers dead. ... It was just what I was supposed
to do, wasnt it? Wasnt it? I tell you again, you are wrong! The woman no
longer struggled; it was pointless. Instead, she remained rigid against
the wall, no part of her body moving, as if by doing so she might be
permitted to speak. Will you listen to me? she asked with difficulty,
Jasons forearm

[Dump-users] =?iso-2022-jp?B?GyRCPFVOaUonJCRBaj5sPmU+OhsoQg==?=

[<not...@ya...>]

☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
　　　２００５年１１月現在の逆援助謝礼￥平均相場

　　　　　・デートのみ　：　３０，０００円 
　　　　　　　　　　　　　　　　　
　　　　　・セックス込み：１２０，０００円 
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆

　これは、女性が男性へ支払う謝礼の相場です。
　女性によっては相場の３倍や４倍を男性へお渡しする方も
　いらっしゃるようです。

　詳しくは、下記ホームページをご覧下さい。
　http://sclass.cx/j/entry.html

　※紹介料、会員登録料は無料となっております。

□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■

　☆　ご登録手順です　☆

　 1.登録フォームを入力
　   ↓
   2.数名の女性会員様のお写真がお客様のメールに届きます
　 　↓
　 3.指名する
　 　↓
   4.本人と待ち合わせ
　 　↓
   5.やる事をやる

   実行する方はこちら
 　↓↓↓
 　http://sclass.cx/j/entry.html
             　　　　　　　　　　　　　　　　　 
□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■

※重要※
　謝礼の後払いはトラブルの元になりますので、必ず前払いで
　受け取ってください。

[Dump-users] Small Cap Express for dump-users

[Salas <rul...@kc...>]

A Must Watch ALERT Monday Dec 12th
Cash Now Corporation,

Symbol: CHNW
Price: .23
Up 0.14 (127.27%) on Thursday Dec 8th alone
Active (strong)

Volume Has Been Pretty Good. PR Program This Weekend Apprising Potential 
Investors of This One. A new PR campiagn will start Thursday. Get in before 
this starts for the best gains

News

Great news just released. This should really start to move!

The News

1) Payday Loan and Check-Cashing Leader Cash Now Offering Financing on 
Premium Autos for Those With Credit Challenges
   Market Wire (Thu, Dec 8)


2)Payday Loan Leader Cash Now Re-Launches Infomercials, Fueling Expansion of 
Licensees and Further Organic Growth
  Market Wire (Wed 10:00am)

3) Payday Loan Leader Cash Now Strengthens Infrastructure to Handle Increase 
in Business -- 'Scaling for the Future'
  Market Wire (Wed 10:00am)


DiscI_imer: Statements regarding fi_ancial matters in this pr_ss re1ease 
other than historical facts are ``f0rw_rd-lO0king statements'' within the 
meaning of se(tion 27 A of the S_curities A(t of 193 3, Se(tion 21 E of the 
Se(urities Ex(hange A(t of 1934, and as that term is defined in the Pr_vate 
Se(urities Litig_tion Ref orm A(t of 1995. The (ompany intends that such 
statements about the (ompany's future expe(tations, in(luding future 
revenues and e_rnings, and all other f0rward-l0Oking statements, be subje(t 
to the safe har bors created thereby. Since these statements (future ope 
rational results and s ales) involve ri sks and un(ertainties and are 
subject to (hange at any time, the (ompany's actu al re sults may differ 
materi ally from ex pected results.

Re: [Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[Stelian P. <st...@po...>]

Le vendredi 02 d=E9cembre 2005 =E0 14:09 +0100, Stelian Pop a =E9crit :
> Le samedi 26 novembre 2005 =E0 10:50 -0500, sb...@ab... a =E9crit :
> > I've tried compiling from the CVS. The problem still exists.
> >=20
> > It is a problem of going from kernel 2.6.14-1.1532_FC4 to 2.6.14-
> > 1.1637_FC4. There is no problem, if I run with the older kernel.
>=20
> Could you tell me the exact steps leading to the error ? Because I've
> tried and cannot reproduce the problem. Maybe there is no problem, it's
> just that the value of the EA tag is really different at restore time..=
.

Any news on that ? Did you have the time to do the tests ?

Stelian.
--=20
Stelian Pop <st...@po...>

Re: [Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[Stelian P. <st...@po...>]

Le samedi 26 novembre 2005 =E0 10:50 -0500, sb...@ab... a =E9crit :
> I've tried compiling from the CVS. The problem still exists.
>=20
> It is a problem of going from kernel 2.6.14-1.1532_FC4 to 2.6.14-
> 1.1637_FC4. There is no problem, if I run with the older kernel.

Could you tell me the exact steps leading to the error ? Because I've
tried and cannot reproduce the problem. Maybe there is no problem, it's
just that the value of the EA tag is really different at restore time...

This is what I do:

# uname -r
2.6.14-1.1637_FC4

# dump
dump 0.4b40 (using libext2fs 1.37 of 21-Mar-2005)
....

# getfattr -d -m . /boot/grub/minix_stage1_5
getfattr: Removing leading '/' from absolute path names
# file: boot/grub/minix_stage1_5
security.selinux=3D"system_u:object_r:boot_runtime_t\000"

# dump 0f /tmp/eatest /boot/
  DUMP: Date of this level 0 dump: Fri Dec  2 14:06:18 2005
  DUMP: Dumping /dev/hdb1 (/ (dir boot)) to /tmp/eatest
....
  DUMP: Average transfer rate: 6305 kB/s
  DUMP: DUMP IS DONE

# cd /tmp
# restore rf eatest
....

# getfattr -d -m . /tmp/boot/grub/minix_stage1_5
getfattr: Removing leading '/' from absolute path names
# file: tmp/boot/grub/minix_stage1_5
security.selinux=3D"system_u:object_r:boot_runtime_t\000"

As you see, the EA attribute is identical between the original file and
the restored one.=20

Stelian.
--=20
Stelian Pop <st...@po...>

Re: [Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[Stelian P. <st...@po...>]

Le samedi 26 novembre 2005 =E0 10:50 -0500, sb...@ab... a =E9crit :
> I've tried compiling from the CVS. The problem still exists.
>=20
> It is a problem of going from kernel 2.6.14-1.1532_FC4 to 2.6.14-
> 1.1637_FC4. There is no problem, if I run with the older kernel.

Well, I'll take a look at the EA disk format then and figure out what
has changed, once again :(

Stelian.
--=20
Stelian Pop <st...@po...>

Re: [Dump-users] st driver's buffer corrupting multivolume dumps

[Stelian P. <st...@po...>]

Le vendredi 25 novembre 2005 =E0 12:30 -0800, Kenneth Porter a =E9crit :
> --On Friday, November 25, 2005 12:52 PM -0600 Brent Busby=20
> <br...@ke...> wrote:
>=20
> > I've seen lots of posts in the dump mailing lists from people with th=
is
> > problem, and elsewhere, but no solutions, and it doesn't seem so much=
 a
> > dump problem as a general tape drive problem, since it's the SCSI tap=
e
> > driver that seems to create this scenario, and it would probably happ=
en
> > just the same with tar or anything that tries to span data across tap=
e
> > volumes on Linux.
>=20
> While I have no solution, I'd suggest checking with the linux-scsi mail=
ing=20
> list, as someone there with a good understanding of the st driver may k=
now=20
> what's going on.
>=20
> <http://vger.kernel.org/majordomo-info.html>
> <http://vger.kernel.org/vger-lists.html>
>=20
> Let us know what you find. It sounds like an interesting problem.

I think he is already reading the linux-scsi mailing list, but in case
he isn't it may be useful to also CC: the scsi tape driver maintainer,
Kai Makisara, in your mails.

Good luck.

Stelian.
--=20
Stelian Pop <st...@po...>

Re: [Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[<sb...@ab...>]

I've tried compiling from the CVS. The problem still exists.

It is a problem of going from kernel 2.6.14-1.1532_FC4 to 2.6.14-
1.1637_FC4. There is no problem, if I run with the older kernel.


Subject:        	Re: [Dump-users] EA system_u:object_r:boot_runtime_t valu=
e changed
	Error Messages
From:           	Stelian Pop <st...@po...>
To:             	sb...@ab...
Copies to:      	dum...@li...
Date sent:      	Mon, 14 Nov 2005 21:50:42 +0100
Keywords:       	
> Le lundi 14 novembre 2005 =E0 11:57 -0500, sb...@ab... a =E9crit :
> 
> > After changing the Fedora Core 4 kernel to 2.6.14-1.1637_FC4 (from
> > 2.6.14-1.1532_FC4) I've started getting the following error messages
> > when using restore to compare a dump backup:
> > 
> > ./grub/minix_stage1_5: EA system_u:object_r:boot_runtime_t value
> > changed
> 
> There were a few problems with the ACL code in restore-0.4b40, which
> were fixed but I haven't got the time yet to make a release, so the
> code is available in the CVS.
> 
> However, your issue here could be different (like a change in the EA
> disk format between the two kernels).
> 
> I suggest you:
>  1) try the dump/restore version from the CVS
>  2) determine what the difference really is. For this, try extracting
> one of those files, and run on each of them getfattr, like below:
>   getfattr -d -m . /boot/grub/minix_stage1_5
> 
> Stelian.
> -- 
> Stelian Pop <st...@po...>
> 


Stephen Bauman
13810 Franklin Ave 2N
Flushing NY 11355-3302
Tel: 718-359-7972  (USA)

Re: [Dump-users] st driver's buffer corrupting multivolume dumps

[Kenneth P. <sh...@se...>]

--On Friday, November 25, 2005 12:52 PM -0600 Brent Busby 
<br...@ke...> wrote:

> I've seen lots of posts in the dump mailing lists from people with this
> problem, and elsewhere, but no solutions, and it doesn't seem so much a
> dump problem as a general tape drive problem, since it's the SCSI tape
> driver that seems to create this scenario, and it would probably happen
> just the same with tar or anything that tries to span data across tape
> volumes on Linux.

While I have no solution, I'd suggest checking with the linux-scsi mailing 
list, as someone there with a good understanding of the st driver may know 
what's going on.

<http://vger.kernel.org/majordomo-info.html>
<http://vger.kernel.org/vger-lists.html>

Let us know what you find. It sounds like an interesting problem.

[Dump-users] st driver's buffer corrupting multivolume dumps

[Brent B. <br...@ke...>]

I'm trying to solve a problem that I've been having for a *long* time:

When I do multivolume dumps, doing 'restore -C' on them almost always 
reveals corruption on files at and just after the point where the 
archive spans to the next tape.  I've learned from the man page for the 
st driver that this is to be expected if write buffering is on (which it 
is by default):

 	MT_ST_BUFFER_WRITES  (Default: true)
 	Buffer all write operations in fixed block mode.  If this option
 	is false and the drive uses a fixed block size, then all write
 	operations must be for a multiple of the block size.  This
 	option must be set false to write reliable multi-volume
 	archives.

 	MT_ST_ASYNC_WRITES  (Default: true)
 	When this options is true write operations return immediately
 	without waiting for the data to be transferred to the drive if
 	the data fits into the driver's buffer.  The write threshold
 	determines how full the buffer must be before a new SCSI write
 	command is issued.  Any errors reported by the drive will be
 	held until the next operation.  This option must be set false to
 	write reliable multi-volume archives.

So...that would mean that buffered writes and async writes should be 
turned off if you expect to span tapes with dump (or tar, or anything 
else probably), right?  So I do 'mt stoptions 4', and I still get:

  BOT ONLINE IM_REP_EN

from 'mt status'.  That's odd.  The 'IM_REP_ON' at the end means it's 
still doing things asyncronously.  Again, from the 'st' driver man page:

 	GMT_IM_REP_EN(x):  Immediate report mode.  This bit is set if
 	there are no guarantees that the data has been physically
 	written to the tape when the write call returns. It is set zero
 	only when the driver does not buffer data and the drive is set
 	not to buffer data.

So apparently it ignored my 'mt stoptions 4' call, because IM_REP_EN is 
still on, thus write buffers are still on, thus I'll probably get a 
corrupted backup again if I try to span multiple tapes.  Now I try 
another mt command, 'mt drvbuffer 0' to just shut off all buffers 
completely.  Now 'mt status' gives me:

  BOT ONLINE

Good!  No more IM_REP_EN now.  I'm safe, right?  We'll see.  So I get 
ready to do a dump, and here's what that looks like:

village:~# mt erase
village:~# mt rewind
village:~# mt datcompression 2
Compression on.
Compression capable.
Decompression capable.
village:~# mt drvbuffer 0
village:~# mt stoptions 4
village:~# mt status
drive type = Generic SCSI-2 tape
drive status = 637534720
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 512 bytes. Density code 0x26 (unknown).
Soft error count since last status=0
General status bits on (41000000):
  BOT ONLINE

So the tape table of contents is erased, it's at the beginning, hardware 
compression is on, all my nasty write-buffering is off, and 'mt status' 
is giving me only "BOT ONLINE" with no "IM_REP_EN" to prove it's okay. 
So I can dump?  Here we go:

village:~# dump -0au /srv
   DUMP: Date of this level 0 dump: Fri Nov 25 12:23:24 2005
   DUMP: Dumping /dev/sdb6 (/srv) to /dev/nst0
   DUMP: Label: /srv
   DUMP: Writing 10 Kilobyte records
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 58195461 blocks.
   DUMP: Volume 1 started with block 1 at: Fri Nov 25 12:24:28 2005
   DUMP: 0.00% done at 3 kB/s, finished in 4931:10
   DUMP: 0.00% done at 3 kB/s, finished in 4947:55
   DUMP: Interrupt received.
   DUMP: Do you want to abort dump?: ("yes" or "no")   DUMP: Interrupt 
received.
   DUMP: Interrupt received.
   DUMP: Do you want to abort dump?: ("yes" or "no")   DUMP: Do you want 
to abort dump?: ("yes" or "no") yes
   DUMP: The ENTIRE dump is aborted.
village:~#

And that's what it does...  Everything looks fine through Phase II, then 
the tape drive starts, and it seems to be streaming just fine with no 
shoeshining of the tape at all...except...the hard drive is showing 
hardly any activity at all.  What is it streaming?  The tape motor is 
running, the tape drive activity light is on...but the hard drive is 
sending...nothing.  Finally, as you can see above, dump ends up spending 
so much time waiting to start Phase III that it prints its percent done 
progress messages before it even gets that far.  (And the progress 
messages say it's doing 3kB/s, and that it will finish in about five 
thousand hours.)  All the while the tape drive motor is running, and 
it's happily streaming *something*, though with nothing coming from the 
hard drive, I can't imagine what.  If I do 'mt tell' after aborting it, 
I get:

village:~# mt tell
At block 3980.

So I'm now almost two megabytes into the tape media, I never even got to 
Phase III, thus it didn't even start archiving data yet.  Very, very 
weird.

Sorry about the long detailed message -- usually if you post a brief 
message, nobody can help you, so I thought I'd post the whole thing. 
What I'm hoping someone here can do is just tell me what *they* do for 
successful multivolume dumps, which can be verified by 'restore -C' as 
good.  I've seen lots of posts in the dump mailing lists from people 
with this problem, and elsewhere, but no solutions, and it doesn't seem 
so much a dump problem as a general tape drive problem, since it's the 
SCSI tape driver that seems to create this scenario, and it would 
probably happen just the same with tar or anything that tries to span 
data across tape volumes on Linux.

Can anyone help with this?  If you're successfully writing (and 
verifying!) multivolume tape archives, how are you doing it?  The 
problem only shows up on a 'restore -C' -- during the write, it looks 
okay -- so if you don't actually verify, you don't really know that you 
aren't having this problem, too.

-- 
+ Brent A. Busby,   UNIX Systems Admin	 +   "It's like being	+
+ James Franck / Enrico Fermi Institute	 +    blindsided by a	+
+     The University of Chicago		 +    flying dwarf..."	+

[Dump-users] Re:

[yuki <go_...@ya...>]

Š®„«‘S„«–³„«—¿„«•„«Žg„«‚¢„«•ú„«‘è„«
„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®
@@@@@@@@¤¤¤¤¤¤
http://www.checkcheck-zero.net/?id=pc120
 
Ÿ“ü‰ï”ï^”N‰ï”ï
žƒ[ƒ‹ŽóM•‘—M
Ÿ—‘z‚Ì‘ŠŽè^‚²‹ßŠŒŸõ
žŽÊ^^“®‰æ‚Ì“o˜^•‰{——
ŸZŠ^ƒAƒhƒŒƒX^“d˜b”ԍ†‚ÌŒðŠ·
 
’j«‰—«Š‚Æ‚à‚ÉŠ®‘S–³—¿‚Å‘S‚Ä‚²—˜—p’¸‚¯‚Ü‚·B
http://www.checkcheck-zero.net/?id=pc120
 
ˆÀSƒTƒCƒgéŒ¾
EEEc„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ªš
ƒ‰ƒuƒŠ[ƒ[ƒ‹‚̓Xƒ|ƒ“ƒT[ƒTƒCƒg—l‚©‚ç‚̍L—¿‚݂̂ʼn^‰c‚µ‚Ä‚¨‚è‚Ü‚·B
‚»‚ׁ̈A‘SƒT[ƒrƒX‚ðŠ®‘S–³—¿‚Å‘S‚Ä‚²—˜—p’¸‚¯‚Ü‚·B
—‘z‚Ì‘ŠŽè‚ð‹‚ß‚é•ûX‚ɈÀS‚ƐM—Š‚ð‘æˆê‚ɍl‚¦‚È‚ª‚çA
‹CŒy‚É‚¨Žg‚¢’¸‚¯‚éƒT[ƒrƒX‚ð–ÚŽw‚µA
–œ‘S‚̃Tƒ|[ƒg‘̐§‚ÅŠF—l‚ɍ‡‚Á‚½‚¨‘ŠŽè’T‚µ‚ð‚¨Žè“`‚¢‚µ‚Ä‚¨‚è‚Ü‚·B
š„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ªcEEE
http://www.checkcheck-zero.net/?id=pc120

--
”zM‹‘”ہF
kis...@ca...

Re: [Dump-users] /dev directory error messages

[Stelian P. <st...@po...>]

Le lundi 14 novembre 2005 =E0 12:03 -0500, sb...@ab... a =E9crit :
> Since upgrading to the Fedora 3 Core I've been getting a lot of error=20
> messages on a restore compare of the following type:
>=20
> /sbin/restore: unable to stat ./dev/pup: No such file or directory
>=20
> These have continued with Fedorea Core 4. I'm using dump-0.4b40-2.
>=20
> I'm simply backing up my entire root partition with a dump statement=20
> and comparing the backup using restore.
>=20
> I've not paid any attention to these messages. Is there a way to=20
> eliminate them?

Those errors are caused by the fact that you're comparing two different
things: the backuped /dev (the one stored on the disk and seen by dump)
is in fact hidden by the dynamic udev based /dev (which restore sees).

I'd say that either you don't compare the backup, or you compare the
filesystem with udev not running (requiring booting from alternate
media), or you simply exclude /dev from the dump, since it isn't
terribly useful nowadays.

Stelian.
--=20
Stelian Pop <st...@po...>

Re: [Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[Stelian P. <st...@po...>]

Le lundi 14 novembre 2005 =E0 11:57 -0500, sb...@ab... a =E9crit :

> After changing the Fedora Core 4 kernel to 2.6.14-1.1637_FC4 (from=20
> 2.6.14-1.1532_FC4) I've started getting the following error messages=20
> when using restore to compare a dump backup:
>=20
> ./grub/minix_stage1_5: EA system_u:object_r:boot_runtime_t value=20
> changed

There were a few problems with the ACL code in restore-0.4b40, which
were fixed but I haven't got the time yet to make a release, so the code
is available in the CVS.

However, your issue here could be different (like a change in the EA
disk format between the two kernels).

I suggest you:
	1) try the dump/restore version from the CVS
	2) determine what the difference really is. For this, try extracting
one of those files, and run on each of them getfattr, like below:
		getfattr -d -m . /boot/grub/minix_stage1_5

Stelian.
--=20
Stelian Pop <st...@po...>

[Dump-users] /dev directory error messages

[<sb...@ab...>]

Since upgrading to the Fedora 3 Core I've been getting a lot of error 
messages on a restore compare of the following type:

/sbin/restore: unable to stat ./dev/pup: No such file or directory

These have continued with Fedorea Core 4. I'm using dump-0.4b40-2.

I'm simply backing up my entire root partition with a dump statement 
and comparing the backup using restore.

I've not paid any attention to these messages. Is there a way to 
eliminate them?

Thanks in advance.

Stephen Bauman

Stephen Bauman
13810 Franklin Ave 2N
Flushing NY 11355-3302
Tel: 718-359-7972  (USA)

[Dump-users] EA system_u:object_r:boot_runtime_t value changed Error Messages

[<sb...@ab...>]

After changing the Fedora Core 4 kernel to 2.6.14-1.1637_FC4 (from 
2.6.14-1.1532_FC4) I've started getting the following error messages 
when using restore to compare a dump backup:

./grub/minix_stage1_5: EA system_u:object_r:boot_runtime_t value 
changed

The above is an error message for the /boot partition. There are many 
similar lines for almost every file. The same occurs on other 
partitions.

It's unlikely that the so many files have changed, so I'm thinking 
that something got broken.

The dump command is:
/sbin/dump -0uM -B 500000 -y -L root \
  -f /mnt/backup/Linux/root / >> /mnt/backup/Linux/backup.log

This is the dump command for the root partition. The backup medium is 
a hard drive on another machine that was whose mount point is: 
/mnt/backup.

The restore command is:
/sbin/restore -C -M -y -D / \
 -f /mnt/backup/Linux/root >> /mnt/backup/Linux/backup.log

The backup log does not show any messages. This is a cron job, so I 
get the error messages in an email.

The version of the dump rpm is: dump-0.4b40-2, which I downloaded 
from as part of the Fedora Core 4 updates.

Any ideas? Is the backup ok and the messages spurious? 

Thanks in advance.

Stephen Bauman

Stephen Bauman
13810 Franklin Ave 2N
Flushing NY 11355-3302
Tel: 718-359-7972  (USA)

[Dump-users] Re: Robertos Shocking story

[Jonah H. <hu...@vb...>]

He
ss Ph
ss Spe
er!
llo, Don't mi
armaExpre
cial Off
VALVIAXanAmbCIALev
IUM Now $GRA Now $axienLIS Now $itra
1.213.33  3.75 
plus many other - The website
- Best - Easy - Total - Home - Fast 
PricOrdeConfDeliShip
esringidentialityveryping

[Dump-users] =?ISO-2202-JP?Q?=82=E2=82=9F=82=E2=82=9F|=81E=83=D6=81E)/?=

[<ai...@ho...>]

k8uRUoLFgrKC34LxgsiCs4Kigr6Cr4LHi5aCtYLEgsuBSA0KgqCCvYK1gs2N
oYFBkGyLQ0FWj5eXRILwltqOd4K1gsSC6YF1gt2C44LxgXaCwYLEjL6CpILx
gr6Cr4LHguaC64K1gq2Cyygq34Gk3yopgfQNCpPLkVKCsYLxgsiYYoK3gumC
zILggseCpIKpgsiCwYLEjnaCpILxgr6Cr4LHgUGC3YLjgvGCzYNHg2KDYILI
grGCxoKqjUSCq4LIgvGCvoKvgseBQYK7guqCvoKvgraC4YKxgsyOZI6WgsWU
hILqgsGOcYLJgsiC6YLMgs2T74K1gqKC3YK9gqKCyILxgr4oVF9UKQ0KgruC
6oLFgUGSaoLMkGyC8Irsgs6Ct4LJgs2Cx4KkgrWCvYLngseCpIK1gr2C54Ki
gqKCqYLBgsSMvoKkgsyC8JBGgViLs4KmgsSC2YK1gqKCzILLgUgNCo3Fj4mC
yY1sgqaCwoKigr2CzIKqIoNJg2mDaoFbgvCMqYK5gsSLu5WxgrOCuYLpIoLB
gsSMvoKkgsyCyILxgr6Cr4LHgUGC3YLjgvGC4ILggsGCxoKiguuC8YLIjG+M
sYK1gsSCqoLxgs6C54LIgquC4YKigq+CyIKigrWBQYKigquCyILojuiTYILB
gsSCxoKpjL6CpILMguCCt4Kygq2J9oK1gqKCxo52gqSCqYLngVMoO4FMgaSB
TUFgYIK+gsGCxIKxgsyDgYFbg4uCzI6ek1+CxYr5gsmJ9oK1gqKCtoLhgvGC
l4KXgpcNCg0KgtCCxoLcgriCzYNJg2mDaoFbgvCMZ5HRgsWOQoLBgr2CzILF
jKmCxIKtgr6Cs4KigUmMqYLpgr6Cr4K+gsGCvYLng16DX4LFgrWC5YH0ifaC
tYKtgsiCooK1gZkNCmh0dHA6Ly93d3cuaGFwcHktbG92ZTIuY2MvMTEyMS8N
CoGqDQqC3YLjgvGCzIN5gVuDV4KpgueDioOTg06CqoKggumCyYLlgvGBSZOu
ieaC4IxmjdqCxYKrgumDVINDg2eCyILMgsWBmQ0KlOGUu4LFguCCyILxgsWC
4I7zgq+VdIKvgsSC6YLMgsWSvJDag4GDYoNagVuDV4LggueCwYLEguCCooKi
grUoXm9eKZimDQoNCoypgueC6oK9kJSCxoKpguCVqoKpgumCqYLnkJSOmoKq
kZ2CpoLEgumCsYLGgvCLRoLBgsSBY4FjDQqCooKildSOloLwkdKCwYLEgumC
y4H0gt2C44LxgsWCtYK9gZk=

[Dump-users] scsi parity errors when dump-ing

[Kolev, N. <NK...@tr...>]

Hi,
 =

I used to get these every once in a while, but now I am getting it every
time I try to do a dump. The confusing part is that when I was getting
them very rarely the problem magically seemed to go away, I mean I would
see a couple of times and then everything will be fine. The tape drive
(Quantum SDLT320) was just recently cleaned, and the tapes are brand
new.
 =

here's what happens when I dump (I only see the non-DUMP messages on
tty1, otherwise they can be seen in the kernel print buffer):
 =

/usr/sbin/dump 0aqfL /dev/nst0 SCOUT_BACKUP /app/solid
  DUMP: Date of this level 0 dump: Wed Oct 26 01:00:47 2005
  DUMP: Dumping /dev/md2 (/app/solid) to /dev/nst0
  DUMP: Label: SCOUT_BACKUP
  DUMP: Writing 10 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 54354 blocks.
  DUMP: Volume 1 started with block 1 at: Wed Oct 26 01:00:56 2005
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
SCSI Error: (1:6:0) Status=3D02h (CHECK CONDITION)
 Key=3DBh (ABORTED COMMAND); FRU=3D00h
 ASC/ASCQ=3D47h/00h ""
 CDB: 0A 00 00 28 00 00 - "WRITE(6)"
 =

st0: Error with sense data: Current st09:00: sense key Aborted Command
Additional sense indicates Scsi parity error
  DUMP: write error 14440 blocks into volume 1: Input/output error
  DUMP: Do you want to rewrite this volume? - forced abort
  DUMP: The ENTIRE dump is aborted.
 =

Any help on how to doctor or at least understand this will be greatly
appreciated.
 =

Thanks,
-nik




Confidentiality Notice
This e-mail (including any attachments) is intended only for the recipients=
 named above. It may contain confidential or privileged information and sho=
uld not be read, copied or otherwise used by any other person. If you are n=
ot a named recipient, please notify the sender of that fact and delete the =
e-mail from your system.

[Dump-users] =?shift-jis?B?kOiCog==?=

[<dia...@21...>]

gUCBgYGBkeWQbILMl/aQ6IKigYGBgQ0KDQqBYIFgjaGMjoLMl/aCzI1zlfuBYIFggWCBYIFggWCB
YIFggWCBYIFggWCBYIFggWANCo7jgqKCzILNgq+CwYK1gsSScILFgs2CyIKigUINCiAgICAgICAg
ICAgICAgIIK7gsyO44KzgsmTT4K1gqaCyIKigsyCqpJwgr6BQg0KDQqBmZJOgsmCxYLgjuOCoo+K
gs2CoILogtyCt4FCDQogICAgICAgi62CqoLBgr2C6IK5griBQQ0KICAgjqmVqoLMjuOCs4LwgruC
zILcgtyO84KvgsaC34LpgrGCxoKqkeWQ2ILFgreBQg0KDQqBYIFggWCBYIFggWCBYIFggWCBYIFg
gWCBYIFggWCBYIFggWCBYIFggWCBYIFggWANCg0KkeWQbILMioSC6JDYguiCzYFBiOqO7YLMl52J
8IFBgruCtYLE5tKR8i4uLoFCDQqOZI6Wi0GC6ILMlqeJ74LJgUGT4I+PgsyX9oikgskNCg0Kj+6V
8YNUg0ODZ4FGgUBodHRwOi8vd3d3LmRlYWlhcmVhLmNvbQ0KMjE6NTI6MjYNCg0KDQoNCiAg

[Dump-users] Re: Wesley's Story hour

[Ean M. <met...@la...>]

I am in good health and have always enjoyed sex.
I was losing my erection during intercourse and during oral sex with 
my girlfriend.
It was difficult to pinpoint the problem so I decided to order some 
Vjagrra online.

I ordered my Vjagrra which arrived in several days. I ordered 4x100mg 
pills and on the weekend decided to give it a go without saying 
anything to my girlfriend ;) 35 minutes before we went to bed I took 
half a pill, and WOW! what a difference. 

I had a rock hard erection for over an hour of non stop sex. Even 
after I had climaxed I was ready to go again in twenty minutes, which 
we did. this lasted for over two hours, and I was still hard in the 
shower after. 

It was like being a teenager over again. Amazing!

If you have a problem, try Vjagrra, it is great http://www.efetievusag.com

[Dump-users] Re: Pharumcy Works Excellent

[Alfonsina H. <al...@ar...>]

Hi,

CjALL jS $3.49
VjAGR RA $3.29
Xana nax
P roazac
Prropecj a
Amn bjen
UItt ram
Soa ma
VALL jUM $1.25
Levv jtra


http://parlaywlj.caganel.info

_________________________________________________________________
Luther translated twenty of these fables, and was urged by A FAMISHED FOX saw 
some clusters of ripe black grapes hanging lighted a fire, and warmed them. He 
let the Horse make free with A FLEA settled upon the bare foot of a Wrestler 
and bit him, costume. In the evening he was shut up by the shepherd in the