2019.3.1 Update Release - Read Only Filesystem - Undesirable Default

[Sn3akyP3t3]

The first sign of a problem was the first time run file system expansion attempt failure issued a warning asking to do it manually.

Upon login just to the right of the username there is a (ro) indicating in Read Only mode.

sudo fdisk -l
shows a bunch of ram disks assigned such as /dev/ram15

I'm not able to spot the cause at this time. Will test with previous image to confirm not bad SD card.

This is not a first boot only problem, but persists for every boot.

[Sn3akyP3t3]

Confirmed something is wrong with that release or maybe its how it treats large SD cards. Anyway, same card with 2019.2.1 Update Release boots just fine.

[PeterJohnson]

Can you try again with 3.1? No one else has reported an issue like this and there’s a lot of 3.1 installs out there...
What size SD card?

[Sn3akyP3t3]

128 GB is the size of the card. We sought that out due to an awesome flash sale and also for post match video review.

[Sn3akyP3t3]

Confirmed again 3rd time. This time card new out of box never used. 128 GB Samsung EVO Plus. Raspberry Pi boots in read-only mode. First time boot warns can't expand filesystem and same behavior previously reported.

I dropped back into Windows and looked at the partition structure and found it no different than any other expanded image install. First partition is boot and 2nd is the data, but not yet expanded due to the read-only situation.

[Sn3akyP3t3]

Tried on a 16 GB SD card previously used on earlier image with same Read-Only results. If you say this is working then the only other variable is the process I'm using to write the image to SD card. Thats Etcher version 1.4.9. I see they have a 5.x update so I'll install that and try again.

[Sn3akyP3t3]

Updated Etcher to 1.5.5 and still getting the same read-only behavior on the 16 GB card after re-flashing it.

[Sn3akyP3t3]

Looks like this is a misunderstanding of the intended design and also a different expected behavior on login. I'm not familiar with the read/write flipping option in the web UI, but it appears that the default setting is now Read-Only upon boot. The previous version it was RW which is what led me to believe something was wrong.

The fix for me is the RW or RO aliases mentioned in #126

[Sn3akyP3t3]

Actually, on second thought maybe the default should be RW so that the file expansion process can succeed as intended. If a post-processing step to flip it to RO needs to happen it should at least allow the expansion step to take place.

[Sn3akyP3t3]

Even if I change the card to RW the Pi config utility cannot expand the partition. This is something that didn't pose a problem with previous releases.

sudo raspi-config
Option 7
Option A1

Error message:
mmcblk0p2 is not the last partition. Don't know how to expand.

[PeterJohnson]

It’s read/write on first boot so the expansion can happen, but the script which does the expansion changes it to read only and then reboots.

[PeterJohnson]

See #42

[PeterJohnson]

Although hmm, maybe I still have it be ro in the initial fstab. That’s always been the case however so it would have been broken in 2.1 as well. Given the way the script works though we could easily make it not read only on first boot, which would be safer and perhaps avoid this issue.

[Sn3akyP3t3]

Ah, well I popped in the 16 GB card in the Windows side and I'm seeing it expanded the partition.

Not the case for the 128 GB cards though.

Any way I can bypass the RO on boot default behavior for the time being? fstab you say?

[Sn3akyP3t3]

Altered fstab and rebooted in rw mode.

Retried this and still got an error... sad day.
sudo raspi-config
Option 7
Option A1

Error message:
mmcblk0p2 is not the last partition. Don't know how to expand.

[Sn3akyP3t3]

I'm at a loss on how to manually overcome this. I'm out of time to troubleshoot today, but I do believe it has something to do with those /dev/ram[0-15] mounts that are seen with fdisk -l. I don't recall seeing these before.

https://www.raspberrypi.org/forums/viewtopic.php?t=115300

[Sn3akyP3t3]

If you have any ideas on what to try let me know and I'll try them later tonight.

[PeterJohnson]

There aren’t really many changes in 2019.3.1 that could have broken resizing... so the fact it works with 2.1 and not 3.1 is puzzling, but should be possible to isolate.

[PeterJohnson]

Actually, the initial /etc/fstab is indeed read-write (stage1/01-sys-tweaks/files/fstab). It's only made read-only after the resize is done on first boot. It sounds like what is happening is that first-boot resize is failing for some reason--probably the same reason raspi-config is failing later. What does fdisk -l /dev/mmcblk0 output? The filesystem resize should be completely ignoring the ramdisks and looking at only /dev/mmcblk0 partitions.

[FRC-3277]

pi@frcvision(rw):~$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 119.3 GiB, 128043712512 bytes, 250085376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6b341386

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 98077 89886 43.9M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 5996543 5898240 2.8G 83 Linux

[FRC-3277]

I talked with another one of our mentors and we think we may temporarily solve this by expanding it on a Linux OS machine.

[FRC-3277]

Expanding the partition externally has been our working solution so far with this. We can come back later and do more testing if desired.