urgent help need! disk partition info lost

urgent help need! disk partition info lost

[Paul L]

Due to some careless handling of my laptop, the SD card popped out
when the machine is still running. When I put it back in and reboot
the machine, it says "partition table error". I then ran fdisk and
recreated the single partition. Then I can no longer mount the nilfs2
partition that was on the SD card!

Can any one help to me recover the file system? I believe all data are
still there, but just some bits and pieces are missing for the mount
to work. Any help is greatly appreciated!

PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
back in time... so help please!

-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 2489 bytes --]

Did you first format this card with fdisk?
did you give it the exact same info this time around?

Can you read /dev/'sdcard' ? (sdcard being the device in the dev directory
where the card lives)

If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
and go to address 0400 - 04B0 to see if nilfs still exists?

be very careful no to save any data in hexedit, it will definitely and
finally
destoy your data.

0400 looks vagely like this:
00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
......44.....V..
00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
9..s............
00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
..fe............
00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
................
00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
.H......s..J....
00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
........s..J....
00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
..2.....s..J....
00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
.N..............
00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
.....Ls.=..E.
000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
.(DB=...Var64...
000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................

the 34 34 in the top line say this is nilfs.


cheers

jan de kruyf




On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Due to some careless handling of my laptop, the SD card popped out
> when the machine is still running. When I put it back in and reboot
> the machine, it says "partition table error". I then ran fdisk and
> recreated the single partition. Then I can no longer mount the nilfs2
> partition that was on the SD card!
>
> Can any one help to me recover the file system? I believe all data are
> still there, but just some bits and pieces are missing for the mount
> to work. Any help is greatly appreciated!
>
> PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
> back in time... so help please!
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 3200 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[Paul L]

Thanks for the tips. When I first used the SD card, I used fdisk to
create the partition.

The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
at the line 0x0400, it is indeed 34 34. What should I do then?

I tried gparted, but apparently it has no support for nilfs2.

Regards,
Paul Liu

On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Did you first format this card with fdisk?
> did you give it the exact same info this time around?
>
> Can you read /dev/'sdcard' ? (sdcard being the device in the dev directory
> where the card lives)
>
> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
> and go to address 0400 - 04B0 to see if nilfs still exists?
>
> be very careful no to save any data in hexedit, it will definitely and
> finally
> destoy your data.
>
> 0400 looks vagely like this:
> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> ......44.....V..
> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> 9..s............
> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> ..fe............
> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> ................
> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> .H......s..J....
> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> ........s..J....
> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> ..2.....s..J....
> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> .N..............
> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> .....Ls.=..E.
> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> .(DB=...Var64...
> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
>
> the 34 34 in the top line say this is nilfs.
>
>
> cheers
>
> jan de kruyf
>
>
>
>
> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Due to some careless handling of my laptop, the SD card popped out
>> when the machine is still running. When I put it back in and reboot
>> the machine, it says "partition table error". I then ran fdisk and
>> recreated the single partition. Then I can no longer mount the nilfs2
>> partition that was on the SD card!
>>
>> Can any one help to me recover the file system? I believe all data are
>> still there, but just some bits and pieces are missing for the mount
>> to work. Any help is greatly appreciated!
>>
>> PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
>> back in time... so help please!
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Paul L]

just want to add that I've always been using 1 partition on this
device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
doesn't show that 34 34 at line begining with 0x400, only hexedit
/dev/mmcblk0 shows it. Not sure if this is a problem.

Any help is greatly appreciated!


On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Thanks for the tips. When I first used the SD card, I used fdisk to
> create the partition.
>
> The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
> at the line 0x0400, it is indeed 34 34. What should I do then?
>
> I tried gparted, but apparently it has no support for nilfs2.
>
> Regards,
> Paul Liu
>
> On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Did you first format this card with fdisk?
>> did you give it the exact same info this time around?
>>
>> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
>> directory
>> where the card lives)
>>
>> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
>> and go to address 0400 - 04B0 to see if nilfs still exists?
>>
>> be very careful no to save any data in hexedit, it will definitely and
>> finally
>> destoy your data.
>>
>> 0400 looks vagely like this:
>> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>> ......44.....V..
>> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>> 9..s............
>> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>> ..fe............
>> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>> ................
>> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> ................
>> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> .H......s..J....
>> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> ........s..J....
>> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>> ..2.....s..J....
>> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>> .N..............
>> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
>> .....Ls.=..E.
>> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>> .(DB=...Var64...
>> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> ................
>> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> ................
>>
>> the 34 34 in the top line say this is nilfs.
>>
>>
>> cheers
>>
>> jan de kruyf
>>
>>
>>
>>
>> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> Due to some careless handling of my laptop, the SD card popped out
>>> when the machine is still running. When I put it back in and reboot
>>> the machine, it says "partition table error". I then ran fdisk and
>>> recreated the single partition. Then I can no longer mount the nilfs2
>>> partition that was on the SD card!
>>>
>>> Can any one help to me recover the file system? I believe all data are
>>> still there, but just some bits and pieces are missing for the mount
>>> to work. Any help is greatly appreciated!
>>>
>>> PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
>>> back in time... so help please!
>>>
>>> --
>>> Regards,
>>> Paul Liu
>>>
>>> Yale Haskell Group
>>> http://www.haskell.org/yale
>>> _______________________________________________
>>> users mailing list
>>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> https://www.nilfs.org/mailman/listinfo/users
>>>
>>
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 6046 bytes --]

 hallo,
Almost sounds like you had only the root master-boot-record /dev/mmcblk0
before and now you have added 1 main partition /dev/mmcblk0p1.

If (and only if) that is the case we have to undo the the 1st partition +
check that no nilfs is overwritten.
and I would have to urgently study fdisk to see exactly what it writes when
and where.
The last time I did tricks like these is quit a few years ago.

It is the Linux version of fdisk is it??

So here is the plan of action:
hexdump the master boot record to file.
like this:

dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512

then dump any partitions of the device in a format useful as input to
sfdisk. For example,
                  % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
sfdisk is a tool provided with the util-linux
package<http://www.kernel.org/pub/linux/utils/util-linux/>.


or you could use hexdump to get machine readable or man readable images.
Here is the man readable version:
hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
etc.

By the way boor records always end with '55 AA'.

Keep your files in a safe place in case we mess something we can at least go
back to the present situation.
If you could dd the whole drive to a file, now that would be magic indeed!
but you must have the space on a harddrive.
count=... is the number of sectors in the above line (dd ...) that you dump
to file.
Hexedit will tell you the number of sectors is you start it with -s option
and then go to the last sector.
DONT stop hexedit with control-x use cntl-c.
DONT use high level or even midlevel tools on a stuffed disk, it normally
messes more than it solves.
unless of course you really,really know what you are doing.
Fiddling the bytes is in general safe and gives results, if a man keeps a
cool head.

Please send me the fdisk version, the size of the card, and the mbr dump to
feast my eyes on.

cheers,

Jan de kruyf.



