Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Plop Linux / New Plop 20.1 scroll not work
« Last post by The_Raven on October 16, 2020, 15:17:10 PM »
Hello

I have installed the new plop 20.1. So far so good, only one little problem:
Scrolling up and down with "shift pageUP/pageDOWN" is not working.

Any idea how to enable scroll?  :D
12
Boot Managers / plop Boot manager with 1.44Mb floppy: Not working
« Last post by George on October 04, 2020, 12:03:07 PM »
I am trying Plop with my old PC with Asus SiS630E motherboard ( P3 850MHz). THough the PC started with the floppy and displayed a full row of dots ...began second row of dots ( 10-12 of them in the second row). THen it is stuck there. FDD light was on always, I have waited for 10mts...but no change. Steps that I have follwed are the following.

1. Downloaded the latest plpbt_5.0.15
2. Formatted the floppy disk in FAT16.
3) imaged the floppy disk (1.44mb) with linux (RHEL)'dd' utility ("dd if=plpbt.img of=/dev/fd0")
4) Rebooted the PC with booting sequence set to floppy-disk

   It started booting from the floppy....gave me a row and quarter full of dots ("......."); then got stuck   

   Could someone guide me on how to proceed?


Another update: ('plpbtin.img')
   With some googling, I have even tried imaging 'plpbtin.img'(instead of 'plpbt.img') on the floppy. Now it has  moved one more step (beyond 'dots') and got a gray-screen with 'flat' written on mid-left of the screen. But it is stuck there. FDD light is always glowing! Looks like a bug.

Resolved!!!:
> I was using a Dell made USB keyboard. It was not handled by the PLOP. Changed the keyboard to my old PS2 one. All is well now. Now, I need to try te same for plpbt.img also. Will update after that.

> THis initial issue ( stuck at 'dots') were also due to the fact that USB device ( either Keyboard or Mass storage) plugged into the USB port. With an empty USB port , plop works fine.

  It may be a good idea to capture it in guidelines.
13
HFS+ Rescue / Re: All recovered files seem corrupt
« Last post by wout on September 30, 2020, 22:55:51 PM »
Yep, I did. The command for step 3 was:
# ./hfsprescue_x64 -s3 /dev/sdb -o 1437184  -d '/mnt/plek/'

and my latest single-file attempt went like this:
# ./hfsprescue --one-file /dev/sdb 2664 -o 1437184 -d /mnt/plek --vh-file /mnt/plek/VolumeHeader --eof-file /mnt/plek/restored/ExtentsOverflowFile

.. where I thought I'd "hardcode" as much as possible.

Thanks again!
14
HFS+ Rescue / Re: All recovered files seem corrupt
« Last post by Elmar on September 29, 2020, 17:36:11 PM »
Did you use -o 1437184 with the per-file restore too?
15
HFS+ Rescue / Re: All recovered files seem corrupt
« Last post by wout on September 29, 2020, 16:51:13 PM »
Thanks for your message, Elmar.

After finding the volume header, the initial command was:
# ./hfsprescue_x64 -s1 /dev/sdb -o 1437184 -d /mnt/plek

EDIT - maybe I should post the results of step 1, as well:

hfsprescue 3.5-rc1 2020/04/26 by Elmar Hanlhofer https://www.plop.at

Start: 2020/09/15 12:41:54

*** Using offset 1437184 (1 MB)
Signature:                      0x2b48, H+
LastMountedVersion:             10.0, last mount by Mac OS X.
FileCount:                      9
DirCount:                       3
BlockSize:                      4096
TotalBlocks:                    7680
AllocationFile StartBlock:      1
ExtentsOverflowFile StartBlock: 2
CatalogFile StartBlock:         62
Total size:                     931 GB

100.00% scanned (931.51 GB). Found: 274447 directories, 386992 files.d

End: 2020/09/17 11:55:04
Elapsed time: 47 hours, 13 minutes.
Done.


