.hw_model corrupt

Hi,

anyhow my system managed to ruin the .hw_model file in /boot/dietpi. Is there a way to let this be properly regenerated or do you have any idea how to fix this?

Thanks in advance and happy easter

zerbes
hw_model_corrupt.jpg

Happy Easter!

rm /boot/dietpi/.hw_model
/boot/dietpi/func/dietpi-obtain_hw_model

This is done on every boot btw.

Is it an RPi (dedicated /boot partition)? Please check & repair the file system:

umount /boot
fsck /dev/mmcblk0p1
mount /boot

Also ls -l /boot might contain some FSCK* named files which indicate that corruptions were present.

Damn you are faster than I’m typing on my mobile :stuck_out_tongue:

Thanks for the support on easter monday :slight_smile:

I deleted the file and have let it rebuild

root@DietPi:~# rm /boot/dietpi/.hw_model
root@DietPi:~# /boot/dietpi/func/dietpi-obtain_hw_model

I tried to unmount the partition but it did not work

root@DietPi:~# umount /boot
umount: /boot: target is busy.
root@DietPi:~# fsck /dev/mmcblk0p1

i checked the file system and found errors but did not yet fix these as i first would like to ask i am doing it “correctly”. I would remove the dirty bit, copy no boot sector, free the cluster. Is that correct?

Thank you in advance,

zerbes

fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 2
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
Reclaimed 1 unused cluster (512 bytes).
Free cluster summary wrong (415442 vs. really 415443)
1) Correct
2) Don't correct
? 2
Perform changes ? (y/n) n

Sorry for the late reply. Yes your choices are fine. When a reboot succeeds, you can rerun the check and 1) Copy original to backup as then the original seems to work fine. Generally before doing actual repairs, I’d unmount the file system. It was showing “target is busy” and hence did not unmount it. Assure that df does not show it, so that no write can collide with the repair.