Open skaarj0 opened 6 years ago
Temporary issue solved.
I do not have knowledge about issue closing procedures but I may have a workaround for this.
Here is a fast desperate workaround explaining how you can get a working FreeBSD for RPI3 without storage corruption due to error in inode number counting (df -i showing all ok) and cg checksum failures (caused probably by growfs). Warning: this will probably give you a working FreeBSD-RPI3 image BUT it does not give a proper explanation of WHY bsd12 is corrupting the storage media.
Use it if you really really need it working as soon as possible and you have no time to waste. Security and stability are not guaranteed.
Ingredients:
so far RPI3 should read ${YOUR_FAVOURITE_SDCARD}, load the required files from msdos partition, read the ${rootdir}/boot/loader.conf and load the freebsd12-current kernel.
So far at power-up the RPI3 should read ${YOUR_FAVOURITE_SDCARD}, load the required files from msdos partition, read the ${rootdir}/boot/loader.conf and load the freebsd12-current kernel. Later it will read ${YOUR_FAVOURITE_SDCARD_ROOTDIR}/etc/fstab which instructs it to use /dev/${external_hdd_root_partition} as root directory and /dev/${external_hdd_swap_partition} as swap.
At this point my RPI3 managed to boot the hybrid BSD11 world + bsd12 kernel without any cg->checksum failures.
I am currently compiling firefox from /usr/ports to stress the system.
cd /usr/ports/www/firefox && make config - I removed all references to video playing and sound, leaving just SNDIO as sound support and BUNDLED_CAIRO (first option activated by default).
I pkg-installed all required dependencies which exist in the repository.
/usr/ports/lang/rust is required and it does not come as a precompiled package. Stop the compiling process as soon as configuration files are generated. Use /usr/local/bin/mc to find all files containing "-march=native", remove all occurrences (F4-replace with blank space) because compiler does not support this flag on aarch64.
Firefox compiling fails at startup due to some core dump of python2.7 which I don't want to solve.
Same happens for /usr/ports/www/chromium.
Switching to /usr/ports/www/seamonkey
So far in the last 24 hours no more cylinder group (cg) CRC failures occurred.
Plans for the future: if everything works fine, my plan is as following: bsdinstall partedit to modify sdcard: delete root partition, add a smaller one and leave some space for some swap; newfs -t -O2 -U -j -f 512 -b 4096 ${sdcard_root_partition}; (see man newfs) mound ${sdcard_root_partition} to /mnt, cd /mnt && dump -0f - / |restore -rf - umount /mnt Create a backup image file of the sdcard - to avoid re-working all of these in case of any unforseen errors; Continue to stress the RPI and the external HDD by compiling heavy stuff such as blender, audacity, gimp or OpenOffice; Keep a FreeBSD-based RPI3 in working condition because it is much simple to make it serve you - Linux is a pain.
Please recreate the experiment in order to confirm.
As we already know, FreeBSD 12-Current has some very strange issues with UFS2+j+softupdates filesystem, which may or may not be caused by growfs: when a certain number of occupied inodes is reached, system gets stuck with cylinder group checksum failures - slowing it down - and not even the all-mighty aarch64-built fsck is able to correct this. However, fsck + mounting the system on a traditional architecture (x86, x64) shows no problems.
So I decided to switch to FreeBSD 11 and to try booting my RPI3. Now here's what I've got so far:
Here's what I got so far:
Booting the crochet-resulted FreeBSD 11.1-stable r329320 aarch64 rpi3 image: At startup it loads u-boot, starts loader.efi, it is able to read the filesystem, to list files and load the kernel. After kernel is loaded I have 10 seconds to press enter to boot or space to pause. At boot it clears the screen, it hangs and turns off the monitor. The last message I am able to see (before clearing the screen) is "using dtb provided by EFI at 0x8004000";
Booting the crochet-resulted FreeBSD12.0-CURRENT-aarch64-rpi3 image
It boots normal, as it is expected to boot. However it causes the above mentioned filesystem issues after portsnap fetch extract + building some heavy stuff such as firefox.
Booting the crochet-resulted <> FreeBSD 11.1-stable r329320 aarch64 rpi3 image using the 12.0-current kernel+modules:
I replaced just the kernel and modules: 11.1-stable image containing 11.1-stable world and 12.0-current kernel+modules in /boot/kernel. No modifications were made on the fat partition or anywhere else.
The resulting image causes the system to boot normally, but with the same filesystem issues (cg group checksum failed after portsnap fetch extract + compiling some heavy stuff such as firefox).
Booting the crochet-resulted <> FreeBSD 12.0-current aarch64 rp3 image using the 11.1-stable kernel
Exactly like step3, I replaced just the kernel + modules: 12.0-current image containing 12.0-current world and 11.1-stable kernel+modules in /boot/kernel.
It is performing exactly as in step 1.
From these experiments I reached the conclusion that there's something wrong going on during 11.1-stable kernel compilation process for aarch64-rpi3.
There are no display information even when full debug is enabled in the 11.1-aarch64-rpi3 kernel configuration, so I am unable to determine any further steps to investigate.
Please feel free to re-run these experiments to confirm. For weeks I have been searching every developer mailing lists I could find to get more information about any working FreeBSD 11.x kernel on RPI3. So far there's a strange silence on this subject.
In the mean time I am stuck - please advise.