![]() ![]() I added a path to the initrd file and the root filesystem image. I personally don't have access to devices this large to test, but this is now a pattern across several users.After much experimentation, I have CoreOS mostly working via tftpboot. Similar I'm suspecting that it's to do with GPT partitions themselves, and potentially not the file system within, although I don't have enough data. I'm going to attempt to take this user through a similar "file system on the raw device and not in a partition" method to see if their problem is also solved.Īre there any known limitations with either Raspberry Pi 4 hardware, current RPi firmware or anything else that cause errors in large disks? Seems to be over the 16TB mark, although I might have found one other with a 12TB device that exhibited troubles. However attempting to mount on boot fails. It appears the partition was created successfully, as well as the mkfs portion. Similar issue, 16TB drive, GPT partitioned and ext4 formatted, throws the following error when attempting to mount:ĮXT4-fs (sda1): filesystem too large to mount safely on this system What stood out specifically was the lack of GPT partition in that case (as well as the GPT CRC error in the screenshot above, which again worked fine on a Windows machine with no errors). ![]() The user has since loaded about 12TB of data on their 18TB device and confirmed it works as expected across multiple reboots. I finally solved this issue by instructing the user to wipe the drive and put a BtrFS file system directly on the raw device (/dev/sda, and not a partition like /dev/sda1) which mounted at boot without issues. The drive works perfectly as expected when used in Windows 10 on an x86 workstation as a standard removable hard disk.Īpologies for the screenshot instead of text output, the user sent these through:Īnd I have a GitHub issue tracking it here: Similarly wiping the drive clean with wipefs, partitioning and formatting the drive in NTFS (ensuring ntfs-3g was installed and working on the Pi side with smaller devices that worked fine), and attempting to mount at boot via fstab also failed. The user attempted partitioning the drive with gdisk (GPT mandatory due to the drive size, fdisk/MBR won't work), formatting as ext4, adding it to fstab and mounting it at boot. I instructed the user to wipe the disk with wipefs and start again via the command line. ![]() This failed, and I assumed Cockpit was the issue. Initially the user used an open source tool web management called "Cockpit" on the RPi to do the partition/format/mount (behind the scenes it uses very simple gdisk/mkfs things and adds an entry to fstab as normal). We've confirmed all the usual suspects - power is fine (these are large spindle drives, vendor provided in their own USB3 chassis with a supplied 12V power supply and adequate amps), and dmesg confirms there are no ATA resets or any of the usual suspects you see when USB block devices don't get enough power. All running the stock RPiOS provided kernel (5.10.X), and a mix of 32bit and 64bit OSes. The project only supports the current RPiOS based on Debian 11 Bullseye (no users are on Debian 10 Buster). Smaller drives - 8TB or lower, have yet to report these errors. ![]() It's seeing a few people attempt to connect very large (16TB+) USB3 connected drives to their RPis and attempt to format and mount these, many of whom find errors when trying to do so. I run an open source project that offers people a way to use a Raspberry Pi as a NAS for legacy protocols, computers and consoles. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |