UFS Unable to reformat SD card slice

giorgiob

Member

Thanks: 1
Messages: 34

#1
I have an SD card with an official FreeBSD image on it.

A few days ago the filesystem got corrupted because the power supply was interrupted before I could do a clean shutdown.
I tried to repair the filesystem: I put the SD card in a card reader and attached it to my desktop. The slice with the root
filesystem shows up as /dev/da1s2a. I tried running fsck -y /dev/da1s2a. Several errors were
fixed but at the end the filesystem was still dirty. I ran the command several times but I always got the same errors
again and again.

So I mounted the filesystem and did a backup with tar. My plan is now to reformat the slice and
untar all the files back to the SD. If the system boots, I want to reinstall all packages, in case some files have
been deleted or got corrupted. With some luck, I hope this will give me my previous system back.

In order to reformat the slice, I ran
sudo dumpfs -m /dev/da1s2a > ../fmt.sh
which produced:
newfs -L rootfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 8192 -k 2576 -m 8 -o time -s 15636352 /dev/da1s2a

If I understand correctly, this command should format the slice with exactly the same parameters as before.
I then ran the command and got the output:

/dev/da1s2a: 7634.9MB (15636352 sectors) block size 32768, fragment size 4096
using 13 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072

I was a bit surprised that the command ran very fast, as if it did not do anything at all. So I mounted the filesystem and, indeed, the whole old content is still there. If I run fsck, all the old errors are still there.

So my question are: why does newfs do nothing on this filesystem? Is there a way to force it to create a new filesystem, overwriting the old one?
 

ShelLuser

Son of Beastie

Thanks: 1,490
Messages: 3,262

#2
First of all I don't understand why you'd use all those parameters for newfs, you're only over-complicating things. In some cases you're even "wasting" resources; for example -m where you basically specified the default value.

As such my suggestion would be to take another careful look at the newfs(8) manualpage and don't use parameters if you don't have to. From that same manualpage I think you might be looking for the -E parameter. Although care should be taken of course, I'm not too sure if it actually means to empty the entire storage media or just the section of the disk you pointed it to.
 
OP
OP
G

giorgiob

Member

Thanks: 1
Messages: 34

#3
I do not see the problem with copying and pasting a command generated by dumpfs: this should ensure that the new filesystem has the same parameters as the original one. On Linux I have already had the experience that a filesystem created with default parameters on one distribution was not opened by the kernel of another distribution because of missing modules. Maybe this will not occur under FreeBSD by I would like to create a filesystem with the same parameters to be on the safe side.

Anyway, I have also tried newfs -U /dev/da1s2a with the same result: the old filesystem (with its files and errors) is still there. So the main problem seems to be that newfs does not do anything and does not issue any error message or warning.

I had considered the -E option but as far as I understand it is used for overwriting the whole content of the slice, which is not what I want: I just want to create a fresh filesystem.
 

ShelLuser

Son of Beastie

Thanks: 1,490
Messages: 3,262

#4
Anyway, I have also tried newfs -U /dev/da1s2a with the same result: the old filesystem (with its files and errors) is still there. So the main problem seems to be that newfs does not do anything and does not issue any error message or warning.
I assume you ruled out obvious problems such as a possible read/only lock on the card?

Definitely agree that this seems a bit bizarre. I'd start by checking if the system can actually write anything at all on that card and if so you might want to try and remove & replace the partition itself using gpart.
 
OP
OP
G

giorgiob

Member

Thanks: 1
Messages: 34

#5
The SD card comes with an adapter that has a sort of switch on its side. If I move the switch down and insert the card, I can only mount the card read only and, if I run fsck on it, I get errors / warnings that it cannot write to the card. So I assume: switch down means read-only.

So I moved the switch up and now fsck does not complain that it cannot write to the card but at every run it shows the same errors, as if it could not change anything. I also mounted the slice and edited a file. No complaint that it cannot write. Unmounted and mounted again: the file has not been changed! Maybe the card is simply broken (?)
 
OP
OP
G

giorgiob

Member

Thanks: 1
Messages: 34

#6
For the record: it turned out to be a broken / worn out SD card.
I could read an image of the SD card with dd and write it to a new SD card.
I then repaired the filesystem from my desktop using fsck -y. This worked at the first
attempt.
Next I inserted the SD card into my rpi and booted: everything seemed to work. To be sure that
no packages are broken due to lost files, I cleaned the package cache and forced a reinstall of all
packages: sudo pkg clean -a followed by sudo pkg upgrade -f
 
OP
OP
G

giorgiob

Member

Thanks: 1
Messages: 34

#8
About two years if I remember correctly.
I keep the swap file on an attached external USB disk in the hope of extending the SD card's life.
Maybe I should also move the /var folder to the external disk.
 

tingo

Daemon

Thanks: 341
Messages: 1,871

#9
Two years is about the lifelength we see for SDcards used as system drive on some embedded systems (doorlock) with Raspberry Pi in our makerspace.
 
OP
OP
G

giorgiob

Member

Thanks: 1
Messages: 34

#10
Two years is about the lifelength we see for SDcards used as system drive on some embedded systems (doorlock) with Raspberry Pi in our makerspace.
Interesting. Do you think that moving the var directory out of the SD card would make a difference? I have this possibility since the rpi has an attached USB disk.
 
Top