This all sounds interesting so far, however the costs for guarding the facility (miners consuming 1MW are worth quite something), on-premise support (i.e. replugging miners) might probably outrun every discount you get. Colour me vaguely interested, I am waiting to see some real figures like kW/h and hosting prices to run through my inner counting frame. On another more amusing note: Finally a "real" miner from deep of his heart here  |
|
|
|
For all your encryption needs, I highly recommend VeraCrypt. The continuation of the highly successful TrueCrypt project, it's free, open-source, and thoroughly tried and tested. The "open-source" part is especially important, and is considered a requirement for an encryption product that's worth your time and trust, as a closed-source product may have backdoors that no one can detect. Need to store data on the cloud, but worried about others having access to it or the cloud server getting hacked? Simple! Just create an encrypted VeraCrypt container, put all your sensitive data in there, and then store the container file itself in the cloud. No one can access your files without the container passphrase, which only you will know. That's not a backup. Seen this too many times, people trusting the cloud, then comes a thunderstorm and that specific cloud where your goodies were is blown away (with or without encryption). Think decentralization! I used duplicity with free protonmail accounts to backup some important data offsite (additionally to local backups). I agree thet Veracrypt looks mature, unlike i.e. encfs based things that shouldn't be trusted with important data as its not good enough for that. But it's a nice overview that VB1001 posted, thanks. A local folder that syncs with a cloud service does not have this problem. Dropbox for example. That's still not a backup, the article VB1001 quoted talks about backing up to the cloud, not just having a synch'd copy there. (I know backing up is for coward pussies but still I beg to differ) |
|
|
|
For all your encryption needs, I highly recommend VeraCrypt. The continuation of the highly successful TrueCrypt project, it's free, open-source, and thoroughly tried and tested. The "open-source" part is especially important, and is considered a requirement for an encryption product that's worth your time and trust, as a closed-source product may have backdoors that no one can detect. Need to store data on the cloud, but worried about others having access to it or the cloud server getting hacked? Simple! Just create an encrypted VeraCrypt container, put all your sensitive data in there, and then store the container file itself in the cloud. No one can access your files without the container passphrase, which only you will know. That's not a backup. Seen this too many times, people trusting the cloud, then comes a thunderstorm and that specific cloud where your goodies were is blown away (with or without encryption). Think decentralization! I used duplicity with free protonmail accounts to backup some important data offsite (additionally to local backups). I agree thet Veracrypt looks mature, unlike i.e. encfs based things that shouldn't be trusted with important data as its not good enough for that. But it's a nice overview that VB1001 posted, thanks. |
|
|
|
you still here psyco ?  turn it off Yeah, I tend to stick to things I committed to but it seems time to let it go finally |
|
|
|
G3N either needs some community activity in the next days and weeks or it will rest in peace. All my attempts to get it listed on a small exchange didn't work out so far and I am about to give up and shut down the block explorer as well as the seed nodes. Well done Hort, great job...  |
|
|
|
Hi! Where is BTM community, guys (dbkeys, psycodad, Grendew) ? What is going on? Price is so low now... Let's make strike to 180 sat, please  I am still following this thread, but I am unsure what you expect from me (or the others named). |
|
|
|
You sure there is an ext4 filesystem to be expected? (Just asking, no offence meant) Otherwise I'd be keen to hear of any ideas from makrospex, I am getting a bit lost, the loop part still doesn't let go on me. Just as some therapeutic exercise, could you post the output of (I am really just fishing for new ideas here) At this point I need to ask: Did this contain a wallet that you didn't have backuped otherwise or any other unique and valuable data or just a synched btc node that you want to get back online without synching from genesis? |
|
|
|
At least there are valid superblock backups, that's a start I guess. Please try the mounts with the device I suggested above and not /dev/md0: i.e. mount -t ext4 -o ro,offset=32768 /dev/md0p1 /mnt/md0 root@bitcorn:/mnt/md0# mount -t ext4 -o ro,offset=32768 /dev/md0p1 /mnt/md0
mount: /mnt/md0: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. from mke2fs: /dev/md0p1 alignment is offset by 1024 bytes. This may result in very poor performance, (re)-partitioning suggested. Might that have something to do with it ? Add 1024 to whatever the offsets say ? Hmm, not sure about the offset, you could try with 1024 and by adding 1024, you could also try to fsck it with the backup superblock added: fsck.ext4 -b 32768 /dev/md0p1 Otherwise I am bit confused about the loop part still, did you by chance have for example an encrypted filesystem on top of that raid device? |
|
|
|
At least there are valid superblock backups, that's a start I guess.^The software just simply tells us where these backup superblocks would be stored on a partition of given size. Please try the mounts with the device I suggested above and not /dev/md0: i.e. mount -t ext4 -o ro,offset=32768 /dev/md0p1 /mnt/md0 |
|
|
|
doh then it's making out the backup superblock adresses via and using these to find a vital copy to use. My fucking spacebar is making me mad, something sticksunder it, so i have to punch it after every word to get a space in the text  Agree with makrospex, next try would be actually finding and restoring a good backup of the superblock of m0p1, I think he meant to say: to find the superblocks. Triplecheck it has the -n before you answer 'y' to the following prompt! Regarding the mounts to try from makrospex, please try these again with /dev/ md0p1 instead of /dev/ md0, i.e.: mount -t ext4 -o=ro,offset xxx /dev/md0p1 /mnt/md0 Maybe also check that /mnt/md0 is empty, otherwise the mount might fail with a slightly different error message that you could overlook easily. |
|
|
|
@Bob: Can you show us /etc/mdadm/mdadm.conf and when it was last modified (so we know it was not recreated recently): cat /etc/mdadm/mdadm.conf; stat /etc/mdadm/mdadm.conf It might gives us a new idea.. * psycodad needs much more coffee.. I commented out the mdadm.conf ARRAY stuff. I figured it looked fucked up enough that it was effectively useless. I have no idea what I'm doing. #ARRAY /dev/md0 metadata=1.2 spares=1 name=xserver:0 UUID=e0104263:8aef7ef8:2d66045f:26a69f31
#ARRAY /dev/md0 metadata=1.2 spares=1 name=xserver:0 UUID=6314fb8d:1466fbbd:5aa88188:793c3019
#ARRAY /dev/md0 metadata=1.2 spares=1 name=bitcorn:0 UUID=4b7f5741:476a4550:ba1184b2:76efd22e
#ARRAY /dev/md/0 metadata=1.2 UUID=4b7f5741:476a4550:ba1184b2:76efd22e name=bitcorn:0
#ARRAY /dev/md/bitcorn:0 metadata=1.2 name=bitcorn:0 UUID=4196079a:155fab25:eb7fa044:37adb2ce Okay, that looks pretty weird, I guess that system has seen quite a few changes already. I am still circling around this partition type 0xfd on m0p1. Just for fun and giggles could you try to see if there is another raid device on top of m0p1 when you scan now? |
|
|
|
<snip> -n
Causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem. This can be used to determine the location of the backup superblocks for a particular filesystem, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again. (With the -n option added, of course!) I suggest the default values ("auto" at setup) were used on filesystem creation, so should output the same backup block numbers for use with Waddaya think? Not trying to be a smartass at all (ok, maybe a tiny lil bit  ), that was what I meant by: <snip>
If dumpe2fs finds no superblock backups, there is the risky way of using mke2fs in simulation mode, by basically 'dry'-reformatting your partition the computer will come up with the same superblock addresses as the first time it formatted it.
RL calls, will check back tomorrow.
It seems dangerous, it will ask you to answer y to reformat your partition (even though with -n it doesn't). Though I tried it on USB stick and it does indeed not reformat (even the wording and confirmation is confusion as the author of mke2fs once admitted). But yes, that would be one of the next steps I'd also propose. After that I only have testdisk in my mind, but that's rather dangerous too easy to do something wrong. |
|
|
|
Moinmoin, Thanks makrospex for picking up where I left :-) Anyway, there is one thing that strikes me as very odd, but it may be too early or I may be simply too stupid (or both), but...: sgdisk -p /dev/md0
root@bitcorn:/dev# sgdisk -p /dev/md0
Disk /dev/md0: 15627544576 sectors, 7.3 TiB
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15627544542
Partitions will be aligned on 8-sector boundaries
Total free space is 8141 sectors (4.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 5118 15611104253 7.3 TiB FD00
2 15611104256 15627541487 7.8 GiB 8200 While p2 is correctly showing as type "linux swap" (0x82), p1 shows as "Linux raid autodetect" (0xfd). IMHO it should show as 0x83 for an ext4 partition. Looking for some confirmation or shown to be wrong from makrospex here. @Bob: Can you show us /etc/mdadm/mdadm.conf and when it was last modified (so we know it was not recreated recently): cat /etc/mdadm/mdadm.conf; stat /etc/mdadm/mdadm.conf It might gives us a new idea.. * psycodad needs much more coffee.. |
|
|
|
<snip>
Good points/ideas! Will be interesting to see the output of sgdisk and if it confirms my current theory. I also didn't find much about /dev/md127 on the net. any idea psycodad?
Never seen that md127 before, would check /etc/mdadm/mdadm.conf, but that's only a wild guess. After revisiting the below, I noticed that md0p1 has no recognized filesystem. So trying to rebuild the journal with tune2fs is probably of no help. But it indeed hints to a broken super block me thinks. re: lsblk -f, etc. re: It crashed due to power failure, for the sake of argument. Cant be sure of LVM. I'm a bit of a tard when it comes to Linux. root@bitcorn:/# lsblk -f
root@bitcorn:/# blkid
/dev/sda1: UUID="BA8D-865F" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="080f6638-f09f-4518-a785-6212e1b305b8"
/dev/sda2: UUID="42a6267e-28ba-4c93-8554-3dea69f5eb2e" TYPE="ext4" PARTUUID="f25d3ecd-9158-42b4-b502-4853b96bba78"
/dev/sda3: UUID="9bdd83b3-0bb0-474e-a83e-8394a1fb2e8b" TYPE="swap" PARTUUID="75ae0f41-c850-4153-af77-b2085f465a4d"
/dev/sdb: UUID="b7b2edc8-cd74-ad69-e5e4-81961dcc8509" UUID_SUB="8757b0af-bb26-b0e6-f0e1-eb5672344df3" LABEL="bitcorn:0" TYPE="linux_raid_member"
/dev/sdc: UUID="b7b2edc8-cd74-ad69-e5e4-81961dcc8509" UUID_SUB="600cedf1-06f6-f8a1-5c27-528f7588eada" LABEL="bitcorn:0" TYPE="linux_raid_member"
/dev/sdd: UUID="b7b2edc8-cd74-ad69-e5e4-81961dcc8509" UUID_SUB="9c08f657-41d9-1a24-33b9-0f993e7f0d6f" LABEL="bitcorn:0" TYPE="linux_raid_member"
/dev/md0: PTTYPE="gpt"
/dev/md0p1: PARTUUID="11d10ea4-e100-3949-b9d2-c30072ef7648"
/dev/md0p2: UUID="3df11d9c-51f2-48d8-9ab0-49b6dcd47753" TYPE="swap" PARTUUID="53d67f15-7962-ed43-840a-881c288fc86a"
root@bitcorn:/#
It definitely should read TYPE="ext4" at the md0p1 line, but there is no partition type detected at all. Based on this the best recommendation I can come up with at this point is trying to restore a backup superblock on md0p1. If dumpe2fs finds no superblock backups, there is the risky way of using mke2fs in simulation mode, by basically 'dry'-reformatting your partition the computer will come up with the same superblock addresses as the first time it formatted it. RL calls, will check back tomorrow. |
|
|
|
Hmmm... that would have been too easy anyway You could try again to find backup superblocks with dumpe2fs: dumpe2fs /dev/md0p1|grep -i super |
|
|
|
root@bitcorn:/dev# swapon -a
root@bitcorn:/dev# mount /dev/md0p1 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/md0p1, missing codepage or helper program, or other error.
root@bitcorn:/dev# mount /dev/md0p1 /mnt/md0
mount: /mnt/md0: wrong fs type, bad option, bad superblock on /dev/md0p1, missing codepage or helper program, or other error. Try fsck'ing it first: |
|
|
|
Ok, checked again through what you posted above and would suggest the following: swapon -a
mount /dev/md0p1 /mnt Didn't really question you trying to mount md0, even so your output above says you partitioned md0... |
|
|
|
Apologies, didn't check back and just typed from the top of my head, my fault. Edited in above post. Regarding the problem at hand: Did the RAID ever rebuild/resynch during your tries resp. after the failure?
I mean hours of disk activity while cat /proc/mdstat shows minimal progress? Took about 12 hours to rebuild/resync when I tried. Hmm, okay then my assumption was wrong, then the array should be clean. |
|
|
|
Seriously: Again don't panic, a power failure can't fsck up your array so badly, only the operator is capable of that (I know *exactly* what I am talking about here! - Lost TBs of data only due to getting panicky and impatient ). If you didn't forget to tell us about re-formatting the fs or similar nasties you are still in a good position. Just annoying problems so far. Regarding the problem at hand: Did the RAID ever rebuild/resynch during your tries resp. after the failure? I mean hours of disk activity while cat /proc/mdstat shows minimal progress? If not, you have probably forcefully assembled a damaged RAID by --assume-clean from above. The next thing I would recommend to try is actually resynching that RAID, either by simply rebooting or by stopping md with mdadm --stop /dev/md0
mdadm --assemble --scan should then show it is synching.
Edit: Try dumpe2fs /dev/md0|grep super as makrospex suggested to verify if the superblock suggested by fsck.ext4 are correct (did assume so, but I could be wrong).
|
|
|
|
@Bob: Does it anything after that (probably not)? Please try with the superblock backups listed, i.e. fsck.ext4 -b 8193 /dev/md0 Agree with makrospex^, fs is fs no matter on which block device it sits (at least from the perspective of the user and the tools trying to fix a filesystem). |
|
|
|
|
Show Posts
