search

RPi-Distro / repo

Issue tracking for the archive.raspberrypi.com repo
37 stars 1 forks source link

USB boot loops in resizing rootfs #221

Closed Devnol closed 3 years ago

Devnol commented 3 years ago

I flashed the latest Raspbian OS 32-bit Lite on a 120GB Samsung SM0128G NVMe drive in a USB 3.0 Enclosure. I boot the SSD from my raspberry pi 4 from a USB 3.0 port. It gets to the pseudo-gui saying "resized root filesystem, rebooting in 5 seconds". It reboots and says the same message again and again. diskutil on my mac shows no change to the fs size whatsoever.

For flashing I used Raspberry Pi Imager v1.4 for mac, as well as BalenaEtcher. I have also noticed that if I plug the drive back in on my mac it gets corrupted in some way and no longer boots on the pi.

Devnol commented 3 years ago

to elaborate further on my last statement of corruption, once the flashing is done, running diskutil list on my mac lists the drive as follows:

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *121.3 GB   disk4
   1:             Windows_FAT_32 ⁨boot⁩                    268.4 MB   disk4s1
   2:                      Linux ⁨⁩                        1.6 GB     disk4s2
                    (free space)                         119.5 GB   -

Unplugging the drive and plugging it right back in the table changes to:

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *121.3 GB   disk4
XECDesign commented 3 years ago

It looks like the device is reporting the writes are going through and everything is okay, while data is actually getting corrupted.

I've seen something like that occur on a device I'm using - https://www.raspberrypi.org/forums/viewtopic.php?t=244948

I wonder if it may be the same issue. I'd try booting from an SD card, plugging in the USB device, copying some data to it, rebooting and then comparing it against what you copied. If that results in corrupted data, testing after running that hdparam command from that thread may confirm whether that's the issue.

Unfortunately that command is not persistent. On my drive I added a udev rule which runs the command whenever that device is detected, but it wouldn't help with the initial resize.

If we can confirm that's the issue, we can ask the kernel folk whether there's anything they can do to enable it by default for known-bad devices.

Devnol commented 3 years ago

the drive works fine. I couldn't test it on the pi itself but it works on my pc

Devnol commented 3 years ago

Upon further inspection it appears that my drive is indeed malfunctioning, sometimes it mounts ro, sometimes I make a file and the ACL is _unknown and I can't chown it. All sorts of weird stuff.

XECDesign commented 3 years ago

Do the issues mostly start to show up after a reboot? I just found another one of my drives doing similar stuff and again, disabling write-caching fixes it for me.

Devnol commented 3 years ago

these issues aren't present on using the drive with a Pi, but in my macOS laptop. And yes, sometimes the issues show up when I reboot. How can I disable write-caching?

Devnol commented 3 years ago

Can definitely confirm my drive is problematic. I made a large random file by using cat /dev/urandom > /Volumes/mydrive/file and ran a checksum on it. Then removed the drive and ran an md5 again. The checksums were different. I think we can consider the issue closed for now.