(I'm running hfsprescue on linux)

Cheers,
Wout
16
HFS+ Rescue / Re: All recovered files seem corrupt
« Last post by Elmar on September 25, 2020, 08:24:02 AM »
Hello,

what was the initial hfsprescue command?

Best Regards
Elmar
17
HFS+ Rescue / All recovered files seem corrupt
« Last post by wout on September 23, 2020, 16:45:38 PM »
Hi,

I've been trying to "rescue" a disk that's quite important to someone.
As HFS+ Rescue looked interesting, I spent some time with it.

I managed to find a volume header, and eventually I went through all steps successfully. I also have a file list which looks very promising, as in, it has many recognizable filenames.

Recovering the files works, too (no errors), but it seems like ALL of them are corrupt after getting them from the disk. Office docs, images, sound files, text files. I've found one video file which, although very garbled, showed part of a familliar face, but that's it.

The same happens with per-file restores. Any file I try, it will restore successfully but it will be a useless, corrupted file.

As I'm fresh out of ideas, I'm hoping maybe one of you guys might have an idea on how to proceed. I'm obviously more than willing to provide any info you'd require.

Thanks in advance!
18
HFS+ Rescue / Re: Volume Header is not correct — Not sure where to go next!
« Last post by Elmar on September 11, 2020, 05:38:36 AM »
Hello,

maybe, there are only wrong partition values in the partition table.

Are you able to print the partition start, end and similar values with a tool on OSX?
If not, boot up Linux and use "gfdisk" or "gparted" or similar.

Regards
Elmar
19
HFS+ Rescue / Volume Header is not correct — Not sure where to go next!
« Last post by dtom on September 08, 2020, 20:25:42 PM »
My computer got fried a few weeks ago and ever since I've been trying to restore an external backup hard drive.

Since the enclosure was dead, I bought an external enclosure and pulled the drive.

Anytime I insert, I get a "Could not read, initialize?" error.

I've looked at the drive with a bunch of different tools — and it looks like the data is all there — but that the partition is "lost."

From testdisk, it appears as if volume headers are available:

Scanned 300 MB.
============================================
A Volume Header has been found.

Partition start:     314597376 (Byte), 0x12c06000, 614448 (LBA Sector), at 300 MB
Volume Header start: 314598400 (Byte), 0x12c06400, 614450 (LBA Sector), at 300 MB

Signature:                                      0x2b48, H+
LastMountedVersion:                       HFSJ, last mount by Mac OS X.
FileCount:                                      14375770
DirCount:                                       1452607
BlockSize:                                      8192
TotalBlocks:                                    488318330
AllocationFile StartBlock:                 1
ExtentsOverflowFile StartBlock:        46366
CatalogFile StartBlock:                    524318


—————————————


Using HFSPRESCUE, I get this basic sequence on the drive:


>> sudo hfsprescue -s1 /dev/disk2s1
>> Warning: Unusual block size! Use -b 557843968 to force this block size.



>> sudo hfsprescue -s1 /dev/disk1s1 -b 4096
>> 100.00% scanned (465.75 GB). Found: 1436358 directories, 13923483 files.
>> *** Force block size: 4096
>> Signature: 0x00,  (Unknown)
>> LastMountedVersion:             , last mount was not done by Mac OS X.
>> FileCount:                                    0
>> DirCount:                                     0
>> BlockSize:                                    4096
>> TotalBlocks:                                  0
>> AllocationFile StartBlock:                0
>> ExtentsOverflowFile StartBlock:      0
>> CatalogFile StartBlock:                   0
>> Total size:                                     465 GB



>> sudo hfsprescue -s2 /dev/disk1s1
>> Fresh database created with 13711253 entries. 163422 duplicate entries removed.


(At this point, I copied the HFSPRESCUE data onto a different external drive ("Restore") as I didn't have space on my internal drive for the restore and wanted to avoid messing up the drive I was working with.)



>>sudo /Volumes/Restore/hfsprescue/MacOSX/hfsprescue -s3 /dev/disk1s1 -b 4096 --force -d /Volumes/Restore/
>> You are forcing the block size. I assume, the Volume Header is not correct.
>> Automatic extracting of the ExtentsOverflowFile has been disabled! This means
>> strong fragmented files will not be restored! When you want to use the
>> ExtentsOverflowFile, then you have to restore it manually with '--extract-eof'.
>> Use '--ignore-eof' to restore without ExtentsOverFlowFile.


I then ran:
>> sudo /Volumes/Restore/hfsprescue/MacOSX/hfsprescue -s3 /dev/disk1s1 -b 4096 --force -d /Volumes/Restore/ --ignore-eof

I let this run for a little bit, but it looked like everything returned a "Invalid start block for…"


—————————————


I'm not exactly sure where to go from here!

Any help would be appreciated as I really believe this data can be recovered — and that the partition has just gone "missing."
20
HFS+ Rescue / Re: Invalid enty
« Last post by nicedog on August 19, 2020, 18:25:55 PM »
turns out it is an exfat formatted drive. sorry for the confusion.
Pages: 1 [2] 3 4 ... 10