[Solved] Ext3 Filesystem not recognized - Sun partitions

cafe · 2015-01-23 17:18:10

Hello everyone,

I'm trying to recover some data from a hard-drive that was removed from my old Sun Ultra 45. It used to hold a Debian installation with several partitions, all in ext3.

Now, I'm trying to mount this HD in my arch to recover my data, but I can't get any of the partitions (/dev/sdbX) to be recognized. Even though "fdisk -l" list them all

# fdisk -l

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbf92486e

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1  *     2048 234440703 234438656 111.8G 83 Linux

Detected sun disklabel with wrong version [0].
Detected sun disklabel with wrong vtoc.sanity [0x00000000].
Detected sun disklabel with wrong vtoc.nparts [0].
Warning: Wrong values need to be fixed up and will be corrected by w(rite)

Disk /dev/sdb: 558.9 GiB, 600127266816 bytes, 1172123568 sectors
Geometry: 255 heads, 63 sectors/track, 7425 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device         Start        End    Sectors   Size Id Type         Flags
/dev/sdb1          0    1959929    1959930   957M  1 Boot              
/dev/sdb2    1959930   99619064   97659135  46.6G 83 Linux native      
/dev/sdb3          0 1172118464 1172118465 558.9G  5 Whole disk        
/dev/sdb4   99619065  197278199   97659135  46.6G 83 Linux native      
/dev/sdb5  197278200 1172118464  974840265 464.9G 83 Linux native      

Partition table entries are not in disk order.

And "ls /dev/sd*" just lists the drive, not the partitions :

# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sdb

I'm using a btrfs filesystem in /dev/sda1 and I have e2fsprogs installed.
What am I missing?

Cheers,

Last edited by cafe (2015-01-28 02:29:04)

smirky · 2015-01-23 17:27:44

Are you sure you've connected the hard drive properly (supplying it with power and plugging it to the motherboard)?

alphaniner · 2015-01-23 18:30:40

Detected sun disklabel with wrong version [0].
Detected sun disklabel with wrong vtoc.sanity [0x00000000].
Detected sun disklabel with wrong vtoc.nparts [0].
Warning: Wrong values need to be fixed up and will be corrected by w(rite)

cafe · 2015-01-23 18:34:09

smirky wrote:

Are you sure you've connected the hard drive properly (supplying it with power and plugging it to the motherboard)?

Yes, I'm actually able to access my boot partition (the first partition listed by fdisk), but not my personal data.

@alphaniner : Do you think it is possible to correct these errors?

alphaniner · 2015-01-23 19:02:55

As the output says, "wrong values ... will be corrected by w(rite)".

Presumably that means you have to open the disk with fdisk and use the 'w' command.

If I were you though, I'd try to find a way to access the partitions without modifying the table and/or at least do some research to make sure it's safe to let fdisk make the corrections.

smirky · 2015-01-23 19:10:51

Strange. The only thing I found in the top results addressing your problem is this: http://forums.gentoo.org/viewtopic-t-21 … art-0.html

cafe · 2015-01-23 20:51:16

These are bad news..
I don't think I can change the partition table without loosing my data..

I'll try to put this HD back to a sun machine and recover my data.
Thank you all for the help.

I'll report back if I think of something else.
Cheers,

alphaniner · 2015-01-23 21:09:39

I think you still misunderstand. If you open the disk with fdisk, then immediately issue 'w' command, fdisk should automatically fix the disklabel for you. At least, that's my understanding of the output. But I'd still recommend looking into it further to make sure it's reasonably safe.

Knute · 2015-01-24 04:48:51

Doesn't a Sun system use a different architecture than an x86? If so, you may need to build the.. what is it SPARC or ARM compatibility into the kernel. I'm guessing that it's an architecture issue that you are encountering, but I'll be the first to admit that I'm not at all sure about that guess.

alphaniner · 2015-01-24 06:33:42

@Knute: SPARC was the Sun architecture, but that's not relevant. The issue is that Sun used a different method of partitioning called disklabel, and for whatever reason fdisk has issues with it.

nstgc · 2015-01-24 14:06:22

cafe wrote:

These are bad news..
I don't think I can change the partition table without loosing my data..
I'll try to put this HD back to a sun machine and recover my data.
Thank you all for the help.
I'll report back if I think of something else.
Cheers,

