| View previous topic :: View next topic |
| Author |
Message |
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
 Posted: Fri Jun 13, 2014 8:27 pm Post subject: HELP! Rescuing an external HDD |
 |
|
Hi all,
I did something pretty stupid and misdirected at dd. Fortunately (I hope) I caught it early and it was a small file. However, at present, I cannot access the USB drive. When I attempt an ls I get the following:
| Code: | | ls: reading directory .: Input/output error |
A check of my dmesg reveals:
| Code: | | [535774.141103] EXT4-fs warning (device sdc1): __ext4_read_dirblock:908: error reading directory block (ino 2, block 0) |
I used the usb drive to back u some data as I am changing over a system. That other system's drive is wiped. There was other stuff on the drive, too, so any help would be appreciated.
Best,
Alex |
|
| Back to top |
|
 |
audiodef
Watchman
Joined: 06 Jul 2005
Posts: 6639
Location: The soundosphere
|
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Fri Jun 13, 2014 8:45 pm Post subject: |
|
|
| audiodef wrote: | | I'm not an expert at recovery, but I would start with the most basic of steps and run fsck on the drive. |
I get the following error message when I do that.
| Code: |
fsck /dev/sdc1
fsck from util-linux 2.24.1
e2fsck 1.42.7 (21-Jan-2013)
fsck.ext4: No such file or directory while trying to open /dev/sdc1
Possibly non-existent device?
|
Best,
Alex |
|
| Back to top |
|
|
audiodef
Watchman
Joined: 06 Jul 2005
Posts: 6639
Location: The soundosphere
|
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Fri Jun 13, 2014 10:07 pm Post subject: |
|
|
Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it?
Alex |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jun 13, 2014 11:16 pm Post subject: |
|
|
| evoweiss wrote: | | Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it? |
Alex ... when you ran dd you probably overwrote the gpt headers/partition table hence the difficulty finding /dev/sdc1. For disc rescue *never* work on the disk itself but make a copy of the block device, I generally would use sys-fs/ddrescue for this purpose. You then work on the copy so that should you damage it its easy to make another copy and start over. Once I have an image of the disk I would try and rebuild the partition table (with gpt partitoned disks you can use gdisk to 'verify' and then, via the 'recovery & transformation menu', fix any discrepencies between the main and backup data). Dependent on how successful I was with the partition recovery I would run testdisk and/or PhotoRec on the copy, to try and recover data ... only once this was done would I use fsck.
best ... khay |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Fri Jun 13, 2014 11:21 pm Post subject: |
|
|
| khayyam wrote: | | evoweiss wrote: | | Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it? |
Alex ... when you ran dd you probably overwrote the gpt headers/partition table hence the difficulty finding /dev/sdc1. For disc rescue *never* work on the disk itself but make a copy of the block device, I generally would use sys-fs/ddrescue for this purpose. You then work on the copy so that should you damage it its easy to make another copy and start over. Once I have an image of the disk I would try and rebuild the partition table (with gpt partitoned disks you can use gdisk to 'verify' and then, via the 'recovery & transformation menu', fix any discrepencies between the main and backup data). Dependent on how successful I was with the partition recovery I would run testdisk and/or PhotoRec on the copy, to try and recover data ... only once this was done would I use fsck. |
Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system.
I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point?
Best,
Alex |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jun 14, 2014 12:04 am Post subject: |
|
|
| evoweiss wrote: | | Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system. |
Alex ... you're welcome. Well, how important is the data? I assume that if it doesn't have any value at all you wouldn't be trying to rescue it, if its irreplacable then you have decide if the cost of a new disk (to make the copy to) is worth it. In the many cases I've had to do this, for others I might add, I've always been successful and in each of these cases its always been a matter of not working on the disk itself and so the cost of a disk would have been acceptable (another reason I don't touch the disk itself is that as a last resort the disk could be sent to a professional recovery service ... and that's a sign of how important the data was).
| evoweiss wrote: | | I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point? |
I honestly can't remember off hand if MBR stores any backup of the partition table, but gparted/parted may be able to fix it (I'm not entirely sure but I seem to remember gparted has some data recovery functionality). Again, I'd always work on a copy ... as you never know what a tool is going to do and you don't get a second chance working on the actual disk. BTW sysrescecd has all these tools (gparted, gdisk, testdisk, PhotoRec) installed.
Good luck & best ... khay |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Jun 14, 2014 5:58 am Post subject: |
|
|
Hi there,
I know next to nothing about HDD recovery and worry that I may have gone beyond the pale with what I already did. Is there any way to tell if this is the case?
I looked up those tools and cannot work out how I would go about actually recovering the drive. Sorry to be a pest.
Best,
Alex
| khayyam wrote: | | evoweiss wrote: | | Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system. |
Alex ... you're welcome. Well, how important is the data? I assume that if it doesn't have any value at all you wouldn't be trying to rescue it, if its irreplacable then you have decide if the cost of a new disk (to make the copy to) is worth it. In the many cases I've had to do this, for others I might add, I've always been successful and in each of these cases its always been a matter of not working on the disk itself and so the cost of a disk would have been acceptable (another reason I don't touch the disk itself is that as a last resort the disk could be sent to a professional recovery service ... and that's a sign of how important the data was).
| evoweiss wrote: | | I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point? |
I honestly can't remember off hand if MBR stores any backup of the partition table, but gparted/parted may be able to fix it (I'm not entirely sure but I seem to remember gparted has some data recovery functionality). Again, I'd always work on a copy ... as you never know what a tool is going to do and you don't get a second chance working on the actual disk. BTW sysrescecd has all these tools (gparted, gdisk, testdisk, PhotoRec) installed.
Good luck & best ... khay |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jun 14, 2014 10:22 am Post subject: |
|
|
| evoweiss wrote: | | I know next to nothing about HDD recovery and worry that I may have gone beyond the pale with what I already did. Is there any way to tell if this is the case? |
Alex ... no, there isn't an easy way to tell exactly what state the disk is in, having run 'fsck -y' whatever changes it made are permanent. However, the fact that lost+found has some content means that some (all?) content was marked as having a problem and may still be recoverable (see: this guide).
| evoweiss wrote: | | I looked up those tools and cannot work out how I would go about actually recovering the drive. Sorry to be a pest. |
No problem ... I'd consider the filesystem kaput, you really should copy everything from it and reformat as there is no way of knowing what sectors of the disk dd overwrote. Your problem is you don't have the disk space to move the data from the disk to a known working filesystem before doing this. So, there is no way for me to advise you as its not simply a matter of pointing a tool at the disk and saying "fix it". A recovery tool (like testdisk or photorec) will generally not "fix" the data but allow you to rescue data that may not be accessible via the normal methods (ie, accessing the filesystem). As for gparted, I really wouldn't try this because the most important thing is to recover data, not fix the partition table. As it seems you can currently mount the partition I wouldn't run anything that might effect your ability to do so and copy data from the disk.
There really isn't a magic bullet, you simply can't trust the integrity of the disk currently, that's why you should focus of data recovery (obviously to another filesystem).
best ... khay |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Sat Jun 14, 2014 3:18 pm Post subject: |
|
|
evoweiss,
It looks like I'm too late to this party :(
fsck is the very last thing to do after everything else has failed. The reason is, is that is makes some guesses then modifies the filesystem.
It often makes a bad situation worse.
The first step is always to try mounting read only, using an alternate superblock.
If you have an image of the drive so you can get back to pre fsck state, you can still try this.
If not, its too late.
If the partition table is destroyed, well you don't really need it anyway. mount has an offset=<bytes> option so you can tell it the filesystem start' offset from the start of the drive.
You really don't want to try evey 1k boundary, so testdisk is useful to narrow things down. It often has false positives, so don't let it write a partition table for you.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again
|
| Posted: Sat Jun 14, 2014 4:38 pm Post subject: |
|
|
With regards to not having space for a copy, I ran into this dilemma myself very recently. An acquaintance had a drive (NTFS) where the MFT (and its mirror) were eaten up by some of the 24 bad sectors (or that's my diagnosis of it anyblue).
The drive was/is 457.8 GiBs or so, and I had no such space around to spare. I was then thinking that, everything is possible, so it should be possible to split the image and mount it later as one. I found some signs towards it being possible indeed, but I didn't really look into it more, nor test it, for I happened to get a hold of an external 1.8 TiB drive.
So, would it actually be possible, or/and at all viable route for this kind of situations?
_________________
Kindest of regardses. |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Jun 14, 2014 6:59 pm Post subject: |
|
|
Hi all,
Many thanks for the tips, commiseration, etc. How would I use testdisk to try and rescue things (I believe the drive was ext4). The only fortunate thing is that the files are mostly not overly necessary, but, of course, it'd be nice to have them back.
One thing that might help is that the main file I'd like to recover is a .tar.gz file. It's the only such file on the drive. The other files are either .wav or .mp3, though I suspect the former. If that would help, great, though, if not, at least the best photos were printed.
Best,
Alex |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Sat Jun 14, 2014 8:48 pm Post subject: |
|
|
evoweiss,
Testdisk can help recover the partition table, not the files.
You need to know before you start that the MSDOS Partition table you were probably using is a series of hacks to get over the immediate problem.
Entries for partitions 1..4 are stored in the MBR. That's all there was space for when the need for partitions arose HDD reached >32Mb. (Really MB)
The extended partition is a fake. Only one block of it is used. The rest reserves space on the HDD for logical partitions 'inside' it. HDD >128Mb became available.
The single used block of the extended partition contains a MBR that is almost empty. It contains a partition table entry to the first logical partition, if any.
This is used to find the next logical partition and so on, just like a linked list.
So ... you can write the entries for partitions 1..4 as often as you like, no data will be harmed
For partitions 5 an later, writing the entry in the wrong place will overwrite something valuable and break the linked list.
Testdisk will scan your HDD, its read only, for blocks that look like the start of filesystems and report them.
If it offers to write a partition table, decline but make a note of the block numbers.
Now use mount to have a look
| Code: | | mount -o ro,offset=<block_no * 512> -t ext4 /dev/sdX /some/mountpoint |
offset is a decimal number of bytes from the start of sdX. There is really no partition number there.
Testing with | Code: | | mount -o ro,offset=32256 /dev/sda /mnt/someplace |
and will mount the first partition on /dev/sda without using the partition table, if the install is old enough to have the first partition start at sector 63.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Jun 14, 2014 9:02 pm Post subject: |
|
|
| NeddySeagoon wrote: | evoweiss,
Testdisk can help recover the partition table, not the files.
You need to know before you start that the MSDOS Partition table you were probably using is a series of hacks to get over the immediate problem.
Entries for partitions 1..4 are stored in the MBR. That's all there was space for when the need for partitions arose HDD reached >32Mb. (Really MB)
The extended partition is a fake. Only one block of it is used. The rest reserves space on the HDD for logical partitions 'inside' it. HDD >128Mb became available.
The single used block of the extended partition contains a MBR that is almost empty. It contains a partition table entry to the first logical partition, if any.
This is used to find the next logical partition and so on, just like a linked list.
So ... you can write the entries for partitions 1..4 as often as you like, no data will be harmed
For partitions 5 an later, writing the entry in the wrong place will overwrite something valuable and break the linked list.
Testdisk will scan your HDD, its read only, for blocks that look like the start of filesystems and report them.
If it offers to write a partition table, decline but make a note of the block numbers.
|
Okay, running testdisk now.
The output is as follows and doesn't sounds good:
| Code: |
Disk /dev/sdc1 - 1204 MB / 1149 MiB - CHS 1149 64 32
Partition Start End Size in sectors
No partition found or selected for recovery
|
The same came about as a result of the "deeper search".
Thoughts, including how screwed I must be  .
Best,
Alex |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Sat Jun 14, 2014 9:41 pm Post subject: |
|
|
evoweiss,
How was the drive partitioned?
If it was one big partition, not having a partition table is the least of your problems.
The first partition will start at either sector 63 or at sector 2048 depending on the version of fdisk you used to write the partition table.
So, try to mount the first partition. Thats offset=32256 or offset=1048576.
If both fail, we can try alternate superblocks too but to limit the guessing, knowing the filesystem size (approx) would be useful as we will need to translate between disk block size (1k and filesystem block size (1k, 2k or 4k)
Is it really only a 1G drive?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Mon Jun 16, 2014 6:40 pm Post subject: |
|
|
Hey Neddy,
Sorry for the delay in replying.
| NeddySeagoon wrote: |
How was the drive partitioned?
If it was one big partition, not having a partition table is the least of your problems.
|
I partitioned it myself. Just one big partition. What's the recommended approach?
| Quote: | | The first partition will start at either sector 63 or at sector 2048 depending on the version of fdisk you used to write the partition table. So, try to mount the first partition. Thats offset=32256 or offset=1048576. |
I'll do so. Might it actually be better for me to first buy another 1TB drive (I need to anyway) and to then start on this stuff?
| Quote: |
If both fail, we can try alternate superblocks too but to limit the guessing, knowing the filesystem size (approx) would be useful as we will need to translate between disk block size (1k and filesystem block size (1k, 2k or 4k)
|
Okay sounds good.
| Quote: | | Is it really only a 1G drive? |
Sorry, my bad! It's a 1 TB device.
Best,
Alex |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Mon Jun 16, 2014 6:48 pm Post subject: |
|
|
Okay, so I tried the mount command, but things are still not working. The error I get is:
| Code: |
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
|
The corresponding syslog message is:
| Code: |
[249039.147946] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
|
Same thing happens with the other offset.
Best,
Alex |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Mon Jun 16, 2014 8:47 pm Post subject: |
|
|
evoweiss,
So lets try another superblock ...
Add in sb=131072 to the two mount commands above
| Code: | | mount -o ro, offset=32256 sb=131072 /dev/sdX /mnt/someplace |
Try the other offset= too.
How big was the file you incorrectly dd ed?
There are more backup superblocks too
Homework :)
Read man mount - just the ext2 ext3 and ext4 filesystem specific bits.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Mon Jun 16, 2014 8:56 pm Post subject: |
|
|
Hi Neddy,
| NeddySeagoon wrote: |
So lets try another superblock ...
Add in sb=131072 to the two mount commands above
| Code: | | mount -o ro, offset=32256 sb=131072 /dev/sdX /mnt/someplace |
Try the other offset= too.
|
Adding sb=131072 just gave me the mount options as opposed to doing anything.
| Quote: |
How big was the file you incorrectly dd ed?
|
I don't remember, honestly. There are a few files I wouldn't mind rescuing if possible.
| Quote: |
There are more backup superblocks too
|
Okay... as soon as I get the sb thing to work.
| Quote: |
Homework
Read man mount - just the ext2 ext3 and ext4 filesystem specific bits.
|
I'll try.
Best,
Alex |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Jun 21, 2014 3:22 am Post subject: |
|
|
Hi all,
So I figured out why the command wasn't working (extra spaces), but it's still not mounting as it's saying "wrong fs type".
The external drive I ordered arrived. Any thoughts on good next steps?
Best,
Alex |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Sat Jun 21, 2014 9:14 am Post subject: |
|
|
evoweiss,
Sorry about the extra spaces.
Use the new drive to make an image of the old drive, so you can always got back to where you are now.
We can try some more of the backup superblocks.
photorec, given some luck, can recover some file types, from filesystems. It scans the entire drive for file headers and makes some assumptions about the data layout on the drive.
On a 1Tb filesystem (my /home) you get backup superblocks at | Code: | $ sudo dumpe2fs /dev/mapper/vg-home | grep superblock
dumpe2fs 1.42.10 (18-May-2014)
Primary superblock at 0, Group descriptors at 1-64
Backup superblock at 32768, Group descriptors at 32769-32832
Backup superblock at 98304, Group descriptors at 98305-98368
Backup superblock at 163840, Group descriptors at 163841-163904
Backup superblock at 229376, Group descriptors at 229377-229440
Backup superblock at 294912, Group descriptors at 294913-294976
Backup superblock at 819200, Group descriptors at 819201-819264
Backup superblock at 884736, Group descriptors at 884737-884800
Backup superblock at 1605632, Group descriptors at 1605633-1605696
Backup superblock at 2654208, Group descriptors at 2654209-2654272
Backup superblock at 4096000, Group descriptors at 4096001-4096064
Backup superblock at 7962624, Group descriptors at 7962625-7962688
Backup superblock at 11239424, Group descriptors at 11239425-11239488
Backup superblock at 20480000, Group descriptors at 20480001-20480064
Backup superblock at 23887872, Group descriptors at 23887873-23887936
Backup superblock at 71663616, Group descriptors at 71663617-71663680
Backup superblock at 78675968, Group descriptors at 78675969-78676032
Backup superblock at 102400000, Group descriptors at 102400001-102400064
Backup superblock at 214990848, Group descriptors at 214990849-214990912 |
On a 1Tb filesystem, the block size is 4k. You need to know this since the numbers above are in filesystem blocks but the mount sb= option is in 1k blocks.
That was a key part of your homework.
| Code: | sb=n Instead of block 1, use block n as superblock. This could be useful when the filesystem has been damaged.
(Earlier, copies of the superblock would be made every 8192 blocks: in block 1, 8193, 16385, ... (and one got
thousands of copies on a big filesystem). Since version 1.08, mke2fs has a -s (sparse superblock) option to
reduce the number of backup superblocks, and since version 1.15 this is the default. Note that this may mean
that ext2 filesystems created by a recent mke2fs cannot be mounted r/w under Linux 2.0.*.) The block number
here uses 1 k units. Thus, if you want to use logical block 32768 on a filesystem with 4 k blocks, use
"sb=131072". |
We already know that | Code: | Primary superblock at 0, Group descriptors at 1-64
Backup superblock at 32768, Group descriptors at 32769-32832 |
don't work.
Try a few others. You will need to test with both offset= values as we don't know where the partition starts.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Jun 21, 2014 4:40 pm Post subject: |
|
|
Hi Neddy,
At present, I'm using dd to clone the botched usb drive to the new usb drive. I just plugged the latter in and issued the command:
| Code: |
# dd if=/dev/sdc of=/dev/sdd
|
It may take a while, but time is something I have this weekend. Once I've got that done, I'll follow your instructions and will get back to you.
Thanks again.
Best,
Alex |
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Fri Jul 04, 2014 11:12 pm Post subject: |
|
|
Hi Neddy,
None of that seems to be working. All I'm getting is:
| Code: |
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
|
Not sure if I'm not doing something right or what.
Also, it took forever to dd the drive. It would be from one USB drive to another, so I imagine it's slow. Any way to speed that up?
Best,
Alex |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Sat Jul 05, 2014 8:49 am Post subject: |
|
|
evoweiss,
USB HDD are slow, USB2 does not support DMA so the CPU has to read and write every byte.
USB to USB is even slower. USB3 is supposed to be better - it does DMA.
To clone my laptop hard drive (250G) takes over 4 hours to a USB2 HDD. Its only 45 min if I use the eSATA port, to the same external drive in the same enclosure.
Thats the difference that DMA makes to only the output drive. The internal HDD is always DMA
Show me some of the commands you hove been using and the resulting error messages in dmesg.
Its possible that the root directory has been trashed. Thats why I was interested in the size of the file you incorrectly dd'ed.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
