Using the methods described here and in the linked post didn’t work: the dd ... commands all failed with the following
dd: /dev/block/bootdevice/by-name/modemst1: write error: No space left on device
4097+0 records in
4096+0 records out
2097152 bytes (2.0 M) copied, 0.108931 s, 18 M/s
What did work was deleting files /dev/block/bootdevice/by-name/modemst1 and /dev/block/bootdevice/by-name/modemst2 which I did via the terminal app in TWRP after mounting system and vendor. Doing it in an adb root` shell command would probably do the same
I think the error message is bogus. It still deletes the file. I somewhere read the explanation for it, but forgot the exact reason, so I am not going to put some speculation about it here.
Thanks. You may be right, but running the dd... commands did not fix the issue for me: the SIM card was still not detected after a reboot. Deleting the files manually via TWRP did fix it for me, so Iposted in case that happens for others. Anyway, the important thing is that issue is now fixed and my phone i working again.
What would be really intersting to know is why the modem files get corrupted in the first place. With that knowledge, it would eventuelly be possible to not let the problem arise at all.
If it’s any use to you in tracking down the cause, I have only encountered this problem very rarely. Until yesterday, the last time was at least two years ago. When I encountered the problem yesterday, I had been swapping SIMs in order to set up one of my test devices as an extra phone for my wife to use while her number is being ported to a new provider. So, in the space of a couple of hours, I swapped a couple of times between
the GifGaff SIM that was in the device before I started;
the EE SIM for the number which is being ported to…
… the new Lebara SIM to which the EE number will be ported (with luck, sometime today or tomorrow).
I seem to recall that when I first encountered the problem I was doing a lot of SIM-swapping and ROM-hopping (between /e/OS, LOS for microG, maybe ‘normal’ LineageOS, but I don’t recall the details, and I can’t find any notes about it in my journal
Trying the dd... approach (via adb root & adb shell - error No space left on device, via fastboot - error Erase operation not supported on partition) did not work. Deleting the files usng the TWRP terminal did work.
Pete maintains the lineageos 4 microg project (I also contribute there as able), and it is that build system that is used to create the unofficial iodé images. Here is the wiki on using it:
I did on my two xz1 compact the last update everything works fine.
On one of my device I had the “empty IMEI” issue but with the commands lines in the TWRP terminal it worked again.
Thanks
I just dirty flashed the IodeOS 5.17 from beginning of October and it is running smooth. Thank you.
I also installed the new TWRP version that j4nn released in July on XDA developers. Does this new TWRP change your recommendation how to do a full backup / restore of the phone with IodeOS? So far, I have used android restore tool and root debug. However, I know from old phones that full image backup could be done with TWRP. Does this now also work for lilac? I ask because my device unfortunately has a defective screen now (some dead pixels after mechanical impact) and I was able to get another lilac device but I would like to transfer all data / apps from the old device to the new device as easy as possible. Maybe the new TWRP from July can help here.
Does this mean that it might be possible that the Sony camera app also comes to IodeOS 5.x ROM for lilac at some point? I use OpenCamera at the moment and I am fine with the picture quality. But it is a bit annoying that the camera needs quite some time to load always when starting the app.
I know that backup works, but I don’t know that restore works (so that’s not very helpful - sorry ).I backed up, and tries a restore which appeared ro succedd but the phone wouldn;t boot until I did a wipe or format data (don’t remember which - sorry). I use a pattern to encrypt / lock my device, and when you run backup in the new TWRP it detects the lock and suggests disabling the lock before backing up. I don’t know whether that might allow the restore to work.
I no longer use XZ1C as my daily driver, and I use other means for backup so I didn’t dig any further. I would be interested to know if the backup / restore cycle works - or can be made to work - with this TWRP, but I really don’t have the time to spend on it myself: too much going on in the los4microG project ATM
Only if it gets to the point where it can be built from sources in GitHub (or some other git forge). This loos promising, but I don’t have the time to try it out at the moment. If anyone else can try making and testing either a v5-staging IodéOS or lineage-21.0 LOS or los4microG build, I will happily include it in my builds for the Sony Yoshino devices. (Sorry, but I really don’t have time to do that myself.)
I switched from LineageOS 17.1, and everything generally works fine. Even the fingerprint reader is always active. However, I’ve noticed poorer battery standby time. But, that’s a minor issue. The worst change is that the proximity sensor doesn’t activate when someone calls. Previously, the sensor detected when I had the phone in my pocket and only activated the display when I took it out. The second issue is captive portal detection. I don’t know if it’s because of this private server or a bug, but before, I would connect to the network and open the login page. Now, it immediately asks for a password that I don’t have. I mainly want the sensor fixed because the tiles accidentally expand, and I often draw the wrong pattern before taking the phone out.
).I backed up, and tries a restore which appeared ro succedd but the phone wouldn;t boot until I did a wipe or format data (don’t remember which - sorry). I use a pattern to encrypt / lock my device, and when you run backup in the new TWRP it detects the lock and suggests disabling the lock before backing up. I don’t know whether that might allow the restore to work.