[gentoo-user] /var/tmp/portage not empty?

[gentoo-user] /var/tmp/portage not empty?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 698 bytes --]

I am trying to clean up what seems like a remnant of a failed emerge, but I 
can delete the directory in question:

# rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': Directory not 
empty

Am I missing something simple here?  Why can't I remove it?  It seems empty to 
me:

# ls -la /var/tmp/portage/sys-devel/gcc-4.4.3-
r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
total 1
drwxr-xr-x 2 portage portage 3 May 28 07:48 .
drwxr-xr-x 3 portage portage 3 May 28 07:48 ..
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] /var/tmp/portage not empty?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Mon, 7 Jun 2010 20:54:36 +0100, Mick wrote:

> # rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale':
> Directory not empty
> 
> Am I missing something simple here?  Why can't I remove it?  It seems
> empty to me:

Filesystem corruption?


-- 
Neil Bothwick

Three kinds of people: Those who can count, and those who can't.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] /var/tmp/portage not empty?

[Dale]

Mick wrote:
> I am trying to clean up what seems like a remnant of a failed emerge, but I
> can delete the directory in question:
>
> # rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': Directory not
> empty
>
> Am I missing something simple here?  Why can't I remove it?  It seems empty to
> me:
>
> # ls -la /var/tmp/portage/sys-devel/gcc-4.4.3-
> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> total 1
> drwxr-xr-x 2 portage portage 3 May 28 07:48 .
> drwxr-xr-x 3 portage portage 3 May 28 07:48 ..
>    

I generally use rm -rfv when I delete something and do it as root as 
well.  It is gone after that.  I'm not sure what the difference is 
between R and r tho.  I need to go check the man page I guess.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] /var/tmp/portage not empty?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1259 bytes --]

On Monday 07 June 2010 21:24:37 Dale wrote:
> Mick wrote:
> > I am trying to clean up what seems like a remnant of a failed emerge, but
> > I can delete the directory in question:
> >
> > # rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> > rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': Directory
> > not empty
> >
> > Am I missing something simple here?  Why can't I remove it?  It seems
> > empty to me:
> >
> > # ls -la /var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> > total 1
> > drwxr-xr-x 2 portage portage 3 May 28 07:48 .
> > drwxr-xr-x 3 portage portage 3 May 28 07:48 ..
> 
> I generally use rm -rfv when I delete something and do it as root as
> well.  It is gone after that.  I'm not sure what the difference is
> between R and r tho.  I need to go check the man page I guess.  ;-)
> 
> Dale
> 
> :-)  :-)
> 
-r, -R, --recursive
              remove directories and their contents recursively

I am getting worried now about fs corruption.  The fs is supposed to be 
checked at boot time .... 
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] /var/tmp/portage not empty?

[Alan McKinnon]

On Monday 07 June 2010 22:24:37 Dale wrote:
> Mick wrote:
> > I am trying to clean up what seems like a remnant of a failed emerge, but
> > I can delete the directory in question:
> > 
> > # rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> > rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': Directory
> > not empty
> > 
> > Am I missing something simple here?  Why can't I remove it?  It seems
> > empty to me:
> > 
> > # ls -la /var/tmp/portage/sys-devel/gcc-4.4.3-
> > r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
> > total 1
> > drwxr-xr-x 2 portage portage 3 May 28 07:48 .
> > drwxr-xr-x 3 portage portage 3 May 28 07:48 ..
> 
> I generally use rm -rfv when I delete something and do it as root as
> well.  It is gone after that.  I'm not sure what the difference is
> between R and r tho.  I need to go check the man page I guess.  ;-)

The "#" in his quoted prompt implies that he is doing it as root.

the -r -R and --recursive switches to rm are all synonymous.

Neil is likely correct - filesystem corruption. A quick easy way to check is 
to run ls -al starting with the target then going up on directory in turn. If 
you start getting lots of "???" in the output, corruption is almost certain.



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] /var/tmp/portage not empty?

[Paul Hartman]

On Mon, Jun 7, 2010 at 2:54 PM, Mick <michaelkintzios@gmail.com> wrote:
> I am trying to clean up what seems like a remnant of a failed emerge, but I
> can delete the directory in question:

Maybe try lsof to see if anything is using one of those directories

Re: [gentoo-user] /var/tmp/portage not empty?

[Alex Schuster]

Mick writes:

> I am getting worried now about fs corruption.

I would be, too.

> The fs is supposed to be checked at boot time .... 

But only if it was not shut down correctly. To force a complete fsck on
reboot on a file system that looks sane, issue a 'touch /force_fsck'.

	Wonko

Re: [gentoo-user] /var/tmp/portage not empty?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Mon, 7 Jun 2010 22:45:57 +0100, Mick wrote:

> I am getting worried now about fs corruption.  The fs is supposed to be 
> checked at boot time .... 

Only if it's marked unclean. extN filesystems are only checked every so
many mounts or days. Run fsck with the --force option to force a proper
check.


-- 
Neil Bothwick

Picard: 'What do the sensors say Mr Data?'
Data:   'They tell us that we can't say "F*ck" Sir."
Picard: 'I meant the ship's sensors Mr Data'

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] /var/tmp/portage not empty?

[Dale]

Mick wrote:
> On Monday 07 June 2010 21:24:37 Dale wrote:
>    
>> Mick wrote:
>>      
>>> I am trying to clean up what seems like a remnant of a failed emerge, but
>>> I can delete the directory in question:
>>>
>>> # rm -Rf /var/tmp/portage/sys-devel/gcc-4.4.3-
>>> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
>>> rm: cannot remove `/var/tmp/portage/sys-devel/gcc-4.4.3-
>>> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': Directory
>>> not empty
>>>
>>> Am I missing something simple here?  Why can't I remove it?  It seems
>>> empty to me:
>>>
>>> # ls -la /var/tmp/portage/sys-devel/gcc-4.4.3-
>>> r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale
>>> total 1
>>> drwxr-xr-x 2 portage portage 3 May 28 07:48 .
>>> drwxr-xr-x 3 portage portage 3 May 28 07:48 ..
>>>        
>> I generally use rm -rfv when I delete something and do it as root as
>> well.  It is gone after that.  I'm not sure what the difference is
>> between R and r tho.  I need to go check the man page I guess.  ;-)
>>
>> Dale
>>
>> :-)  :-)
>>
>>      
> -r, -R, --recursive
>                remove directories and their contents recursively
>
> I am getting worried now about fs corruption.  The fs is supposed to be
> checked at boot time ....
>    

Since you were using the -f option, I would be to.  Something odd 
somewhere.  Could there be a lock file in there or something?  I would 
think the -f option would over ride that to tho.

Try to umount it and see if it complains about something.  I would be in 
single user to do that tho.  Just in case.

Dale

:-)  :-)

Re: [gentoo-user] /var/tmp/portage not empty?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Mon, 7 Jun 2010 23:46:19 +0200, Alan McKinnon wrote:

> Neil is likely correct - filesystem corruption. A quick easy way to
> check is to run ls -al starting with the target then going up on
> directory in turn. If you start getting lots of "???" in the output,
> corruption is almost certain.

Paul's suggestion of running lsof may be valid too. If a process had a
lock n a file that was then deleted, the file wouldn't show up in ls but
would prevent the directory being deleted until the lock was released.

If you don't want to mess around with lsof and tracking down the process,
a reboot will solve that one.


-- 
Neil Bothwick

If at first you don't succeed, call in an airstrike.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] /var/tmp/portage not empty?

[Mick]

On 8 June 2010 10:47, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 7 Jun 2010 23:46:19 +0200, Alan McKinnon wrote:
>
>> Neil is likely correct - filesystem corruption. A quick easy way to
>> check is to run ls -al starting with the target then going up on
>> directory in turn. If you start getting lots of "???" in the output,
>> corruption is almost certain.
>
> Paul's suggestion of running lsof may be valid too. If a process had a
> lock n a file that was then deleted, the file wouldn't show up in ls but
> would prevent the directory being deleted until the lock was released.
>
> If you don't want to mess around with lsof and tracking down the process,
> a reboot will solve that one.

It seems that the fs was well and truly corrupted.  :-(

I looked carefully for ????? output of ls -la, which is a sure warning
something went sideways with the fs, but unfortunately I couldn't find
anything wrong.

I have tried throughout the day to recover my machine to no avail.  I
downloaded gcc ebuild and sources from a snapshot and recompiled it
using a live cd.  The same file problem as reported above arose at
least twice.  I have so far run fsck three times - everytime it seems
to fix the error and then I can delete the rogue directories.

Now tell me, is it possible that each time the fs corrupts itself in
the same manner - i.e. at the /var/tmp/portage/sys-devel/... ?

I found that /, /var and /usr/portage were corrupted.  Each one on its
own separate partition.  Each one on a reiser4 type fs ...

Smartmontools doesn't show any failures/errors.

Is reiser4 prone to corruption?  Thankfully my home partition and a
large data partition both on reiser4 are OK.
-- 
Regards,
Mick

Re: [gentoo-user] /var/tmp/portage not empty?

[Mick]

On 8 June 2010 18:42, Mick <michaelkintzios@gmail.com> wrote:
> On 8 June 2010 10:47, Neil Bothwick <neil@digimed.co.uk> wrote:
>> On Mon, 7 Jun 2010 23:46:19 +0200, Alan McKinnon wrote:
>>
>>> Neil is likely correct - filesystem corruption. A quick easy way to
>>> check is to run ls -al starting with the target then going up on
>>> directory in turn. If you start getting lots of "???" in the output,
>>> corruption is almost certain.
>>
>> Paul's suggestion of running lsof may be valid too. If a process had a
>> lock n a file that was then deleted, the file wouldn't show up in ls but
>> would prevent the directory being deleted until the lock was released.
>>
>> If you don't want to mess around with lsof and tracking down the process,
>> a reboot will solve that one.
>
> It seems that the fs was well and truly corrupted.  :-(
>
> I looked carefully for ????? output of ls -la, which is a sure warning
> something went sideways with the fs, but unfortunately I couldn't find
> anything wrong.
>
> I have tried throughout the day to recover my machine to no avail.  I
> downloaded gcc ebuild and sources from a snapshot and recompiled it
> using a live cd.  The same file problem as reported above arose at
> least twice.  I have so far run fsck three times - everytime it seems
> to fix the error and then I can delete the rogue directories.
>
> Now tell me, is it possible that each time the fs corrupts itself in
> the same manner - i.e. at the /var/tmp/portage/sys-devel/... ?
>
> I found that /, /var and /usr/portage were corrupted.  Each one on its
> own separate partition.  Each one on a reiser4 type fs ...
>
> Smartmontools doesn't show any failures/errors.
>
> Is reiser4 prone to corruption?  Thankfully my home partition and a
> large data partition both on reiser4 are OK.

I used dd to zero the partitions, formatted them afresh (again with
reiser4) and then installed gcc-4.4.3-r2 with the Live-CD as part of
re-installing my system.

I couldn't believe my eyes where I saw this at the end of the emerge:
=======================================================
>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/g++ -> x86_64-pc-linux-gnu-g++
>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gcc -> x86_64-pc-linux-gnu-gcc
>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gfortran -> x86_64-pc-linux-gnu-gfortran
 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.3 ...             [ ok ]

 * If you have issues with packages unable to locate libstdc++.la,
 * then try running 'fix_libtool_files.sh' on the old gcc versions.

>>> Regenerating /etc/ld.so.cache...
rm: cannot remove
`/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale':
Directory not empty
=======================================================

To save me from losing it, can you please tell me if your
/var/tmp/portage has such a stale file in there following your emerge
of gcc-4.4.3-r2 ?  Surely I can't blame the fs this time?

-- 
Regards,
Mick

Re: [gentoo-user] /var/tmp/portage not empty?

[James Ausmus]

On Tue, Jun 8, 2010 at 2:01 PM, Mick <michaelkintzios@gmail.com> wrote:
> On 8 June 2010 18:42, Mick <michaelkintzios@gmail.com> wrote:
>> On 8 June 2010 10:47, Neil Bothwick <neil@digimed.co.uk> wrote:
>>> On Mon, 7 Jun 2010 23:46:19 +0200, Alan McKinnon wrote:
>>>
>>>> Neil is likely correct - filesystem corruption. A quick easy way to
>>>> check is to run ls -al starting with the target then going up on
>>>> directory in turn. If you start getting lots of "???" in the output,
>>>> corruption is almost certain.
>>>
>>> Paul's suggestion of running lsof may be valid too. If a process had a
>>> lock n a file that was then deleted, the file wouldn't show up in ls but
>>> would prevent the directory being deleted until the lock was released.
>>>
>>> If you don't want to mess around with lsof and tracking down the process,
>>> a reboot will solve that one.
>>
>> It seems that the fs was well and truly corrupted.  :-(
>>
>> I looked carefully for ????? output of ls -la, which is a sure warning
>> something went sideways with the fs, but unfortunately I couldn't find
>> anything wrong.
>>
>> I have tried throughout the day to recover my machine to no avail.  I
>> downloaded gcc ebuild and sources from a snapshot and recompiled it
>> using a live cd.  The same file problem as reported above arose at
>> least twice.  I have so far run fsck three times - everytime it seems
>> to fix the error and then I can delete the rogue directories.
>>
>> Now tell me, is it possible that each time the fs corrupts itself in
>> the same manner - i.e. at the /var/tmp/portage/sys-devel/... ?
>>
>> I found that /, /var and /usr/portage were corrupted.  Each one on its
>> own separate partition.  Each one on a reiser4 type fs ...
>>
>> Smartmontools doesn't show any failures/errors.
>>
>> Is reiser4 prone to corruption?  Thankfully my home partition and a
>> large data partition both on reiser4 are OK.
>
> I used dd to zero the partitions, formatted them afresh (again with
> reiser4) and then installed gcc-4.4.3-r2 with the Live-CD as part of
> re-installing my system.
>
> I couldn't believe my eyes where I saw this at the end of the emerge:
> =======================================================
>>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/g++ -> x86_64-pc-linux-gnu-g++
>>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gcc -> x86_64-pc-linux-gnu-gcc
>>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gfortran -> x86_64-pc-linux-gnu-gfortran
>  * Switching native-compiler to x86_64-pc-linux-gnu-4.4.3 ...             [ ok ]
>
>  * If you have issues with packages unable to locate libstdc++.la,
>  * then try running 'fix_libtool_files.sh' on the old gcc versions.
>
>>>> Regenerating /etc/ld.so.cache...
> rm: cannot remove
> `/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale':
> Directory not empty
> =======================================================
>
> To save me from losing it, can you please tell me if your
> /var/tmp/portage has such a stale file in there following your emerge
> of gcc-4.4.3-r2 ?  Surely I can't blame the fs this time?

Bizarre - out of curiousity, since you've already wiped the partition
once - what happens if you dd/wipe/reformat again, but with ext2 or
something similarly basic (and non-experimental)?


>
> --
> Regards,
> Mick
>
>

Re: [gentoo-user] /var/tmp/portage not empty?

[Mick]

On 8 June 2010 21:10, James Ausmus <james.ausmus@gmail.com> wrote:
> On Tue, Jun 8, 2010 at 2:01 PM, Mick <michaelkintzios@gmail.com> wrote:

>> To save me from losing it, can you please tell me if your
>> /var/tmp/portage has such a stale file in there following your emerge
>> of gcc-4.4.3-r2 ?  Surely I can't blame the fs this time?
>
> Bizarre - out of curiousity, since you've already wiped the partition
> once - what happens if you dd/wipe/reformat again, but with ext2 or
> something similarly basic (and non-experimental)?

I'm two hours into an install now and would not really like to do
that.  However, if I am faced with another fs failure after I reboot,
I will soon conclude that I have a hardware problem.  The only catch
is that the OEM Windows 7 fs has not exhibited any problems yet,
because I've only booted into it a dozen times so far.  Not even sure
if I can claim from the warranty for this laptop.
-- 
Regards,
Mick

[gentoo-user] Re: /var/tmp/portage not empty?

[walt]

On 06/08/2010 11:42 AM, Mick wrote:

> It seems that the fs was well and truly corrupted.  :-(
> Is reiser4 prone to corruption?

I know zero about reiserfs, so I'm uniquely qualified to make suggestions :)

Did you do any/some/all of the steps mentioned here?:

http://www.cyberciti.biz/tips/repairing-reiserfs-file-system-with-reiserfsck.html

I'd hope that the reiser utilities might give you some useful error messages.

Re: [gentoo-user] Re: /var/tmp/portage not empty?

[Mick]

On 8 June 2010 23:54, walt <w41ter@gmail.com> wrote:
> On 06/08/2010 11:42 AM, Mick wrote:
>
>> It seems that the fs was well and truly corrupted.  :-(
>> Is reiser4 prone to corruption?
>
> I know zero about reiserfs, so I'm uniquely qualified to make suggestions :)
>
> Did you do any/some/all of the steps mentioned here?:
>
> http://www.cyberciti.biz/tips/repairing-reiserfs-file-system-with-reiserfsck.html
>
> I'd hope that the reiser utilities might give you some useful error
> messages.

Thanks I used reiser4progs to check and repair the fs.  The weird
thing is that I had to repeat this on the /var partition, after I
zero'ed it, reformatted it and reinstalled gentoo on it.   O_O

How is it possible that the same directory/file gets corrupted again
after a reinstall?  Could it be that gcc has some stealth anti-reiser4
fs code that borks it every time!  I am really confused with this
problem.

PS.  Any idea how I could set the partition label to "var" without
damaging the data on it?  I forgot to do that at the time I formatted
it ...
-- 
Regards,
Mick

Re: [gentoo-user] Re: /var/tmp/portage not empty?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Wed, 9 Jun 2010 06:03:51 +0000, Mick wrote:

> Thanks I used reiser4progs to check and repair the fs.  The weird
> thing is that I had to repeat this on the /var partition, after I
> zero'ed it, reformatted it and reinstalled gentoo on it.   O_O
> 
> How is it possible that the same directory/file gets corrupted again
> after a reinstall? 

The first thing I'd do it set PORTAGE_TMPDIR to somewhere less important
than /var. You don't want to risk corrupting system files while sorting
this out. It would also show whether the problem was with an ebuild or
the filesystem. Use a tmpfs filesystem if you have the memory.


-- 
Neil Bothwick

Teamwork is essential; it gives the enemy other people to shoot at.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: /var/tmp/portage not empty?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1790 bytes --]

On Wednesday 09 June 2010 09:32:40 Neil Bothwick wrote:
> On Wed, 9 Jun 2010 06:03:51 +0000, Mick wrote:
> > Thanks I used reiser4progs to check and repair the fs.  The weird
> > thing is that I had to repeat this on the /var partition, after I
> > zero'ed it, reformatted it and reinstalled gentoo on it.   O_O
> >
> > How is it possible that the same directory/file gets corrupted again
> > after a reinstall?
> 
> The first thing I'd do it set PORTAGE_TMPDIR to somewhere less important
> than /var. You don't want to risk corrupting system files while sorting
> this out. It would also show whether the problem was with an ebuild or
> the filesystem. Use a tmpfs filesystem if you have the memory.

I had to reinstall because I didn't catch this early enough the first time and 
it corrupted my other system partitions.  This corruption happened when I 
installed gcc-4.4.3-r2.

After I reinstalled and while still running the LiveCD I updated gcc to the 
same gcc-4.4.3-r2 version.  As I said, again I ended up with a corrupted  
'/var/tmp/portage/sys-devel/gcc-4.4.3-
r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale' directory.

Running fsck.reiser4 --check and then --fix corrected the corruption and that 
was that.  Before I reinstalled, the corruption must have been more pervasive 
because fsck.reiser4 could not fix it - a simple reboot would bring it back.

So, my conclusion from this sad story is that on my system reiser4 was 
attacked by gcc!  O_O

I'd be interested to know if any other gentoo systems running a separate /var 
partition on reiser4 noticed this, in which case I'd file a bug for it.  If 
I'm alone in having this problem then I'll wait until it happens again before 
I open a bug report.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]