Could you dd the drive to another drive, then try it on the drive that contains the copy?

cafe · 2015-01-25 23:31:07

nstgc wrote:

Could you dd the drive to another drive, then try it on the drive that contains the copy?

Good idea! I'll get a spare drive to test it.
Thanks

cafe · 2015-01-26 14:47:49

I couldn't find a spare drive big enough to fit my data. This is a 600GB drive, and I only have a 300GB spare drive. I still want to try @alphaniner's solution though :

alphaniner wrote:

If you open the disk with fdisk, then immediately issue 'w' command, fdisk should automatically fix the disklabel for you.

If I copy the first 2MB from my drive with "dd" to a backup file, could I eventually revert any changes made by fdisk? That would be just in case something bad happens.

alphaniner · 2015-01-26 16:16:57

That could work, but I'd still only do it as a last resort. Instead, dd the first ~1GB (enough to capture sdb1) to a file. Then use fdisk to repair the table on the duplicate. If it seems to work, see if you are then able to mount the first partition. Even though it's just a duplicate, I'd mount it ro to be on the safe side.

nstgc · 2015-01-26 20:23:40

That's a good point. You can still dd to the other drive just to see if it will work before doing anything that may cause damage, even if you can't dd everything.

Actually, here is another idea if you don't mind listening to a bit of crazy.

Could you set up an array of some kind (mdadm or fake-raid) of multiple drives then fdisk on that? Several drives together may hold the 600GB. It may work.

Still, it does seem trying anything on a partial copy is better than trying something on the original.

cafe · 2015-01-27 22:48:42

I've finally did it!
Thank you all for the precious help.

As suggested by @alphaniner, I first copied the first gigabyte of the drive to a local file.
I've then ran :

# fdisk <file-with-first-gig>

and issued the command write to correct the partitions table. That allowed me to mount the first partition of the drive without any issues.

Then I proceeded to the actual drive. As before, I opened the drive with fdisk and corrected the partitions table, but weirdly enough, none of the partitions appeared under /dev/sdbX. I think there is something wrong with my udev rules. I had to issue the command :

# partprobe

from the parted package to make udev recognize my partitions. After that, the rest was a piece of cake.
I just had to mount the partition of interest to recover my data.

I discovered that this HD was actually holding a Linux From Scratch (LFS) that I'd compiled long ago.
Good times.. When I had time to do these things.

@nstgc

nstgc wrote:

Actually, here is another idea if you don't mind listening to a bit of crazy.
Could you set up an array of some kind (mdadm or fake-raid) of multiple drives then fdisk on that? Several drives together may hold the 600GB. It may work.

That was actually a good idea. But I just had one drive at my disposal. Thanks anyway for the help!

You can mark this thread as solved.
Thank you all!
Cheers,

alphaniner · 2015-01-28 00:17:56

Did you see any messages containing "re-read" after issuing 'w' in fdisk? Normally there's a system call to re-read the partition table after making changes. Due to the unusual situation, it could be that fdisk just didn't make the system call, or that it failed.

Anyway, that's just FYI. Glad you got it worked out. To mark the thread as solved, you need to edit the first post and add [Solved] to the title.

cafe · 2015-01-28 02:28:32

Yes, there was a message like that, so I restarted my pc to let the kernel & udev take care of it for me... But they didn't, so I had to issue the command partprobe myself...

Arch Linux

#1 2015-01-23 17:18:10

[Solved] Ext3 Filesystem not recognized - Sun partitions

#2 2015-01-23 17:27:44

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#3 2015-01-23 18:30:40

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#4 2015-01-23 18:34:09

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#5 2015-01-23 19:02:55

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#6 2015-01-23 19:10:51

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#7 2015-01-23 20:51:16

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#8 2015-01-23 21:09:39

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#9 2015-01-24 04:48:51

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#10 2015-01-24 06:33:42

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#11 2015-01-24 14:06:22

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#12 2015-01-25 23:31:07

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#13 2015-01-26 14:47:49

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#14 2015-01-26 16:16:57

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#15 2015-01-26 20:23:40

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#16 2015-01-27 22:48:42

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#17 2015-01-28 00:17:56

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

#18 2015-01-28 02:28:32

Re: [Solved] Ext3 Filesystem not recognized - Sun partitions

Board footer