Raspberry Pi Forums

I installed Pidora 18 with separate /boot (in 32MB SDCard) and /root (32GB 2.0 USB stick).

Problem: Whenever I update /boot (like modifying cmdline.txt), and then reboot, the whole SDcard partition table is trashed, so it will not boot at all (no signal in HDMI.)

It reboots properly as long as /boot was not modified from Raspberry Pi.

I have another same exact Raspberry Pi model B with 32MB SDcard and 32GB USB stick, and this one doesn't cause any problems with modifying /boot. The only difference would be the 32GB USB sticks, which are from different manufacturers and production dates (about 3 years apart, and the one that has the newest USB is failing.) The 32MB SDcard in both Pi's are from the same model cellphones. The power chargers on both Pi's are rated 5V 700mA, although from different manufacturers.

I tried partitioning the SDcard using parted, fdisk, and gparted in Linux Fedora 18 desktop, but none of them makes any difference. I also tried a 64MB SDcard, and it had the same issue.

Could this be the fault of the 32GB USB stick (its partition table never gets damaged though), or possibly using the cheap cellphone charger rated 5V 700mA? Or is this a software issue?

I am not inclined to test out any of these devices (SDcard, USB stick, or power charger) to my other perfectly working Pi lest it breaks that one if it's a hardware issue.

Here are some more results.

The partition table also gets trashed if I modify the /boot filesystem and some time passes (no reboot was required to trash it).

I even copied the whole boot disk image from the other Pi's SDcard, and it works up until any modification to /boot, so it cannot be the way SDcard was partitioned (since the same image works perfectly in the other Pi.)

At least I found a workaround: Remove 'comment=systemd.automount' from the /boot entry in /etc/fstab: I can now safely modify /boot filesystem by manually mounting it using normal mount command.

It's no longer urgent, but I still don't know out why it causes problems in the first place, while the other Pi worked flawlessly. At best, I think it may be a timing issue when /boot is automounted by systemd, but when I do manually mount long after the system is running, it may have become stable. Just my random guess.