On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> just want to add that I've always been using 1 partition on this
> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
> doesn't show that 34 34 at line begining with 0x400, only hexedit
> /dev/mmcblk0 shows it. Not sure if this is a problem.
>
> Any help is greatly appreciated!
>
>
> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Thanks for the tips. When I first used the SD card, I used fdisk to
> > create the partition.
> >
> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
> > at the line 0x0400, it is indeed 34 34. What should I do then?
> >
> > I tried gparted, but apparently it has no support for nilfs2.
> >
> > Regards,
> > Paul Liu
> >
> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> Did you first format this card with fdisk?
> >> did you give it the exact same info this time around?
> >>
> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
> >> directory
> >> where the card lives)
> >>
> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >>
> >> be very careful no to save any data in hexedit, it will definitely and
> >> finally
> >> destoy your data.
> >>
> >> 0400 looks vagely like this:
> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >> ......44.....V..
> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >> 9..s............
> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >> ..fe............
> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >> ................
> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> ................
> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> .H......s..J....
> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> ........s..J....
> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >> ..2.....s..J....
> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >> .N..............
> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> >> .....Ls.=..E.
> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >> .(DB=...Var64...
> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> ................
> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> ................
> >>
> >> the 34 34 in the top line say this is nilfs.
> >>
> >>
> >> cheers
> >>
> >> jan de kruyf
> >>
> >>
> >>
> >>
> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >>> Due to some careless handling of my laptop, the SD card popped out
> >>> when the machine is still running. When I put it back in and reboot
> >>> the machine, it says "partition table error". I then ran fdisk and
> >>> recreated the single partition. Then I can no longer mount the nilfs2
> >>> partition that was on the SD card!
> >>>
> >>> Can any one help to me recover the file system? I believe all data are
> >>> still there, but just some bits and pieces are missing for the mount
> >>> to work. Any help is greatly appreciated!
> >>>
> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
> >>> back in time... so help please!
> >>>
> >>> --
> >>> Regards,
> >>> Paul Liu
> >>>
> >>> Yale Haskell Group
> >>> http://www.haskell.org/yale
> >>> _______________________________________________
> >>> users mailing list
> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> https://www.nilfs.org/mailman/listinfo/users
> >>>
> >>
> >
> >
> > --
> > Regards,
> > Paul Liu
> >
> > Yale Haskell Group
> > http://www.haskell.org/yale
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 8412 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[Paul L]

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

Thanks a lot for the instructions! I'm attaching the mbr and partition
table with this email.

I'm pretty sure I had 1 partition on the card, since my /etc/fstab
mounts mmcblk0p1.

I think something corrupted my disk first, and then what I've done to
the disk after noticing the corruption:

1. fdisk, it says use "w" will correct the error, so I did. But then
the one parition is gone.
2. fdisk again, create a single partition, then "w"

My mistake was that I didn't create a backup copy of the MBR. A hard
lesson learned :(

Also, why is that my hexedit doesn't take the "-s" option? It's
version 0.9.7, and can't edit bigger than 4.2GB.

My SD card is A-DATA brand, class 6, and 16GB.

I'm using Linux, and fdisk version (util-linux-ng 2.14.1)

Regards,
Paul Liu

On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>  hallo,
> Almost sounds like you had only the root master-boot-record /dev/mmcblk0
> before and now you have added 1 main partition /dev/mmcblk0p1.
>
> If (and only if) that is the case we have to undo the the 1st partition +
> check that no nilfs is overwritten.
> and I would have to urgently study fdisk to see exactly what it writes when
> and where.
> The last time I did tricks like these is quit a few years ago.
>
> It is the Linux version of fdisk is it??
>
> So here is the plan of action:
> hexdump the master boot record to file.
> like this:
>
> dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>
> then dump any partitions of the device in a format useful as input to
> sfdisk. For example,
>                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> sfdisk is a tool provided with the util-linux
> package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>
>
> or you could use hexdump to get machine readable or man readable images.
> Here is the man readable version:
> hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> etc.
>
> By the way boor records always end with '55 AA'.
>
> Keep your files in a safe place in case we mess something we can at least go
> back to the present situation.
> If you could dd the whole drive to a file, now that would be magic indeed!
> but you must have the space on a harddrive.
> count=... is the number of sectors in the above line (dd ...) that you dump
> to file.
> Hexedit will tell you the number of sectors is you start it with -s option
> and then go to the last sector.
> DONT stop hexedit with control-x use cntl-c.
> DONT use high level or even midlevel tools on a stuffed disk, it normally
> messes more than it solves.
> unless of course you really,really know what you are doing.
> Fiddling the bytes is in general safe and gives results, if a man keeps a
> cool head.
>
> Please send me the fdisk version, the size of the card, and the mbr dump to
> feast my eyes on.
>
> cheers,
>
> Jan de kruyf.
>
>
>
> On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> just want to add that I've always been using 1 partition on this
>> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
>> doesn't show that 34 34 at line begining with 0x400, only hexedit
>> /dev/mmcblk0 shows it. Not sure if this is a problem.
>>
>> Any help is greatly appreciated!
>>
>>
>> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Thanks for the tips. When I first used the SD card, I used fdisk to
>> > create the partition.
>> >
>> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
>> > at the line 0x0400, it is indeed 34 34. What should I do then?
>> >
>> > I tried gparted, but apparently it has no support for nilfs2.
>> >
>> > Regards,
>> > Paul Liu
>> >
>> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> Did you first format this card with fdisk?
>> >> did you give it the exact same info this time around?
>> >>
>> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
>> >> directory
>> >> where the card lives)
>> >>
>> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
>> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>> >>
>> >> be very careful no to save any data in hexedit, it will definitely and
>> >> finally
>> >> destoy your data.
>> >>
>> >> 0400 looks vagely like this:
>> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>> >> ......44.....V..
>> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>> >> 9..s............
>> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>> >> ..fe............
>> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>> >> ................
>> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> ................
>> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> .H......s..J....
>> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> ........s..J....
>> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>> >> ..2.....s..J....
>> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>> >> .N..............
>> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
>> >> .....Ls.=..E.
>> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>> >> .(DB=...Var64...
>> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> ................
>> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> ................
>> >>
>> >> the 34 34 in the top line say this is nilfs.
>> >>
>> >>
>> >> cheers
>> >>
>> >> jan de kruyf
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>
>> >>> Due to some careless handling of my laptop, the SD card popped out
>> >>> when the machine is still running. When I put it back in and reboot
>> >>> the machine, it says "partition table error". I then ran fdisk and
>> >>> recreated the single partition. Then I can no longer mount the nilfs2
>> >>> partition that was on the SD card!
>> >>>
>> >>> Can any one help to me recover the file system? I believe all data are
>> >>> still there, but just some bits and pieces are missing for the mount
>> >>> to work. Any help is greatly appreciated!
>> >>>
>> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my stuff
>> >>> back in time... so help please!
>> >>>
>> >>> --
>> >>> Regards,
>> >>> Paul Liu
>> >>>
>> >>> Yale Haskell Group
>> >>> http://www.haskell.org/yale
>> >>> _______________________________________________
>> >>> users mailing list
>> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> https://www.nilfs.org/mailman/listinfo/users
>> >>>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Paul Liu
>> >
>> > Yale Haskell Group
>> > http://www.haskell.org/yale
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

[-- Attachment #2: mmcblk0.out --]
[-- Type: application/octet-stream, Size: 273 bytes --]

# partition table of /dev/mmcblk0
unit: sectors

/dev/mmcblk0p1 : start=       16, size= 32235504, Id=83
/dev/mmcblk0p2 : start=        0, size=        0, Id= 0
/dev/mmcblk0p3 : start=        0, size=        0, Id= 0
/dev/mmcblk0p4 : start=        0, size=        0, Id= 0

[-- Attachment #3: backup-mmcblk0.mbr --]
[-- Type: application/octet-stream, Size: 512 bytes --]

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 8504 bytes --]

26 august 98: hexedit 0.9.5 release
september 2005:
    - version 1.2.12  this is the one I am running.

did I hear that you have always had /dev/mmcblk0p1 in fstab??

hd -n1536 /dev/mmcblk0 >part.start
hd -s8191 -n1536 /dev/mmcblk0 >part1.start
an to verify the last line:
hd -n1536 /dev/mmcblk0p1 >part1a.start
it will have the same data but different addresses if I did the sums right

and the difficult one is now the backup of the nilfs superblock
it is 10 sectors back from the end of the partition. but lets first get
these
then i will calculate what data I want.

cheers,

Jan de Kruyf

On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Thanks a lot for the instructions! I'm attaching the mbr and partition
> table with this email.
>
> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
> mounts mmcblk0p1.
>
> I think something corrupted my disk first, and then what I've done to
> the disk after noticing the corruption:
>
> 1. fdisk, it says use "w" will correct the error, so I did. But then
> the one parition is gone.
> 2. fdisk again, create a single partition, then "w"
>
> My mistake was that I didn't create a backup copy of the MBR. A hard
> lesson learned :(
>
> Also, why is that my hexedit doesn't take the "-s" option? It's
> version 0.9.7, and can't edit bigger than 4.2GB.
>
> My SD card is A-DATA brand, class 6, and 16GB.
>
> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>
> Regards,
> Paul Liu
>
> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >  hallo,
> > Almost sounds like you had only the root master-boot-record /dev/mmcblk0
> > before and now you have added 1 main partition /dev/mmcblk0p1.
> >
> > If (and only if) that is the case we have to undo the the 1st partition +
> > check that no nilfs is overwritten.
> > and I would have to urgently study fdisk to see exactly what it writes
> when
> > and where.
> > The last time I did tricks like these is quit a few years ago.
> >
> > It is the Linux version of fdisk is it??
> >
> > So here is the plan of action:
> > hexdump the master boot record to file.
> > like this:
> >
> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >
> > then dump any partitions of the device in a format useful as input to
> > sfdisk. For example,
> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> > sfdisk is a tool provided with the util-linux
> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >
> >
> > or you could use hexdump to get machine readable or man readable images.
> > Here is the man readable version:
> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> > etc.
> >
> > By the way boor records always end with '55 AA'.
> >
> > Keep your files in a safe place in case we mess something we can at least
> go
> > back to the present situation.
> > If you could dd the whole drive to a file, now that would be magic
> indeed!
> > but you must have the space on a harddrive.
> > count=... is the number of sectors in the above line (dd ...) that you
> dump
> > to file.
> > Hexedit will tell you the number of sectors is you start it with -s
> option
> > and then go to the last sector.
> > DONT stop hexedit with control-x use cntl-c.
> > DONT use high level or even midlevel tools on a stuffed disk, it normally
> > messes more than it solves.
> > unless of course you really,really know what you are doing.
> > Fiddling the bytes is in general safe and gives results, if a man keeps a
> > cool head.
> >
> > Please send me the fdisk version, the size of the card, and the mbr dump
> to
> > feast my eyes on.
> >
> > cheers,
> >
> > Jan de kruyf.
> >
> >
> >
> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> just want to add that I've always been using 1 partition on this
> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >>
> >> Any help is greatly appreciated!
> >>
> >>
> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > Thanks for the tips. When I first used the SD card, I used fdisk to
> >> > create the partition.
> >> >
> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
> >> >
> >> > I tried gparted, but apparently it has no support for nilfs2.
> >> >
> >> > Regards,
> >> > Paul Liu
> >> >
> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> Did you first format this card with fdisk?
> >> >> did you give it the exact same info this time around?
> >> >>
> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
> >> >> directory
> >> >> where the card lives)
> >> >>
> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >> >>
> >> >> be very careful no to save any data in hexedit, it will definitely
> and
> >> >> finally
> >> >> destoy your data.
> >> >>
> >> >> 0400 looks vagely like this:
> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >> >> ......44.....V..
> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >> >> 9..s............
> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >> >> ..fe............
> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >> >> ................
> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> ................
> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> .H......s..J....
> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> ........s..J....
> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >> >> ..2.....s..J....
> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >> >> .N..............
> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> >> >> .....Ls.=..E.
> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >> >> .(DB=...Var64...
> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> ................
> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> ................
> >> >>
> >> >> the 34 34 in the top line say this is nilfs.
> >> >>
> >> >>
> >> >> cheers
> >> >>
> >> >> jan de kruyf
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>
> >> >>> Due to some careless handling of my laptop, the SD card popped out
> >> >>> when the machine is still running. When I put it back in and reboot
> >> >>> the machine, it says "partition table error". I then ran fdisk and
> >> >>> recreated the single partition. Then I can no longer mount the
> nilfs2
> >> >>> partition that was on the SD card!
> >> >>>
> >> >>> Can any one help to me recover the file system? I believe all data
> are
> >> >>> still there, but just some bits and pieces are missing for the mount
> >> >>> to work. Any help is greatly appreciated!
> >> >>>
> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my
> stuff
> >> >>> back in time... so help please!
> >> >>>
> >> >>> --
> >> >>> Regards,
> >> >>> Paul Liu
> >> >>>
> >> >>> Yale Haskell Group
> >> >>> http://www.haskell.org/yale
> >> >>> _______________________________________________
> >> >>> users mailing list
> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >>>
> >> >>
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Paul Liu
> >> >
> >> > Yale Haskell Group
> >> > http://www.haskell.org/yale
> >> >
> >>
> >>
> >> --
> >> Regards,
> >> Paul Liu
> >>
> >> Yale Haskell Group
> >> http://www.haskell.org/yale
> >> _______________________________________________
> >> users mailing list
> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> https://www.nilfs.org/mailman/listinfo/users
> >>
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
>
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>
>

[-- Attachment #1.2: Type: text/html, Size: 12268 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[Paul L]

On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 26 august 98: hexedit 0.9.5 release
> september 2005:
>     - version 1.2.12  this is the one I am running.

Ah, I must be using the wrong hexedit.. now I've installed the same one you use.

> did I hear that you have always had /dev/mmcblk0p1 in fstab??

Yes. What I put there is:

/dev/mmcblk0p1 /home    nilfs2 defaults           1 1

> hd -n1536 /dev/mmcblk0 >part.start
> hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> an to verify the last line:
> hd -n1536 /dev/mmcblk0p1 >part1a.start

Here is the output (I use hexdump instead of hd, hopefully they are the same)

bash-3.1# cat part.start
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 0002 0000 0000 3434 0100 0000 b209 5b31
0000410 1183 794c 0002 0000 07af 0000 0000 0000
0000420 0000 d780 0003 0000 0001 0000 0000 0000
0000430 0800 0000 0005 0000 090b 000e 0000 0000
0000440 0710 0035 0000 0000 8502 0008 0000 0000
0000450 8800 000b 0000 0000 93c1 493c 0000 0000
0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
00004b0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000600
bash-3.1# cat part1.start
0001fff 0000 0000 0000 0000 0000 0000 0000 0000
*
00025ff
bash-3.1# cat part1a.start
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000600

Regards,
Paul Liu

> On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Thanks a lot for the instructions! I'm attaching the mbr and partition
>> table with this email.
>>
>> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
>> mounts mmcblk0p1.
>>
>> I think something corrupted my disk first, and then what I've done to
>> the disk after noticing the corruption:
>>
>> 1. fdisk, it says use "w" will correct the error, so I did. But then
>> the one parition is gone.
>> 2. fdisk again, create a single partition, then "w"
>>
>> My mistake was that I didn't create a backup copy of the MBR. A hard
>> lesson learned :(
>>
>> Also, why is that my hexedit doesn't take the "-s" option? It's
>> version 0.9.7, and can't edit bigger than 4.2GB.
>>
>> My SD card is A-DATA brand, class 6, and 16GB.
>>
>> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>>
>> Regards,
>> Paul Liu
>>
>> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >  hallo,
>> > Almost sounds like you had only the root master-boot-record /dev/mmcblk0
>> > before and now you have added 1 main partition /dev/mmcblk0p1.
>> >
>> > If (and only if) that is the case we have to undo the the 1st partition
>> > +
>> > check that no nilfs is overwritten.
>> > and I would have to urgently study fdisk to see exactly what it writes
>> when
>> > and where.
>> > The last time I did tricks like these is quit a few years ago.
>> >
>> > It is the Linux version of fdisk is it??
>> >
>> > So here is the plan of action:
>> > hexdump the master boot record to file.
>> > like this:
>> >
>> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >
>> > then dump any partitions of the device in a format useful as input to
>> > sfdisk. For example,
>> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> > sfdisk is a tool provided with the util-linux
>> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >
>> >
>> > or you could use hexdump to get machine readable or man readable images.
>> > Here is the man readable version:
>> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> > etc.
>> >
>> > By the way boor records always end with '55 AA'.
>> >
>> > Keep your files in a safe place in case we mess something we can at
>> > least
>> go
>> > back to the present situation.
>> > If you could dd the whole drive to a file, now that would be magic
>> indeed!
>> > but you must have the space on a harddrive.
>> > count=... is the number of sectors in the above line (dd ...) that you
>> dump
>> > to file.
>> > Hexedit will tell you the number of sectors is you start it with -s
>> option
>> > and then go to the last sector.
>> > DONT stop hexedit with control-x use cntl-c.
>> > DONT use high level or even midlevel tools on a stuffed disk, it
>> > normally
>> > messes more than it solves.
>> > unless of course you really,really know what you are doing.
>> > Fiddling the bytes is in general safe and gives results, if a man keeps
>> > a
>> > cool head.
>> >
>> > Please send me the fdisk version, the size of the card, and the mbr dump
>> to
>> > feast my eyes on.
>> >
>> > cheers,
>> >
>> > Jan de kruyf.
>> >
>> >
>> >
>> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> just want to add that I've always been using 1 partition on this
>> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
>> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
>> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >>
>> >> Any help is greatly appreciated!
>> >>
>> >>
>> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> > Thanks for the tips. When I first used the SD card, I used fdisk to
>> >> > create the partition.
>> >> >
>> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows that
>> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
>> >> >
>> >> > I tried gparted, but apparently it has no support for nilfs2.
>> >> >
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> Did you first format this card with fdisk?
>> >> >> did you give it the exact same info this time around?
>> >> >>
>> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
>> >> >> directory
>> >> >> where the card lives)
>> >> >>
>> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
>> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>> >> >>
>> >> >> be very careful no to save any data in hexedit, it will definitely
>> and
>> >> >> finally
>> >> >> destoy your data.
>> >> >>
>> >> >> 0400 looks vagely like this:
>> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>> >> >> ......44.....V..
>> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>> >> >> 9..s............
>> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>> >> >> ..fe............
>> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>> >> >> ................
>> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> ................
>> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> .H......s..J....
>> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> ........s..J....
>> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>> >> >> ..2.....s..J....
>> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>> >> >> .N..............
>> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
>> >> >> .....Ls.=..E.
>> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>> >> >> .(DB=...Var64...
>> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> ................
>> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> ................
>> >> >>
>> >> >> the 34 34 in the top line say this is nilfs.
>> >> >>
>> >> >>
>> >> >> cheers
>> >> >>
>> >> >> jan de kruyf
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>
>> >> >>> Due to some careless handling of my laptop, the SD card popped out
>> >> >>> when the machine is still running. When I put it back in and reboot
>> >> >>> the machine, it says "partition table error". I then ran fdisk and
>> >> >>> recreated the single partition. Then I can no longer mount the
>> nilfs2
>> >> >>> partition that was on the SD card!
>> >> >>>
>> >> >>> Can any one help to me recover the file system? I believe all data
>> are
>> >> >>> still there, but just some bits and pieces are missing for the
>> >> >>> mount
>> >> >>> to work. Any help is greatly appreciated!
>> >> >>>
>> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my
>> stuff
>> >> >>> back in time... so help please!
>> >> >>>
>> >> >>> --
>> >> >>> Regards,
>> >> >>> Paul Liu
>> >> >>>
>> >> >>> Yale Haskell Group
>> >> >>> http://www.haskell.org/yale
>> >> >>> _______________________________________________
>> >> >>> users mailing list
>> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > Yale Haskell Group
>> >> > http://www.haskell.org/yale
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> Yale Haskell Group
>> >> http://www.haskell.org/yale
>> >> _______________________________________________
>> >> users mailing list
>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>>
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 15999 bytes --]

Hallo,
here we go again. As a matter of interest, what version of nilfs and what
distribution are you running? And what processor?
your endiannes confused me at first.

glad you fixed your hexedit

I have looked at some numbers in the superblock and they look ok. I do
wonder if you have the garbage collector running.

now for the second superblock. Please pay attention to the exact place of
it. Because it is of vital
importance if it in in partition 1 or in the root of the disk.

the first superblock sits as you observed in the root. The flags say amongst
others that it was unmounted cleanly but errors were detected.

see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations. in the
distribution.
/**
 * struct nilfs_super_block - structure of super block on disk
 */
struct nilfs_super_block {
....
translates bit for bit to what you see written in the super block on disk.

Here is an example from a partition of mine on how to discover the
superblock copy
it should read the same as the 1st but in your case it might not.
It is a leftshift - subtract 1 - right shift algorithm.
go in hexedit to the last data with ">" (shift .)
note the address of the last byte (the size of the partion)
in mine:
6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
or the status line might give it
the address of the copy is now at 6566A000
i.e. 6566B has 1 subtracted from it and the 3 least significant digits have
been zeroed.

so please dump yours, see if the algorithm works on the 1st part or on the
root or both,
so we know where it is.
And check if it is exactly the same as the first one you send me
"0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
etc.

the next thing to discover is where the start of (nilfs)segment 0 is.
I am not quite sure what is written in it, but the signature is quite
distinct.
This is what it looks on my machine:

00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
................
00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
..G[Qb......8...
00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
...........J....
00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
............2...
00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
................
00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
........{...{...
00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
................
00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
................
00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
................
00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
................
00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
................
000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
................
000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
................
000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
................
000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
................
000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
................
000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
................
00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
................
00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
................
00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
................
00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
................
00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
................
00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
................
00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
................
00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
................
00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
................
00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
................
000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
................
000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
................
000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
................
000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
................
000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
................

Segment 0 starts at hex 1000 of a nilfs partition as you can see above and
carries on for quite a while like this.

so have a look on your disk if it sits at 1000 of the root partition or at
1000 of partition 1.

Once we have these things sorted I would say that we are ready to plant the
_right_ superblock of the 2
in the right place and see if the partition is recoqnized by nilfs.
Off course we will save the place where we are going to plant that block
first.

And now back to the birthday party . . . .

Cheers,

Jan



On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 26 august 98: hexedit 0.9.5 release
> > september 2005:
> >     - version 1.2.12  this is the one I am running.
>
> Ah, I must be using the wrong hexedit.. now I've installed the same one you
> use.
>
> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>
> Yes. What I put there is:
>
> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>
> > hd -n1536 /dev/mmcblk0 >part.start
> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> > an to verify the last line:
> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>
> Here is the output (I use hexdump instead of hd, hopefully they are the
> same)
>
> bash-3.1# cat part.start
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000600
> bash-3.1# cat part1.start
> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 00025ff
> bash-3.1# cat part1a.start
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000600
>
> Regards,
> Paul Liu
>
> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> Thanks a lot for the instructions! I'm attaching the mbr and partition
> >> table with this email.
> >>
> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
> >> mounts mmcblk0p1.
> >>
> >> I think something corrupted my disk first, and then what I've done to
> >> the disk after noticing the corruption:
> >>
> >> 1. fdisk, it says use "w" will correct the error, so I did. But then
> >> the one parition is gone.
> >> 2. fdisk again, create a single partition, then "w"
> >>
> >> My mistake was that I didn't create a backup copy of the MBR. A hard
> >> lesson learned :(
> >>
> >> Also, why is that my hexedit doesn't take the "-s" option? It's
> >> version 0.9.7, and can't edit bigger than 4.2GB.
> >>
> >> My SD card is A-DATA brand, class 6, and 16GB.
> >>
> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
> >>
> >> Regards,
> >> Paul Liu
> >>
> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >  hallo,
> >> > Almost sounds like you had only the root master-boot-record
> /dev/mmcblk0
> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
> >> >
> >> > If (and only if) that is the case we have to undo the the 1st
> partition
> >> > +
> >> > check that no nilfs is overwritten.
> >> > and I would have to urgently study fdisk to see exactly what it writes
> >> when
> >> > and where.
> >> > The last time I did tricks like these is quit a few years ago.
> >> >
> >> > It is the Linux version of fdisk is it??
> >> >
> >> > So here is the plan of action:
> >> > hexdump the master boot record to file.
> >> > like this:
> >> >
> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >> >
> >> > then dump any partitions of the device in a format useful as input to
> >> > sfdisk. For example,
> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> >> > sfdisk is a tool provided with the util-linux
> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >> >
> >> >
> >> > or you could use hexdump to get machine readable or man readable
> images.
> >> > Here is the man readable version:
> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> >> > etc.
> >> >
> >> > By the way boor records always end with '55 AA'.
> >> >
> >> > Keep your files in a safe place in case we mess something we can at
> >> > least
> >> go
> >> > back to the present situation.
> >> > If you could dd the whole drive to a file, now that would be magic
> >> indeed!
> >> > but you must have the space on a harddrive.
> >> > count=... is the number of sectors in the above line (dd ...) that you
> >> dump
> >> > to file.
> >> > Hexedit will tell you the number of sectors is you start it with -s
> >> option
> >> > and then go to the last sector.
> >> > DONT stop hexedit with control-x use cntl-c.
> >> > DONT use high level or even midlevel tools on a stuffed disk, it
> >> > normally
> >> > messes more than it solves.
> >> > unless of course you really,really know what you are doing.
> >> > Fiddling the bytes is in general safe and gives results, if a man
> keeps
> >> > a
> >> > cool head.
> >> >
> >> > Please send me the fdisk version, the size of the card, and the mbr
> dump
> >> to
> >> > feast my eyes on.
> >> >
> >> > cheers,
> >> >
> >> > Jan de kruyf.
> >> >
> >> >
> >> >
> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >
> >> >> just want to add that I've always been using 1 partition on this
> >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
> >> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >> >>
> >> >> Any help is greatly appreciated!
> >> >>
> >> >>
> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> > Thanks for the tips. When I first used the SD card, I used fdisk to
> >> >> > create the partition.
> >> >> >
> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows
> that
> >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
> >> >> >
> >> >> > I tried gparted, but apparently it has no support for nilfs2.
> >> >> >
> >> >> > Regards,
> >> >> > Paul Liu
> >> >> >
> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >> Did you first format this card with fdisk?
> >> >> >> did you give it the exact same info this time around?
> >> >> >>
> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
> >> >> >> directory
> >> >> >> where the card lives)
> >> >> >>
> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as root?
> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >> >> >>
> >> >> >> be very careful no to save any data in hexedit, it will definitely
> >> and
> >> >> >> finally
> >> >> >> destoy your data.
> >> >> >>
> >> >> >> 0400 looks vagely like this:
> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >> >> >> ......44.....V..
> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >> >> >> 9..s............
> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> ..fe............
> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> ................
> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> ................
> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> .H......s..J....
> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> ........s..J....
> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >> >> >> ..2.....s..J....
> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >> >> >> .N..............
> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> >> >> >> .....Ls.=..E.
> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >> >> >> .(DB=...Var64...
> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> ................
> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> ................
> >> >> >>
> >> >> >> the 34 34 in the top line say this is nilfs.
> >> >> >>
> >> >> >>
> >> >> >> cheers
> >> >> >>
> >> >> >> jan de kruyf
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >>
> >> >> >>> Due to some careless handling of my laptop, the SD card popped
> out
> >> >> >>> when the machine is still running. When I put it back in and
> reboot
> >> >> >>> the machine, it says "partition table error". I then ran fdisk
> and
> >> >> >>> recreated the single partition. Then I can no longer mount the
> >> nilfs2
> >> >> >>> partition that was on the SD card!
> >> >> >>>
> >> >> >>> Can any one help to me recover the file system? I believe all
> data
> >> are
> >> >> >>> still there, but just some bits and pieces are missing for the
> >> >> >>> mount
> >> >> >>> to work. Any help is greatly appreciated!
> >> >> >>>
> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my
> >> stuff
> >> >> >>> back in time... so help please!
> >> >> >>>
> >> >> >>> --
> >> >> >>> Regards,
> >> >> >>> Paul Liu
> >> >> >>>
> >> >> >>> Yale Haskell Group
> >> >> >>> http://www.haskell.org/yale
> >> >> >>> _______________________________________________
> >> >> >>> users mailing list
> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Paul Liu
> >> >> >
> >> >> > Yale Haskell Group
> >> >> > http://www.haskell.org/yale
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Paul Liu
> >> >>
> >> >> Yale Haskell Group
> >> >> http://www.haskell.org/yale
> >> >> _______________________________________________
> >> >> users mailing list
> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>
> >> >
> >>
> >>
> >> --
> >> Regards,
> >> Paul Liu
> >>
> >> Yale Haskell Group
> >> http://www.haskell.org/yale
> >>
> >> _______________________________________________
> >> users mailing list
> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> https://www.nilfs.org/mailman/listinfo/users
> >>
> >>
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 22281 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[David Arendt]

Hi,

I am not sure if it has already been said, but before trying any
recovery, I would recommend to do a dd of the device to a file and would
also recommend to do recovery tries on a copy of this file mounted as a
loop device, this way you can make sure not to destroy more data by the
recovery tries. I would also recommend passing the -i parameter to the
mount command during recovery tries in order to prevent garbage
collection from running.

Bye,
David Arendt

Jan de Kruyf wrote:
> Hallo,
> here we go again. As a matter of interest, what version of nilfs and
> what distribution are you running? And what processor?
> your endiannes confused me at first.
>
> glad you fixed your hexedit
>
> I have looked at some numbers in the superblock and they look ok. I do
> wonder if you have the garbage collector running.
>
> now for the second superblock. Please pay attention to the exact place
> of it. Because it is of vital
> importance if it in in partition 1 or in the root of the disk.
>
> the first superblock sits as you observed in the root. The flags say
> amongst others that it was unmounted cleanly but errors were detected.
>
> see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations.
> in the distribution.
> /**
>  * struct nilfs_super_block - structure of super block on disk
>  */
> struct nilfs_super_block {
> ....
> translates bit for bit to what you see written in the super block on disk.
>
> Here is an example from a partition of mine on how to discover the
> superblock copy
> it should read the same as the 1st but in your case it might not.
> It is a leftshift - subtract 1 - right shift algorithm.
> go in hexedit to the last data with ">" (shift .)
> note the address of the last byte (the size of the partion)
> in mine:
> 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> ................
> or the status line might give it
> the address of the copy is now at 6566A000
> i.e. 6566B has 1 subtracted from it and the 3 least significant digits
> have been zeroed.
>
> so please dump yours, see if the algorithm works on the 1st part or on
> the root or both,
> so we know where it is.
> And check if it is exactly the same as the first one you send me
> "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> etc.
>
> the next thing to discover is where the start of (nilfs)segment 0 is.
> I am not quite sure what is written in it, but the signature is quite
> distinct.
> This is what it looks on my machine:
>
> 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> ................
> 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> ................
> 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> ................
> 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> ................
> 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00 
> ..G[Qb......8...
> 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00 
> ...........J....
> 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00 
> ............2...
> 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00 
> ................
> 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00 
> ........{...{...
> 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00 
> ................
> 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00 
> ................
> 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00 
> ................
> 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00 
> ................
> 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00 
> ................
> 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00 
> ................
> 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00 
> ................
> 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00 
> ................
> 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00 
> ................
> 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00 
> ................
> 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00 
> ................
> 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00 
> ................
> 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00 
> ................
> 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00 
> ................
> 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00 
> ................
> 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00 
> ................
> 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00 
> ................
> 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00 
> ................
> 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00 
> ................
> 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00 
> ................
> 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00 
> ................
> 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00 
> ................
> 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00 
> ................
> 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00 
> ................
> 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00 
> ................
> 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00 
> ................
>
> Segment 0 starts at hex 1000 of a nilfs partition as you can see above
> and carries on for quite a while like this.
>
> so have a look on your disk if it sits at 1000 of the root partition
> or at 1000 of partition 1.
>
> Once we have these things sorted I would say that we are ready to
> plant the _right_ superblock of the 2
> in the right place and see if the partition is recoqnized by nilfs.
> Off course we will save the place where we are going to plant that
> block first.
>
> And now back to the birthday party . . . .
>
> Cheers,
>
> Jan
>
>
>
> On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
>     On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     > 26 august 98: hexedit 0.9.5 release
>     > september 2005:
>     >     - version 1.2.12  this is the one I am running.
>
>     Ah, I must be using the wrong hexedit.. now I've installed the
>     same one you use.
>
>     > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>
>     Yes. What I put there is:
>
>     /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>
>     > hd -n1536 /dev/mmcblk0 >part.start
>     > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>     > an to verify the last line:
>     > hd -n1536 /dev/mmcblk0p1 >part1a.start
>
>     Here is the output (I use hexdump instead of hd, hopefully they
>     are the same)
>
>     bash-3.1# cat part.start
>     0000000 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>     00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>     00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>     0000200 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>     0000410 1183 794c 0002 0000 07af 0000 0000 0000
>     0000420 0000 d780 0003 0000 0001 0000 0000 0000
>     0000430 0800 0000 0005 0000 090b 000e 0000 0000
>     0000440 0710 0035 0000 0000 8502 0008 0000 0000
>     0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>     0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>     0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>     0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>     0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>     00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>     00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     0000600
>     bash-3.1# cat part1.start
>     0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     00025ff
>     bash-3.1# cat part1a.start
>     0000000 0000 0000 0000 0000 0000 0000 0000 0000
>     *
>     0000600
>
>     Regards,
>     Paul Liu
>
>     > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >
>     >> Thanks a lot for the instructions! I'm attaching the mbr and
>     partition
>     >> table with this email.
>     >>
>     >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
>     >> mounts mmcblk0p1.
>     >>
>     >> I think something corrupted my disk first, and then what I've
>     done to
>     >> the disk after noticing the corruption:
>     >>
>     >> 1. fdisk, it says use "w" will correct the error, so I did. But
>     then
>     >> the one parition is gone.
>     >> 2. fdisk again, create a single partition, then "w"
>     >>
>     >> My mistake was that I didn't create a backup copy of the MBR. A
>     hard
>     >> lesson learned :(
>     >>
>     >> Also, why is that my hexedit doesn't take the "-s" option? It's
>     >> version 0.9.7, and can't edit bigger than 4.2GB.
>     >>
>     >> My SD card is A-DATA brand, class 6, and 16GB.
>     >>
>     >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>     >>
>     >> Regards,
>     >> Paul Liu
>     >>
>     >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >  hallo,
>     >> > Almost sounds like you had only the root master-boot-record
>     /dev/mmcblk0
>     >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>     >> >
>     >> > If (and only if) that is the case we have to undo the the 1st
>     partition
>     >> > +
>     >> > check that no nilfs is overwritten.
>     >> > and I would have to urgently study fdisk to see exactly what
>     it writes
>     >> when
>     >> > and where.
>     >> > The last time I did tricks like these is quit a few years ago.
>     >> >
>     >> > It is the Linux version of fdisk is it??
>     >> >
>     >> > So here is the plan of action:
>     >> > hexdump the master boot record to file.
>     >> > like this:
>     >> >
>     >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>     >> >
>     >> > then dump any partitions of the device in a format useful as
>     input to
>     >> > sfdisk. For example,
>     >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>     >> > sfdisk is a tool provided with the util-linux
>     >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>     >> >
>     >> >
>     >> > or you could use hexdump to get machine readable or man
>     readable images.
>     >> > Here is the man readable version:
>     >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>     >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>     >> > etc.
>     >> >
>     >> > By the way boor records always end with '55 AA'.
>     >> >
>     >> > Keep your files in a safe place in case we mess something we
>     can at
>     >> > least
>     >> go
>     >> > back to the present situation.
>     >> > If you could dd the whole drive to a file, now that would be
>     magic
>     >> indeed!
>     >> > but you must have the space on a harddrive.
>     >> > count=... is the number of sectors in the above line (dd ...)
>     that you
>     >> dump
>     >> > to file.
>     >> > Hexedit will tell you the number of sectors is you start it
>     with -s
>     >> option
>     >> > and then go to the last sector.
>     >> > DONT stop hexedit with control-x use cntl-c.
>     >> > DONT use high level or even midlevel tools on a stuffed disk, it
>     >> > normally
>     >> > messes more than it solves.
>     >> > unless of course you really,really know what you are doing.
>     >> > Fiddling the bytes is in general safe and gives results, if a
>     man keeps
>     >> > a
>     >> > cool head.
>     >> >
>     >> > Please send me the fdisk version, the size of the card, and
>     the mbr dump
>     >> to
>     >> > feast my eyes on.
>     >> >
>     >> > cheers,
>     >> >
>     >> > Jan de kruyf.
>     >> >
>     >> >
>     >> >
>     >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >
>     >> >> just want to add that I've always been using 1 partition on this
>     >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
>     >> >> doesn't show that 34 34 at line begining with 0x400, only
>     hexedit
>     >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>     >> >>
>     >> >> Any help is greatly appreciated!
>     >> >>
>     >> >>
>     >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> > Thanks for the tips. When I first used the SD card, I used
>     fdisk to
>     >> >> > create the partition.
>     >> >> >
>     >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0
>     shows that
>     >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
>     >> >> >
>     >> >> > I tried gparted, but apparently it has no support for nilfs2.
>     >> >> >
>     >> >> > Regards,
>     >> >> > Paul Liu
>     >> >> >
>     >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >> Did you first format this card with fdisk?
>     >> >> >> did you give it the exact same info this time around?
>     >> >> >>
>     >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in
>     the dev
>     >> >> >> directory
>     >> >> >> where the card lives)
>     >> >> >>
>     >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal
>     as root?
>     >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>     >> >> >>
>     >> >> >> be very careful no to save any data in hexedit, it will
>     definitely
>     >> and
>     >> >> >> finally
>     >> >> >> destoy your data.
>     >> >> >>
>     >> >> >> 0400 looks vagely like this:
>     >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>     >> >> >> ......44.....V..
>     >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>     >> >> >> 9..s............
>     >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>     >> >> >> ..fe............
>     >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>     >> >> >> ................
>     >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     >> >> >> ................
>     >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>     >> >> >> .H......s..J....
>     >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>     >> >> >> ........s..J....
>     >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>     >> >> >> ..2.....s..J....
>     >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>     >> >> >> .N..............
>     >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45
>     85  ..
>     >> >> >> .....Ls.=..E.
>     >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>     >> >> >> .(DB=...Var64...
>     >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     >> >> >> ................
>     >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     >> >> >> ................
>     >> >> >>
>     >> >> >> the 34 34 in the top line say this is nilfs.
>     >> >> >>
>     >> >> >>
>     >> >> >> cheers
>     >> >> >>
>     >> >> >> jan de kruyf
>     >> >> >>
>     >> >> >>
>     >> >> >>
>     >> >> >>
>     >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >>
>     >> >> >>> Due to some careless handling of my laptop, the SD card
>     popped out
>     >> >> >>> when the machine is still running. When I put it back in
>     and reboot
>     >> >> >>> the machine, it says "partition table error". I then ran
>     fdisk and
>     >> >> >>> recreated the single partition. Then I can no longer
>     mount the
>     >> nilfs2
>     >> >> >>> partition that was on the SD card!
>     >> >> >>>
>     >> >> >>> Can any one help to me recover the file system? I
>     believe all data
>     >> are
>     >> >> >>> still there, but just some bits and pieces are missing
>     for the
>     >> >> >>> mount
>     >> >> >>> to work. Any help is greatly appreciated!
>     >> >> >>>
>     >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I
>     can get my
>     >> stuff
>     >> >> >>> back in time... so help please!
>     >> >> >>>
>     >> >> >>> --
>     >> >> >>> Regards,
>     >> >> >>> Paul Liu
>     >> >> >>>
>     >> >> >>> Yale Haskell Group
>     >> >> >>> http://www.haskell.org/yale
>     >> >> >>> _______________________________________________
>     >> >> >>> users mailing list
>     >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>     >> >> >>>
>     >> >> >>
>     >> >> >
>     >> >> >
>     >> >> > --
>     >> >> > Regards,
>     >> >> > Paul Liu
>     >> >> >
>     >> >> > Yale Haskell Group
>     >> >> > http://www.haskell.org/yale
>     >> >> >
>     >> >>
>     >> >>
>     >> >> --
>     >> >> Regards,
>     >> >> Paul Liu
>     >> >>
>     >> >> Yale Haskell Group
>     >> >> http://www.haskell.org/yale
>     >> >> _______________________________________________
>     >> >> users mailing list
>     >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> >> https://www.nilfs.org/mailman/listinfo/users
>     >> >>
>     >> >
>     >>
>     >>
>     >> --
>     >> Regards,
>     >> Paul Liu
>     >>
>     >> Yale Haskell Group
>     >> http://www.haskell.org/yale
>     >>
>     >> _______________________________________________
>     >> users mailing list
>     >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> https://www.nilfs.org/mailman/listinfo/users
>     >>
>     >>
>     >
>
>
>     --
>     Regards,
>     Paul Liu
>
>     Yale Haskell Group
>     http://www.haskell.org/yale
>     _______________________________________________
>     users mailing list
>     users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     https://www.nilfs.org/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>   

Re: urgent help need! disk partition info lost

[Paul L]

I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
Aspire One model A101,  which uses Atom CPU.

I failed to find the superblock towards the end of either mmcblk0 or
mmcblk0p1, but a search of hex string 0200000000003434 reveals that:

mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
at address 00401000.

mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
at 003FF000.

I hope my SD card is not messing up itself by rearranging the blocks!

Regards,
Paul Liu

On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hallo,
> here we go again. As a matter of interest, what version of nilfs and what
> distribution are you running? And what processor?
> your endiannes confused me at first.
>
> glad you fixed your hexedit
>
> I have looked at some numbers in the superblock and they look ok. I do
> wonder if you have the garbage collector running.
>
> now for the second superblock. Please pay attention to the exact place of
> it. Because it is of vital
> importance if it in in partition 1 or in the root of the disk.
>
> the first superblock sits as you observed in the root. The flags say amongst
> others that it was unmounted cleanly but errors were detected.
>
> see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations. in the
> distribution.
> /**
>  * struct nilfs_super_block - structure of super block on disk
>  */
> struct nilfs_super_block {
> ....
> translates bit for bit to what you see written in the super block on disk.
>
> Here is an example from a partition of mine on how to discover the
> superblock copy
> it should read the same as the 1st but in your case it might not.
> It is a leftshift - subtract 1 - right shift algorithm.
> go in hexedit to the last data with ">" (shift .)
> note the address of the last byte (the size of the partion)
> in mine:
> 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> or the status line might give it
> the address of the copy is now at 6566A000
> i.e. 6566B has 1 subtracted from it and the 3 least significant digits have
> been zeroed.
>
> so please dump yours, see if the algorithm works on the 1st part or on the
> root or both,
> so we know where it is.
> And check if it is exactly the same as the first one you send me
> "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> etc.
>
> the next thing to discover is where the start of (nilfs)segment 0 is.
> I am not quite sure what is written in it, but the signature is quite
> distinct.
> This is what it looks on my machine:
>
> 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> ................
> 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
> ..G[Qb......8...
> 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
> ...........J....
> 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
> ............2...
> 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
> ................
> 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
> ........{...{...
> 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
> ................
> 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
> ................
> 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
> ................
> 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
> ................
> 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
> ................
> 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
> ................
> 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
> ................
> 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
> ................
> 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
> ................
> 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
> ................
> 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
> ................
> 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
> ................
> 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
> ................
> 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
> ................
> 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
> ................
> 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
> ................
> 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
> ................
> 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
> ................
> 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
> ................
> 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
> ................
> 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
> ................
> 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
> ................
> 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
> ................
> 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
> ................
> 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
> ................
> 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
> ................
>
> Segment 0 starts at hex 1000 of a nilfs partition as you can see above and
> carries on for quite a while like this.
>
> so have a look on your disk if it sits at 1000 of the root partition or at
> 1000 of partition 1.
>
> Once we have these things sorted I would say that we are ready to plant the
> _right_ superblock of the 2
> in the right place and see if the partition is recoqnized by nilfs.
> Off course we will save the place where we are going to plant that block
> first.
>
> And now back to the birthday party . . . .
>
> Cheers,
>
> Jan
>
>
>
> On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > 26 august 98: hexedit 0.9.5 release
>> > september 2005:
>> >     - version 1.2.12  this is the one I am running.
>>
>> Ah, I must be using the wrong hexedit.. now I've installed the same one
>> you
>> use.
>>
>> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>>
>> Yes. What I put there is:
>>
>> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>>
>> > hd -n1536 /dev/mmcblk0 >part.start
>> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>> > an to verify the last line:
>> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>>
>> Here is the output (I use hexdump instead of hd, hopefully they are the
>> same)
>>
>> bash-3.1# cat part.start
>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 0000600
>> bash-3.1# cat part1.start
>> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 00025ff
>> bash-3.1# cat part1a.start
>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 0000600
>>
>> Regards,
>> Paul Liu
>>
>> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> Thanks a lot for the instructions! I'm attaching the mbr and partition
>> >> table with this email.
>> >>
>> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
>> >> mounts mmcblk0p1.
>> >>
>> >> I think something corrupted my disk first, and then what I've done to
>> >> the disk after noticing the corruption:
>> >>
>> >> 1. fdisk, it says use "w" will correct the error, so I did. But then
>> >> the one parition is gone.
>> >> 2. fdisk again, create a single partition, then "w"
>> >>
>> >> My mistake was that I didn't create a backup copy of the MBR. A hard
>> >> lesson learned :(
>> >>
>> >> Also, why is that my hexedit doesn't take the "-s" option? It's
>> >> version 0.9.7, and can't edit bigger than 4.2GB.
>> >>
>> >> My SD card is A-DATA brand, class 6, and 16GB.
>> >>
>> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>> >>
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >  hallo,
>> >> > Almost sounds like you had only the root master-boot-record
>> /dev/mmcblk0
>> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>> >> >
>> >> > If (and only if) that is the case we have to undo the the 1st
>> partition
>> >> > +
>> >> > check that no nilfs is overwritten.
>> >> > and I would have to urgently study fdisk to see exactly what it
>> >> > writes
>> >> when
>> >> > and where.
>> >> > The last time I did tricks like these is quit a few years ago.
>> >> >
>> >> > It is the Linux version of fdisk is it??
>> >> >
>> >> > So here is the plan of action:
>> >> > hexdump the master boot record to file.
>> >> > like this:
>> >> >
>> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >> >
>> >> > then dump any partitions of the device in a format useful as input to
>> >> > sfdisk. For example,
>> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> >> > sfdisk is a tool provided with the util-linux
>> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >> >
>> >> >
>> >> > or you could use hexdump to get machine readable or man readable
>> images.
>> >> > Here is the man readable version:
>> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> >> > etc.
>> >> >
>> >> > By the way boor records always end with '55 AA'.
>> >> >
>> >> > Keep your files in a safe place in case we mess something we can at
>> >> > least
>> >> go
>> >> > back to the present situation.
>> >> > If you could dd the whole drive to a file, now that would be magic
>> >> indeed!
>> >> > but you must have the space on a harddrive.
>> >> > count=... is the number of sectors in the above line (dd ...) that
>> >> > you
>> >> dump
>> >> > to file.
>> >> > Hexedit will tell you the number of sectors is you start it with -s
>> >> option
>> >> > and then go to the last sector.
>> >> > DONT stop hexedit with control-x use cntl-c.
>> >> > DONT use high level or even midlevel tools on a stuffed disk, it
>> >> > normally
>> >> > messes more than it solves.
>> >> > unless of course you really,really know what you are doing.
>> >> > Fiddling the bytes is in general safe and gives results, if a man
>> keeps
>> >> > a
>> >> > cool head.
>> >> >
>> >> > Please send me the fdisk version, the size of the card, and the mbr
>> dump
>> >> to
>> >> > feast my eyes on.
>> >> >
>> >> > cheers,
>> >> >
>> >> > Jan de kruyf.
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >
>> >> >> just want to add that I've always been using 1 partition on this
>> >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
>> >> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
>> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >> >>
>> >> >> Any help is greatly appreciated!
>> >> >>
>> >> >>
>> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> > Thanks for the tips. When I first used the SD card, I used fdisk
>> >> >> > to
>> >> >> > create the partition.
>> >> >> >
>> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows
>> that
>> >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
>> >> >> >
>> >> >> > I tried gparted, but apparently it has no support for nilfs2.
>> >> >> >
>> >> >> > Regards,
>> >> >> > Paul Liu
>> >> >> >
>> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >> Did you first format this card with fdisk?
>> >> >> >> did you give it the exact same info this time around?
>> >> >> >>
>> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the dev
>> >> >> >> directory
>> >> >> >> where the card lives)
>> >> >> >>
>> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as
>> >> >> >> root?
>> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>> >> >> >>
>> >> >> >> be very careful no to save any data in hexedit, it will
>> >> >> >> definitely
>> >> and
>> >> >> >> finally
>> >> >> >> destoy your data.
>> >> >> >>
>> >> >> >> 0400 looks vagely like this:
>> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>> >> >> >> ......44.....V..
>> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>> >> >> >> 9..s............
>> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>> >> >> >> ..fe............
>> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>> >> >> >> ................
>> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> ................
>> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> >> .H......s..J....
>> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> >> ........s..J....
>> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>> >> >> >> ..2.....s..J....
>> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>> >> >> >> .N..............
>> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
>> >> >> >> .....Ls.=..E.
>> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>> >> >> >> .(DB=...Var64...
>> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> ................
>> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> ................
>> >> >> >>
>> >> >> >> the 34 34 in the top line say this is nilfs.
>> >> >> >>
>> >> >> >>
>> >> >> >> cheers
>> >> >> >>
>> >> >> >> jan de kruyf
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >>
>> >> >> >>> Due to some careless handling of my laptop, the SD card popped
>> out
>> >> >> >>> when the machine is still running. When I put it back in and
>> reboot
>> >> >> >>> the machine, it says "partition table error". I then ran fdisk
>> and
>> >> >> >>> recreated the single partition. Then I can no longer mount the
>> >> nilfs2
>> >> >> >>> partition that was on the SD card!
>> >> >> >>>
>> >> >> >>> Can any one help to me recover the file system? I believe all
>> data
>> >> are
>> >> >> >>> still there, but just some bits and pieces are missing for the
>> >> >> >>> mount
>> >> >> >>> to work. Any help is greatly appreciated!
>> >> >> >>>
>> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get my
>> >> stuff
>> >> >> >>> back in time... so help please!
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Regards,
>> >> >> >>> Paul Liu
>> >> >> >>>
>> >> >> >>> Yale Haskell Group
>> >> >> >>> http://www.haskell.org/yale
>> >> >> >>> _______________________________________________
>> >> >> >>> users mailing list
>> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Paul Liu
>> >> >> >
>> >> >> > Yale Haskell Group
>> >> >> > http://www.haskell.org/yale
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Regards,
>> >> >> Paul Liu
>> >> >>
>> >> >> Yale Haskell Group
>> >> >> http://www.haskell.org/yale
>> >> >> _______________________________________________
>> >> >> users mailing list
>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> Yale Haskell Group
>> >> http://www.haskell.org/yale
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>
>> >>
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 19952 bytes --]

David,
Thanks for your comment. The dd suggestion has been passed, the -i
suggestion is very valuable thanks. I just a few weeks ago struggled with
the garbage collector running when it should not have on a broken disk.
And perhaps you would like to have a look at your superblock and check the
sequence of the bytes.
Paul's reading and what I see on my machine are different.

Paul,
On my machine I see least significant byte at the left of any data type,
then d*16 etc.
In your images I see d*16, lsb,  d*4096, d*256, etc.
i.e. within each group of 4 characters on your screen in an hexdump the left
2 and the right 2 are interchanged from a normal i386 or i686 image. This
does not make sense to me.
Unless David has more light I would think that there is / was a ram
addressing problem in the hardware at least when the superblock was written
or now when it is read.
the other thing I do not like is that we dont find the backup block.

>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>at address 00401000.
>mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
>at 003FF000.

is this result from searching in the root only or did you first search in
the root and then in partition 1??

I will try to calculate the exact address where the backup block should be
found.

so long,
Cheers

Jan de Kruyf.


On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
> Aspire One model A101,  which uses Atom CPU.
>
> I failed to find the superblock towards the end of either mmcblk0 or
> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>
> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> at address 00401000.
>
> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
> at 003FF000.
>
> I hope my SD card is not messing up itself by rearranging the blocks!
>
> Regards,
> Paul Liu
>
> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hallo,
> > here we go again. As a matter of interest, what version of nilfs and what
> > distribution are you running? And what processor?
> > your endiannes confused me at first.
> >
> > glad you fixed your hexedit
> >
> > I have looked at some numbers in the superblock and they look ok. I do
> > wonder if you have the garbage collector running.
> >
> > now for the second superblock. Please pay attention to the exact place of
> > it. Because it is of vital
> > importance if it in in partition 1 or in the root of the disk.
> >
> > the first superblock sits as you observed in the root. The flags say
> amongst
> > others that it was unmounted cleanly but errors were detected.
> >
> > see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations. in
> the
> > distribution.
> > /**
> >  * struct nilfs_super_block - structure of super block on disk
> >  */
> > struct nilfs_super_block {
> > ....
> > translates bit for bit to what you see written in the super block on
> disk.
> >
> > Here is an example from a partition of mine on how to discover the
> > superblock copy
> > it should read the same as the 1st but in your case it might not.
> > It is a leftshift - subtract 1 - right shift algorithm.
> > go in hexedit to the last data with ">" (shift .)
> > note the address of the last byte (the size of the partion)
> > in mine:
> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > or the status line might give it
> > the address of the copy is now at 6566A000
> > i.e. 6566B has 1 subtracted from it and the 3 least significant digits
> have
> > been zeroed.
> >
> > so please dump yours, see if the algorithm works on the 1st part or on
> the
> > root or both,
> > so we know where it is.
> > And check if it is exactly the same as the first one you send me
> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> > etc.
> >
> > the next thing to discover is where the start of (nilfs)segment 0 is.
> > I am not quite sure what is written in it, but the signature is quite
> > distinct.
> > This is what it looks on my machine:
> >
> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
> > ..G[Qb......8...
> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
> > ...........J....
> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
> > ............2...
> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
> > ................
> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
> > ........{...{...
> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
> > ................
> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
> > ................
> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
> > ................
> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
> > ................
> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
> > ................
> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
> > ................
> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
> > ................
> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
> > ................
> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
> > ................
> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
> > ................
> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
> > ................
> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
> > ................
> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
> > ................
> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
> > ................
> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
> > ................
> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
> > ................
> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
> > ................
> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
> > ................
> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
> > ................
> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
> > ................
> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
> > ................
> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
> > ................
> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
> > ................
> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
> > ................
> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
> > ................
> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
> > ................
> >
> > Segment 0 starts at hex 1000 of a nilfs partition as you can see above
> and
> > carries on for quite a while like this.
> >
> > so have a look on your disk if it sits at 1000 of the root partition or
> at
> > 1000 of partition 1.
> >
> > Once we have these things sorted I would say that we are ready to plant
> the
> > _right_ superblock of the 2
> > in the right place and see if the partition is recoqnized by nilfs.
> > Off course we will save the place where we are going to plant that block
> > first.
> >
> > And now back to the birthday party . . . .
> >
> > Cheers,
> >
> > Jan
> >
> >
> >
> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > 26 august 98: hexedit 0.9.5 release
> >> > september 2005:
> >> >     - version 1.2.12  this is the one I am running.
> >>
> >> Ah, I must be using the wrong hexedit.. now I've installed the same one
> >> you
> >> use.
> >>
> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
> >>
> >> Yes. What I put there is:
> >>
> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
> >>
> >> > hd -n1536 /dev/mmcblk0 >part.start
> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> >> > an to verify the last line:
> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
> >>
> >> Here is the output (I use hexdump instead of hd, hopefully they are the
> >> same)
> >>
> >> bash-3.1# cat part.start
> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000600
> >> bash-3.1# cat part1.start
> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00025ff
> >> bash-3.1# cat part1a.start
> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000600
> >>
> >> Regards,
> >> Paul Liu
> >>
> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >
> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
> partition
> >> >> table with this email.
> >> >>
> >> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
> >> >> mounts mmcblk0p1.
> >> >>
> >> >> I think something corrupted my disk first, and then what I've done to
> >> >> the disk after noticing the corruption:
> >> >>
> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But then
> >> >> the one parition is gone.
> >> >> 2. fdisk again, create a single partition, then "w"
> >> >>
> >> >> My mistake was that I didn't create a backup copy of the MBR. A hard
> >> >> lesson learned :(
> >> >>
> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
> >> >>
> >> >> My SD card is A-DATA brand, class 6, and 16GB.
> >> >>
> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
> >> >>
> >> >> Regards,
> >> >> Paul Liu
> >> >>
> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >  hallo,
> >> >> > Almost sounds like you had only the root master-boot-record
> >> /dev/mmcblk0
> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
> >> >> >
> >> >> > If (and only if) that is the case we have to undo the the 1st
> >> partition
> >> >> > +
> >> >> > check that no nilfs is overwritten.
> >> >> > and I would have to urgently study fdisk to see exactly what it
> >> >> > writes
> >> >> when
> >> >> > and where.
> >> >> > The last time I did tricks like these is quit a few years ago.
> >> >> >
> >> >> > It is the Linux version of fdisk is it??
> >> >> >
> >> >> > So here is the plan of action:
> >> >> > hexdump the master boot record to file.
> >> >> > like this:
> >> >> >
> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >> >> >
> >> >> > then dump any partitions of the device in a format useful as input
> to
> >> >> > sfdisk. For example,
> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> >> >> > sfdisk is a tool provided with the util-linux
> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >> >> >
> >> >> >
> >> >> > or you could use hexdump to get machine readable or man readable
> >> images.
> >> >> > Here is the man readable version:
> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> >> >> > etc.
> >> >> >
> >> >> > By the way boor records always end with '55 AA'.
> >> >> >
> >> >> > Keep your files in a safe place in case we mess something we can at
> >> >> > least
> >> >> go
> >> >> > back to the present situation.
> >> >> > If you could dd the whole drive to a file, now that would be magic
> >> >> indeed!
> >> >> > but you must have the space on a harddrive.
> >> >> > count=... is the number of sectors in the above line (dd ...) that
> >> >> > you
> >> >> dump
> >> >> > to file.
> >> >> > Hexedit will tell you the number of sectors is you start it with -s
> >> >> option
> >> >> > and then go to the last sector.
> >> >> > DONT stop hexedit with control-x use cntl-c.
> >> >> > DONT use high level or even midlevel tools on a stuffed disk, it
> >> >> > normally
> >> >> > messes more than it solves.
> >> >> > unless of course you really,really know what you are doing.
> >> >> > Fiddling the bytes is in general safe and gives results, if a man
> >> keeps
> >> >> > a
> >> >> > cool head.
> >> >> >
> >> >> > Please send me the fdisk version, the size of the card, and the mbr
> >> dump
> >> >> to
> >> >> > feast my eyes on.
> >> >> >
> >> >> > cheers,
> >> >> >
> >> >> > Jan de kruyf.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >
> >> >> >> just want to add that I've always been using 1 partition on this
> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
> >> >> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >> >> >>
> >> >> >> Any help is greatly appreciated!
> >> >> >>
> >> >> >>
> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >> > Thanks for the tips. When I first used the SD card, I used fdisk
> >> >> >> > to
> >> >> >> > create the partition.
> >> >> >> >
> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows
> >> that
> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
> >> >> >> >
> >> >> >> > I tried gparted, but apparently it has no support for nilfs2.
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > Paul Liu
> >> >> >> >
> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >> >> Did you first format this card with fdisk?
> >> >> >> >> did you give it the exact same info this time around?
> >> >> >> >>
> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the
> dev
> >> >> >> >> directory
> >> >> >> >> where the card lives)
> >> >> >> >>
> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as
> >> >> >> >> root?
> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >> >> >> >>
> >> >> >> >> be very careful no to save any data in hexedit, it will
> >> >> >> >> definitely
> >> >> and
> >> >> >> >> finally
> >> >> >> >> destoy your data.
> >> >> >> >>
> >> >> >> >> 0400 looks vagely like this:
> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >> >> >> >> ......44.....V..
> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >> >> >> >> 9..s............
> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> >> ..fe............
> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> .H......s..J....
> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> ........s..J....
> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> ..2.....s..J....
> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >> >> >> >> .N..............
> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> >> >> >> >> .....Ls.=..E.
> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >> >> >> >> .(DB=...Var64...
> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >>
> >> >> >> >> the 34 34 in the top line say this is nilfs.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> cheers
> >> >> >> >>
> >> >> >> >> jan de kruyf
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> >> >> >> >>
> >> >> >> >>> Due to some careless handling of my laptop, the SD card popped
> >> out
> >> >> >> >>> when the machine is still running. When I put it back in and
> >> reboot
> >> >> >> >>> the machine, it says "partition table error". I then ran fdisk
> >> and
> >> >> >> >>> recreated the single partition. Then I can no longer mount the
> >> >> nilfs2
> >> >> >> >>> partition that was on the SD card!
> >> >> >> >>>
> >> >> >> >>> Can any one help to me recover the file system? I believe all
> >> data
> >> >> are
> >> >> >> >>> still there, but just some bits and pieces are missing for the
> >> >> >> >>> mount
> >> >> >> >>> to work. Any help is greatly appreciated!
> >> >> >> >>>
> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get
> my
> >> >> stuff
> >> >> >> >>> back in time... so help please!
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>> Regards,
> >> >> >> >>> Paul Liu
> >> >> >> >>>
> >> >> >> >>> Yale Haskell Group
> >> >> >> >>> http://www.haskell.org/yale
> >> >> >> >>> _______________________________________________
> >> >> >> >>> users mailing list
> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Paul Liu
> >> >> >> >
> >> >> >> > Yale Haskell Group
> >> >> >> > http://www.haskell.org/yale
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Regards,
> >> >> >> Paul Liu
> >> >> >>
> >> >> >> Yale Haskell Group
> >> >> >> http://www.haskell.org/yale
> >> >> >> _______________________________________________
> >> >> >> users mailing list
> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Paul Liu
> >> >>
> >> >> Yale Haskell Group
> >> >> http://www.haskell.org/yale
> >> >>
> >> >> _______________________________________________
> >> >> users mailing list
> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Regards,
> >> Paul Liu
> >>
> >> Yale Haskell Group
> >> http://www.haskell.org/yale
> >> _______________________________________________
> >> users mailing list
> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> https://www.nilfs.org/mailman/listinfo/users
> >>
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 29296 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 18831 bytes --]

just thought of something. You searched with standard (little, I think)
endianess
i.e. the image from my mail to you.
 try the image from YOUR main superblock:
0002 0000 0000 3434
and see if the backup copy surfaces.

jan.

On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
> Aspire One model A101,  which uses Atom CPU.
>
> I failed to find the superblock towards the end of either mmcblk0 or
> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>
> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> at address 00401000.
>
> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
> at 003FF000.
>
> I hope my SD card is not messing up itself by rearranging the blocks!
>
> Regards,
> Paul Liu
>
> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hallo,
> > here we go again. As a matter of interest, what version of nilfs and what
> > distribution are you running? And what processor?
> > your endiannes confused me at first.
> >
> > glad you fixed your hexedit
> >
> > I have looked at some numbers in the superblock and they look ok. I do
> > wonder if you have the garbage collector running.
> >
> > now for the second superblock. Please pay attention to the exact place of
> > it. Because it is of vital
> > importance if it in in partition 1 or in the root of the disk.
> >
> > the first superblock sits as you observed in the root. The flags say
> amongst
> > others that it was unmounted cleanly but errors were detected.
> >
> > see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations. in
> the
> > distribution.
> > /**
> >  * struct nilfs_super_block - structure of super block on disk
> >  */
> > struct nilfs_super_block {
> > ....
> > translates bit for bit to what you see written in the super block on
> disk.
> >
> > Here is an example from a partition of mine on how to discover the
> > superblock copy
> > it should read the same as the 1st but in your case it might not.
> > It is a leftshift - subtract 1 - right shift algorithm.
> > go in hexedit to the last data with ">" (shift .)
> > note the address of the last byte (the size of the partion)
> > in mine:
> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > or the status line might give it
> > the address of the copy is now at 6566A000
> > i.e. 6566B has 1 subtracted from it and the 3 least significant digits
> have
> > been zeroed.
> >
> > so please dump yours, see if the algorithm works on the 1st part or on
> the
> > root or both,
> > so we know where it is.
> > And check if it is exactly the same as the first one you send me
> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> > etc.
> >
> > the next thing to discover is where the start of (nilfs)segment 0 is.
> > I am not quite sure what is written in it, but the signature is quite
> > distinct.
> > This is what it looks on my machine:
> >
> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> > ................
> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
> > ..G[Qb......8...
> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
> > ...........J....
> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
> > ............2...
> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
> > ................
> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
> > ........{...{...
> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
> > ................
> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
> > ................
> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
> > ................
> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
> > ................
> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
> > ................
> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
> > ................
> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
> > ................
> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
> > ................
> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
> > ................
> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
> > ................
> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
> > ................
> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
> > ................
> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
> > ................
> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
> > ................
> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
> > ................
> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
> > ................
> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
> > ................
> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
> > ................
> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
> > ................
> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
> > ................
> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
> > ................
> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
> > ................
> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
> > ................
> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
> > ................
> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
> > ................
> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
> > ................
> >
> > Segment 0 starts at hex 1000 of a nilfs partition as you can see above
> and
> > carries on for quite a while like this.
> >
> > so have a look on your disk if it sits at 1000 of the root partition or
> at
> > 1000 of partition 1.
> >
> > Once we have these things sorted I would say that we are ready to plant
> the
> > _right_ superblock of the 2
> > in the right place and see if the partition is recoqnized by nilfs.
> > Off course we will save the place where we are going to plant that block
> > first.
> >
> > And now back to the birthday party . . . .
> >
> > Cheers,
> >
> > Jan
> >
> >
> >
> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > 26 august 98: hexedit 0.9.5 release
> >> > september 2005:
> >> >     - version 1.2.12  this is the one I am running.
> >>
> >> Ah, I must be using the wrong hexedit.. now I've installed the same one
> >> you
> >> use.
> >>
> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
> >>
> >> Yes. What I put there is:
> >>
> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
> >>
> >> > hd -n1536 /dev/mmcblk0 >part.start
> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> >> > an to verify the last line:
> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
> >>
> >> Here is the output (I use hexdump instead of hd, hopefully they are the
> >> same)
> >>
> >> bash-3.1# cat part.start
> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000600
> >> bash-3.1# cat part1.start
> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 00025ff
> >> bash-3.1# cat part1a.start
> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> *
> >> 0000600
> >>
> >> Regards,
> >> Paul Liu
> >>
> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >
> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
> partition
> >> >> table with this email.
> >> >>
> >> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
> >> >> mounts mmcblk0p1.
> >> >>
> >> >> I think something corrupted my disk first, and then what I've done to
> >> >> the disk after noticing the corruption:
> >> >>
> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But then
> >> >> the one parition is gone.
> >> >> 2. fdisk again, create a single partition, then "w"
> >> >>
> >> >> My mistake was that I didn't create a backup copy of the MBR. A hard
> >> >> lesson learned :(
> >> >>
> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
> >> >>
> >> >> My SD card is A-DATA brand, class 6, and 16GB.
> >> >>
> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
> >> >>
> >> >> Regards,
> >> >> Paul Liu
> >> >>
> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >  hallo,
> >> >> > Almost sounds like you had only the root master-boot-record
> >> /dev/mmcblk0
> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
> >> >> >
> >> >> > If (and only if) that is the case we have to undo the the 1st
> >> partition
> >> >> > +
> >> >> > check that no nilfs is overwritten.
> >> >> > and I would have to urgently study fdisk to see exactly what it
> >> >> > writes
> >> >> when
> >> >> > and where.
> >> >> > The last time I did tricks like these is quit a few years ago.
> >> >> >
> >> >> > It is the Linux version of fdisk is it??
> >> >> >
> >> >> > So here is the plan of action:
> >> >> > hexdump the master boot record to file.
> >> >> > like this:
> >> >> >
> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >> >> >
> >> >> > then dump any partitions of the device in a format useful as input
> to
> >> >> > sfdisk. For example,
> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> >> >> > sfdisk is a tool provided with the util-linux
> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >> >> >
> >> >> >
> >> >> > or you could use hexdump to get machine readable or man readable
> >> images.
> >> >> > Here is the man readable version:
> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> >> >> > etc.
> >> >> >
> >> >> > By the way boor records always end with '55 AA'.
> >> >> >
> >> >> > Keep your files in a safe place in case we mess something we can at
> >> >> > least
> >> >> go
> >> >> > back to the present situation.
> >> >> > If you could dd the whole drive to a file, now that would be magic
> >> >> indeed!
> >> >> > but you must have the space on a harddrive.
> >> >> > count=... is the number of sectors in the above line (dd ...) that
> >> >> > you
> >> >> dump
> >> >> > to file.
> >> >> > Hexedit will tell you the number of sectors is you start it with -s
> >> >> option
> >> >> > and then go to the last sector.
> >> >> > DONT stop hexedit with control-x use cntl-c.
> >> >> > DONT use high level or even midlevel tools on a stuffed disk, it
> >> >> > normally
> >> >> > messes more than it solves.
> >> >> > unless of course you really,really know what you are doing.
> >> >> > Fiddling the bytes is in general safe and gives results, if a man
> >> keeps
> >> >> > a
> >> >> > cool head.
> >> >> >
> >> >> > Please send me the fdisk version, the size of the card, and the mbr
> >> dump
> >> >> to
> >> >> > feast my eyes on.
> >> >> >
> >> >> > cheers,
> >> >> >
> >> >> > Jan de kruyf.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >
> >> >> >> just want to add that I've always been using 1 partition on this
> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
> >> >> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >> >> >>
> >> >> >> Any help is greatly appreciated!
> >> >> >>
> >> >> >>
> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >> > Thanks for the tips. When I first used the SD card, I used fdisk
> >> >> >> > to
> >> >> >> > create the partition.
> >> >> >> >
> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0 shows
> >> that
> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
> >> >> >> >
> >> >> >> > I tried gparted, but apparently it has no support for nilfs2.
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > Paul Liu
> >> >> >> >
> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> >> >> Did you first format this card with fdisk?
> >> >> >> >> did you give it the exact same info this time around?
> >> >> >> >>
> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the
> dev
> >> >> >> >> directory
> >> >> >> >> where the card lives)
> >> >> >> >>
> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as
> >> >> >> >> root?
> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >> >> >> >>
> >> >> >> >> be very careful no to save any data in hexedit, it will
> >> >> >> >> definitely
> >> >> and
> >> >> >> >> finally
> >> >> >> >> destoy your data.
> >> >> >> >>
> >> >> >> >> 0400 looks vagely like this:
> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >> >> >> >> ......44.....V..
> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >> >> >> >> 9..s............
> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> >> ..fe............
> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> .H......s..J....
> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> ........s..J....
> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >> >> >> >> ..2.....s..J....
> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >> >> >> >> .N..............
> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85  ..
> >> >> >> >> .....Ls.=..E.
> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >> >> >> >> .(DB=...Var64...
> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >> >> >> ................
> >> >> >> >>
> >> >> >> >> the 34 34 in the top line say this is nilfs.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> cheers
> >> >> >> >>
> >> >> >> >> jan de kruyf
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> >> >> >> >>
> >> >> >> >>> Due to some careless handling of my laptop, the SD card popped
> >> out
> >> >> >> >>> when the machine is still running. When I put it back in and
> >> reboot
> >> >> >> >>> the machine, it says "partition table error". I then ran fdisk
> >> and
> >> >> >> >>> recreated the single partition. Then I can no longer mount the
> >> >> nilfs2
> >> >> >> >>> partition that was on the SD card!
> >> >> >> >>>
> >> >> >> >>> Can any one help to me recover the file system? I believe all
> >> data
> >> >> are
> >> >> >> >>> still there, but just some bits and pieces are missing for the
> >> >> >> >>> mount
> >> >> >> >>> to work. Any help is greatly appreciated!
> >> >> >> >>>
> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get
> my
> >> >> stuff
> >> >> >> >>> back in time... so help please!
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>> Regards,
> >> >> >> >>> Paul Liu
> >> >> >> >>>
> >> >> >> >>> Yale Haskell Group
> >> >> >> >>> http://www.haskell.org/yale
> >> >> >> >>> _______________________________________________
> >> >> >> >>> users mailing list
> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Paul Liu
> >> >> >> >
> >> >> >> > Yale Haskell Group
> >> >> >> > http://www.haskell.org/yale
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Regards,
> >> >> >> Paul Liu
> >> >> >>
> >> >> >> Yale Haskell Group
> >> >> >> http://www.haskell.org/yale
> >> >> >> _______________________________________________
> >> >> >> users mailing list
> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Paul Liu
> >> >>
> >> >> Yale Haskell Group
> >> >> http://www.haskell.org/yale
> >> >>
> >> >> _______________________________________________
> >> >> users mailing list
> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Regards,
> >> Paul Liu
> >>
> >> Yale Haskell Group
> >> http://www.haskell.org/yale
> >> _______________________________________________
> >> users mailing list
> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> https://www.nilfs.org/mailman/listinfo/users
> >>
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 28060 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: urgent help need! disk partition info lost

[David Arendt]

Hi,

My superblock looks like this:

0000400 0002 0000 0000 3434 0100 0000 4398 ed19

Here is the second copy:

a00a6c000 0002 0000 0000 3434 0100 0000 4398 ed19

Bye,
David Arendt

Jan de Kruyf wrote:
> David,
> Thanks for your comment. The dd suggestion has been passed, the -i
> suggestion is very valuable thanks. I just a few weeks ago struggled
> with the garbage collector running when it should not have on a broken
> disk.
> And perhaps you would like to have a look at your superblock and check
> the sequence of the bytes.
> Paul's reading and what I see on my machine are different.
>
> Paul,
> On my machine I see least significant byte at the left of any data
> type, then d*16 etc.
> In your images I see d*16, lsb,  d*4096, d*256, etc.
> i.e. within each group of 4 characters on your screen in an hexdump
> the left 2 and the right 2 are interchanged from a normal i386 or i686
> image. This does not make sense to me.
> Unless David has more light I would think that there is / was a ram
> addressing problem in the hardware at least when the superblock was
> written or now when it is read.
> the other thing I do not like is that we dont find the backup block.
>
> >mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> >at address 00401000.
> >mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
> >at 003FF000.
>
> is this result from searching in the root only or did you first search
> in the root and then in partition 1??
>
> I will try to calculate the exact address where the backup block
> should be found.
>
> so long,
> Cheers
>
> Jan de Kruyf.
>
>
> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
>     I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>     Aspire One model A101,  which uses Atom CPU.
>
>     I failed to find the superblock towards the end of either mmcblk0 or
>     mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>
>     mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>     at address 00401000.
>
>     mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
>     at 003FF000.
>
>     I hope my SD card is not messing up itself by rearranging the blocks!
>
>     Regards,
>     Paul Liu
>
>     On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     > Hallo,
>     > here we go again. As a matter of interest, what version of nilfs
>     and what
>     > distribution are you running? And what processor?
>     > your endiannes confused me at first.
>     >
>     > glad you fixed your hexedit
>     >
>     > I have looked at some numbers in the superblock and they look
>     ok. I do
>     > wonder if you have the garbage collector running.
>     >
>     > now for the second superblock. Please pay attention to the exact
>     place of
>     > it. Because it is of vital
>     > importance if it in in partition 1 or in the root of the disk.
>     >
>     > the first superblock sits as you observed in the root. The flags
>     say amongst
>     > others that it was unmounted cleanly but errors were detected.
>     >
>     > see  nilfs2_fs.h - NILFS2 on-disk structures and common
>     declarations. in the
>     > distribution.
>     > /**
>     >  * struct nilfs_super_block - structure of super block on disk
>     >  */
>     > struct nilfs_super_block {
>     > ....
>     > translates bit for bit to what you see written in the super
>     block on disk.
>     >
>     > Here is an example from a partition of mine on how to discover the
>     > superblock copy
>     > it should read the same as the 1st but in your case it might not.
>     > It is a leftshift - subtract 1 - right shift algorithm.
>     > go in hexedit to the last data with ">" (shift .)
>     > note the address of the last byte (the size of the partion)
>     > in mine:
>     > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     > ................
>     > or the status line might give it
>     > the address of the copy is now at 6566A000
>     > i.e. 6566B has 1 subtracted from it and the 3 least significant
>     digits have
>     > been zeroed.
>     >
>     > so please dump yours, see if the algorithm works on the 1st part
>     or on the
>     > root or both,
>     > so we know where it is.
>     > And check if it is exactly the same as the first one you send me
>     > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>     > etc.
>     >
>     > the next thing to discover is where the start of (nilfs)segment
>     0 is.
>     > I am not quite sure what is written in it, but the signature is
>     quite
>     > distinct.
>     > This is what it looks on my machine:
>     >
>     > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     > ................
>     > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     > ................
>     > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     > ................
>     > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>     > ................
>     > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>     > ..G[Qb......8...
>     > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>     > ...........J....
>     > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>     > ............2...
>     > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>     > ................
>     > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>     > ........{...{...
>     > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>     > ................
>     > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>     > ................
>     > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>     > ................
>     > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>     > ................
>     > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>     > ................
>     > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>     > ................
>     > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>     > ................
>     > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>     > ................
>     > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>     > ................
>     > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>     > ................
>     > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>     > ................
>     > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>     > ................
>     > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>     > ................
>     > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>     > ................
>     > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>     > ................
>     > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>     > ................
>     > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>     > ................
>     > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>     > ................
>     > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>     > ................
>     > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>     > ................
>     > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>     > ................
>     > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>     > ................
>     > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>     > ................
>     > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>     > ................
>     > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>     > ................
>     > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>     > ................
>     >
>     > Segment 0 starts at hex 1000 of a nilfs partition as you can see
>     above and
>     > carries on for quite a while like this.
>     >
>     > so have a look on your disk if it sits at 1000 of the root
>     partition or at
>     > 1000 of partition 1.
>     >
>     > Once we have these things sorted I would say that we are ready
>     to plant the
>     > _right_ superblock of the 2
>     > in the right place and see if the partition is recoqnized by nilfs.
>     > Off course we will save the place where we are going to plant
>     that block
>     > first.
>     >
>     > And now back to the birthday party . . . .
>     >
>     > Cheers,
>     >
>     > Jan
>     >
>     >
>     >
>     > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >
>     >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> > 26 august 98: hexedit 0.9.5 release
>     >> > september 2005:
>     >> >     - version 1.2.12  this is the one I am running.
>     >>
>     >> Ah, I must be using the wrong hexedit.. now I've installed the
>     same one
>     >> you
>     >> use.
>     >>
>     >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>     >>
>     >> Yes. What I put there is:
>     >>
>     >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>     >>
>     >> > hd -n1536 /dev/mmcblk0 >part.start
>     >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>     >> > an to verify the last line:
>     >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>     >>
>     >> Here is the output (I use hexdump instead of hd, hopefully they
>     are the
>     >> same)
>     >>
>     >> bash-3.1# cat part.start
>     >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>     >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>     >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>     >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>     >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>     >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>     >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>     >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>     >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>     >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>     >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>     >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>     >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>     >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>     >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 0000600
>     >> bash-3.1# cat part1.start
>     >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 00025ff
>     >> bash-3.1# cat part1a.start
>     >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>     >> *
>     >> 0000600
>     >>
>     >> Regards,
>     >> Paul Liu
>     >>
>     >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >
>     >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>     partition
>     >> >> table with this email.
>     >> >>
>     >> >> I'm pretty sure I had 1 partition on the card, since my
>     /etc/fstab
>     >> >> mounts mmcblk0p1.
>     >> >>
>     >> >> I think something corrupted my disk first, and then what
>     I've done to
>     >> >> the disk after noticing the corruption:
>     >> >>
>     >> >> 1. fdisk, it says use "w" will correct the error, so I did.
>     But then
>     >> >> the one parition is gone.
>     >> >> 2. fdisk again, create a single partition, then "w"
>     >> >>
>     >> >> My mistake was that I didn't create a backup copy of the
>     MBR. A hard
>     >> >> lesson learned :(
>     >> >>
>     >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
>     >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>     >> >>
>     >> >> My SD card is A-DATA brand, class 6, and 16GB.
>     >> >>
>     >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>     >> >>
>     >> >> Regards,
>     >> >> Paul Liu
>     >> >>
>     >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >  hallo,
>     >> >> > Almost sounds like you had only the root master-boot-record
>     >> /dev/mmcblk0
>     >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>     >> >> >
>     >> >> > If (and only if) that is the case we have to undo the the 1st
>     >> partition
>     >> >> > +
>     >> >> > check that no nilfs is overwritten.
>     >> >> > and I would have to urgently study fdisk to see exactly
>     what it
>     >> >> > writes
>     >> >> when
>     >> >> > and where.
>     >> >> > The last time I did tricks like these is quit a few years ago.
>     >> >> >
>     >> >> > It is the Linux version of fdisk is it??
>     >> >> >
>     >> >> > So here is the plan of action:
>     >> >> > hexdump the master boot record to file.
>     >> >> > like this:
>     >> >> >
>     >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>     >> >> >
>     >> >> > then dump any partitions of the device in a format useful
>     as input to
>     >> >> > sfdisk. For example,
>     >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>     >> >> > sfdisk is a tool provided with the util-linux
>     >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>     >> >> >
>     >> >> >
>     >> >> > or you could use hexdump to get machine readable or man
>     readable
>     >> images.
>     >> >> > Here is the man readable version:
>     >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>     >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>     >> >> > etc.
>     >> >> >
>     >> >> > By the way boor records always end with '55 AA'.
>     >> >> >
>     >> >> > Keep your files in a safe place in case we mess something
>     we can at
>     >> >> > least
>     >> >> go
>     >> >> > back to the present situation.
>     >> >> > If you could dd the whole drive to a file, now that would
>     be magic
>     >> >> indeed!
>     >> >> > but you must have the space on a harddrive.
>     >> >> > count=... is the number of sectors in the above line (dd
>     ...) that
>     >> >> > you
>     >> >> dump
>     >> >> > to file.
>     >> >> > Hexedit will tell you the number of sectors is you start
>     it with -s
>     >> >> option
>     >> >> > and then go to the last sector.
>     >> >> > DONT stop hexedit with control-x use cntl-c.
>     >> >> > DONT use high level or even midlevel tools on a stuffed
>     disk, it
>     >> >> > normally
>     >> >> > messes more than it solves.
>     >> >> > unless of course you really,really know what you are doing.
>     >> >> > Fiddling the bytes is in general safe and gives results,
>     if a man
>     >> keeps
>     >> >> > a
>     >> >> > cool head.
>     >> >> >
>     >> >> > Please send me the fdisk version, the size of the card,
>     and the mbr
>     >> dump
>     >> >> to
>     >> >> > feast my eyes on.
>     >> >> >
>     >> >> > cheers,
>     >> >> >
>     >> >> > Jan de kruyf.
>     >> >> >
>     >> >> >
>     >> >> >
>     >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >
>     >> >> >> just want to add that I've always been using 1 partition
>     on this
>     >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
>     /dev/mmcblk0p1
>     >> >> >> doesn't show that 34 34 at line begining with 0x400, only
>     hexedit
>     >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>     >> >> >>
>     >> >> >> Any help is greatly appreciated!
>     >> >> >>
>     >> >> >>
>     >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >> > Thanks for the tips. When I first used the SD card, I
>     used fdisk
>     >> >> >> > to
>     >> >> >> > create the partition.
>     >> >> >> >
>     >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s
>     /dev/mmcblk0 shows
>     >> that
>     >> >> >> > at the line 0x0400, it is indeed 34 34. What should I
>     do then?
>     >> >> >> >
>     >> >> >> > I tried gparted, but apparently it has no support for
>     nilfs2.
>     >> >> >> >
>     >> >> >> > Regards,
>     >> >> >> > Paul Liu
>     >> >> >> >
>     >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>     <mailto:jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >> >> Did you first format this card with fdisk?
>     >> >> >> >> did you give it the exact same info this time around?
>     >> >> >> >>
>     >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device
>     in the dev
>     >> >> >> >> directory
>     >> >> >> >> where the card lives)
>     >> >> >> >>
>     >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a
>     terminal as
>     >> >> >> >> root?
>     >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still
>     exists?
>     >> >> >> >>
>     >> >> >> >> be very careful no to save any data in hexedit, it will
>     >> >> >> >> definitely
>     >> >> and
>     >> >> >> >> finally
>     >> >> >> >> destoy your data.
>     >> >> >> >>
>     >> >> >> >> 0400 looks vagely like this:
>     >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56
>     F0 B9
>     >> >> >> >> ......44.....V..
>     >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00
>     00 00
>     >> >> >> >> 9..s............
>     >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00
>     00 00
>     >> >> >> >> ..fe............
>     >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00
>     00 00
>     >> >> >> >> ................
>     >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00
>     00 00
>     >> >> >> >> ................
>     >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00
>     00 00
>     >> >> >> >> .H......s..J....
>     >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00
>     00 00
>     >> >> >> >> ........s..J....
>     >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00
>     00 00
>     >> >> >> >> ..2.....s..J....
>     >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00
>     00 00
>     >> >> >> >> .N..............
>     >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC
>     45 85  ..
>     >> >> >> >> .....Ls.=..E.
>     >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00
>     00 00
>     >> >> >> >> .(DB=...Var64...
>     >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>     00 00
>     >> >> >> >> ................
>     >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>     00 00
>     >> >> >> >> ................
>     >> >> >> >>
>     >> >> >> >> the 34 34 in the top line say this is nilfs.
>     >> >> >> >>
>     >> >> >> >>
>     >> >> >> >> cheers
>     >> >> >> >>
>     >> >> >> >> jan de kruyf
>     >> >> >> >>
>     >> >> >> >>
>     >> >> >> >>
>     >> >> >> >>
>     >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L
>     <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>     >> >> >> >>
>     >> >> >> >>> Due to some careless handling of my laptop, the SD
>     card popped
>     >> out
>     >> >> >> >>> when the machine is still running. When I put it back
>     in and
>     >> reboot
>     >> >> >> >>> the machine, it says "partition table error". I then
>     ran fdisk
>     >> and
>     >> >> >> >>> recreated the single partition. Then I can no longer
>     mount the
>     >> >> nilfs2
>     >> >> >> >>> partition that was on the SD card!
>     >> >> >> >>>
>     >> >> >> >>> Can any one help to me recover the file system? I
>     believe all
>     >> data
>     >> >> are
>     >> >> >> >>> still there, but just some bits and pieces are
>     missing for the
>     >> >> >> >>> mount
>     >> >> >> >>> to work. Any help is greatly appreciated!
>     >> >> >> >>>
>     >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I
>     can get my
>     >> >> stuff
>     >> >> >> >>> back in time... so help please!
>     >> >> >> >>>
>     >> >> >> >>> --
>     >> >> >> >>> Regards,
>     >> >> >> >>> Paul Liu
>     >> >> >> >>>
>     >> >> >> >>> Yale Haskell Group
>     >> >> >> >>> http://www.haskell.org/yale
>     >> >> >> >>> _______________________________________________
>     >> >> >> >>> users mailing list
>     >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>     >> >> >> >>>
>     >> >> >> >>
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > --
>     >> >> >> > Regards,
>     >> >> >> > Paul Liu
>     >> >> >> >
>     >> >> >> > Yale Haskell Group
>     >> >> >> > http://www.haskell.org/yale
>     >> >> >> >
>     >> >> >>
>     >> >> >>
>     >> >> >> --
>     >> >> >> Regards,
>     >> >> >> Paul Liu
>     >> >> >>
>     >> >> >> Yale Haskell Group
>     >> >> >> http://www.haskell.org/yale
>     >> >> >> _______________________________________________
>     >> >> >> users mailing list
>     >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> >> >> https://www.nilfs.org/mailman/listinfo/users
>     >> >> >>
>     >> >> >
>     >> >>
>     >> >>
>     >> >> --
>     >> >> Regards,
>     >> >> Paul Liu
>     >> >>
>     >> >> Yale Haskell Group
>     >> >> http://www.haskell.org/yale
>     >> >>
>     >> >> _______________________________________________
>     >> >> users mailing list
>     >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> >> https://www.nilfs.org/mailman/listinfo/users
>     >> >>
>     >> >>
>     >> >
>     >>
>     >>
>     >> --
>     >> Regards,
>     >> Paul Liu
>     >>
>     >> Yale Haskell Group
>     >> http://www.haskell.org/yale
>     >> _______________________________________________
>     >> users mailing list
>     >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     >> https://www.nilfs.org/mailman/listinfo/users
>     >>
>     >
>
>
>     --
>     Regards,
>     Paul Liu
>
>     Yale Haskell Group
>     http://www.haskell.org/yale
>     _______________________________________________
>     users mailing list
>     users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org <mailto:users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
>     https://www.nilfs.org/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>   

Re: urgent help need! disk partition info lost

[Paul L]

I think it might be the "hexdump" utility that I used. It by default
groups things by word, so in little endian it'd say 0002 but the
actual byte sequence is 02 00.

I re-dump the following in byte sequence using od.

first superblock

000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

backup copy of the super block (actually different from the above)

400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The address is the absolute index into the root partition
/dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
the super block is not something at the end of the disk.

The first partition /dev/mmcblk0p1 indexes into the root parition by
8192 bytes.

Regards,
Paul Liu

On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> just thought of something. You searched with standard (little, I think)
> endianess
> i.e. the image from my mail to you.
>  try the image from YOUR main superblock:
> 0002 0000 0000 3434
> and see if the backup copy surfaces.
>
> jan.
>
> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>> Aspire One model A101,  which uses Atom CPU.
>>
>> I failed to find the superblock towards the end of either mmcblk0 or
>> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>>
>> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>> at address 00401000.
>>
>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
>> at 003FF000.
>>
>> I hope my SD card is not messing up itself by rearranging the blocks!
>>
>> Regards,
>> Paul Liu
>>
>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Hallo,
>> > here we go again. As a matter of interest, what version of nilfs and
>> > what
>> > distribution are you running? And what processor?
>> > your endiannes confused me at first.
>> >
>> > glad you fixed your hexedit
>> >
>> > I have looked at some numbers in the superblock and they look ok. I do
>> > wonder if you have the garbage collector running.
>> >
>> > now for the second superblock. Please pay attention to the exact place
>> > of
>> > it. Because it is of vital
>> > importance if it in in partition 1 or in the root of the disk.
>> >
>> > the first superblock sits as you observed in the root. The flags say
>> amongst
>> > others that it was unmounted cleanly but errors were detected.
>> >
>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations. in
>> the
>> > distribution.
>> > /**
>> >  * struct nilfs_super_block - structure of super block on disk
>> >  */
>> > struct nilfs_super_block {
>> > ....
>> > translates bit for bit to what you see written in the super block on
>> disk.
>> >
>> > Here is an example from a partition of mine on how to discover the
>> > superblock copy
>> > it should read the same as the 1st but in your case it might not.
>> > It is a leftshift - subtract 1 - right shift algorithm.
>> > go in hexedit to the last data with ">" (shift .)
>> > note the address of the last byte (the size of the partion)
>> > in mine:
>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> > ................
>> > or the status line might give it
>> > the address of the copy is now at 6566A000
>> > i.e. 6566B has 1 subtracted from it and the 3 least significant digits
>> have
>> > been zeroed.
>> >
>> > so please dump yours, see if the algorithm works on the 1st part or on
>> the
>> > root or both,
>> > so we know where it is.
>> > And check if it is exactly the same as the first one you send me
>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>> > etc.
>> >
>> > the next thing to discover is where the start of (nilfs)segment 0 is.
>> > I am not quite sure what is written in it, but the signature is quite
>> > distinct.
>> > This is what it looks on my machine:
>> >
>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> > ................
>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> > ................
>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> > ................
>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> > ................
>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>> > ..G[Qb......8...
>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>> > ...........J....
>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>> > ............2...
>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>> > ................
>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>> > ........{...{...
>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>> > ................
>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>> > ................
>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>> > ................
>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>> > ................
>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>> > ................
>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>> > ................
>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>> > ................
>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>> > ................
>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>> > ................
>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>> > ................
>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>> > ................
>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>> > ................
>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>> > ................
>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>> > ................
>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>> > ................
>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>> > ................
>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>> > ................
>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>> > ................
>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>> > ................
>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>> > ................
>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>> > ................
>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>> > ................
>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>> > ................
>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>> > ................
>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>> > ................
>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>> > ................
>> >
>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see above
>> and
>> > carries on for quite a while like this.
>> >
>> > so have a look on your disk if it sits at 1000 of the root partition or
>> at
>> > 1000 of partition 1.
>> >
>> > Once we have these things sorted I would say that we are ready to plant
>> the
>> > _right_ superblock of the 2
>> > in the right place and see if the partition is recoqnized by nilfs.
>> > Off course we will save the place where we are going to plant that block
>> > first.
>> >
>> > And now back to the birthday party . . . .
>> >
>> > Cheers,
>> >
>> > Jan
>> >
>> >
>> >
>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> > 26 august 98: hexedit 0.9.5 release
>> >> > september 2005:
>> >> >     - version 1.2.12  this is the one I am running.
>> >>
>> >> Ah, I must be using the wrong hexedit.. now I've installed the same one
>> >> you
>> >> use.
>> >>
>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>> >>
>> >> Yes. What I put there is:
>> >>
>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>> >>
>> >> > hd -n1536 /dev/mmcblk0 >part.start
>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>> >> > an to verify the last line:
>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>> >>
>> >> Here is the output (I use hexdump instead of hd, hopefully they are the
>> >> same)
>> >>
>> >> bash-3.1# cat part.start
>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 0000600
>> >> bash-3.1# cat part1.start
>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 00025ff
>> >> bash-3.1# cat part1a.start
>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> *
>> >> 0000600
>> >>
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >
>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>> partition
>> >> >> table with this email.
>> >> >>
>> >> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
>> >> >> mounts mmcblk0p1.
>> >> >>
>> >> >> I think something corrupted my disk first, and then what I've done
>> >> >> to
>> >> >> the disk after noticing the corruption:
>> >> >>
>> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But then
>> >> >> the one parition is gone.
>> >> >> 2. fdisk again, create a single partition, then "w"
>> >> >>
>> >> >> My mistake was that I didn't create a backup copy of the MBR. A hard
>> >> >> lesson learned :(
>> >> >>
>> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>> >> >>
>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
>> >> >>
>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>> >> >>
>> >> >> Regards,
>> >> >> Paul Liu
>> >> >>
>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >  hallo,
>> >> >> > Almost sounds like you had only the root master-boot-record
>> >> /dev/mmcblk0
>> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>> >> >> >
>> >> >> > If (and only if) that is the case we have to undo the the 1st
>> >> partition
>> >> >> > +
>> >> >> > check that no nilfs is overwritten.
>> >> >> > and I would have to urgently study fdisk to see exactly what it
>> >> >> > writes
>> >> >> when
>> >> >> > and where.
>> >> >> > The last time I did tricks like these is quit a few years ago.
>> >> >> >
>> >> >> > It is the Linux version of fdisk is it??
>> >> >> >
>> >> >> > So here is the plan of action:
>> >> >> > hexdump the master boot record to file.
>> >> >> > like this:
>> >> >> >
>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >> >> >
>> >> >> > then dump any partitions of the device in a format useful as input
>> to
>> >> >> > sfdisk. For example,
>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> >> >> > sfdisk is a tool provided with the util-linux
>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >> >> >
>> >> >> >
>> >> >> > or you could use hexdump to get machine readable or man readable
>> >> images.
>> >> >> > Here is the man readable version:
>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> >> >> > etc.
>> >> >> >
>> >> >> > By the way boor records always end with '55 AA'.
>> >> >> >
>> >> >> > Keep your files in a safe place in case we mess something we can
>> >> >> > at
>> >> >> > least
>> >> >> go
>> >> >> > back to the present situation.
>> >> >> > If you could dd the whole drive to a file, now that would be magic
>> >> >> indeed!
>> >> >> > but you must have the space on a harddrive.
>> >> >> > count=... is the number of sectors in the above line (dd ...) that
>> >> >> > you
>> >> >> dump
>> >> >> > to file.
>> >> >> > Hexedit will tell you the number of sectors is you start it with
>> >> >> > -s
>> >> >> option
>> >> >> > and then go to the last sector.
>> >> >> > DONT stop hexedit with control-x use cntl-c.
>> >> >> > DONT use high level or even midlevel tools on a stuffed disk, it
>> >> >> > normally
>> >> >> > messes more than it solves.
>> >> >> > unless of course you really,really know what you are doing.
>> >> >> > Fiddling the bytes is in general safe and gives results, if a man
>> >> keeps
>> >> >> > a
>> >> >> > cool head.
>> >> >> >
>> >> >> > Please send me the fdisk version, the size of the card, and the
>> >> >> > mbr
>> >> dump
>> >> >> to
>> >> >> > feast my eyes on.
>> >> >> >
>> >> >> > cheers,
>> >> >> >
>> >> >> > Jan de kruyf.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >
>> >> >> >> just want to add that I've always been using 1 partition on this
>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit /dev/mmcblk0p1
>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only hexedit
>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >> >> >>
>> >> >> >> Any help is greatly appreciated!
>> >> >> >>
>> >> >> >>
>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >> > Thanks for the tips. When I first used the SD card, I used
>> >> >> >> > fdisk
>> >> >> >> > to
>> >> >> >> > create the partition.
>> >> >> >> >
>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0
>> >> >> >> > shows
>> >> that
>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do then?
>> >> >> >> >
>> >> >> >> > I tried gparted, but apparently it has no support for nilfs2.
>> >> >> >> >
>> >> >> >> > Regards,
>> >> >> >> > Paul Liu
>> >> >> >> >
>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> >> >> Did you first format this card with fdisk?
>> >> >> >> >> did you give it the exact same info this time around?
>> >> >> >> >>
>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the
>> dev
>> >> >> >> >> directory
>> >> >> >> >> where the card lives)
>> >> >> >> >>
>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as
>> >> >> >> >> root?
>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>> >> >> >> >>
>> >> >> >> >> be very careful no to save any data in hexedit, it will
>> >> >> >> >> definitely
>> >> >> and
>> >> >> >> >> finally
>> >> >> >> >> destoy your data.
>> >> >> >> >>
>> >> >> >> >> 0400 looks vagely like this:
>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>> >> >> >> >> ......44.....V..
>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>> >> >> >> >> 9..s............
>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>> >> >> >> >> ..fe............
>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>> >> >> >> >> ................
>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> >> ................
>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> >> >> .H......s..J....
>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>> >> >> >> >> ........s..J....
>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>> >> >> >> >> ..2.....s..J....
>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>> >> >> >> >> .N..............
>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85
>> >> >> >> >> ..
>> >> >> >> >> .....Ls.=..E.
>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>> >> >> >> >> .(DB=...Var64...
>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> >> ................
>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >> >> >> ................
>> >> >> >> >>
>> >> >> >> >> the 34 34 in the top line say this is nilfs.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> cheers
>> >> >> >> >>
>> >> >> >> >> jan de kruyf
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>> >> >> >> >>
>> >> >> >> >>> Due to some careless handling of my laptop, the SD card
>> >> >> >> >>> popped
>> >> out
>> >> >> >> >>> when the machine is still running. When I put it back in and
>> >> reboot
>> >> >> >> >>> the machine, it says "partition table error". I then ran
>> >> >> >> >>> fdisk
>> >> and
>> >> >> >> >>> recreated the single partition. Then I can no longer mount
>> >> >> >> >>> the
>> >> >> nilfs2
>> >> >> >> >>> partition that was on the SD card!
>> >> >> >> >>>
>> >> >> >> >>> Can any one help to me recover the file system? I believe all
>> >> data
>> >> >> are
>> >> >> >> >>> still there, but just some bits and pieces are missing for
>> >> >> >> >>> the
>> >> >> >> >>> mount
>> >> >> >> >>> to work. Any help is greatly appreciated!
>> >> >> >> >>>
>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can get
>> my
>> >> >> stuff
>> >> >> >> >>> back in time... so help please!
>> >> >> >> >>>
>> >> >> >> >>> --
>> >> >> >> >>> Regards,
>> >> >> >> >>> Paul Liu
>> >> >> >> >>>
>> >> >> >> >>> Yale Haskell Group
>> >> >> >> >>> http://www.haskell.org/yale
>> >> >> >> >>> _______________________________________________
>> >> >> >> >>> users mailing list
>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Regards,
>> >> >> >> > Paul Liu
>> >> >> >> >
>> >> >> >> > Yale Haskell Group
>> >> >> >> > http://www.haskell.org/yale
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Regards,
>> >> >> >> Paul Liu
>> >> >> >>
>> >> >> >> Yale Haskell Group
>> >> >> >> http://www.haskell.org/yale
>> >> >> >> _______________________________________________
>> >> >> >> users mailing list
>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Regards,
>> >> >> Paul Liu
>> >> >>
>> >> >> Yale Haskell Group
>> >> >> http://www.haskell.org/yale
>> >> >>
>> >> >> _______________________________________________
>> >> >> users mailing list
>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> Yale Haskell Group
>> >> http://www.haskell.org/yale
>> >> _______________________________________________
>> >> users mailing list
>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Paul L]

BTW, I checked the other disk that I have nilfs2 installed, the two
super blocks indeed are one at the beginning, and one at the end of
the partition.

Very strange that this isn't the case on /dev/mmcblk0. Indeed I
started using nilfs version 2.0.5 on it, then later upgraded to
2.0.15, not sure if in between something caused this problem.


On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I think it might be the "hexdump" utility that I used. It by default
> groups things by word, so in little endian it'd say 0002 but the
> actual byte sequence is 02 00.
>
> I re-dump the following in byte sequence using od.
>
> first superblock
>
> 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
> 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
> 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
> 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
> 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> backup copy of the super block (actually different from the above)
>
> 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
> 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
> 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
> 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
> 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> The address is the absolute index into the root partition
> /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
> the super block is not something at the end of the disk.
>
> The first partition /dev/mmcblk0p1 indexes into the root parition by
> 8192 bytes.
>
> Regards,
> Paul Liu
>
> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> just thought of something. You searched with standard (little, I think)
>> endianess
>> i.e. the image from my mail to you.
>>  try the image from YOUR main superblock:
>> 0002 0000 0000 3434
>> and see if the backup copy surfaces.
>>
>> jan.
>>
>> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>>> Aspire One model A101,  which uses Atom CPU.
>>>
>>> I failed to find the superblock towards the end of either mmcblk0 or
>>> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>>>
>>> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>>> at address 00401000.
>>>
>>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
>>> at 003FF000.
>>>
>>> I hope my SD card is not messing up itself by rearranging the blocks!
>>>
>>> Regards,
>>> Paul Liu
>>>
>>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> > Hallo,
>>> > here we go again. As a matter of interest, what version of nilfs and
>>> > what
>>> > distribution are you running? And what processor?
>>> > your endiannes confused me at first.
>>> >
>>> > glad you fixed your hexedit
>>> >
>>> > I have looked at some numbers in the superblock and they look ok. I do
>>> > wonder if you have the garbage collector running.
>>> >
>>> > now for the second superblock. Please pay attention to the exact place
>>> > of
>>> > it. Because it is of vital
>>> > importance if it in in partition 1 or in the root of the disk.
>>> >
>>> > the first superblock sits as you observed in the root. The flags say
>>> amongst
>>> > others that it was unmounted cleanly but errors were detected.
>>> >
>>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations.
>>> > in
>>> the
>>> > distribution.
>>> > /**
>>> >  * struct nilfs_super_block - structure of super block on disk
>>> >  */
>>> > struct nilfs_super_block {
>>> > ....
>>> > translates bit for bit to what you see written in the super block on
>>> disk.
>>> >
>>> > Here is an example from a partition of mine on how to discover the
>>> > superblock copy
>>> > it should read the same as the 1st but in your case it might not.
>>> > It is a leftshift - subtract 1 - right shift algorithm.
>>> > go in hexedit to the last data with ">" (shift .)
>>> > note the address of the last byte (the size of the partion)
>>> > in mine:
>>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> > ................
>>> > or the status line might give it
>>> > the address of the copy is now at 6566A000
>>> > i.e. 6566B has 1 subtracted from it and the 3 least significant digits
>>> have
>>> > been zeroed.
>>> >
>>> > so please dump yours, see if the algorithm works on the 1st part or on
>>> the
>>> > root or both,
>>> > so we know where it is.
>>> > And check if it is exactly the same as the first one you send me
>>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>>> > etc.
>>> >
>>> > the next thing to discover is where the start of (nilfs)segment 0 is.
>>> > I am not quite sure what is written in it, but the signature is quite
>>> > distinct.
>>> > This is what it looks on my machine:
>>> >
>>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> > ................
>>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> > ................
>>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> > ................
>>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> > ................
>>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>>> > ..G[Qb......8...
>>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>>> > ...........J....
>>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>>> > ............2...
>>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>>> > ................
>>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>>> > ........{...{...
>>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>>> > ................
>>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>>> > ................
>>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>>> > ................
>>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>>> > ................
>>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>>> > ................
>>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>>> > ................
>>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>>> > ................
>>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>>> > ................
>>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>>> > ................
>>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>>> > ................
>>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>>> > ................
>>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>>> > ................
>>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>>> > ................
>>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>>> > ................
>>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>>> > ................
>>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>>> > ................
>>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>>> > ................
>>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>>> > ................
>>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>>> > ................
>>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>>> > ................
>>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>>> > ................
>>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>>> > ................
>>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>>> > ................
>>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>>> > ................
>>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>>> > ................
>>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>>> > ................
>>> >
>>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see above
>>> and
>>> > carries on for quite a while like this.
>>> >
>>> > so have a look on your disk if it sits at 1000 of the root partition
>>> > or
>>> at
>>> > 1000 of partition 1.
>>> >
>>> > Once we have these things sorted I would say that we are ready to
>>> > plant
>>> the
>>> > _right_ superblock of the 2
>>> > in the right place and see if the partition is recoqnized by nilfs.
>>> > Off course we will save the place where we are going to plant that
>>> > block
>>> > first.
>>> >
>>> > And now back to the birthday party . . . .
>>> >
>>> > Cheers,
>>> >
>>> > Jan
>>> >
>>> >
>>> >
>>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >
>>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >> > 26 august 98: hexedit 0.9.5 release
>>> >> > september 2005:
>>> >> >     - version 1.2.12  this is the one I am running.
>>> >>
>>> >> Ah, I must be using the wrong hexedit.. now I've installed the same
>>> >> one
>>> >> you
>>> >> use.
>>> >>
>>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>>> >>
>>> >> Yes. What I put there is:
>>> >>
>>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>>> >>
>>> >> > hd -n1536 /dev/mmcblk0 >part.start
>>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>>> >> > an to verify the last line:
>>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>>> >>
>>> >> Here is the output (I use hexdump instead of hd, hopefully they are
>>> >> the
>>> >> same)
>>> >>
>>> >> bash-3.1# cat part.start
>>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 0000600
>>> >> bash-3.1# cat part1.start
>>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 00025ff
>>> >> bash-3.1# cat part1a.start
>>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>>> >> *
>>> >> 0000600
>>> >>
>>> >> Regards,
>>> >> Paul Liu
>>> >>
>>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >> >
>>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>>> partition
>>> >> >> table with this email.
>>> >> >>
>>> >> >> I'm pretty sure I had 1 partition on the card, since my /etc/fstab
>>> >> >> mounts mmcblk0p1.
>>> >> >>
>>> >> >> I think something corrupted my disk first, and then what I've done
>>> >> >> to
>>> >> >> the disk after noticing the corruption:
>>> >> >>
>>> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But
>>> >> >> then
>>> >> >> the one parition is gone.
>>> >> >> 2. fdisk again, create a single partition, then "w"
>>> >> >>
>>> >> >> My mistake was that I didn't create a backup copy of the MBR. A
>>> >> >> hard
>>> >> >> lesson learned :(
>>> >> >>
>>> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
>>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>>> >> >>
>>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
>>> >> >>
>>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>>> >> >>
>>> >> >> Regards,
>>> >> >> Paul Liu
>>> >> >>
>>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >> >> >  hallo,
>>> >> >> > Almost sounds like you had only the root master-boot-record
>>> >> /dev/mmcblk0
>>> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>>> >> >> >
>>> >> >> > If (and only if) that is the case we have to undo the the 1st
>>> >> partition
>>> >> >> > +
>>> >> >> > check that no nilfs is overwritten.
>>> >> >> > and I would have to urgently study fdisk to see exactly what it
>>> >> >> > writes
>>> >> >> when
>>> >> >> > and where.
>>> >> >> > The last time I did tricks like these is quit a few years ago.
>>> >> >> >
>>> >> >> > It is the Linux version of fdisk is it??
>>> >> >> >
>>> >> >> > So here is the plan of action:
>>> >> >> > hexdump the master boot record to file.
>>> >> >> > like this:
>>> >> >> >
>>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>>> >> >> >
>>> >> >> > then dump any partitions of the device in a format useful as
>>> >> >> > input
>>> to
>>> >> >> > sfdisk. For example,
>>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>>> >> >> > sfdisk is a tool provided with the util-linux
>>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>>> >> >> >
>>> >> >> >
>>> >> >> > or you could use hexdump to get machine readable or man readable
>>> >> images.
>>> >> >> > Here is the man readable version:
>>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>>> >> >> > etc.
>>> >> >> >
>>> >> >> > By the way boor records always end with '55 AA'.
>>> >> >> >
>>> >> >> > Keep your files in a safe place in case we mess something we can
>>> >> >> > at
>>> >> >> > least
>>> >> >> go
>>> >> >> > back to the present situation.
>>> >> >> > If you could dd the whole drive to a file, now that would be
>>> >> >> > magic
>>> >> >> indeed!
>>> >> >> > but you must have the space on a harddrive.
>>> >> >> > count=... is the number of sectors in the above line (dd ...)
>>> >> >> > that
>>> >> >> > you
>>> >> >> dump
>>> >> >> > to file.
>>> >> >> > Hexedit will tell you the number of sectors is you start it with
>>> >> >> > -s
>>> >> >> option
>>> >> >> > and then go to the last sector.
>>> >> >> > DONT stop hexedit with control-x use cntl-c.
>>> >> >> > DONT use high level or even midlevel tools on a stuffed disk, it
>>> >> >> > normally
>>> >> >> > messes more than it solves.
>>> >> >> > unless of course you really,really know what you are doing.
>>> >> >> > Fiddling the bytes is in general safe and gives results, if a
>>> >> >> > man
>>> >> keeps
>>> >> >> > a
>>> >> >> > cool head.
>>> >> >> >
>>> >> >> > Please send me the fdisk version, the size of the card, and the
>>> >> >> > mbr
>>> >> dump
>>> >> >> to
>>> >> >> > feast my eyes on.
>>> >> >> >
>>> >> >> > cheers,
>>> >> >> >
>>> >> >> > Jan de kruyf.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> just want to add that I've always been using 1 partition on
>>> >> >> >> this
>>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
>>> >> >> >> /dev/mmcblk0p1
>>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
>>> >> >> >> hexedit
>>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>>> >> >> >>
>>> >> >> >> Any help is greatly appreciated!
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >> >> >> > Thanks for the tips. When I first used the SD card, I used
>>> >> >> >> > fdisk
>>> >> >> >> > to
>>> >> >> >> > create the partition.
>>> >> >> >> >
>>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0
>>> >> >> >> > shows
>>> >> that
>>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
>>> >> >> >> > then?
>>> >> >> >> >
>>> >> >> >> > I tried gparted, but apparently it has no support for nilfs2.
>>> >> >> >> >
>>> >> >> >> > Regards,
>>> >> >> >> > Paul Liu
>>> >> >> >> >
>>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >> >> >> >> Did you first format this card with fdisk?
>>> >> >> >> >> did you give it the exact same info this time around?
>>> >> >> >> >>
>>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in the
>>> dev
>>> >> >> >> >> directory
>>> >> >> >> >> where the card lives)
>>> >> >> >> >>
>>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal as
>>> >> >> >> >> root?
>>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
>>> >> >> >> >>
>>> >> >> >> >> be very careful no to save any data in hexedit, it will
>>> >> >> >> >> definitely
>>> >> >> and
>>> >> >> >> >> finally
>>> >> >> >> >> destoy your data.
>>> >> >> >> >>
>>> >> >> >> >> 0400 looks vagely like this:
>>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
>>> >> >> >> >> ......44.....V..
>>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
>>> >> >> >> >> 9..s............
>>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
>>> >> >> >> >> ..fe............
>>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
>>> >> >> >> >> ................
>>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> >> >> >> >> ................
>>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>>> >> >> >> >> .H......s..J....
>>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
>>> >> >> >> >> ........s..J....
>>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
>>> >> >> >> >> ..2.....s..J....
>>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
>>> >> >> >> >> .N..............
>>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85
>>> >> >> >> >> ..
>>> >> >> >> >> .....Ls.=..E.
>>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
>>> >> >> >> >> .(DB=...Var64...
>>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> >> >> >> >> ................
>>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>> >> >> >> >> ................
>>> >> >> >> >>
>>> >> >> >> >> the 34 34 in the top line say this is nilfs.
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> cheers
>>> >> >> >> >>
>>> >> >> >> >> jan de kruyf
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> wrote:
>>> >> >> >> >>
>>> >> >> >> >>> Due to some careless handling of my laptop, the SD card
>>> >> >> >> >>> popped
>>> >> out
>>> >> >> >> >>> when the machine is still running. When I put it back in
>>> >> >> >> >>> and
>>> >> reboot
>>> >> >> >> >>> the machine, it says "partition table error". I then ran
>>> >> >> >> >>> fdisk
>>> >> and
>>> >> >> >> >>> recreated the single partition. Then I can no longer mount
>>> >> >> >> >>> the
>>> >> >> nilfs2
>>> >> >> >> >>> partition that was on the SD card!
>>> >> >> >> >>>
>>> >> >> >> >>> Can any one help to me recover the file system? I believe
>>> >> >> >> >>> all
>>> >> data
>>> >> >> are
>>> >> >> >> >>> still there, but just some bits and pieces are missing for
>>> >> >> >> >>> the
>>> >> >> >> >>> mount
>>> >> >> >> >>> to work. Any help is greatly appreciated!
>>> >> >> >> >>>
>>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can
>>> >> >> >> >>> get
>>> my
>>> >> >> stuff
>>> >> >> >> >>> back in time... so help please!
>>> >> >> >> >>>
>>> >> >> >> >>> --
>>> >> >> >> >>> Regards,
>>> >> >> >> >>> Paul Liu
>>> >> >> >> >>>
>>> >> >> >> >>> Yale Haskell Group
>>> >> >> >> >>> http://www.haskell.org/yale
>>> >> >> >> >>> _______________________________________________
>>> >> >> >> >>> users mailing list
>>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>>> >> >> >> >>>
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > --
>>> >> >> >> > Regards,
>>> >> >> >> > Paul Liu
>>> >> >> >> >
>>> >> >> >> > Yale Haskell Group
>>> >> >> >> > http://www.haskell.org/yale
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Regards,
>>> >> >> >> Paul Liu
>>> >> >> >>
>>> >> >> >> Yale Haskell Group
>>> >> >> >> http://www.haskell.org/yale
>>> >> >> >> _______________________________________________
>>> >> >> >> users mailing list
>>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Regards,
>>> >> >> Paul Liu
>>> >> >>
>>> >> >> Yale Haskell Group
>>> >> >> http://www.haskell.org/yale
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> users mailing list
>>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> >> >> https://www.nilfs.org/mailman/listinfo/users
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Regards,
>>> >> Paul Liu
>>> >>
>>> >> Yale Haskell Group
>>> >> http://www.haskell.org/yale
>>> >> _______________________________________________
>>> >> users mailing list
>>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> >> https://www.nilfs.org/mailman/listinfo/users
>>> >>
>>> >
>>>
>>>
>>> --
>>> Regards,
>>> Paul Liu
>>>
>>> Yale Haskell Group
>>> http://www.haskell.org/yale
>>> _______________________________________________
>>> users mailing list
>>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>>> https://www.nilfs.org/mailman/listinfo/users
>>>
>>
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 26752 bytes --]

Paul,
I have been doing some research in between things today
here is some proposition I came up with, please check my math
and thinking and do some more sleuthing. Please ask if anything
is not clear:

The math has been done on my trusted calc package for emacs
hence the 16# for the base in front.

16#3D7C00000    device size according to you
16#3D7800000    device size according to superblock (at 16#420)
------------- -
16#000400000    this agrees with the partition base address of the second
                             superblock which lives at 16#400400 according
to you
                             also the start address of segment 0 indexes
from here

>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>at address 00401000.

if at least in this line you send me, the addresses are from 00000 of the
device.

So I am inclined to believe that the original(before the accident)
start address of the nilfs partition was at 16#400000 of the device.


Then this holds true according to nilfs2_fs.h:
/*
 * bytes offset of secondary super block
 */
#define NILFS_SB2_OFFSET_BYTES(devsize)    ((((devsize) >> 12) - 1) << 12)

so:
16#3D7800000    device size according to superblock (16#420)
16#000001000    and blank the ls 000 but they are 0 already
------------ -
16#3D77FF000    should be the place of the 2nd superblock in the original
partition
16#000400000    index of the original partition (believed to be)
------------ +
16#3D7BFF000    should be the place in the device where the 2nd superblock
lives.
                              (or maybe I should say the 3rd)

This whole proposition is off course grounded in the belief that the first
superblock
with the error flag set is written in error and should be discarded.
Although it might refer to real additional data because it has more
checkpoints than the 2nd
that you found. But I would rather discard those and retrieve the older
checkpoint.
Both superblocks were created in the same login session by the way.

So could you make an efford to find the 3rd superblock or send me the 3
blocks around the
place I indicated, to see what happened there.

Jan de Kruyf.

"Enthusiasm beats facts anytime"
------------------------------------------


On Thu, Nov 5, 2009 at 5:57 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> BTW, I checked the other disk that I have nilfs2 installed, the two
> super blocks indeed are one at the beginning, and one at the end of
> the partition.
>
> Very strange that this isn't the case on /dev/mmcblk0. Indeed I
> started using nilfs version 2.0.5 on it, then later upgraded to
> 2.0.15, not sure if in between something caused this problem.
>
>
> On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I think it might be the "hexdump" utility that I used. It by default
> > groups things by word, so in little endian it'd say 0002 but the
> > actual byte sequence is 02 00.
> >
> > I re-dump the following in byte sequence using od.
> >
> > first superblock
> >
> > 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> > 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
> > 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> > 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
> > 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> > 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> > 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
> > 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
> > 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> > 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> > 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> > 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> > backup copy of the super block (actually different from the above)
> >
> > 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> > 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
> > 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> > 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
> > 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> > 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> > 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
> > 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
> > 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> > 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> > 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> > 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> > The address is the absolute index into the root partition
> > /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
> > the super block is not something at the end of the disk.
> >
> > The first partition /dev/mmcblk0p1 indexes into the root parition by
> > 8192 bytes.
> >
> > Regards,
> > Paul Liu
> >
> > On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> just thought of something. You searched with standard (little, I think)
> >> endianess
> >> i.e. the image from my mail to you.
> >>  try the image from YOUR main superblock:
> >> 0002 0000 0000 3434
> >> and see if the backup copy surfaces.
> >>
> >> jan.
> >>
> >> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
> >>> Aspire One model A101,  which uses Atom CPU.
> >>>
> >>> I failed to find the superblock towards the end of either mmcblk0 or
> >>> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
> >>>
> >>> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> >>> at address 00401000.
> >>>
> >>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
> >>> at 003FF000.
> >>>
> >>> I hope my SD card is not messing up itself by rearranging the blocks!
> >>>
> >>> Regards,
> >>> Paul Liu
> >>>
> >>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> > Hallo,
> >>> > here we go again. As a matter of interest, what version of nilfs and
> >>> > what
> >>> > distribution are you running? And what processor?
> >>> > your endiannes confused me at first.
> >>> >
> >>> > glad you fixed your hexedit
> >>> >
> >>> > I have looked at some numbers in the superblock and they look ok. I
> do
> >>> > wonder if you have the garbage collector running.
> >>> >
> >>> > now for the second superblock. Please pay attention to the exact
> place
> >>> > of
> >>> > it. Because it is of vital
> >>> > importance if it in in partition 1 or in the root of the disk.
> >>> >
> >>> > the first superblock sits as you observed in the root. The flags say
> >>> amongst
> >>> > others that it was unmounted cleanly but errors were detected.
> >>> >
> >>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common declarations.
> >>> > in
> >>> the
> >>> > distribution.
> >>> > /**
> >>> >  * struct nilfs_super_block - structure of super block on disk
> >>> >  */
> >>> > struct nilfs_super_block {
> >>> > ....
> >>> > translates bit for bit to what you see written in the super block on
> >>> disk.
> >>> >
> >>> > Here is an example from a partition of mine on how to discover the
> >>> > superblock copy
> >>> > it should read the same as the 1st but in your case it might not.
> >>> > It is a leftshift - subtract 1 - right shift algorithm.
> >>> > go in hexedit to the last data with ">" (shift .)
> >>> > note the address of the last byte (the size of the partion)
> >>> > in mine:
> >>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> > ................
> >>> > or the status line might give it
> >>> > the address of the copy is now at 6566A000
> >>> > i.e. 6566B has 1 subtracted from it and the 3 least significant
> digits
> >>> have
> >>> > been zeroed.
> >>> >
> >>> > so please dump yours, see if the algorithm works on the 1st part or
> on
> >>> the
> >>> > root or both,
> >>> > so we know where it is.
> >>> > And check if it is exactly the same as the first one you send me
> >>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> >>> > etc.
> >>> >
> >>> > the next thing to discover is where the start of (nilfs)segment 0 is.
> >>> > I am not quite sure what is written in it, but the signature is quite
> >>> > distinct.
> >>> > This is what it looks on my machine:
> >>> >
> >>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> > ................
> >>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> > ................
> >>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> > ................
> >>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> > ................
> >>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
> >>> > ..G[Qb......8...
> >>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
> >>> > ...........J....
> >>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
> >>> > ............2...
> >>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
> >>> > ................
> >>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
> >>> > ........{...{...
> >>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
> >>> > ................
> >>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
> >>> > ................
> >>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
> >>> > ................
> >>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
> >>> > ................
> >>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
> >>> > ................
> >>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
> >>> > ................
> >>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
> >>> > ................
> >>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
> >>> > ................
> >>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
> >>> > ................
> >>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
> >>> > ................
> >>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
> >>> > ................
> >>> >
> >>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see
> above
> >>> and
> >>> > carries on for quite a while like this.
> >>> >
> >>> > so have a look on your disk if it sits at 1000 of the root partition
> >>> > or
> >>> at
> >>> > 1000 of partition 1.
> >>> >
> >>> > Once we have these things sorted I would say that we are ready to
> >>> > plant
> >>> the
> >>> > _right_ superblock of the 2
> >>> > in the right place and see if the partition is recoqnized by nilfs.
> >>> > Off course we will save the place where we are going to plant that
> >>> > block
> >>> > first.
> >>> >
> >>> > And now back to the birthday party . . . .
> >>> >
> >>> > Cheers,
> >>> >
> >>> > Jan
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >
> >>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >> > 26 august 98: hexedit 0.9.5 release
> >>> >> > september 2005:
> >>> >> >     - version 1.2.12  this is the one I am running.
> >>> >>
> >>> >> Ah, I must be using the wrong hexedit.. now I've installed the same
> >>> >> one
> >>> >> you
> >>> >> use.
> >>> >>
> >>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
> >>> >>
> >>> >> Yes. What I put there is:
> >>> >>
> >>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
> >>> >>
> >>> >> > hd -n1536 /dev/mmcblk0 >part.start
> >>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> >>> >> > an to verify the last line:
> >>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
> >>> >>
> >>> >> Here is the output (I use hexdump instead of hd, hopefully they are
> >>> >> the
> >>> >> same)
> >>> >>
> >>> >> bash-3.1# cat part.start
> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
> >>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
> >>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
> >>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
> >>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
> >>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
> >>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
> >>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
> >>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
> >>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
> >>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
> >>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
> >>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
> >>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
> >>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 0000600
> >>> >> bash-3.1# cat part1.start
> >>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 00025ff
> >>> >> bash-3.1# cat part1a.start
> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >>> >> *
> >>> >> 0000600
> >>> >>
> >>> >> Regards,
> >>> >> Paul Liu
> >>> >>
> >>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >> >
> >>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
> >>> partition
> >>> >> >> table with this email.
> >>> >> >>
> >>> >> >> I'm pretty sure I had 1 partition on the card, since my
> /etc/fstab
> >>> >> >> mounts mmcblk0p1.
> >>> >> >>
> >>> >> >> I think something corrupted my disk first, and then what I've
> done
> >>> >> >> to
> >>> >> >> the disk after noticing the corruption:
> >>> >> >>
> >>> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But
> >>> >> >> then
> >>> >> >> the one parition is gone.
> >>> >> >> 2. fdisk again, create a single partition, then "w"
> >>> >> >>
> >>> >> >> My mistake was that I didn't create a backup copy of the MBR. A
> >>> >> >> hard
> >>> >> >> lesson learned :(
> >>> >> >>
> >>> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
> >>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
> >>> >> >>
> >>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
> >>> >> >>
> >>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
> >>> >> >>
> >>> >> >> Regards,
> >>> >> >> Paul Liu
> >>> >> >>
> >>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >> >> >  hallo,
> >>> >> >> > Almost sounds like you had only the root master-boot-record
> >>> >> /dev/mmcblk0
> >>> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
> >>> >> >> >
> >>> >> >> > If (and only if) that is the case we have to undo the the 1st
> >>> >> partition
> >>> >> >> > +
> >>> >> >> > check that no nilfs is overwritten.
> >>> >> >> > and I would have to urgently study fdisk to see exactly what it
> >>> >> >> > writes
> >>> >> >> when
> >>> >> >> > and where.
> >>> >> >> > The last time I did tricks like these is quit a few years ago.
> >>> >> >> >
> >>> >> >> > It is the Linux version of fdisk is it??
> >>> >> >> >
> >>> >> >> > So here is the plan of action:
> >>> >> >> > hexdump the master boot record to file.
> >>> >> >> > like this:
> >>> >> >> >
> >>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >>> >> >> >
> >>> >> >> > then dump any partitions of the device in a format useful as
> >>> >> >> > input
> >>> to
> >>> >> >> > sfdisk. For example,
> >>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> >>> >> >> > sfdisk is a tool provided with the util-linux
> >>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > or you could use hexdump to get machine readable or man
> readable
> >>> >> images.
> >>> >> >> > Here is the man readable version:
> >>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> >>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> >>> >> >> > etc.
> >>> >> >> >
> >>> >> >> > By the way boor records always end with '55 AA'.
> >>> >> >> >
> >>> >> >> > Keep your files in a safe place in case we mess something we
> can
> >>> >> >> > at
> >>> >> >> > least
> >>> >> >> go
> >>> >> >> > back to the present situation.
> >>> >> >> > If you could dd the whole drive to a file, now that would be
> >>> >> >> > magic
> >>> >> >> indeed!
> >>> >> >> > but you must have the space on a harddrive.
> >>> >> >> > count=... is the number of sectors in the above line (dd ...)
> >>> >> >> > that
> >>> >> >> > you
> >>> >> >> dump
> >>> >> >> > to file.
> >>> >> >> > Hexedit will tell you the number of sectors is you start it
> with
> >>> >> >> > -s
> >>> >> >> option
> >>> >> >> > and then go to the last sector.
> >>> >> >> > DONT stop hexedit with control-x use cntl-c.
> >>> >> >> > DONT use high level or even midlevel tools on a stuffed disk,
> it
> >>> >> >> > normally
> >>> >> >> > messes more than it solves.
> >>> >> >> > unless of course you really,really know what you are doing.
> >>> >> >> > Fiddling the bytes is in general safe and gives results, if a
> >>> >> >> > man
> >>> >> keeps
> >>> >> >> > a
> >>> >> >> > cool head.
> >>> >> >> >
> >>> >> >> > Please send me the fdisk version, the size of the card, and the
> >>> >> >> > mbr
> >>> >> dump
> >>> >> >> to
> >>> >> >> > feast my eyes on.
> >>> >> >> >
> >>> >> >> > cheers,
> >>> >> >> >
> >>> >> >> > Jan de kruyf.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>> >> >> > wrote:
> >>> >> >> >
> >>> >> >> >> just want to add that I've always been using 1 partition on
> >>> >> >> >> this
> >>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
> >>> >> >> >> /dev/mmcblk0p1
> >>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
> >>> >> >> >> hexedit
> >>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >>> >> >> >>
> >>> >> >> >> Any help is greatly appreciated!
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >> >> >> > Thanks for the tips. When I first used the SD card, I used
> >>> >> >> >> > fdisk
> >>> >> >> >> > to
> >>> >> >> >> > create the partition.
> >>> >> >> >> >
> >>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0
> >>> >> >> >> > shows
> >>> >> that
> >>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
> >>> >> >> >> > then?
> >>> >> >> >> >
> >>> >> >> >> > I tried gparted, but apparently it has no support for
> nilfs2.
> >>> >> >> >> >
> >>> >> >> >> > Regards,
> >>> >> >> >> > Paul Liu
> >>> >> >> >> >
> >>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> >> >> >> >> Did you first format this card with fdisk?
> >>> >> >> >> >> did you give it the exact same info this time around?
> >>> >> >> >> >>
> >>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in
> the
> >>> dev
> >>> >> >> >> >> directory
> >>> >> >> >> >> where the card lives)
> >>> >> >> >> >>
> >>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal
> as
> >>> >> >> >> >> root?
> >>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still exists?
> >>> >> >> >> >>
> >>> >> >> >> >> be very careful no to save any data in hexedit, it will
> >>> >> >> >> >> definitely
> >>> >> >> and
> >>> >> >> >> >> finally
> >>> >> >> >> >> destoy your data.
> >>> >> >> >> >>
> >>> >> >> >> >> 0400 looks vagely like this:
> >>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0 B9
> >>> >> >> >> >> ......44.....V..
> >>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00 00
> >>> >> >> >> >> 9..s............
> >>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00 00
> >>> >> >> >> >> ..fe............
> >>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00 00
> >>> >> >> >> >> ................
> >>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> >> >> >> >> ................
> >>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >>> >> >> >> >> .H......s..J....
> >>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00 00
> >>> >> >> >> >> ........s..J....
> >>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00 00
> >>> >> >> >> >> ..2.....s..J....
> >>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00 00
> >>> >> >> >> >> .N..............
> >>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45 85
> >>> >> >> >> >> ..
> >>> >> >> >> >> .....Ls.=..E.
> >>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00 00
> >>> >> >> >> >> .(DB=...Var64...
> >>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> >> >> >> >> ................
> >>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >>> >> >> >> >> ................
> >>> >> >> >> >>
> >>> >> >> >> >> the 34 34 in the top line say this is nilfs.
> >>> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >> >> cheers
> >>> >> >> >> >>
> >>> >> >> >> >> jan de kruyf
> >>> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>> wrote:
> >>> >> >> >> >>
> >>> >> >> >> >>> Due to some careless handling of my laptop, the SD card
> >>> >> >> >> >>> popped
> >>> >> out
> >>> >> >> >> >>> when the machine is still running. When I put it back in
> >>> >> >> >> >>> and
> >>> >> reboot
> >>> >> >> >> >>> the machine, it says "partition table error". I then ran
> >>> >> >> >> >>> fdisk
> >>> >> and
> >>> >> >> >> >>> recreated the single partition. Then I can no longer mount
> >>> >> >> >> >>> the
> >>> >> >> nilfs2
> >>> >> >> >> >>> partition that was on the SD card!
> >>> >> >> >> >>>
> >>> >> >> >> >>> Can any one help to me recover the file system? I believe
> >>> >> >> >> >>> all
> >>> >> data
> >>> >> >> are
> >>> >> >> >> >>> still there, but just some bits and pieces are missing for
> >>> >> >> >> >>> the
> >>> >> >> >> >>> mount
> >>> >> >> >> >>> to work. Any help is greatly appreciated!
> >>> >> >> >> >>>
> >>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can
> >>> >> >> >> >>> get
> >>> my
> >>> >> >> stuff
> >>> >> >> >> >>> back in time... so help please!
> >>> >> >> >> >>>
> >>> >> >> >> >>> --
> >>> >> >> >> >>> Regards,
> >>> >> >> >> >>> Paul Liu
> >>> >> >> >> >>>
> >>> >> >> >> >>> Yale Haskell Group
> >>> >> >> >> >>> http://www.haskell.org/yale
> >>> >> >> >> >>> _______________________________________________
> >>> >> >> >> >>> users mailing list
> >>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >>> >> >> >> >>>
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> > --
> >>> >> >> >> > Regards,
> >>> >> >> >> > Paul Liu
> >>> >> >> >> >
> >>> >> >> >> > Yale Haskell Group
> >>> >> >> >> > http://www.haskell.org/yale
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >> --
> >>> >> >> >> Regards,
> >>> >> >> >> Paul Liu
> >>> >> >> >>
> >>> >> >> >> Yale Haskell Group
> >>> >> >> >> http://www.haskell.org/yale
> >>> >> >> >> _______________________________________________
> >>> >> >> >> users mailing list
> >>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
> >>> >> >> >>
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >> >> --
> >>> >> >> Regards,
> >>> >> >> Paul Liu
> >>> >> >>
> >>> >> >> Yale Haskell Group
> >>> >> >> http://www.haskell.org/yale
> >>> >> >>
> >>> >> >> _______________________________________________
> >>> >> >> users mailing list
> >>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> >> >> https://www.nilfs.org/mailman/listinfo/users
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Regards,
> >>> >> Paul Liu
> >>> >>
> >>> >> Yale Haskell Group
> >>> >> http://www.haskell.org/yale
> >>> >> _______________________________________________
> >>> >> users mailing list
> >>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> >> https://www.nilfs.org/mailman/listinfo/users
> >>> >>
> >>> >
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Paul Liu
> >>>
> >>> Yale Haskell Group
> >>> http://www.haskell.org/yale
> >>> _______________________________________________
> >>> users mailing list
> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >>> https://www.nilfs.org/mailman/listinfo/users
> >>>
> >>
> >
> >
> > --
> > Regards,
> > Paul Liu
> >
> > Yale Haskell Group
> > http://www.haskell.org/yale
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 42840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

[SPAM] Re: urgent help need! disk partition info lost

[Paul L]

Wow, that is some good calculation, thanks!

But unfortunately, the data around 3D7BFF00 doesn't look like a super
block at all.
I did a search of the string  02 00 00 00 00 00 34 34 00 01 00 00 on
the entire disk, only two places showed up.

Also strangely the blocks towards end of the disk are all filled with
data, but from 0x0 to 0x400000 are all 0s except of course the MBR.

I wonder if there is some kind of wrapping around? What could have caused it?

Regards,
Paul Liu

On 11/5/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Paul,
> I have been doing some research in between things today
> here is some proposition I came up with, please check my math
> and thinking and do some more sleuthing. Please ask if anything
> is not clear:
>
> The math has been done on my trusted calc package for emacs
> hence the 16# for the base in front.
>
> 16#3D7C00000    device size according to you
> 16#3D7800000    device size according to superblock (at 16#420)
> ------------- -
> 16#000400000    this agrees with the partition base address of the second
>                              superblock which lives at 16#400400 according
> to you
>                              also the start address of segment 0 indexes
> from here
>
>>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>>at address 00401000.
>
> if at least in this line you send me, the addresses are from 00000 of the
> device.
>
> So I am inclined to believe that the original(before the accident)
> start address of the nilfs partition was at 16#400000 of the device.
>
>
> Then this holds true according to nilfs2_fs.h:
> /*
>  * bytes offset of secondary super block
>  */
> #define NILFS_SB2_OFFSET_BYTES(devsize)    ((((devsize) >> 12) - 1) << 12)
>
> so:
> 16#3D7800000    device size according to superblock (16#420)
> 16#000001000    and blank the ls 000 but they are 0 already
> ------------ -
> 16#3D77FF000    should be the place of the 2nd superblock in the original
> partition
> 16#000400000    index of the original partition (believed to be)
> ------------ +
> 16#3D7BFF000    should be the place in the device where the 2nd superblock
> lives.
>                               (or maybe I should say the 3rd)
>
> This whole proposition is off course grounded in the belief that the first
> superblock
> with the error flag set is written in error and should be discarded.
> Although it might refer to real additional data because it has more
> checkpoints than the 2nd
> that you found. But I would rather discard those and retrieve the older
> checkpoint.
> Both superblocks were created in the same login session by the way.
>
> So could you make an efford to find the 3rd superblock or send me the 3
> blocks around the
> place I indicated, to see what happened there.
>
> Jan de Kruyf.
>
> "Enthusiasm beats facts anytime"
> ------------------------------------------
>
>
> On Thu, Nov 5, 2009 at 5:57 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> BTW, I checked the other disk that I have nilfs2 installed, the two
>> super blocks indeed are one at the beginning, and one at the end of
>> the partition.
>>
>> Very strange that this isn't the case on /dev/mmcblk0. Indeed I
>> started using nilfs version 2.0.5 on it, then later upgraded to
>> 2.0.15, not sure if in between something caused this problem.
>>
>>
>> On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > I think it might be the "hexdump" utility that I used. It by default
>> > groups things by word, so in little endian it'd say 0002 but the
>> > actual byte sequence is 02 00.
>> >
>> > I re-dump the following in byte sequence using od.
>> >
>> > first superblock
>> >
>> > 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> > 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
>> > 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> > 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
>> > 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> > 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> > 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
>> > 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
>> > 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> > 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> > 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> > 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >
>> > backup copy of the super block (actually different from the above)
>> >
>> > 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> > 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
>> > 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> > 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
>> > 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> > 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> > 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
>> > 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
>> > 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> > 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> > 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> > 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >
>> > The address is the absolute index into the root partition
>> > /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
>> > the super block is not something at the end of the disk.
>> >
>> > The first partition /dev/mmcblk0p1 indexes into the root parition by
>> > 8192 bytes.
>> >
>> > Regards,
>> > Paul Liu
>> >
>> > On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> just thought of something. You searched with standard (little, I think)
>> >> endianess
>> >> i.e. the image from my mail to you.
>> >>  try the image from YOUR main superblock:
>> >> 0002 0000 0000 3434
>> >> and see if the backup copy surfaces.
>> >>
>> >> jan.
>> >>
>> >> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>
>> >>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>> >>> Aspire One model A101,  which uses Atom CPU.
>> >>>
>> >>> I failed to find the superblock towards the end of either mmcblk0 or
>> >>> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
>> >>>
>> >>> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>> >>> at address 00401000.
>> >>>
>> >>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0 starts
>> >>> at 003FF000.
>> >>>
>> >>> I hope my SD card is not messing up itself by rearranging the blocks!
>> >>>
>> >>> Regards,
>> >>> Paul Liu
>> >>>
>> >>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> > Hallo,
>> >>> > here we go again. As a matter of interest, what version of nilfs and
>> >>> > what
>> >>> > distribution are you running? And what processor?
>> >>> > your endiannes confused me at first.
>> >>> >
>> >>> > glad you fixed your hexedit
>> >>> >
>> >>> > I have looked at some numbers in the superblock and they look ok. I
>> do
>> >>> > wonder if you have the garbage collector running.
>> >>> >
>> >>> > now for the second superblock. Please pay attention to the exact
>> place
>> >>> > of
>> >>> > it. Because it is of vital
>> >>> > importance if it in in partition 1 or in the root of the disk.
>> >>> >
>> >>> > the first superblock sits as you observed in the root. The flags say
>> >>> amongst
>> >>> > others that it was unmounted cleanly but errors were detected.
>> >>> >
>> >>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common
>> >>> > declarations.
>> >>> > in
>> >>> the
>> >>> > distribution.
>> >>> > /**
>> >>> >  * struct nilfs_super_block - structure of super block on disk
>> >>> >  */
>> >>> > struct nilfs_super_block {
>> >>> > ....
>> >>> > translates bit for bit to what you see written in the super block on
>> >>> disk.
>> >>> >
>> >>> > Here is an example from a partition of mine on how to discover the
>> >>> > superblock copy
>> >>> > it should read the same as the 1st but in your case it might not.
>> >>> > It is a leftshift - subtract 1 - right shift algorithm.
>> >>> > go in hexedit to the last data with ">" (shift .)
>> >>> > note the address of the last byte (the size of the partion)
>> >>> > in mine:
>> >>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >>> > ................
>> >>> > or the status line might give it
>> >>> > the address of the copy is now at 6566A000
>> >>> > i.e. 6566B has 1 subtracted from it and the 3 least significant
>> digits
>> >>> have
>> >>> > been zeroed.
>> >>> >
>> >>> > so please dump yours, see if the algorithm works on the 1st part or
>> on
>> >>> the
>> >>> > root or both,
>> >>> > so we know where it is.
>> >>> > And check if it is exactly the same as the first one you send me
>> >>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>> >>> > etc.
>> >>> >
>> >>> > the next thing to discover is where the start of (nilfs)segment 0
>> >>> > is.
>> >>> > I am not quite sure what is written in it, but the signature is
>> >>> > quite
>> >>> > distinct.
>> >>> > This is what it looks on my machine:
>> >>> >
>> >>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>> >>> > ..G[Qb......8...
>> >>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>> >>> > ...........J....
>> >>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>> >>> > ............2...
>> >>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>> >>> > ........{...{...
>> >>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>> >>> > ................
>> >>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>> >>> > ................
>> >>> >
>> >>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see
>> above
>> >>> and
>> >>> > carries on for quite a while like this.
>> >>> >
>> >>> > so have a look on your disk if it sits at 1000 of the root partition
>> >>> > or
>> >>> at
>> >>> > 1000 of partition 1.
>> >>> >
>> >>> > Once we have these things sorted I would say that we are ready to
>> >>> > plant
>> >>> the
>> >>> > _right_ superblock of the 2
>> >>> > in the right place and see if the partition is recoqnized by nilfs.
>> >>> > Off course we will save the place where we are going to plant that
>> >>> > block
>> >>> > first.
>> >>> >
>> >>> > And now back to the birthday party . . . .
>> >>> >
>> >>> > Cheers,
>> >>> >
>> >>> > Jan
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >
>> >>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >> > 26 august 98: hexedit 0.9.5 release
>> >>> >> > september 2005:
>> >>> >> >     - version 1.2.12  this is the one I am running.
>> >>> >>
>> >>> >> Ah, I must be using the wrong hexedit.. now I've installed the same
>> >>> >> one
>> >>> >> you
>> >>> >> use.
>> >>> >>
>> >>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>> >>> >>
>> >>> >> Yes. What I put there is:
>> >>> >>
>> >>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>> >>> >>
>> >>> >> > hd -n1536 /dev/mmcblk0 >part.start
>> >>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>> >>> >> > an to verify the last line:
>> >>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>> >>> >>
>> >>> >> Here is the output (I use hexdump instead of hd, hopefully they are
>> >>> >> the
>> >>> >> same)
>> >>> >>
>> >>> >> bash-3.1# cat part.start
>> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>> >>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>> >>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>> >>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>> >>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>> >>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>> >>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>> >>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>> >>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>> >>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>> >>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>> >>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>> >>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>> >>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>> >>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 0000600
>> >>> >> bash-3.1# cat part1.start
>> >>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 00025ff
>> >>> >> bash-3.1# cat part1a.start
>> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >>> >> *
>> >>> >> 0000600
>> >>> >>
>> >>> >> Regards,
>> >>> >> Paul Liu
>> >>> >>
>> >>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >> >
>> >>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>> >>> partition
>> >>> >> >> table with this email.
>> >>> >> >>
>> >>> >> >> I'm pretty sure I had 1 partition on the card, since my
>> /etc/fstab
>> >>> >> >> mounts mmcblk0p1.
>> >>> >> >>
>> >>> >> >> I think something corrupted my disk first, and then what I've
>> done
>> >>> >> >> to
>> >>> >> >> the disk after noticing the corruption:
>> >>> >> >>
>> >>> >> >> 1. fdisk, it says use "w" will correct the error, so I did. But
>> >>> >> >> then
>> >>> >> >> the one parition is gone.
>> >>> >> >> 2. fdisk again, create a single partition, then "w"
>> >>> >> >>
>> >>> >> >> My mistake was that I didn't create a backup copy of the MBR. A
>> >>> >> >> hard
>> >>> >> >> lesson learned :(
>> >>> >> >>
>> >>> >> >> Also, why is that my hexedit doesn't take the "-s" option? It's
>> >>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>> >>> >> >>
>> >>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
>> >>> >> >>
>> >>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>> >>> >> >>
>> >>> >> >> Regards,
>> >>> >> >> Paul Liu
>> >>> >> >>
>> >>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >> >> >  hallo,
>> >>> >> >> > Almost sounds like you had only the root master-boot-record
>> >>> >> /dev/mmcblk0
>> >>> >> >> > before and now you have added 1 main partition /dev/mmcblk0p1.
>> >>> >> >> >
>> >>> >> >> > If (and only if) that is the case we have to undo the the 1st
>> >>> >> partition
>> >>> >> >> > +
>> >>> >> >> > check that no nilfs is overwritten.
>> >>> >> >> > and I would have to urgently study fdisk to see exactly what
>> >>> >> >> > it
>> >>> >> >> > writes
>> >>> >> >> when
>> >>> >> >> > and where.
>> >>> >> >> > The last time I did tricks like these is quit a few years ago.
>> >>> >> >> >
>> >>> >> >> > It is the Linux version of fdisk is it??
>> >>> >> >> >
>> >>> >> >> > So here is the plan of action:
>> >>> >> >> > hexdump the master boot record to file.
>> >>> >> >> > like this:
>> >>> >> >> >
>> >>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >>> >> >> >
>> >>> >> >> > then dump any partitions of the device in a format useful as
>> >>> >> >> > input
>> >>> to
>> >>> >> >> > sfdisk. For example,
>> >>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> >>> >> >> > sfdisk is a tool provided with the util-linux
>> >>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > or you could use hexdump to get machine readable or man
>> readable
>> >>> >> images.
>> >>> >> >> > Here is the man readable version:
>> >>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> >>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> >>> >> >> > etc.
>> >>> >> >> >
>> >>> >> >> > By the way boor records always end with '55 AA'.
>> >>> >> >> >
>> >>> >> >> > Keep your files in a safe place in case we mess something we
>> can
>> >>> >> >> > at
>> >>> >> >> > least
>> >>> >> >> go
>> >>> >> >> > back to the present situation.
>> >>> >> >> > If you could dd the whole drive to a file, now that would be
>> >>> >> >> > magic
>> >>> >> >> indeed!
>> >>> >> >> > but you must have the space on a harddrive.
>> >>> >> >> > count=... is the number of sectors in the above line (dd ...)
>> >>> >> >> > that
>> >>> >> >> > you
>> >>> >> >> dump
>> >>> >> >> > to file.
>> >>> >> >> > Hexedit will tell you the number of sectors is you start it
>> with
>> >>> >> >> > -s
>> >>> >> >> option
>> >>> >> >> > and then go to the last sector.
>> >>> >> >> > DONT stop hexedit with control-x use cntl-c.
>> >>> >> >> > DONT use high level or even midlevel tools on a stuffed disk,
>> it
>> >>> >> >> > normally
>> >>> >> >> > messes more than it solves.
>> >>> >> >> > unless of course you really,really know what you are doing.
>> >>> >> >> > Fiddling the bytes is in general safe and gives results, if a
>> >>> >> >> > man
>> >>> >> keeps
>> >>> >> >> > a
>> >>> >> >> > cool head.
>> >>> >> >> >
>> >>> >> >> > Please send me the fdisk version, the size of the card, and
>> >>> >> >> > the
>> >>> >> >> > mbr
>> >>> >> dump
>> >>> >> >> to
>> >>> >> >> > feast my eyes on.
>> >>> >> >> >
>> >>> >> >> > cheers,
>> >>> >> >> >
>> >>> >> >> > Jan de kruyf.
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >>> >> >> > wrote:
>> >>> >> >> >
>> >>> >> >> >> just want to add that I've always been using 1 partition on
>> >>> >> >> >> this
>> >>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
>> >>> >> >> >> /dev/mmcblk0p1
>> >>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
>> >>> >> >> >> hexedit
>> >>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >>> >> >> >>
>> >>> >> >> >> Any help is greatly appreciated!
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >> >> >> > Thanks for the tips. When I first used the SD card, I used
>> >>> >> >> >> > fdisk
>> >>> >> >> >> > to
>> >>> >> >> >> > create the partition.
>> >>> >> >> >> >
>> >>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s /dev/mmcblk0
>> >>> >> >> >> > shows
>> >>> >> that
>> >>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
>> >>> >> >> >> > then?
>> >>> >> >> >> >
>> >>> >> >> >> > I tried gparted, but apparently it has no support for
>> nilfs2.
>> >>> >> >> >> >
>> >>> >> >> >> > Regards,
>> >>> >> >> >> > Paul Liu
>> >>> >> >> >> >
>> >>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> >> >> >> >> Did you first format this card with fdisk?
>> >>> >> >> >> >> did you give it the exact same info this time around?
>> >>> >> >> >> >>
>> >>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in
>> the
>> >>> dev
>> >>> >> >> >> >> directory
>> >>> >> >> >> >> where the card lives)
>> >>> >> >> >> >>
>> >>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a terminal
>> as
>> >>> >> >> >> >> root?
>> >>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still
>> >>> >> >> >> >> exists?
>> >>> >> >> >> >>
>> >>> >> >> >> >> be very careful no to save any data in hexedit, it will
>> >>> >> >> >> >> definitely
>> >>> >> >> and
>> >>> >> >> >> >> finally
>> >>> >> >> >> >> destoy your data.
>> >>> >> >> >> >>
>> >>> >> >> >> >> 0400 looks vagely like this:
>> >>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0
>> >>> >> >> >> >> B9
>> >>> >> >> >> >> ......44.....V..
>> >>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> 9..s............
>> >>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ..fe............
>> >>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ................
>> >>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ................
>> >>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> .H......s..J....
>> >>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ........s..J....
>> >>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ..2.....s..J....
>> >>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> .N..............
>> >>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45
>> >>> >> >> >> >> 85
>> >>> >> >> >> >> ..
>> >>> >> >> >> >> .....Ls.=..E.
>> >>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> .(DB=...Var64...
>> >>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ................
>> >>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
>> >>> >> >> >> >> 00
>> >>> >> >> >> >> ................
>> >>> >> >> >> >>
>> >>> >> >> >> >> the 34 34 in the top line say this is nilfs.
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >> >> cheers
>> >>> >> >> >> >>
>> >>> >> >> >> >> jan de kruyf
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >>> wrote:
>> >>> >> >> >> >>
>> >>> >> >> >> >>> Due to some careless handling of my laptop, the SD card
>> >>> >> >> >> >>> popped
>> >>> >> out
>> >>> >> >> >> >>> when the machine is still running. When I put it back in
>> >>> >> >> >> >>> and
>> >>> >> reboot
>> >>> >> >> >> >>> the machine, it says "partition table error". I then ran
>> >>> >> >> >> >>> fdisk
>> >>> >> and
>> >>> >> >> >> >>> recreated the single partition. Then I can no longer
>> >>> >> >> >> >>> mount
>> >>> >> >> >> >>> the
>> >>> >> >> nilfs2
>> >>> >> >> >> >>> partition that was on the SD card!
>> >>> >> >> >> >>>
>> >>> >> >> >> >>> Can any one help to me recover the file system? I believe
>> >>> >> >> >> >>> all
>> >>> >> data
>> >>> >> >> are
>> >>> >> >> >> >>> still there, but just some bits and pieces are missing
>> >>> >> >> >> >>> for
>> >>> >> >> >> >>> the
>> >>> >> >> >> >>> mount
>> >>> >> >> >> >>> to work. Any help is greatly appreciated!
>> >>> >> >> >> >>>
>> >>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I can
>> >>> >> >> >> >>> get
>> >>> my
>> >>> >> >> stuff
>> >>> >> >> >> >>> back in time... so help please!
>> >>> >> >> >> >>>
>> >>> >> >> >> >>> --
>> >>> >> >> >> >>> Regards,
>> >>> >> >> >> >>> Paul Liu
>> >>> >> >> >> >>>
>> >>> >> >> >> >>> Yale Haskell Group
>> >>> >> >> >> >>> http://www.haskell.org/yale
>> >>> >> >> >> >>> _______________________________________________
>> >>> >> >> >> >>> users mailing list
>> >>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >>> >> >> >> >>>
>> >>> >> >> >> >>
>> >>> >> >> >> >
>> >>> >> >> >> >
>> >>> >> >> >> > --
>> >>> >> >> >> > Regards,
>> >>> >> >> >> > Paul Liu
>> >>> >> >> >> >
>> >>> >> >> >> > Yale Haskell Group
>> >>> >> >> >> > http://www.haskell.org/yale
>> >>> >> >> >> >
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >> --
>> >>> >> >> >> Regards,
>> >>> >> >> >> Paul Liu
>> >>> >> >> >>
>> >>> >> >> >> Yale Haskell Group
>> >>> >> >> >> http://www.haskell.org/yale
>> >>> >> >> >> _______________________________________________
>> >>> >> >> >> users mailing list
>> >>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> --
>> >>> >> >> Regards,
>> >>> >> >> Paul Liu
>> >>> >> >>
>> >>> >> >> Yale Haskell Group
>> >>> >> >> http://www.haskell.org/yale
>> >>> >> >>
>> >>> >> >> _______________________________________________
>> >>> >> >> users mailing list
>> >>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Regards,
>> >>> >> Paul Liu
>> >>> >>
>> >>> >> Yale Haskell Group
>> >>> >> http://www.haskell.org/yale
>> >>> >> _______________________________________________
>> >>> >> users mailing list
>> >>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>> Paul Liu
>> >>>
>> >>> Yale Haskell Group
>> >>> http://www.haskell.org/yale
>> >>> _______________________________________________
>> >>> users mailing list
>> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >>> https://www.nilfs.org/mailman/listinfo/users
>> >>>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Paul Liu
>> >
>> > Yale Haskell Group
>> > http://www.haskell.org/yale
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: [SPAM] Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 31709 bytes --]

Ryusuke,
Good day to you.

I need some help here.
I like to change the partition table on this filesystem that is broken, so
that nilfs will pick up
the primary superblock and what looks like segment 0.
However, the secondary superblock is missing or written out of place, and it
looks
like data is written in the usual place of the secondary superblock.

At the same time I pick up from "the_nilfs.c :: load_nilfs that even if a
partition is mounted read-only
perhaps certain things do get written
this is the code I refer to:
-------------------------
    if (!valid_fs && (s_flags & MS_RDONLY)) {
        printk(KERN_INFO "NILFS: INFO: recovery "
               "required for readonly filesystem.\n");
        if (really_read_only) {
            printk(KERN_ERR "NILFS: write access "
                   "unavailable, cannot proceed.\n");
            err = -EROFS;
            goto failed;
        }
        printk(KERN_INFO "NILFS: write access will "
               "be enabled during recovery.\n");
        sbi->s_super->s_flags &= ~MS_RDONLY;
    }
------------------------
So how do we proceed mounting this filesystem completely read-only to see
if perhaps some data can be recovered. (Provided that the partition table
now
points to a more or less valid nilfs partition.)

Many thanks,

Jan de Kruyf.

On Thu, Nov 5, 2009 at 8:02 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Wow, that is some good calculation, thanks!
>
> But unfortunately, the data around 3D7BFF00 doesn't look like a super
> block at all.
> I did a search of the string  02 00 00 00 00 00 34 34 00 01 00 00 on
> the entire disk, only two places showed up.
>
> Also strangely the blocks towards end of the disk are all filled with
> data, but from 0x0 to 0x400000 are all 0s except of course the MBR.
>
> I wonder if there is some kind of wrapping around? What could have caused
> it?
>
> Regards,
> Paul Liu
>
> On 11/5/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Paul,
> > I have been doing some research in between things today
> > here is some proposition I came up with, please check my math
> > and thinking and do some more sleuthing. Please ask if anything
> > is not clear:
> >
> > The math has been done on my trusted calc package for emacs
> > hence the 16# for the base in front.
> >
> > 16#3D7C00000    device size according to you
> > 16#3D7800000    device size according to superblock (at 16#420)
> > ------------- -
> > 16#000400000    this agrees with the partition base address of the second
> >                              superblock which lives at 16#400400
> according
> > to you
> >                              also the start address of segment 0 indexes
> > from here
> >
> >>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> >>at address 00401000.
> >
> > if at least in this line you send me, the addresses are from 00000 of the
> > device.
> >
> > So I am inclined to believe that the original(before the accident)
> > start address of the nilfs partition was at 16#400000 of the device.
> >
> >
> > Then this holds true according to nilfs2_fs.h:
> > /*
> >  * bytes offset of secondary super block
> >  */
> > #define NILFS_SB2_OFFSET_BYTES(devsize)    ((((devsize) >> 12) - 1) <<
> 12)
> >
> > so:
> > 16#3D7800000    device size according to superblock (16#420)
> > 16#000001000    and blank the ls 000 but they are 0 already
> > ------------ -
> > 16#3D77FF000    should be the place of the 2nd superblock in the original
> > partition
> > 16#000400000    index of the original partition (believed to be)
> > ------------ +
> > 16#3D7BFF000    should be the place in the device where the 2nd
> superblock
> > lives.
> >                               (or maybe I should say the 3rd)
> >
> > This whole proposition is off course grounded in the belief that the
> first
> > superblock
> > with the error flag set is written in error and should be discarded.
> > Although it might refer to real additional data because it has more
> > checkpoints than the 2nd
> > that you found. But I would rather discard those and retrieve the older
> > checkpoint.
> > Both superblocks were created in the same login session by the way.
> >
> > So could you make an efford to find the 3rd superblock or send me the 3
> > blocks around the
> > place I indicated, to see what happened there.
> >
> > Jan de Kruyf.
> >
> > "Enthusiasm beats facts anytime"
> > ------------------------------------------
> >
> >
> > On Thu, Nov 5, 2009 at 5:57 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> BTW, I checked the other disk that I have nilfs2 installed, the two
> >> super blocks indeed are one at the beginning, and one at the end of
> >> the partition.
> >>
> >> Very strange that this isn't the case on /dev/mmcblk0. Indeed I
> >> started using nilfs version 2.0.5 on it, then later upgraded to
> >> 2.0.15, not sure if in between something caused this problem.
> >>
> >>
> >> On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > I think it might be the "hexdump" utility that I used. It by default
> >> > groups things by word, so in little endian it'd say 0002 but the
> >> > actual byte sequence is 02 00.
> >> >
> >> > I re-dump the following in byte sequence using od.
> >> >
> >> > first superblock
> >> >
> >> > 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> >> > 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
> >> > 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> >> > 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
> >> > 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> >> > 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> >> > 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
> >> > 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
> >> > 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> >> > 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> >> > 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> >> > 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> >
> >> > backup copy of the super block (actually different from the above)
> >> >
> >> > 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
> >> > 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
> >> > 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
> >> > 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
> >> > 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
> >> > 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
> >> > 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
> >> > 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
> >> > 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
> >> > 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
> >> > 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
> >> > 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> >
> >> > The address is the absolute index into the root partition
> >> > /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
> >> > the super block is not something at the end of the disk.
> >> >
> >> > The first partition /dev/mmcblk0p1 indexes into the root parition by
> >> > 8192 bytes.
> >> >
> >> > Regards,
> >> > Paul Liu
> >> >
> >> > On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> just thought of something. You searched with standard (little, I
> think)
> >> >> endianess
> >> >> i.e. the image from my mail to you.
> >> >>  try the image from YOUR main superblock:
> >> >> 0002 0000 0000 3434
> >> >> and see if the backup copy surfaces.
> >> >>
> >> >> jan.
> >> >>
> >> >> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>
> >> >>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
> >> >>> Aspire One model A101,  which uses Atom CPU.
> >> >>>
> >> >>> I failed to find the superblock towards the end of either mmcblk0 or
> >> >>> mmcblk0p1, but a search of hex string 0200000000003434 reveals that:
> >> >>>
> >> >>> mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
> >> >>> at address 00401000.
> >> >>>
> >> >>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0
> starts
> >> >>> at 003FF000.
> >> >>>
> >> >>> I hope my SD card is not messing up itself by rearranging the
> blocks!
> >> >>>
> >> >>> Regards,
> >> >>> Paul Liu
> >> >>>
> >> >>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> > Hallo,
> >> >>> > here we go again. As a matter of interest, what version of nilfs
> and
> >> >>> > what
> >> >>> > distribution are you running? And what processor?
> >> >>> > your endiannes confused me at first.
> >> >>> >
> >> >>> > glad you fixed your hexedit
> >> >>> >
> >> >>> > I have looked at some numbers in the superblock and they look ok.
> I
> >> do
> >> >>> > wonder if you have the garbage collector running.
> >> >>> >
> >> >>> > now for the second superblock. Please pay attention to the exact
> >> place
> >> >>> > of
> >> >>> > it. Because it is of vital
> >> >>> > importance if it in in partition 1 or in the root of the disk.
> >> >>> >
> >> >>> > the first superblock sits as you observed in the root. The flags
> say
> >> >>> amongst
> >> >>> > others that it was unmounted cleanly but errors were detected.
> >> >>> >
> >> >>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common
> >> >>> > declarations.
> >> >>> > in
> >> >>> the
> >> >>> > distribution.
> >> >>> > /**
> >> >>> >  * struct nilfs_super_block - structure of super block on disk
> >> >>> >  */
> >> >>> > struct nilfs_super_block {
> >> >>> > ....
> >> >>> > translates bit for bit to what you see written in the super block
> on
> >> >>> disk.
> >> >>> >
> >> >>> > Here is an example from a partition of mine on how to discover the
> >> >>> > superblock copy
> >> >>> > it should read the same as the 1st but in your case it might not.
> >> >>> > It is a leftshift - subtract 1 - right shift algorithm.
> >> >>> > go in hexedit to the last data with ">" (shift .)
> >> >>> > note the address of the last byte (the size of the partion)
> >> >>> > in mine:
> >> >>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > or the status line might give it
> >> >>> > the address of the copy is now at 6566A000
> >> >>> > i.e. 6566B has 1 subtracted from it and the 3 least significant
> >> digits
> >> >>> have
> >> >>> > been zeroed.
> >> >>> >
> >> >>> > so please dump yours, see if the algorithm works on the 1st part
> or
> >> on
> >> >>> the
> >> >>> > root or both,
> >> >>> > so we know where it is.
> >> >>> > And check if it is exactly the same as the first one you send me
> >> >>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
> >> >>> > etc.
> >> >>> >
> >> >>> > the next thing to discover is where the start of (nilfs)segment 0
> >> >>> > is.
> >> >>> > I am not quite sure what is written in it, but the signature is
> >> >>> > quite
> >> >>> > distinct.
> >> >>> > This is what it looks on my machine:
> >> >>> >
> >> >>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
> >> >>> > ..G[Qb......8...
> >> >>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
> >> >>> > ...........J....
> >> >>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
> >> >>> > ............2...
> >> >>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
> >> >>> > ........{...{...
> >> >>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
> >> >>> > ................
> >> >>> >
> >> >>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see
> >> above
> >> >>> and
> >> >>> > carries on for quite a while like this.
> >> >>> >
> >> >>> > so have a look on your disk if it sits at 1000 of the root
> partition
> >> >>> > or
> >> >>> at
> >> >>> > 1000 of partition 1.
> >> >>> >
> >> >>> > Once we have these things sorted I would say that we are ready to
> >> >>> > plant
> >> >>> the
> >> >>> > _right_ superblock of the 2
> >> >>> > in the right place and see if the partition is recoqnized by
> nilfs.
> >> >>> > Off course we will save the place where we are going to plant that
> >> >>> > block
> >> >>> > first.
> >> >>> >
> >> >>> > And now back to the birthday party . . . .
> >> >>> >
> >> >>> > Cheers,
> >> >>> >
> >> >>> > Jan
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> >
> >> >>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> >> > 26 august 98: hexedit 0.9.5 release
> >> >>> >> > september 2005:
> >> >>> >> >     - version 1.2.12  this is the one I am running.
> >> >>> >>
> >> >>> >> Ah, I must be using the wrong hexedit.. now I've installed the
> same
> >> >>> >> one
> >> >>> >> you
> >> >>> >> use.
> >> >>> >>
> >> >>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
> >> >>> >>
> >> >>> >> Yes. What I put there is:
> >> >>> >>
> >> >>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
> >> >>> >>
> >> >>> >> > hd -n1536 /dev/mmcblk0 >part.start
> >> >>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
> >> >>> >> > an to verify the last line:
> >> >>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
> >> >>> >>
> >> >>> >> Here is the output (I use hexdump instead of hd, hopefully they
> are
> >> >>> >> the
> >> >>> >> same)
> >> >>> >>
> >> >>> >> bash-3.1# cat part.start
> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
> >> >>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
> >> >>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
> >> >>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
> >> >>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
> >> >>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
> >> >>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
> >> >>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
> >> >>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
> >> >>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
> >> >>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
> >> >>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
> >> >>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
> >> >>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
> >> >>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 0000600
> >> >>> >> bash-3.1# cat part1.start
> >> >>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 00025ff
> >> >>> >> bash-3.1# cat part1a.start
> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> >> >>> >> *
> >> >>> >> 0000600
> >> >>> >>
> >> >>> >> Regards,
> >> >>> >> Paul Liu
> >> >>> >>
> >> >>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> >> >>> >> >
> >> >>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
> >> >>> partition
> >> >>> >> >> table with this email.
> >> >>> >> >>
> >> >>> >> >> I'm pretty sure I had 1 partition on the card, since my
> >> /etc/fstab
> >> >>> >> >> mounts mmcblk0p1.
> >> >>> >> >>
> >> >>> >> >> I think something corrupted my disk first, and then what I've
> >> done
> >> >>> >> >> to
> >> >>> >> >> the disk after noticing the corruption:
> >> >>> >> >>
> >> >>> >> >> 1. fdisk, it says use "w" will correct the error, so I did.
> But
> >> >>> >> >> then
> >> >>> >> >> the one parition is gone.
> >> >>> >> >> 2. fdisk again, create a single partition, then "w"
> >> >>> >> >>
> >> >>> >> >> My mistake was that I didn't create a backup copy of the MBR.
> A
> >> >>> >> >> hard
> >> >>> >> >> lesson learned :(
> >> >>> >> >>
> >> >>> >> >> Also, why is that my hexedit doesn't take the "-s" option?
> It's
> >> >>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
> >> >>> >> >>
> >> >>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
> >> >>> >> >>
> >> >>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
> >> >>> >> >>
> >> >>> >> >> Regards,
> >> >>> >> >> Paul Liu
> >> >>> >> >>
> >> >>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> >> >> >  hallo,
> >> >>> >> >> > Almost sounds like you had only the root master-boot-record
> >> >>> >> /dev/mmcblk0
> >> >>> >> >> > before and now you have added 1 main partition
> /dev/mmcblk0p1.
> >> >>> >> >> >
> >> >>> >> >> > If (and only if) that is the case we have to undo the the
> 1st
> >> >>> >> partition
> >> >>> >> >> > +
> >> >>> >> >> > check that no nilfs is overwritten.
> >> >>> >> >> > and I would have to urgently study fdisk to see exactly what
> >> >>> >> >> > it
> >> >>> >> >> > writes
> >> >>> >> >> when
> >> >>> >> >> > and where.
> >> >>> >> >> > The last time I did tricks like these is quit a few years
> ago.
> >> >>> >> >> >
> >> >>> >> >> > It is the Linux version of fdisk is it??
> >> >>> >> >> >
> >> >>> >> >> > So here is the plan of action:
> >> >>> >> >> > hexdump the master boot record to file.
> >> >>> >> >> > like this:
> >> >>> >> >> >
> >> >>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
> >> >>> >> >> >
> >> >>> >> >> > then dump any partitions of the device in a format useful as
> >> >>> >> >> > input
> >> >>> to
> >> >>> >> >> > sfdisk. For example,
> >> >>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
> >> >>> >> >> > sfdisk is a tool provided with the util-linux
> >> >>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> > or you could use hexdump to get machine readable or man
> >> readable
> >> >>> >> images.
> >> >>> >> >> > Here is the man readable version:
> >> >>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
> >> >>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
> >> >>> >> >> > etc.
> >> >>> >> >> >
> >> >>> >> >> > By the way boor records always end with '55 AA'.
> >> >>> >> >> >
> >> >>> >> >> > Keep your files in a safe place in case we mess something we
> >> can
> >> >>> >> >> > at
> >> >>> >> >> > least
> >> >>> >> >> go
> >> >>> >> >> > back to the present situation.
> >> >>> >> >> > If you could dd the whole drive to a file, now that would be
> >> >>> >> >> > magic
> >> >>> >> >> indeed!
> >> >>> >> >> > but you must have the space on a harddrive.
> >> >>> >> >> > count=... is the number of sectors in the above line (dd
> ...)
> >> >>> >> >> > that
> >> >>> >> >> > you
> >> >>> >> >> dump
> >> >>> >> >> > to file.
> >> >>> >> >> > Hexedit will tell you the number of sectors is you start it
> >> with
> >> >>> >> >> > -s
> >> >>> >> >> option
> >> >>> >> >> > and then go to the last sector.
> >> >>> >> >> > DONT stop hexedit with control-x use cntl-c.
> >> >>> >> >> > DONT use high level or even midlevel tools on a stuffed
> disk,
> >> it
> >> >>> >> >> > normally
> >> >>> >> >> > messes more than it solves.
> >> >>> >> >> > unless of course you really,really know what you are doing.
> >> >>> >> >> > Fiddling the bytes is in general safe and gives results, if
> a
> >> >>> >> >> > man
> >> >>> >> keeps
> >> >>> >> >> > a
> >> >>> >> >> > cool head.
> >> >>> >> >> >
> >> >>> >> >> > Please send me the fdisk version, the size of the card, and
> >> >>> >> >> > the
> >> >>> >> >> > mbr
> >> >>> >> dump
> >> >>> >> >> to
> >> >>> >> >> > feast my eyes on.
> >> >>> >> >> >
> >> >>> >> >> > cheers,
> >> >>> >> >> >
> >> >>> >> >> > Jan de kruyf.
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> >>> >> >> > wrote:
> >> >>> >> >> >
> >> >>> >> >> >> just want to add that I've always been using 1 partition on
> >> >>> >> >> >> this
> >> >>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
> >> >>> >> >> >> /dev/mmcblk0p1
> >> >>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
> >> >>> >> >> >> hexedit
> >> >>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
> >> >>> >> >> >>
> >> >>> >> >> >> Any help is greatly appreciated!
> >> >>> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> >> >> >> > Thanks for the tips. When I first used the SD card, I
> used
> >> >>> >> >> >> > fdisk
> >> >>> >> >> >> > to
> >> >>> >> >> >> > create the partition.
> >> >>> >> >> >> >
> >> >>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s
> /dev/mmcblk0
> >> >>> >> >> >> > shows
> >> >>> >> that
> >> >>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
> >> >>> >> >> >> > then?
> >> >>> >> >> >> >
> >> >>> >> >> >> > I tried gparted, but apparently it has no support for
> >> nilfs2.
> >> >>> >> >> >> >
> >> >>> >> >> >> > Regards,
> >> >>> >> >> >> > Paul Liu
> >> >>> >> >> >> >
> >> >>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>> >> >> >> >> Did you first format this card with fdisk?
> >> >>> >> >> >> >> did you give it the exact same info this time around?
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device in
> >> the
> >> >>> dev
> >> >>> >> >> >> >> directory
> >> >>> >> >> >> >> where the card lives)
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a
> terminal
> >> as
> >> >>> >> >> >> >> root?
> >> >>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still
> >> >>> >> >> >> >> exists?
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> be very careful no to save any data in hexedit, it will
> >> >>> >> >> >> >> definitely
> >> >>> >> >> and
> >> >>> >> >> >> >> finally
> >> >>> >> >> >> >> destoy your data.
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> 0400 looks vagely like this:
> >> >>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56 F0
> >> >>> >> >> >> >> B9
> >> >>> >> >> >> >> ......44.....V..
> >> >>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> 9..s............
> >> >>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ..fe............
> >> >>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ................
> >> >>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ................
> >> >>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> .H......s..J....
> >> >>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ........s..J....
> >> >>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ..2.....s..J....
> >> >>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> .N..............
> >> >>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC 45
> >> >>> >> >> >> >> 85
> >> >>> >> >> >> >> ..
> >> >>> >> >> >> >> .....Ls.=..E.
> >> >>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> .(DB=...Var64...
> >> >>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ................
> >> >>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> >> >>> >> >> >> >> 00
> >> >>> >> >> >> >> ................
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> the 34 34 in the top line say this is nilfs.
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> cheers
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> jan de kruyf
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <
> ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> >>> wrote:
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>> Due to some careless handling of my laptop, the SD card
> >> >>> >> >> >> >>> popped
> >> >>> >> out
> >> >>> >> >> >> >>> when the machine is still running. When I put it back
> in
> >> >>> >> >> >> >>> and
> >> >>> >> reboot
> >> >>> >> >> >> >>> the machine, it says "partition table error". I then
> ran
> >> >>> >> >> >> >>> fdisk
> >> >>> >> and
> >> >>> >> >> >> >>> recreated the single partition. Then I can no longer
> >> >>> >> >> >> >>> mount
> >> >>> >> >> >> >>> the
> >> >>> >> >> nilfs2
> >> >>> >> >> >> >>> partition that was on the SD card!
> >> >>> >> >> >> >>>
> >> >>> >> >> >> >>> Can any one help to me recover the file system? I
> believe
> >> >>> >> >> >> >>> all
> >> >>> >> data
> >> >>> >> >> are
> >> >>> >> >> >> >>> still there, but just some bits and pieces are missing
> >> >>> >> >> >> >>> for
> >> >>> >> >> >> >>> the
> >> >>> >> >> >> >>> mount
> >> >>> >> >> >> >>> to work. Any help is greatly appreciated!
> >> >>> >> >> >> >>>
> >> >>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I
> can
> >> >>> >> >> >> >>> get
> >> >>> my
> >> >>> >> >> stuff
> >> >>> >> >> >> >>> back in time... so help please!
> >> >>> >> >> >> >>>
> >> >>> >> >> >> >>> --
> >> >>> >> >> >> >>> Regards,
> >> >>> >> >> >> >>> Paul Liu
> >> >>> >> >> >> >>>
> >> >>> >> >> >> >>> Yale Haskell Group
> >> >>> >> >> >> >>> http://www.haskell.org/yale
> >> >>> >> >> >> >>> _______________________________________________
> >> >>> >> >> >> >>> users mailing list
> >> >>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >>> >> >> >> >>>
> >> >>> >> >> >> >>
> >> >>> >> >> >> >
> >> >>> >> >> >> >
> >> >>> >> >> >> > --
> >> >>> >> >> >> > Regards,
> >> >>> >> >> >> > Paul Liu
> >> >>> >> >> >> >
> >> >>> >> >> >> > Yale Haskell Group
> >> >>> >> >> >> > http://www.haskell.org/yale
> >> >>> >> >> >> >
> >> >>> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >> --
> >> >>> >> >> >> Regards,
> >> >>> >> >> >> Paul Liu
> >> >>> >> >> >>
> >> >>> >> >> >> Yale Haskell Group
> >> >>> >> >> >> http://www.haskell.org/yale
> >> >>> >> >> >> _______________________________________________
> >> >>> >> >> >> users mailing list
> >> >>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>> >> >> >>
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> --
> >> >>> >> >> Regards,
> >> >>> >> >> Paul Liu
> >> >>> >> >>
> >> >>> >> >> Yale Haskell Group
> >> >>> >> >> http://www.haskell.org/yale
> >> >>> >> >>
> >> >>> >> >> _______________________________________________
> >> >>> >> >> users mailing list
> >> >>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> >> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Regards,
> >> >>> >> Paul Liu
> >> >>> >>
> >> >>> >> Yale Haskell Group
> >> >>> >> http://www.haskell.org/yale
> >> >>> >> _______________________________________________
> >> >>> >> users mailing list
> >> >>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> >> https://www.nilfs.org/mailman/listinfo/users
> >> >>> >>
> >> >>> >
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Regards,
> >> >>> Paul Liu
> >> >>>
> >> >>> Yale Haskell Group
> >> >>> http://www.haskell.org/yale
> >> >>> _______________________________________________
> >> >>> users mailing list
> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> >>> https://www.nilfs.org/mailman/listinfo/users
> >> >>>
> >> >>
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Paul Liu
> >> >
> >> > Yale Haskell Group
> >> > http://www.haskell.org/yale
> >> >
> >>
> >>
> >> --
> >> Regards,
> >> Paul Liu
> >>
> >> Yale Haskell Group
> >> http://www.haskell.org/yale
> >> _______________________________________________
> >> users mailing list
> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> >> https://www.nilfs.org/mailman/listinfo/users
> >>
> >
>
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 53356 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: [SPAM] Re: urgent help need! disk partition info lost

[Paul L]

Ok, based on the info so far, I've successfully recovered my files!

1. Thanks to David Arendt's suggestion, I backed up all data on the SD
card first in another computer before proceeding.

2. I used sfdisk to create a single partition starting from address
0x400000. This is what Jan suggested based on the information I
provided.

3. I then tried to mount /dev/mmcblk0p1 readonly, but it failed by
first a warning "Checksum error in segment payload", and then "error
searching super root".

4. I then recompiled nilfs2.ko by turning on the debug, installed it
and rebooted the machine.

5. I then tried to mount again after "echo '-vvv recovery' >
/proc/fs/nilfs2 debug_option", now the error message was more
elaborate, and the actual place it failed was when doing a full check
in load_segment_summary(..).

6. Now it seemed no way to proceed, and I decided to try my luck by
modifying nilfs_search_super_root(...) function to do a partial check
instead of a full check (by changing the flag from 1 to 0). Compiled,
installed, and rebooted.

It then all worked out from there. I immediately plugged in a USB
drive, and copied all my files to the backup. Only one file seemed to
have been damaged during the incident. I didn't bother to check if all
the prevoius checkpoint on the nilfs2 partition worked and just went
ahead and re-partitioned and re-formatted the SD card.

I must thank Jan de Kruyf for the tremendeous help! Thank you all very much!

Now I'm just going to celebrate the magical recovery from the loss of
months' hard work!


On 11/5/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Ryusuke,
> Good day to you.
>
> I need some help here.
> I like to change the partition table on this filesystem that is broken, so
> that nilfs will pick up
> the primary superblock and what looks like segment 0.
> However, the secondary superblock is missing or written out of place, and it
> looks
> like data is written in the usual place of the secondary superblock.
>
> At the same time I pick up from "the_nilfs.c :: load_nilfs that even if a
> partition is mounted read-only
> perhaps certain things do get written
> this is the code I refer to:
> -------------------------
>     if (!valid_fs && (s_flags & MS_RDONLY)) {
>         printk(KERN_INFO "NILFS: INFO: recovery "
>                "required for readonly filesystem.\n");
>         if (really_read_only) {
>             printk(KERN_ERR "NILFS: write access "
>                    "unavailable, cannot proceed.\n");
>             err = -EROFS;
>             goto failed;
>         }
>         printk(KERN_INFO "NILFS: write access will "
>                "be enabled during recovery.\n");
>         sbi->s_super->s_flags &= ~MS_RDONLY;
>     }
> ------------------------
> So how do we proceed mounting this filesystem completely read-only to see
> if perhaps some data can be recovered. (Provided that the partition table
> now
> points to a more or less valid nilfs partition.)
>
> Many thanks,
>
> Jan de Kruyf.
>
> On Thu, Nov 5, 2009 at 8:02 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Wow, that is some good calculation, thanks!
>>
>> But unfortunately, the data around 3D7BFF00 doesn't look like a super
>> block at all.
>> I did a search of the string  02 00 00 00 00 00 34 34 00 01 00 00 on
>> the entire disk, only two places showed up.
>>
>> Also strangely the blocks towards end of the disk are all filled with
>> data, but from 0x0 to 0x400000 are all 0s except of course the MBR.
>>
>> I wonder if there is some kind of wrapping around? What could have caused
>> it?
>>
>> Regards,
>> Paul Liu
>>
>> On 11/5/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Paul,
>> > I have been doing some research in between things today
>> > here is some proposition I came up with, please check my math
>> > and thinking and do some more sleuthing. Please ask if anything
>> > is not clear:
>> >
>> > The math has been done on my trusted calc package for emacs
>> > hence the 16# for the base in front.
>> >
>> > 16#3D7C00000    device size according to you
>> > 16#3D7800000    device size according to superblock (at 16#420)
>> > ------------- -
>> > 16#000400000    this agrees with the partition base address of the
>> > second
>> >                              superblock which lives at 16#400400
>> according
>> > to you
>> >                              also the start address of segment 0 indexes
>> > from here
>> >
>> >>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>> >>at address 00401000.
>> >
>> > if at least in this line you send me, the addresses are from 00000 of
>> > the
>> > device.
>> >
>> > So I am inclined to believe that the original(before the accident)
>> > start address of the nilfs partition was at 16#400000 of the device.
>> >
>> >
>> > Then this holds true according to nilfs2_fs.h:
>> > /*
>> >  * bytes offset of secondary super block
>> >  */
>> > #define NILFS_SB2_OFFSET_BYTES(devsize)    ((((devsize) >> 12) - 1) <<
>> 12)
>> >
>> > so:
>> > 16#3D7800000    device size according to superblock (16#420)
>> > 16#000001000    and blank the ls 000 but they are 0 already
>> > ------------ -
>> > 16#3D77FF000    should be the place of the 2nd superblock in the
>> > original
>> > partition
>> > 16#000400000    index of the original partition (believed to be)
>> > ------------ +
>> > 16#3D7BFF000    should be the place in the device where the 2nd
>> superblock
>> > lives.
>> >                               (or maybe I should say the 3rd)
>> >
>> > This whole proposition is off course grounded in the belief that the
>> first
>> > superblock
>> > with the error flag set is written in error and should be discarded.
>> > Although it might refer to real additional data because it has more
>> > checkpoints than the 2nd
>> > that you found. But I would rather discard those and retrieve the older
>> > checkpoint.
>> > Both superblocks were created in the same login session by the way.
>> >
>> > So could you make an efford to find the 3rd superblock or send me the 3
>> > blocks around the
>> > place I indicated, to see what happened there.
>> >
>> > Jan de Kruyf.
>> >
>> > "Enthusiasm beats facts anytime"
>> > ------------------------------------------
>> >
>> >
>> > On Thu, Nov 5, 2009 at 5:57 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> BTW, I checked the other disk that I have nilfs2 installed, the two
>> >> super blocks indeed are one at the beginning, and one at the end of
>> >> the partition.
>> >>
>> >> Very strange that this isn't the case on /dev/mmcblk0. Indeed I
>> >> started using nilfs version 2.0.5 on it, then later upgraded to
>> >> 2.0.15, not sure if in between something caused this problem.
>> >>
>> >>
>> >> On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> > I think it might be the "hexdump" utility that I used. It by default
>> >> > groups things by word, so in little endian it'd say 0002 but the
>> >> > actual byte sequence is 02 00.
>> >> >
>> >> > I re-dump the following in byte sequence using od.
>> >> >
>> >> > first superblock
>> >> >
>> >> > 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> >> > 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
>> >> > 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> >> > 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
>> >> > 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> >> > 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> >> > 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
>> >> > 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
>> >> > 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> >> > 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> >> > 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> >> > 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >> >
>> >> > backup copy of the super block (actually different from the above)
>> >> >
>> >> > 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> >> > 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
>> >> > 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> >> > 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
>> >> > 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> >> > 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> >> > 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
>> >> > 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
>> >> > 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> >> > 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> >> > 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> >> > 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >> >
>> >> > The address is the absolute index into the root partition
>> >> > /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
>> >> > the super block is not something at the end of the disk.
>> >> >
>> >> > The first partition /dev/mmcblk0p1 indexes into the root parition by
>> >> > 8192 bytes.
>> >> >
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> just thought of something. You searched with standard (little, I
>> think)
>> >> >> endianess
>> >> >> i.e. the image from my mail to you.
>> >> >>  try the image from YOUR main superblock:
>> >> >> 0002 0000 0000 3434
>> >> >> and see if the backup copy surfaces.
>> >> >>
>> >> >> jan.
>> >> >>
>> >> >> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>
>> >> >>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>> >> >>> Aspire One model A101,  which uses Atom CPU.
>> >> >>>
>> >> >>> I failed to find the superblock towards the end of either mmcblk0
>> >> >>> or
>> >> >>> mmcblk0p1, but a search of hex string 0200000000003434 reveals
>> >> >>> that:
>> >> >>>
>> >> >>> mmcblk0: starts at address 00400400,  and the nilfs segment 0
>> >> >>> starts
>> >> >>> at address 00401000.
>> >> >>>
>> >> >>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0
>> starts
>> >> >>> at 003FF000.
>> >> >>>
>> >> >>> I hope my SD card is not messing up itself by rearranging the
>> blocks!
>> >> >>>
>> >> >>> Regards,
>> >> >>> Paul Liu
>> >> >>>
>> >> >>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> > Hallo,
>> >> >>> > here we go again. As a matter of interest, what version of nilfs
>> and
>> >> >>> > what
>> >> >>> > distribution are you running? And what processor?
>> >> >>> > your endiannes confused me at first.
>> >> >>> >
>> >> >>> > glad you fixed your hexedit
>> >> >>> >
>> >> >>> > I have looked at some numbers in the superblock and they look ok.
>> I
>> >> do
>> >> >>> > wonder if you have the garbage collector running.
>> >> >>> >
>> >> >>> > now for the second superblock. Please pay attention to the exact
>> >> place
>> >> >>> > of
>> >> >>> > it. Because it is of vital
>> >> >>> > importance if it in in partition 1 or in the root of the disk.
>> >> >>> >
>> >> >>> > the first superblock sits as you observed in the root. The flags
>> say
>> >> >>> amongst
>> >> >>> > others that it was unmounted cleanly but errors were detected.
>> >> >>> >
>> >> >>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common
>> >> >>> > declarations.
>> >> >>> > in
>> >> >>> the
>> >> >>> > distribution.
>> >> >>> > /**
>> >> >>> >  * struct nilfs_super_block - structure of super block on disk
>> >> >>> >  */
>> >> >>> > struct nilfs_super_block {
>> >> >>> > ....
>> >> >>> > translates bit for bit to what you see written in the super block
>> on
>> >> >>> disk.
>> >> >>> >
>> >> >>> > Here is an example from a partition of mine on how to discover
>> >> >>> > the
>> >> >>> > superblock copy
>> >> >>> > it should read the same as the 1st but in your case it might not.
>> >> >>> > It is a leftshift - subtract 1 - right shift algorithm.
>> >> >>> > go in hexedit to the last data with ">" (shift .)
>> >> >>> > note the address of the last byte (the size of the partion)
>> >> >>> > in mine:
>> >> >>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > or the status line might give it
>> >> >>> > the address of the copy is now at 6566A000
>> >> >>> > i.e. 6566B has 1 subtracted from it and the 3 least significant
>> >> digits
>> >> >>> have
>> >> >>> > been zeroed.
>> >> >>> >
>> >> >>> > so please dump yours, see if the algorithm works on the 1st part
>> or
>> >> on
>> >> >>> the
>> >> >>> > root or both,
>> >> >>> > so we know where it is.
>> >> >>> > And check if it is exactly the same as the first one you send me
>> >> >>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>> >> >>> > etc.
>> >> >>> >
>> >> >>> > the next thing to discover is where the start of (nilfs)segment 0
>> >> >>> > is.
>> >> >>> > I am not quite sure what is written in it, but the signature is
>> >> >>> > quite
>> >> >>> > distinct.
>> >> >>> > This is what it looks on my machine:
>> >> >>> >
>> >> >>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>> >> >>> > ..G[Qb......8...
>> >> >>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>> >> >>> > ...........J....
>> >> >>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>> >> >>> > ............2...
>> >> >>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>> >> >>> > ........{...{...
>> >> >>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> >
>> >> >>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see
>> >> above
>> >> >>> and
>> >> >>> > carries on for quite a while like this.
>> >> >>> >
>> >> >>> > so have a look on your disk if it sits at 1000 of the root
>> partition
>> >> >>> > or
>> >> >>> at
>> >> >>> > 1000 of partition 1.
>> >> >>> >
>> >> >>> > Once we have these things sorted I would say that we are ready to
>> >> >>> > plant
>> >> >>> the
>> >> >>> > _right_ superblock of the 2
>> >> >>> > in the right place and see if the partition is recoqnized by
>> nilfs.
>> >> >>> > Off course we will save the place where we are going to plant
>> >> >>> > that
>> >> >>> > block
>> >> >>> > first.
>> >> >>> >
>> >> >>> > And now back to the birthday party . . . .
>> >> >>> >
>> >> >>> > Cheers,
>> >> >>> >
>> >> >>> > Jan
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >
>> >> >>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> > 26 august 98: hexedit 0.9.5 release
>> >> >>> >> > september 2005:
>> >> >>> >> >     - version 1.2.12  this is the one I am running.
>> >> >>> >>
>> >> >>> >> Ah, I must be using the wrong hexedit.. now I've installed the
>> same
>> >> >>> >> one
>> >> >>> >> you
>> >> >>> >> use.
>> >> >>> >>
>> >> >>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>> >> >>> >>
>> >> >>> >> Yes. What I put there is:
>> >> >>> >>
>> >> >>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>> >> >>> >>
>> >> >>> >> > hd -n1536 /dev/mmcblk0 >part.start
>> >> >>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>> >> >>> >> > an to verify the last line:
>> >> >>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>> >> >>> >>
>> >> >>> >> Here is the output (I use hexdump instead of hd, hopefully they
>> are
>> >> >>> >> the
>> >> >>> >> same)
>> >> >>> >>
>> >> >>> >> bash-3.1# cat part.start
>> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>> >> >>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>> >> >>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>> >> >>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>> >> >>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>> >> >>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>> >> >>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>> >> >>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>> >> >>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>> >> >>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>> >> >>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>> >> >>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>> >> >>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>> >> >>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>> >> >>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000600
>> >> >>> >> bash-3.1# cat part1.start
>> >> >>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00025ff
>> >> >>> >> bash-3.1# cat part1a.start
>> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000600
>> >> >>> >>
>> >> >>> >> Regards,
>> >> >>> >> Paul Liu
>> >> >>> >>
>> >> >>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>> >> >>> >> >
>> >> >>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>> >> >>> partition
>> >> >>> >> >> table with this email.
>> >> >>> >> >>
>> >> >>> >> >> I'm pretty sure I had 1 partition on the card, since my
>> >> /etc/fstab
>> >> >>> >> >> mounts mmcblk0p1.
>> >> >>> >> >>
>> >> >>> >> >> I think something corrupted my disk first, and then what I've
>> >> done
>> >> >>> >> >> to
>> >> >>> >> >> the disk after noticing the corruption:
>> >> >>> >> >>
>> >> >>> >> >> 1. fdisk, it says use "w" will correct the error, so I did.
>> But
>> >> >>> >> >> then
>> >> >>> >> >> the one parition is gone.
>> >> >>> >> >> 2. fdisk again, create a single partition, then "w"
>> >> >>> >> >>
>> >> >>> >> >> My mistake was that I didn't create a backup copy of the MBR.
>> A
>> >> >>> >> >> hard
>> >> >>> >> >> lesson learned :(
>> >> >>> >> >>
>> >> >>> >> >> Also, why is that my hexedit doesn't take the "-s" option?
>> It's
>> >> >>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>> >> >>> >> >>
>> >> >>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
>> >> >>> >> >>
>> >> >>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>> >> >>> >> >>
>> >> >>> >> >> Regards,
>> >> >>> >> >> Paul Liu
>> >> >>> >> >>
>> >> >>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >  hallo,
>> >> >>> >> >> > Almost sounds like you had only the root master-boot-record
>> >> >>> >> /dev/mmcblk0
>> >> >>> >> >> > before and now you have added 1 main partition
>> /dev/mmcblk0p1.
>> >> >>> >> >> >
>> >> >>> >> >> > If (and only if) that is the case we have to undo the the
>> 1st
>> >> >>> >> partition
>> >> >>> >> >> > +
>> >> >>> >> >> > check that no nilfs is overwritten.
>> >> >>> >> >> > and I would have to urgently study fdisk to see exactly
>> >> >>> >> >> > what
>> >> >>> >> >> > it
>> >> >>> >> >> > writes
>> >> >>> >> >> when
>> >> >>> >> >> > and where.
>> >> >>> >> >> > The last time I did tricks like these is quit a few years
>> ago.
>> >> >>> >> >> >
>> >> >>> >> >> > It is the Linux version of fdisk is it??
>> >> >>> >> >> >
>> >> >>> >> >> > So here is the plan of action:
>> >> >>> >> >> > hexdump the master boot record to file.
>> >> >>> >> >> > like this:
>> >> >>> >> >> >
>> >> >>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >> >>> >> >> >
>> >> >>> >> >> > then dump any partitions of the device in a format useful
>> >> >>> >> >> > as
>> >> >>> >> >> > input
>> >> >>> to
>> >> >>> >> >> > sfdisk. For example,
>> >> >>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> >> >>> >> >> > sfdisk is a tool provided with the util-linux
>> >> >>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > or you could use hexdump to get machine readable or man
>> >> readable
>> >> >>> >> images.
>> >> >>> >> >> > Here is the man readable version:
>> >> >>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> >> >>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> >> >>> >> >> > etc.
>> >> >>> >> >> >
>> >> >>> >> >> > By the way boor records always end with '55 AA'.
>> >> >>> >> >> >
>> >> >>> >> >> > Keep your files in a safe place in case we mess something
>> >> >>> >> >> > we
>> >> can
>> >> >>> >> >> > at
>> >> >>> >> >> > least
>> >> >>> >> >> go
>> >> >>> >> >> > back to the present situation.
>> >> >>> >> >> > If you could dd the whole drive to a file, now that would
>> >> >>> >> >> > be
>> >> >>> >> >> > magic
>> >> >>> >> >> indeed!
>> >> >>> >> >> > but you must have the space on a harddrive.
>> >> >>> >> >> > count=... is the number of sectors in the above line (dd
>> ...)
>> >> >>> >> >> > that
>> >> >>> >> >> > you
>> >> >>> >> >> dump
>> >> >>> >> >> > to file.
>> >> >>> >> >> > Hexedit will tell you the number of sectors is you start it
>> >> with
>> >> >>> >> >> > -s
>> >> >>> >> >> option
>> >> >>> >> >> > and then go to the last sector.
>> >> >>> >> >> > DONT stop hexedit with control-x use cntl-c.
>> >> >>> >> >> > DONT use high level or even midlevel tools on a stuffed
>> disk,
>> >> it
>> >> >>> >> >> > normally
>> >> >>> >> >> > messes more than it solves.
>> >> >>> >> >> > unless of course you really,really know what you are doing.
>> >> >>> >> >> > Fiddling the bytes is in general safe and gives results, if
>> a
>> >> >>> >> >> > man
>> >> >>> >> keeps
>> >> >>> >> >> > a
>> >> >>> >> >> > cool head.
>> >> >>> >> >> >
>> >> >>> >> >> > Please send me the fdisk version, the size of the card, and
>> >> >>> >> >> > the
>> >> >>> >> >> > mbr
>> >> >>> >> dump
>> >> >>> >> >> to
>> >> >>> >> >> > feast my eyes on.
>> >> >>> >> >> >
>> >> >>> >> >> > cheers,
>> >> >>> >> >> >
>> >> >>> >> >> > Jan de kruyf.
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> >>> >> >> > wrote:
>> >> >>> >> >> >
>> >> >>> >> >> >> just want to add that I've always been using 1 partition
>> >> >>> >> >> >> on
>> >> >>> >> >> >> this
>> >> >>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
>> >> >>> >> >> >> /dev/mmcblk0p1
>> >> >>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
>> >> >>> >> >> >> hexedit
>> >> >>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >> >>> >> >> >>
>> >> >>> >> >> >> Any help is greatly appreciated!
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >> > Thanks for the tips. When I first used the SD card, I
>> used
>> >> >>> >> >> >> > fdisk
>> >> >>> >> >> >> > to
>> >> >>> >> >> >> > create the partition.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s
>> /dev/mmcblk0
>> >> >>> >> >> >> > shows
>> >> >>> >> that
>> >> >>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
>> >> >>> >> >> >> > then?
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > I tried gparted, but apparently it has no support for
>> >> nilfs2.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > Regards,
>> >> >>> >> >> >> > Paul Liu
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >> >> Did you first format this card with fdisk?
>> >> >>> >> >> >> >> did you give it the exact same info this time around?
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device
>> >> >>> >> >> >> >> in
>> >> the
>> >> >>> dev
>> >> >>> >> >> >> >> directory
>> >> >>> >> >> >> >> where the card lives)
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a
>> terminal
>> >> as
>> >> >>> >> >> >> >> root?
>> >> >>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still
>> >> >>> >> >> >> >> exists?
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> be very careful no to save any data in hexedit, it will
>> >> >>> >> >> >> >> definitely
>> >> >>> >> >> and
>> >> >>> >> >> >> >> finally
>> >> >>> >> >> >> >> destoy your data.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> 0400 looks vagely like this:
>> >> >>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56
>> >> >>> >> >> >> >> F0
>> >> >>> >> >> >> >> B9
>> >> >>> >> >> >> >> ......44.....V..
>> >> >>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 9..s............
>> >> >>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ..fe............
>> >> >>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .H......s..J....
>> >> >>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ........s..J....
>> >> >>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ..2.....s..J....
>> >> >>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .N..............
>> >> >>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC
>> >> >>> >> >> >> >> 45
>> >> >>> >> >> >> >> 85
>> >> >>> >> >> >> >> ..
>> >> >>> >> >> >> >> .....Ls.=..E.
>> >> >>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .(DB=...Var64...
>> >> >>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> the 34 34 in the top line say this is nilfs.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> cheers
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> jan de kruyf
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L <
>> ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> >>> wrote:
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>> Due to some careless handling of my laptop, the SD
>> >> >>> >> >> >> >>> card
>> >> >>> >> >> >> >>> popped
>> >> >>> >> out
>> >> >>> >> >> >> >>> when the machine is still running. When I put it back
>> in
>> >> >>> >> >> >> >>> and
>> >> >>> >> reboot
>> >> >>> >> >> >> >>> the machine, it says "partition table error". I then
>> ran
>> >> >>> >> >> >> >>> fdisk
>> >> >>> >> and
>> >> >>> >> >> >> >>> recreated the single partition. Then I can no longer
>> >> >>> >> >> >> >>> mount
>> >> >>> >> >> >> >>> the
>> >> >>> >> >> nilfs2
>> >> >>> >> >> >> >>> partition that was on the SD card!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> Can any one help to me recover the file system? I
>> believe
>> >> >>> >> >> >> >>> all
>> >> >>> >> data
>> >> >>> >> >> are
>> >> >>> >> >> >> >>> still there, but just some bits and pieces are missing
>> >> >>> >> >> >> >>> for
>> >> >>> >> >> >> >>> the
>> >> >>> >> >> >> >>> mount
>> >> >>> >> >> >> >>> to work. Any help is greatly appreciated!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I
>> can
>> >> >>> >> >> >> >>> get
>> >> >>> my
>> >> >>> >> >> stuff
>> >> >>> >> >> >> >>> back in time... so help please!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> --
>> >> >>> >> >> >> >>> Regards,
>> >> >>> >> >> >> >>> Paul Liu
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> Yale Haskell Group
>> >> >>> >> >> >> >>> http://www.haskell.org/yale
>> >> >>> >> >> >> >>> _______________________________________________
>> >> >>> >> >> >> >>> users mailing list
>> >> >>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > --
>> >> >>> >> >> >> > Regards,
>> >> >>> >> >> >> > Paul Liu
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > Yale Haskell Group
>> >> >>> >> >> >> > http://www.haskell.org/yale
>> >> >>> >> >> >> >
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >> --
>> >> >>> >> >> >> Regards,
>> >> >>> >> >> >> Paul Liu
>> >> >>> >> >> >>
>> >> >>> >> >> >> Yale Haskell Group
>> >> >>> >> >> >> http://www.haskell.org/yale
>> >> >>> >> >> >> _______________________________________________
>> >> >>> >> >> >> users mailing list
>> >> >>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> --
>> >> >>> >> >> Regards,
>> >> >>> >> >> Paul Liu
>> >> >>> >> >>
>> >> >>> >> >> Yale Haskell Group
>> >> >>> >> >> http://www.haskell.org/yale
>> >> >>> >> >>
>> >> >>> >> >> _______________________________________________
>> >> >>> >> >> users mailing list
>> >> >>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Regards,
>> >> >>> >> Paul Liu
>> >> >>> >>
>> >> >>> >> Yale Haskell Group
>> >> >>> >> http://www.haskell.org/yale
>> >> >>> >> _______________________________________________
>> >> >>> >> users mailing list
>> >> >>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Regards,
>> >> >>> Paul Liu
>> >> >>>
>> >> >>> Yale Haskell Group
>> >> >>> http://www.haskell.org/yale
>> >> >>> _______________________________________________
>> >> >>> users mailing list
>> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > Yale Haskell Group
>> >> > http://www.haskell.org/yale
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> Yale Haskell Group
>> >> http://www.haskell.org/yale
>> >> _______________________________________________
>> >> users mailing list
>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>>
>


-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: [SPAM] Re: urgent help need! disk partition info lost

[Jérôme Poulin]

On Fri, Nov 6, 2009 at 12:43 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Ok, based on the info so far, I've successfully recovered my files!
>
...
>
> 6. Now it seemed no way to proceed, and I decided to try my luck by
> modifying nilfs_search_super_root(...) function to do a partial check
> instead of a full check (by changing the flag from 1 to 0). Compiled,
> installed, and rebooted.
>
This is where I'd like to add, the filesystem should always allow to
mount read-only whatever there is corruption or not, if there is bad
bad trouble it should mount read-only and ignore the cleanerd, isn't
that right?

> It then all worked out from there. I immediately plugged in a USB
> drive, and copied all my files to the backup. Only one file seemed to
> have been damaged during the incident. I didn't bother to check if all
> the prevoius checkpoint on the nilfs2 partition worked and just went
> ahead and re-partitioned and re-formatted the SD card.
>
> I must thank Jan de Kruyf for the tremendeous help! Thank you all very much!
>
> Now I'm just going to celebrate the magical recovery from the loss of
> months' hard work!
>
>
I guess you're going to make a backup every week from now :)

Re: [SPAM] Re: urgent help need! disk partition info lost

[Jan de Kruyf]

[-- Attachment #1.1: Type: text/plain, Size: 2396 bytes --]

Oh du cleveres Kerlchen. What a way to spend a beautiful friday!
Well you were smart after all I must say. And I would like to add that
I have done similar things with ext2 and it was not half as easy. So Nilfs
shines
as far as I am concerned.

And yes I did expect the partially lost file because the faulty superblock
was written after
the superblock at 0x400400.

So let us sign a petition to the Master (Ryusuke are you listening!) to
provide a special mount-flag
for recovery purposes only so the mounting goes on as far as practical with
suitable warnings.
Perhaps you could supply a diff with the changes you made for your case
Paul.

> I guess you're going to make a backup every week from now :)

Nah, he's got friends -- whaddo ye mean . . . .

Regards,

Jan de Kruyf.


On Fri, Nov 6, 2009 at 9:24 PM, Jérôme Poulin <jeromepoulin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:

> On Fri, Nov 6, 2009 at 12:43 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Ok, based on the info so far, I've successfully recovered my files!
> >
> ...
> >
> > 6. Now it seemed no way to proceed, and I decided to try my luck by
> > modifying nilfs_search_super_root(...) function to do a partial check
> > instead of a full check (by changing the flag from 1 to 0). Compiled,
> > installed, and rebooted.
> >
> This is where I'd like to add, the filesystem should always allow to
> mount read-only whatever there is corruption or not, if there is bad
> bad trouble it should mount read-only and ignore the cleanerd, isn't
> that right?
>
> > It then all worked out from there. I immediately plugged in a USB
> > drive, and copied all my files to the backup. Only one file seemed to
> > have been damaged during the incident. I didn't bother to check if all
> > the prevoius checkpoint on the nilfs2 partition worked and just went
> > ahead and re-partitioned and re-formatted the SD card.
> >
> > I must thank Jan de Kruyf for the tremendeous help! Thank you all very
> much!
> >
> > Now I'm just going to celebrate the magical recovery from the loss of
> > months' hard work!
> >
> >
> I guess you're going to make a backup every week from now :)
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
>

[-- Attachment #1.2: Type: text/html, Size: 3185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

[SPAM] Re: [SPAM] Re: urgent help need! disk partition info lost

[Ryusuke Konishi]

2009/11/6 Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Ryusuke,
> Good day to you.
>
> I need some help here.
> I like to change the partition table on this filesystem that is broken, so
> that nilfs will pick up
> the primary superblock and what looks like segment 0.
> However, the secondary superblock is missing or written out of place, and it
> looks
> like data is written in the usual place of the secondary superblock.

Sorry for my late reply.  I was quite busy this week.

If the partition was formatted with older version of mkfs.nilfs2 and
the partition is dividable by segment size, then the secondary
super block may not be present.

The secondary superblock is created only if there is enough space at the
end of the partition.  This is for preventing the secondary superblock to
destroy a block in the final segment.

To make space to store the secondary superblock, newer mkfs.nilfs2
reduces the number of segments if the partition size is dividable by
the segment size.

> At the same time I pick up from "the_nilfs.c :: load_nilfs that even if a
> partition is mounted read-only
> perhaps certain things do get written
> this is the code I refer to:
> -------------------------
>     if (!valid_fs && (s_flags & MS_RDONLY)) {
>         printk(KERN_INFO "NILFS: INFO: recovery "
>                "required for readonly filesystem.\n");
>         if (really_read_only) {
>             printk(KERN_ERR "NILFS: write access "
>                    "unavailable, cannot proceed.\n");
>             err = -EROFS;
>             goto failed;
>         }
>         printk(KERN_INFO "NILFS: write access will "
>                "be enabled during recovery.\n");
>         sbi->s_super->s_flags &= ~MS_RDONLY;
>     }
> ------------------------
> So how do we proceed mounting this filesystem completely read-only to see
> if perhaps some data can be recovered. (Provided that the partition table
> now
> points to a more or less valid nilfs partition.)

Yes, nilfs does recovery if needed even for a read-only mount.

Ok, you have a point.  I will consider adding a mount option to
disable this action.

Regards,
Ryusuke Konishi

> Many thanks,
>
> Jan de Kruyf.
>
> On Thu, Nov 5, 2009 at 8:02 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Wow, that is some good calculation, thanks!
>>
>> But unfortunately, the data around 3D7BFF00 doesn't look like a super
>> block at all.
>> I did a search of the string  02 00 00 00 00 00 34 34 00 01 00 00 on
>> the entire disk, only two places showed up.
>>
>> Also strangely the blocks towards end of the disk are all filled with
>> data, but from 0x0 to 0x400000 are all 0s except of course the MBR.
>>
>> I wonder if there is some kind of wrapping around? What could have caused
>> it?
>>
>> Regards,
>> Paul Liu
>>
>> On 11/5/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Paul,
>> > I have been doing some research in between things today
>> > here is some proposition I came up with, please check my math
>> > and thinking and do some more sleuthing. Please ask if anything
>> > is not clear:
>> >
>> > The math has been done on my trusted calc package for emacs
>> > hence the 16# for the base in front.
>> >
>> > 16#3D7C00000    device size according to you
>> > 16#3D7800000    device size according to superblock (at 16#420)
>> > ------------- -
>> > 16#000400000    this agrees with the partition base address of the
>> > second
>> >                              superblock which lives at 16#400400
>> > according
>> > to you
>> >                              also the start address of segment 0 indexes
>> > from here
>> >
>> >>mmcblk0: starts at address 00400400,  and the nilfs segment 0 starts
>> >>at address 00401000.
>> >
>> > if at least in this line you send me, the addresses are from 00000 of
>> > the
>> > device.
>> >
>> > So I am inclined to believe that the original(before the accident)
>> > start address of the nilfs partition was at 16#400000 of the device.
>> >
>> >
>> > Then this holds true according to nilfs2_fs.h:
>> > /*
>> >  * bytes offset of secondary super block
>> >  */
>> > #define NILFS_SB2_OFFSET_BYTES(devsize)    ((((devsize) >> 12) - 1) <<
>> > 12)
>> >
>> > so:
>> > 16#3D7800000    device size according to superblock (16#420)
>> > 16#000001000    and blank the ls 000 but they are 0 already
>> > ------------ -
>> > 16#3D77FF000    should be the place of the 2nd superblock in the
>> > original
>> > partition
>> > 16#000400000    index of the original partition (believed to be)
>> > ------------ +
>> > 16#3D7BFF000    should be the place in the device where the 2nd
>> > superblock
>> > lives.
>> >                               (or maybe I should say the 3rd)
>> >
>> > This whole proposition is off course grounded in the belief that the
>> > first
>> > superblock
>> > with the error flag set is written in error and should be discarded.
>> > Although it might refer to real additional data because it has more
>> > checkpoints than the 2nd
>> > that you found. But I would rather discard those and retrieve the older
>> > checkpoint.
>> > Both superblocks were created in the same login session by the way.
>> >
>> > So could you make an efford to find the 3rd superblock or send me the 3
>> > blocks around the
>> > place I indicated, to see what happened there.
>> >
>> > Jan de Kruyf.
>> >
>> > "Enthusiasm beats facts anytime"
>> > ------------------------------------------
>> >
>> >
>> > On Thu, Nov 5, 2009 at 5:57 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> BTW, I checked the other disk that I have nilfs2 installed, the two
>> >> super blocks indeed are one at the beginning, and one at the end of
>> >> the partition.
>> >>
>> >> Very strange that this isn't the case on /dev/mmcblk0. Indeed I
>> >> started using nilfs version 2.0.5 on it, then later upgraded to
>> >> 2.0.15, not sure if in between something caused this problem.
>> >>
>> >>
>> >> On 11/4/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> > I think it might be the "hexdump" utility that I used. It by default
>> >> > groups things by word, so in little endian it'd say 0002 but the
>> >> > actual byte sequence is 02 00.
>> >> >
>> >> > I re-dump the following in byte sequence using od.
>> >> >
>> >> > first superblock
>> >> >
>> >> > 000400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> >> > 000410 83 11 4c 79 02 00 00 00 af 07 00 00 00 00 00 00
>> >> > 000420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> >> > 000430 00 08 00 00 05 00 00 00 0b 09 0e 00 00 00 00 00
>> >> > 000440 10 07 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> >> > 000450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> >> > 000460 3f 01 e2 4a 00 00 00 00 8f 2a ef 4a 00 00 00 00
>> >> > 000470 a2 00 32 00 03 00 01 00 c1 93 3c 49 00 00 00 00
>> >> > 000480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> >> > 000490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> >> > 0004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> >> > 0004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >> >
>> >> > backup copy of the super block (actually different from the above)
>> >> >
>> >> > 400400 02 00 00 00 00 00 34 34 00 01 00 00 09 b2 31 5b
>> >> > 400410 86 db 83 b3 02 00 00 00 af 07 00 00 00 00 00 00
>> >> > 400420 00 00 80 d7 03 00 00 00 01 00 00 00 00 00 00 00
>> >> > 400430 00 08 00 00 05 00 00 00 08 09 0e 00 00 00 00 00
>> >> > 400440 00 00 35 00 00 00 00 00 02 85 08 00 00 00 00 00
>> >> > 400450 00 88 0b 00 00 00 00 00 c1 93 3c 49 00 00 00 00
>> >> > 400460 3f 01 e2 4a 00 00 00 00 fe 24 ef 4a 00 00 00 00
>> >> > 400470 a2 00 32 00 00 00 01 00 c1 93 3c 49 00 00 00 00
>> >> > 400480 00 4e ed 00 00 00 00 00 00 00 00 00 0b 00 00 00
>> >> > 400490 80 00 20 00 c0 00 10 00 2b ed f5 04 cb 41 48 ae
>> >> > 4004a0 8a 7f 49 48 ec 71 f5 e7 00 00 00 00 00 00 00 00
>> >> > 4004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> >> >
>> >> > The address is the absolute index into the root partition
>> >> > /dev/mmcblk0, whose total size is 0x3D7C00000. So the backup copy of
>> >> > the super block is not something at the end of the disk.
>> >> >
>> >> > The first partition /dev/mmcblk0p1 indexes into the root parition by
>> >> > 8192 bytes.
>> >> >
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >> just thought of something. You searched with standard (little, I
>> >> >> think)
>> >> >> endianess
>> >> >> i.e. the image from my mail to you.
>> >> >>  try the image from YOUR main superblock:
>> >> >> 0002 0000 0000 3434
>> >> >> and see if the backup copy surfaces.
>> >> >>
>> >> >> jan.
>> >> >>
>> >> >> On Wed, Nov 4, 2009 at 9:31 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>
>> >> >>> I'm using nilfs 2.0.15, slackware current, kernel 2.6.28, on Acer
>> >> >>> Aspire One model A101,  which uses Atom CPU.
>> >> >>>
>> >> >>> I failed to find the superblock towards the end of either mmcblk0
>> >> >>> or
>> >> >>> mmcblk0p1, but a search of hex string 0200000000003434 reveals
>> >> >>> that:
>> >> >>>
>> >> >>> mmcblk0: starts at address 00400400,  and the nilfs segment 0
>> >> >>> starts
>> >> >>> at address 00401000.
>> >> >>>
>> >> >>> mmcblk0p1: starts at address 003FE400, and the nilfs segment 0
>> >> >>> starts
>> >> >>> at 003FF000.
>> >> >>>
>> >> >>> I hope my SD card is not messing up itself by rearranging the
>> >> >>> blocks!
>> >> >>>
>> >> >>> Regards,
>> >> >>> Paul Liu
>> >> >>>
>> >> >>> On 11/4/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> > Hallo,
>> >> >>> > here we go again. As a matter of interest, what version of nilfs
>> >> >>> > and
>> >> >>> > what
>> >> >>> > distribution are you running? And what processor?
>> >> >>> > your endiannes confused me at first.
>> >> >>> >
>> >> >>> > glad you fixed your hexedit
>> >> >>> >
>> >> >>> > I have looked at some numbers in the superblock and they look ok.
>> >> >>> > I
>> >> do
>> >> >>> > wonder if you have the garbage collector running.
>> >> >>> >
>> >> >>> > now for the second superblock. Please pay attention to the exact
>> >> place
>> >> >>> > of
>> >> >>> > it. Because it is of vital
>> >> >>> > importance if it in in partition 1 or in the root of the disk.
>> >> >>> >
>> >> >>> > the first superblock sits as you observed in the root. The flags
>> >> >>> > say
>> >> >>> amongst
>> >> >>> > others that it was unmounted cleanly but errors were detected.
>> >> >>> >
>> >> >>> > see  nilfs2_fs.h - NILFS2 on-disk structures and common
>> >> >>> > declarations.
>> >> >>> > in
>> >> >>> the
>> >> >>> > distribution.
>> >> >>> > /**
>> >> >>> >  * struct nilfs_super_block - structure of super block on disk
>> >> >>> >  */
>> >> >>> > struct nilfs_super_block {
>> >> >>> > ....
>> >> >>> > translates bit for bit to what you see written in the super block
>> >> >>> > on
>> >> >>> disk.
>> >> >>> >
>> >> >>> > Here is an example from a partition of mine on how to discover
>> >> >>> > the
>> >> >>> > superblock copy
>> >> >>> > it should read the same as the 1st but in your case it might not.
>> >> >>> > It is a leftshift - subtract 1 - right shift algorithm.
>> >> >>> > go in hexedit to the last data with ">" (shift .)
>> >> >>> > note the address of the last byte (the size of the partion)
>> >> >>> > in mine:
>> >> >>> > 6566B3F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > or the status line might give it
>> >> >>> > the address of the copy is now at 6566A000
>> >> >>> > i.e. 6566B has 1 subtracted from it and the 3 least significant
>> >> digits
>> >> >>> have
>> >> >>> > been zeroed.
>> >> >>> >
>> >> >>> > so please dump yours, see if the algorithm works on the 1st part
>> >> >>> > or
>> >> on
>> >> >>> the
>> >> >>> > root or both,
>> >> >>> > so we know where it is.
>> >> >>> > And check if it is exactly the same as the first one you send me
>> >> >>> > "0000400 0002 0000 0000 3434 0100 0000 b209 5b31"
>> >> >>> > etc.
>> >> >>> >
>> >> >>> > the next thing to discover is where the start of (nilfs)segment 0
>> >> >>> > is.
>> >> >>> > I am not quite sure what is written in it, but the signature is
>> >> >>> > quite
>> >> >>> > distinct.
>> >> >>> > This is what it looks on my machine:
>> >> >>> >
>> >> >>> > 00000FC0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FD0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FE0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00000FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001000   C4 1B 47 5B 51 62 19 13  11 FA AF 1E 38 00 10 00
>> >> >>> > ..G[Qb......8...
>> >> >>> > 00001010   FB CE 01 00 00 00 00 00  EE BD F1 4A 00 00 00 00
>> >> >>> > ...........J....
>> >> >>> > 00001020   00 08 00 00 00 00 00 00  FF 07 00 00 32 00 00 00
>> >> >>> > ............2...
>> >> >>> > 00001030   A0 83 00 00 00 00 00 00  EE 0D 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001040   07 00 00 00 00 00 00 00  7B 00 00 00 7B 00 00 00
>> >> >>> > ........{...{...
>> >> >>> > 00001050   EA 9E 07 00 00 00 00 00  F8 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001060   EB 9E 07 00 00 00 00 00  F9 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001070   EC 9E 07 00 00 00 00 00  FA 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001080   ED 9E 07 00 00 00 00 00  FB 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001090   EE 9E 07 00 00 00 00 00  FC 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010A0   EF 9E 07 00 00 00 00 00  FD 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010B0   F0 9E 07 00 00 00 00 00  FE 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010C0   F2 9E 07 00 00 00 00 00  FF 01 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010D0   F3 9E 07 00 00 00 00 00  00 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010E0   F4 9E 07 00 00 00 00 00  01 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000010F0   F5 9E 07 00 00 00 00 00  02 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001100   F6 9E 07 00 00 00 00 00  03 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001110   F7 9E 07 00 00 00 00 00  04 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001120   F8 9E 07 00 00 00 00 00  05 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001130   F9 9E 07 00 00 00 00 00  06 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001140   FA 9E 07 00 00 00 00 00  07 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001150   FB 9E 07 00 00 00 00 00  08 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001160   FC 9E 07 00 00 00 00 00  09 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001170   FD 9E 07 00 00 00 00 00  0A 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001180   FE 9E 07 00 00 00 00 00  0B 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 00001190   FF 9E 07 00 00 00 00 00  0C 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011A0   00 9F 07 00 00 00 00 00  0D 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011B0   01 9F 07 00 00 00 00 00  0E 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011C0   02 9F 07 00 00 00 00 00  0F 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011D0   03 9F 07 00 00 00 00 00  10 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> > 000011E0   04 9F 07 00 00 00 00 00  11 02 00 00 00 00 00 00
>> >> >>> > ................
>> >> >>> >
>> >> >>> > Segment 0 starts at hex 1000 of a nilfs partition as you can see
>> >> above
>> >> >>> and
>> >> >>> > carries on for quite a while like this.
>> >> >>> >
>> >> >>> > so have a look on your disk if it sits at 1000 of the root
>> >> >>> > partition
>> >> >>> > or
>> >> >>> at
>> >> >>> > 1000 of partition 1.
>> >> >>> >
>> >> >>> > Once we have these things sorted I would say that we are ready to
>> >> >>> > plant
>> >> >>> the
>> >> >>> > _right_ superblock of the 2
>> >> >>> > in the right place and see if the partition is recoqnized by
>> >> >>> > nilfs.
>> >> >>> > Off course we will save the place where we are going to plant
>> >> >>> > that
>> >> >>> > block
>> >> >>> > first.
>> >> >>> >
>> >> >>> > And now back to the birthday party . . . .
>> >> >>> >
>> >> >>> > Cheers,
>> >> >>> >
>> >> >>> > Jan
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Wed, Nov 4, 2009 at 4:23 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >
>> >> >>> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> > 26 august 98: hexedit 0.9.5 release
>> >> >>> >> > september 2005:
>> >> >>> >> >     - version 1.2.12  this is the one I am running.
>> >> >>> >>
>> >> >>> >> Ah, I must be using the wrong hexedit.. now I've installed the
>> >> >>> >> same
>> >> >>> >> one
>> >> >>> >> you
>> >> >>> >> use.
>> >> >>> >>
>> >> >>> >> > did I hear that you have always had /dev/mmcblk0p1 in fstab??
>> >> >>> >>
>> >> >>> >> Yes. What I put there is:
>> >> >>> >>
>> >> >>> >> /dev/mmcblk0p1 /home    nilfs2 defaults           1 1
>> >> >>> >>
>> >> >>> >> > hd -n1536 /dev/mmcblk0 >part.start
>> >> >>> >> > hd -s8191 -n1536 /dev/mmcblk0 >part1.start
>> >> >>> >> > an to verify the last line:
>> >> >>> >> > hd -n1536 /dev/mmcblk0p1 >part1a.start
>> >> >>> >>
>> >> >>> >> Here is the output (I use hexdump instead of hd, hopefully they
>> >> >>> >> are
>> >> >>> >> the
>> >> >>> >> same)
>> >> >>> >>
>> >> >>> >> bash-3.1# cat part.start
>> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00001b0 0000 0000 0000 0000 0696 6c22 0000 0100
>> >> >>> >> 00001c0 0001 0383 ffd0 0010 0000 dff0 01eb 0000
>> >> >>> >> 00001d0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
>> >> >>> >> 0000200 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000400 0002 0000 0000 3434 0100 0000 b209 5b31
>> >> >>> >> 0000410 1183 794c 0002 0000 07af 0000 0000 0000
>> >> >>> >> 0000420 0000 d780 0003 0000 0001 0000 0000 0000
>> >> >>> >> 0000430 0800 0000 0005 0000 090b 000e 0000 0000
>> >> >>> >> 0000440 0710 0035 0000 0000 8502 0008 0000 0000
>> >> >>> >> 0000450 8800 000b 0000 0000 93c1 493c 0000 0000
>> >> >>> >> 0000460 013f 4ae2 0000 0000 2a8f 4aef 0000 0000
>> >> >>> >> 0000470 00a2 0032 0003 0001 93c1 493c 0000 0000
>> >> >>> >> 0000480 4e00 00ed 0000 0000 0000 0000 000b 0000
>> >> >>> >> 0000490 0080 0020 00c0 0010 ed2b 04f5 41cb ae48
>> >> >>> >> 00004a0 7f8a 4849 71ec e7f5 0000 0000 0000 0000
>> >> >>> >> 00004b0 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000600
>> >> >>> >> bash-3.1# cat part1.start
>> >> >>> >> 0001fff 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 00025ff
>> >> >>> >> bash-3.1# cat part1a.start
>> >> >>> >> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> >> >>> >> *
>> >> >>> >> 0000600
>> >> >>> >>
>> >> >>> >> Regards,
>> >> >>> >> Paul Liu
>> >> >>> >>
>> >> >>> >> > On Tue, Nov 3, 2009 at 9:48 PM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> >>> >> > wrote:
>> >> >>> >> >
>> >> >>> >> >> Thanks a lot for the instructions! I'm attaching the mbr and
>> >> >>> partition
>> >> >>> >> >> table with this email.
>> >> >>> >> >>
>> >> >>> >> >> I'm pretty sure I had 1 partition on the card, since my
>> >> /etc/fstab
>> >> >>> >> >> mounts mmcblk0p1.
>> >> >>> >> >>
>> >> >>> >> >> I think something corrupted my disk first, and then what I've
>> >> done
>> >> >>> >> >> to
>> >> >>> >> >> the disk after noticing the corruption:
>> >> >>> >> >>
>> >> >>> >> >> 1. fdisk, it says use "w" will correct the error, so I did.
>> >> >>> >> >> But
>> >> >>> >> >> then
>> >> >>> >> >> the one parition is gone.
>> >> >>> >> >> 2. fdisk again, create a single partition, then "w"
>> >> >>> >> >>
>> >> >>> >> >> My mistake was that I didn't create a backup copy of the MBR.
>> >> >>> >> >> A
>> >> >>> >> >> hard
>> >> >>> >> >> lesson learned :(
>> >> >>> >> >>
>> >> >>> >> >> Also, why is that my hexedit doesn't take the "-s" option?
>> >> >>> >> >> It's
>> >> >>> >> >> version 0.9.7, and can't edit bigger than 4.2GB.
>> >> >>> >> >>
>> >> >>> >> >> My SD card is A-DATA brand, class 6, and 16GB.
>> >> >>> >> >>
>> >> >>> >> >> I'm using Linux, and fdisk version (util-linux-ng 2.14.1)
>> >> >>> >> >>
>> >> >>> >> >> Regards,
>> >> >>> >> >> Paul Liu
>> >> >>> >> >>
>> >> >>> >> >> On 11/3/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >  hallo,
>> >> >>> >> >> > Almost sounds like you had only the root master-boot-record
>> >> >>> >> /dev/mmcblk0
>> >> >>> >> >> > before and now you have added 1 main partition
>> >> >>> >> >> > /dev/mmcblk0p1.
>> >> >>> >> >> >
>> >> >>> >> >> > If (and only if) that is the case we have to undo the the
>> >> >>> >> >> > 1st
>> >> >>> >> partition
>> >> >>> >> >> > +
>> >> >>> >> >> > check that no nilfs is overwritten.
>> >> >>> >> >> > and I would have to urgently study fdisk to see exactly
>> >> >>> >> >> > what
>> >> >>> >> >> > it
>> >> >>> >> >> > writes
>> >> >>> >> >> when
>> >> >>> >> >> > and where.
>> >> >>> >> >> > The last time I did tricks like these is quit a few years
>> >> >>> >> >> > ago.
>> >> >>> >> >> >
>> >> >>> >> >> > It is the Linux version of fdisk is it??
>> >> >>> >> >> >
>> >> >>> >> >> > So here is the plan of action:
>> >> >>> >> >> > hexdump the master boot record to file.
>> >> >>> >> >> > like this:
>> >> >>> >> >> >
>> >> >>> >> >> > dd if=/dev/mmcblk0 of=backup-mmcblk0.mbr count=1 bs=512
>> >> >>> >> >> >
>> >> >>> >> >> > then dump any partitions of the device in a format useful
>> >> >>> >> >> > as
>> >> >>> >> >> > input
>> >> >>> to
>> >> >>> >> >> > sfdisk. For example,
>> >> >>> >> >> >                   % sfdisk -d /dev/mmcblk0  > mmcblk0 .out
>> >> >>> >> >> > sfdisk is a tool provided with the util-linux
>> >> >>> >> >> > package<http://www.kernel.org/pub/linux/utils/util-linux/>.
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > or you could use hexdump to get machine readable or man
>> >> readable
>> >> >>> >> images.
>> >> >>> >> >> > Here is the man readable version:
>> >> >>> >> >> > hd -n512 /dev/mmcblk0 > backup-mmcblk0.mbr
>> >> >>> >> >> > hd -n512 /dev/mmcblk0p1 >backup-mmcblk0p1.mbr
>> >> >>> >> >> > etc.
>> >> >>> >> >> >
>> >> >>> >> >> > By the way boor records always end with '55 AA'.
>> >> >>> >> >> >
>> >> >>> >> >> > Keep your files in a safe place in case we mess something
>> >> >>> >> >> > we
>> >> can
>> >> >>> >> >> > at
>> >> >>> >> >> > least
>> >> >>> >> >> go
>> >> >>> >> >> > back to the present situation.
>> >> >>> >> >> > If you could dd the whole drive to a file, now that would
>> >> >>> >> >> > be
>> >> >>> >> >> > magic
>> >> >>> >> >> indeed!
>> >> >>> >> >> > but you must have the space on a harddrive.
>> >> >>> >> >> > count=... is the number of sectors in the above line (dd
>> >> >>> >> >> > ...)
>> >> >>> >> >> > that
>> >> >>> >> >> > you
>> >> >>> >> >> dump
>> >> >>> >> >> > to file.
>> >> >>> >> >> > Hexedit will tell you the number of sectors is you start it
>> >> with
>> >> >>> >> >> > -s
>> >> >>> >> >> option
>> >> >>> >> >> > and then go to the last sector.
>> >> >>> >> >> > DONT stop hexedit with control-x use cntl-c.
>> >> >>> >> >> > DONT use high level or even midlevel tools on a stuffed
>> >> >>> >> >> > disk,
>> >> it
>> >> >>> >> >> > normally
>> >> >>> >> >> > messes more than it solves.
>> >> >>> >> >> > unless of course you really,really know what you are doing.
>> >> >>> >> >> > Fiddling the bytes is in general safe and gives results, if
>> >> >>> >> >> > a
>> >> >>> >> >> > man
>> >> >>> >> keeps
>> >> >>> >> >> > a
>> >> >>> >> >> > cool head.
>> >> >>> >> >> >
>> >> >>> >> >> > Please send me the fdisk version, the size of the card, and
>> >> >>> >> >> > the
>> >> >>> >> >> > mbr
>> >> >>> >> dump
>> >> >>> >> >> to
>> >> >>> >> >> > feast my eyes on.
>> >> >>> >> >> >
>> >> >>> >> >> > cheers,
>> >> >>> >> >> >
>> >> >>> >> >> > Jan de kruyf.
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > On Tue, Nov 3, 2009 at 1:27 AM, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> >>> >> >> > wrote:
>> >> >>> >> >> >
>> >> >>> >> >> >> just want to add that I've always been using 1 partition
>> >> >>> >> >> >> on
>> >> >>> >> >> >> this
>> >> >>> >> >> >> device, it's actually /dev/mmcblk0p1. But hexedit
>> >> >>> >> >> >> /dev/mmcblk0p1
>> >> >>> >> >> >> doesn't show that 34 34 at line begining with 0x400, only
>> >> >>> >> >> >> hexedit
>> >> >>> >> >> >> /dev/mmcblk0 shows it. Not sure if this is a problem.
>> >> >>> >> >> >>
>> >> >>> >> >> >> Any help is greatly appreciated!
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >> On 11/2/09, Paul L <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >> > Thanks for the tips. When I first used the SD card, I
>> >> >>> >> >> >> > used
>> >> >>> >> >> >> > fdisk
>> >> >>> >> >> >> > to
>> >> >>> >> >> >> > create the partition.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > The device is /dev/mmcblk0, and hexedit -d -s
>> >> >>> >> >> >> > /dev/mmcblk0
>> >> >>> >> >> >> > shows
>> >> >>> >> that
>> >> >>> >> >> >> > at the line 0x0400, it is indeed 34 34. What should I do
>> >> >>> >> >> >> > then?
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > I tried gparted, but apparently it has no support for
>> >> nilfs2.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > Regards,
>> >> >>> >> >> >> > Paul Liu
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > On 11/2/09, Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> >>> >> >> >> >> Did you first format this card with fdisk?
>> >> >>> >> >> >> >> did you give it the exact same info this time around?
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> Can you read /dev/'sdcard' ? (sdcard being the device
>> >> >>> >> >> >> >> in
>> >> the
>> >> >>> dev
>> >> >>> >> >> >> >> directory
>> >> >>> >> >> >> >> where the card lives)
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> If yes can you run hexedit -s /dev/sdcard1  in a
>> >> >>> >> >> >> >> terminal
>> >> as
>> >> >>> >> >> >> >> root?
>> >> >>> >> >> >> >> and go to address 0400 - 04B0 to see if nilfs still
>> >> >>> >> >> >> >> exists?
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> be very careful no to save any data in hexedit, it will
>> >> >>> >> >> >> >> definitely
>> >> >>> >> >> and
>> >> >>> >> >> >> >> finally
>> >> >>> >> >> >> >> destoy your data.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> 0400 looks vagely like this:
>> >> >>> >> >> >> >> 00000400   02 00 00 00 00 00 34 34  00 01 00 00 D3 56
>> >> >>> >> >> >> >> F0
>> >> >>> >> >> >> >> B9
>> >> >>> >> >> >> >> ......44.....V..
>> >> >>> >> >> >> >> 00000410   39 BF D9 73 02 00 00 00  CA 02 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 9..s............
>> >> >>> >> >> >> >> 00000420   00 B4 66 65 01 00 00 00  01 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ..fe............
>> >> >>> >> >> >> >> 00000430   00 08 00 00 05 00 00 00  01 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 00000440   01 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 00000450   00 48 16 00 00 00 00 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .H......s..J....
>> >> >>> >> >> >> >> 00000460   00 00 00 00 00 00 00 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ........s..J....
>> >> >>> >> >> >> >> 00000470   00 00 32 00 01 00 01 00  73 95 DC 4A 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ..2.....s..J....
>> >> >>> >> >> >> >> 00000480   00 4E ED 00 00 00 00 00  00 00 00 00 0B 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .N..............
>> >> >>> >> >> >> >> 00000490   80 00 20 00 C0 00 10 00  4C 73 DD 3D 01 EC
>> >> >>> >> >> >> >> 45
>> >> >>> >> >> >> >> 85
>> >> >>> >> >> >> >> ..
>> >> >>> >> >> >> >> .....Ls.=..E.
>> >> >>> >> >> >> >> 000004A0   94 28 44 42 3D F6 EF EC  56 61 72 36 34 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> .(DB=...Var64...
>> >> >>> >> >> >> >> 000004B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >> 000004C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> 00
>> >> >>> >> >> >> >> ................
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> the 34 34 in the top line say this is nilfs.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> cheers
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> jan de kruyf
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> On Mon, Nov 2, 2009 at 9:06 PM, Paul L
>> >> >>> >> >> >> >> <ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> >>> wrote:
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>> Due to some careless handling of my laptop, the SD
>> >> >>> >> >> >> >>> card
>> >> >>> >> >> >> >>> popped
>> >> >>> >> out
>> >> >>> >> >> >> >>> when the machine is still running. When I put it back
>> >> >>> >> >> >> >>> in
>> >> >>> >> >> >> >>> and
>> >> >>> >> reboot
>> >> >>> >> >> >> >>> the machine, it says "partition table error". I then
>> >> >>> >> >> >> >>> ran
>> >> >>> >> >> >> >>> fdisk
>> >> >>> >> and
>> >> >>> >> >> >> >>> recreated the single partition. Then I can no longer
>> >> >>> >> >> >> >>> mount
>> >> >>> >> >> >> >>> the
>> >> >>> >> >> nilfs2
>> >> >>> >> >> >> >>> partition that was on the SD card!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> Can any one help to me recover the file system? I
>> >> >>> >> >> >> >>> believe
>> >> >>> >> >> >> >>> all
>> >> >>> >> data
>> >> >>> >> >> are
>> >> >>> >> >> >> >>> still there, but just some bits and pieces are missing
>> >> >>> >> >> >> >>> for
>> >> >>> >> >> >> >>> the
>> >> >>> >> >> >> >>> mount
>> >> >>> >> >> >> >>> to work. Any help is greatly appreciated!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> PS: I've a deadline to meet in 4 hours, not sure if I
>> >> >>> >> >> >> >>> can
>> >> >>> >> >> >> >>> get
>> >> >>> my
>> >> >>> >> >> stuff
>> >> >>> >> >> >> >>> back in time... so help please!
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> --
>> >> >>> >> >> >> >>> Regards,
>> >> >>> >> >> >> >>> Paul Liu
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>> Yale Haskell Group
>> >> >>> >> >> >> >>> http://www.haskell.org/yale
>> >> >>> >> >> >> >>> _______________________________________________
>> >> >>> >> >> >> >>> users mailing list
>> >> >>> >> >> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >> >> >>>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > --
>> >> >>> >> >> >> > Regards,
>> >> >>> >> >> >> > Paul Liu
>> >> >>> >> >> >> >
>> >> >>> >> >> >> > Yale Haskell Group
>> >> >>> >> >> >> > http://www.haskell.org/yale
>> >> >>> >> >> >> >
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >> --
>> >> >>> >> >> >> Regards,
>> >> >>> >> >> >> Paul Liu
>> >> >>> >> >> >>
>> >> >>> >> >> >> Yale Haskell Group
>> >> >>> >> >> >> http://www.haskell.org/yale
>> >> >>> >> >> >> _______________________________________________
>> >> >>> >> >> >> users mailing list
>> >> >>> >> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> --
>> >> >>> >> >> Regards,
>> >> >>> >> >> Paul Liu
>> >> >>> >> >>
>> >> >>> >> >> Yale Haskell Group
>> >> >>> >> >> http://www.haskell.org/yale
>> >> >>> >> >>
>> >> >>> >> >> _______________________________________________
>> >> >>> >> >> users mailing list
>> >> >>> >> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Regards,
>> >> >>> >> Paul Liu
>> >> >>> >>
>> >> >>> >> Yale Haskell Group
>> >> >>> >> http://www.haskell.org/yale
>> >> >>> >> _______________________________________________
>> >> >>> >> users mailing list
>> >> >>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> >> https://www.nilfs.org/mailman/listinfo/users
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Regards,
>> >> >>> Paul Liu
>> >> >>>
>> >> >>> Yale Haskell Group
>> >> >>> http://www.haskell.org/yale
>> >> >>> _______________________________________________
>> >> >>> users mailing list
>> >> >>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> >>> https://www.nilfs.org/mailman/listinfo/users
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Paul Liu
>> >> >
>> >> > Yale Haskell Group
>> >> > http://www.haskell.org/yale
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paul Liu
>> >>
>> >> Yale Haskell Group
>> >> http://www.haskell.org/yale
>> >> _______________________________________________
>> >> users mailing list
>> >> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> >> https://www.nilfs.org/mailman/listinfo/users
>> >>
>> >
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> Yale Haskell Group
>> http://www.haskell.org/yale
>> _______________________________________________
>> users mailing list
>> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
>> https://www.nilfs.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users

Re: [SPAM] Re: [SPAM] Re: urgent help need! disk partition info lost

[Ryusuke Konishi]

On Sat, 7 Nov 2009 21:28:03 +0900, Ryusuke Konishi wrote:
> 2009/11/6 Jan de Kruyf <jan.de.kruyf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > At the same time I pick up from "the_nilfs.c :: load_nilfs that even if a
> > partition is mounted read-only
> > perhaps certain things do get written
> > this is the code I refer to:
> > -------------------------
> >     if (!valid_fs && (s_flags & MS_RDONLY)) {
> >         printk(KERN_INFO "NILFS: INFO: recovery "
> >                "required for readonly filesystem.\n");
> >         if (really_read_only) {
> >             printk(KERN_ERR "NILFS: write access "
> >                    "unavailable, cannot proceed.\n");
> >             err = -EROFS;
> >             goto failed;
> >         }
> >         printk(KERN_INFO "NILFS: write access will "
> >                "be enabled during recovery.\n");
> >         sbi->s_super->s_flags &= ~MS_RDONLY;
> >     }
> > ------------------------
> > So how do we proceed mounting this filesystem completely read-only to see
> > if perhaps some data can be recovered. (Provided that the partition table
> > now
> > points to a more or less valid nilfs partition.)
> 
> Yes, nilfs does recovery if needed even for a read-only mount.
> 
> Ok, you have a point.  I will consider adding a mount option to
> disable this action.
> 
> Regards,
> Ryusuke Konishi

Here is a patch to disable write access during recovery on mount.

A new mount option "-o norepair" is added instead of disabling write
access for read-only mount by default.  This is because the repair
action is needed especially for the root filesystem; the root
filesystem is first mounted with a read-only option and remounted
read/write later on.

If the write access is not allowed by default, mounting the root
filesystem after unexpected reboot will always fail.  The same issue
is actually present in journaling filesystems like ext3.

So, I think this is a practical solution.
How does this look like ?

This patch was made for the out-of-tree kernel module, and moreover,
is not divided properly.  So, if you OK, I will reorganize the patch
and queue it for the next merge window.

Regards,
Ryusuke Konishi
--

diff --git a/fs/nilfs2_fs.h b/fs/nilfs2_fs.h
index 79fec6a..3b15f19 100644
--- a/fs/nilfs2_fs.h
+++ b/fs/nilfs2_fs.h
@@ -151,6 +151,8 @@ struct nilfs_super_root {
 #define NILFS_MOUNT_BARRIER		0x1000  /* Use block barriers */
 #define NILFS_MOUNT_STRICT_ORDER	0x2000  /* Apply strict in-order
 						   semantics also for data */
+#define NILFS_MOUNT_NOREPAIR		0x4000  /* Disable write access during
+						   mount-time recovery */
 
 
 /**
diff --git a/fs/super.c b/fs/super.c
index c9acc9a..097e3fb 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -513,6 +513,11 @@ static int nilfs_mark_recovery_complete(struct nilfs_sb_info *sbi)
 	down_write(&nilfs->ns_sem);
 	if (!(nilfs->ns_mount_state & NILFS_VALID_FS)) {
 		nilfs->ns_mount_state |= NILFS_VALID_FS;
+		if (sbi->s_super->s_flags & MS_RDONLY) {
+			struct nilfs_super_block *sbp = nilfs->ns_sbp[0];
+
+			sbp->s_state |= cpu_to_le16(NILFS_VALID_FS);
+		}
 		err = nilfs_commit_super(sbi, 1);
 		if (likely(!err))
 			printk(KERN_INFO "NILFS: recovery complete.\n");
@@ -649,7 +654,7 @@ static struct export_operations nilfs_export_ops = {
 
 enum {
 	Opt_err_cont, Opt_err_panic, Opt_err_ro,
-	Opt_barrier, Opt_snapshot, Opt_order,
+	Opt_barrier, Opt_snapshot, Opt_order, Opt_norepair,
 	Opt_err,
 };
 
@@ -660,6 +665,7 @@ static match_table_t tokens = {
 	{Opt_barrier, "barrier=%s"},
 	{Opt_snapshot, "cp=%u"},
 	{Opt_order, "order=%s"},
+	{Opt_norepair, "norepair"},
 	{Opt_err, NULL}
 };
 
@@ -728,6 +734,15 @@ static int parse_options(char *options, struct super_block *sb)
 			sbi->s_snapshot_cno = option;
 			nilfs_set_opt(sbi, SNAPSHOT);
 			break;
+		case Opt_norepair:
+			if (!(sb->s_flags & MS_RDONLY))
+				return 0;
+			/*
+			 * Turning off repair action (allowed only for
+			 * read only mounts or snapshots).
+			 */
+			nilfs_set_opt(sbi, NOREPAIR);
+			break;
 		default:
 			printk(KERN_ERR
 			       "NILFS: Unrecognized mount option \"%s\"\n", p);
@@ -946,10 +961,12 @@ nilfs_fill_super(struct super_block *sb, void *data, int silent,
 		up_write(&nilfs->ns_sem);
 	}
 
-	err = nilfs_mark_recovery_complete(sbi);
-	if (unlikely(err)) {
-		printk(KERN_ERR "NILFS: recovery failed.\n");
-		goto failed_root;
+	if (!nilfs_test_opt(sbi, NOREPAIR)) {
+		err = nilfs_mark_recovery_complete(sbi);
+		if (unlikely(err)) {
+			printk(KERN_ERR "NILFS: recovery failed.\n");
+			goto failed_root;
+		}
 	}
 
 	down_write(&nilfs->ns_super_sem);
@@ -1051,6 +1068,14 @@ static int nilfs_remount(struct super_block *sb, int *flags, char *data)
 			err = -EINVAL;
 			goto restore_opts;
 		}
+		if (!(nilfs->ns_mount_state & NILFS_VALID_FS)) {
+			printk(KERN_WARNING "NILFS (device %s): couldn't "
+			       "remount because the filesystem is in an "
+			       "incomplete recovery state.\n",
+			       sb->s_id);
+			err = -EINVAL;
+			goto restore_opts;
+		}
 		sb->s_flags &= ~MS_RDONLY;
 		nilfs_clear_opt(sbi, SNAPSHOT);
 		sbi->s_snapshot_cno = 0;
diff --git a/fs/the_nilfs.c b/fs/the_nilfs.c
index 365971b..084bbeb 100644
--- a/fs/the_nilfs.c
+++ b/fs/the_nilfs.c
@@ -303,19 +303,9 @@ int load_nilfs(struct the_nilfs *nilfs, struct nilfs_sb_info *sbi)
 	valid_fs = (nilfs->ns_mount_state & NILFS_VALID_FS);
 	up_write(&nilfs->ns_sem);
 
-	if (!valid_fs && (s_flags & MS_RDONLY)) {
+	if (!valid_fs && (s_flags & MS_RDONLY))
 		printk(KERN_INFO "NILFS: INFO: recovery "
 		       "required for readonly filesystem.\n");
-		if (really_read_only) {
-			printk(KERN_ERR "NILFS: write access "
-			       "unavailable, cannot proceed.\n");
-			err = -EROFS;
-			goto failed;
-		}
-		printk(KERN_INFO "NILFS: write access will "
-		       "be enabled during recovery.\n");
-		sbi->s_super->s_flags &= ~MS_RDONLY;
-	}
 
 	err = nilfs_search_super_root(nilfs, sbi, &ri);
 	if (unlikely(err)) {
@@ -329,18 +319,38 @@ int load_nilfs(struct the_nilfs *nilfs, struct nilfs_sb_info *sbi)
 		goto failed;
 	}
 
-	if (!valid_fs) {
-		err = nilfs_recover_logical_segments(nilfs, sbi, &ri);
-		if (unlikely(err)) {
-			nilfs_mdt_destroy(nilfs->ns_cpfile);
-			nilfs_mdt_destroy(nilfs->ns_sufile);
-			nilfs_mdt_destroy(nilfs->ns_dat);
+	if (valid_fs)
+		goto skip_rollforward;
+
+	if (s_flags & MS_RDONLY) {
+		if (nilfs_test_opt(sbi, NOREPAIR)) {
+			printk(KERN_INFO "NILFS: roll-forward recovery will "
+			       "be skipped because of the norepair option\n");
+			goto skip_rollforward;
+		}
+		if (really_read_only) {
+			printk(KERN_ERR "NILFS: write access unavailable, "
+			       "cannot proceed.\n");
+			err = -EROFS;
 			goto failed;
 		}
-		if (ri.ri_need_recovery == NILFS_RECOVERY_SR_UPDATED)
-			sbi->s_super->s_dirt = 1;
+		printk(KERN_INFO "NILFS: write access will be enabled "
+		       "during recovery.\n");
+		sbi->s_super->s_flags &= ~MS_RDONLY;
 	}
 
+	err = nilfs_recover_logical_segments(nilfs, sbi, &ri);
+	if (unlikely(err)) {
+		nilfs_mdt_destroy(nilfs->ns_cpfile);
+		nilfs_mdt_destroy(nilfs->ns_sufile);
+		nilfs_mdt_destroy(nilfs->ns_dat);
+		goto failed;
+	}
+
+ skip_rollforward:
+	if (ri.ri_need_recovery == NILFS_RECOVERY_SR_UPDATED)
+		sbi->s_super->s_dirt = 1;
+
 	set_nilfs_loaded(nilfs);
 
  failed:
diff --git a/nilfs2.txt b/nilfs2.txt
index dbbda00..f7af22a 100644
--- a/nilfs2.txt
+++ b/nilfs2.txt
@@ -71,6 +71,10 @@ order=strict		Apply strict in-order semantics that preserves sequence
 			blocks.  That means, it is guaranteed that no
 			overtaking of events occurs in the recovered file
 			system after a crash.
+norepair		Disable repair action of filesystem on mount. This
+			option is allowed only for readonly mount or snapshots.
+			This disables all write access to disk including the
+			mount-time recovery.
 
 NILFS2 usage
 ============