Can you plug a keyboard into it?
2 Likes
Alternatively, you can boot Jumpdrive and back out the latest update (if you can identify more specifically what needs to be backed out).
I assume you are talking about byzantium.
Booting Jumpdrive would also demonstrate working hardware, or otherwise.
1 Like
Up to date there is not any critical bug on Byzantium related to your issues, the only issue introduced in the latest updates is that Librem 5 is slow to load internet pages, this new problem is also in debian bookworm.
I don’t think it’s a hardware issue, but a software issue.
First make sure that all the firmware and software of L5 it up to date. Please use all time the original Librem 5 charger and cable.
Um, isn’t that rather difficult to do if you are stuck at the disk decryption screen?
1 Like
You right not much to do, i not sure what Jumpdrive can do, so the easy fix should be reflash.
Some time the system updater broke the system on an update because people it forced any packages before.
Talk about the Monitor/Digitizer, there is a bug on the firmware but is not for Input but for scroll.
Of course Purism already tracking a new firmware to burn to the Monitor. 
check this out: https://forums.puri.sm/t/cant-use-l5-after-update/16245
There is a solution by @mladen in #14
3 Likes
Ok, I’ve been busy enough at work that I haven’t had a chance to get this working until now, so I’ve been without a phone for a few days. I tried the keyboard, but that didn’t work. So I went through the link that t0m pointed to. Thanks t0m - once I got most of the way through the fix, it became evident that there was probably a hiccup with disk space (or something else) on the update that made the phone barf. I hate to put stuff on two threads, but I may do a bit of that in case someone stumbles on this one instead of the original one that solves the issue. Along with my quirk that I have a question about.
So I run open Suse, which made it a little bit of a hassle getting uuu working, but I was able to solve that issue using Snap and manually moving the uuu binary. But I got that working and downloaded/ran the script as outlined by mladen et. al., and connected via jumpdrive just fine. But when I get to where the files should be, some, but not all, of the expected files were there:
Neither the “initrd.img”, “vmlinuz”, nor their .bak’s are there. I am guessing the best course of action would be to copy the serialized versions to non-serialized files and see what happens?
i.e. cp initrd.img-5.16.0-1-librem5 initrd.img AND cp vmlinuz-5.16.0-1-librem5 vmlinuz ?
EDIT: apparently this would have done nothing, since it is normal for these files to not be here anymore
I’ll pose the question over on the other thread as well, and see if they have a recommendation.
Updating over here, since the other thread isn’t getting any traction. I was advised that it wasn’t the same out-of-space issue, because that was resolved. However, my phone is still not booting in the same exact manner as that issue caused, but corrupt files are corrupt files, so I would think the fix should be similar. However, the phone doesn’t seem to maintain a backup of those files anymore (unless someone can point me to them in a different location).
I am hoping someone would advise which files would be the most likely to need replacement with these symptoms and maybe a source for them?
There is a procedure written by @mladen to recover a non booting device: Can't use L5 after update!
It seems that the steps #10 and #11 of this are outdated.
- Delete “initrd.img” and “vmlinuz”
- Rename “initrd.img.bak” to “initrd.img”, rename “vmlinuz.bak” to “vmlinuz”
and should be updated by someone from support@
1 Like
How is not booting? u-boot always booting.
Maybe you need to execute 20sec of super long press power, if the batt it really empty it will not boot either with super long press, in the case it requiere other execute.
1 Like
Have you read the post #1 of the OP? He/she says that it is booting to the point where the disk encryption key must be entered, but not reacting on the touch screen. Please re-read.
2 Likes
Yes, maybe. Also and before you reflash your phone (as there is no warranty from my side for below draft or rather coarse direction):
cd /media/user/L5_path/
ls -lh
dd if=boot.scr of=L5boot_scr.script bs=72 skip=1
Edit, as su, L5boot_scr.script text file and look for (or something else related to your setup, this is just an example):
setenv fk_kvers '5.17.0-1-librem5'
Continue with:
dd if=boot.scr.bak of=L5boot_scr.bak.script bs=72 skip=1
Compare two outputs, rethink your next step and solve this issue. Perhaps you’d like to end up with this after removing (and backuping) original boot_scr and boot_scr.bak files, as su:
apt install u-boot-tools −− needed to be adjusted toward: https://software.opensuse.org/package/u-boot-tools
mkimage -c none -A arm -T script -d L5boot_scr.bak.script boot.scr −− from .bak to the regular .scr
… or just rm boot.scr and rename boot.scr.bak to it.
Ok, this has been a fun adventure. I first tried switching to the backup boot.scr. That didn’t do the trick. Then I rebuilt it per your instructions. That didn’t do the trick either.
Oh, and that line I looked for seemed correct: setenv fk_kvers ‘5.16.0-1-librem5’ [not 5.17]
I wonder if someone could please give me a sample of their ls -lh -R so I could compare if I’m missing something, if something is of different size, or if there’s an updated version I could try out?
Mine:
This is taken after flashing a fresh image yesterday.
It seems like you have gone through all the more usual steps of reverting to backups etc. with no success.
My mind is on a slow burn this morning so I may be overlooking something but I’m thinking you could possibly supplant an initrd.img and vmlinuz (or possibly the whole boot partition) from a recent install image? You would need to update/change the UUIDs on the current block devices to match those used by initrd but should be possible.
But I’m also thinking, is your phone setup/config so complex that you can’t just start over?
2 Likes
Thank you for the screenshot. I agree, and don’t see much of a difference there. So, what you propose
is exactly what I wish to do. I could probably tackle it with some general instructions or guidance, and a pointer where to get this image. The reason I hesitate starting over is I took quite a few steps getting things going, including the hair-raising VoLte enable. Setting up SMS, MMS, and voice all at once seemed like a delicate balance, but now some invasive honeysuckle has invaded my boot partition. Hopefully I can just slash and burn that, as opposed to taking out my entire rain forest.
But now I have to go to work.
The general process would be something along the lines of…
- Download an recent LUKS variant Byzantium image
- Check the image for the required UUIDs
- Change the UUIDs on the block devices within your current system
- Update crypttab and fstab of your current system to point to the new UUIDs
- Transfer the initrd.img and vmlinuz from the downloaded image to the boot partition of your current system
- Reboot and rejoice (maybe)
I have no experience with open Suse so I wouldn’t even have a stab at the exact commands and utilities required. I can give some examples relating to Debian and it’d be up to you to do the open Suse translation. You’ll probably need to install at least the cryptsetup utility if your main system does not use encryption I would imagine the other utilities required are probably available as standard.
If you decide to go ahead with it, let me know and I’ll put together some steps with example (Debian) commands.
For downloading an image, if you have the flashing/update script/tool from Purism then getting an image should be a simple case of…
./librem5-flash-image --variant luks --skip-cleanup --skip-flash
The --skip-cleanup and --skip-flash options just mean the image will be downloaded only, watch the output of the script as it will detail the location of where the image will be saved.
If you don’t have the flashing/update script, you can download images directly via the artifacts of the Jenkins Image Build (be sure to grab from one of the “luks librem5r4 byzantium image” jobs rather than the plain and it’s the “.img.xz” file you would need which will also need decompressing after download.
2 Likes
Curiosity got the better of me and I decided to try using an initrd.img and vmlinuz from a downloaded image and changing UUIDs on the phone to suit, it worked for me without issue. For your reference my terminal log showing the steps required can be found below, does it need to be broken down into a step-by-step guide?
Before getting going in the terminal, I downloaded build 10988 and placed the decompressed image in /home/ripley/librem5/images/byzantium-luks-10988/ I span up Jumpdrive on the phone, the /boot partition was automatically mounted by my OS at /media/ripley/55f622fb-738d-4765-9979-77b040a8c29c/ my OS also pops up an option to open/unlock the LUKS container, I cancelled/declined that and worked with the LUKS container directly within the terminal.
The calls to vi within the terminal log are just opening the respective files for editing, you can use your preferred text editor of choice and I’m going to assume that the contents of these files are self-explanatory to you and the required edits are obvious?
The calls to blkid | grep are just sanity checks to ensure the UUID changes took.
Terminal log as follows(I couldn’t find any sensible highlighting that didn’t turn the root commands into comments)…
root@sulaco:~# SRC_IMG=$(losetup --show -Prf /home/ripley/librem5/images/byzantium-luks-10988/librem5r4.img)
root@sulaco:~# cryptsetup luksUUID ${SRC_IMG}p2
040fa73a-aa27-458e-a8cc-7fba8ced031c
root@sulaco:~# cryptsetup open ${SRC_IMG}p2 src_img
Enter passphrase for /dev/loop0p2:
root@sulaco:~# mount /dev/mapper/src_img /mnt
mount: /mnt: WARNING: device write-protected, mounted read-only.
root@sulaco:~# cat /mnt/etc/fstab
proc /proc proc defaults 0 0
UUID=f8d74bc4-a994-4f5c-86b0-34f4929e4d2f / ext4 errors=remount-ro 0 1
UUID=77fd1729-1804-4c81-b131-389ee22db7bd /boot ext2 errors=remount-ro 0 2
root@sulaco:~# umount /mnt
root@sulaco:~# cryptsetup close src_img
root@sulaco:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 4.2G 1 loop
├─loop0p1 259:0 0 465M 1 loop
└─loop0p2 259:1 0 3.7G 1 loop
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 23.3G 0 part /
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 9.3G 0 part /var
├─sda6 8:6 0 7.8G 0 part [SWAP]
├─sda7 8:7 0 1.9G 0 part /tmp
└─sda8 8:8 0 190.7G 0 part /home
sdb 8:16 1 29.1G 0 disk
├─sdb1 8:17 1 465M 0 part /media/ripley/55f622fb-738d-4765-9979-77b040a8c29c
└─sdb2 8:18 1 28.7G 0 part
sr0 11:0 1 122.4M 0 rom
root@sulaco:~# cryptsetup --uuid 040fa73a-aa27-458e-a8cc-7fba8ced031c luksUUID /dev/sdb2
WARNING!
========
Do you really want to change UUID of device?
Are you sure? (Type uppercase yes): YES
root@sulaco:~# cryptsetup open /dev/sdb2 l5disk
Enter passphrase for /dev/sdb2:
root@sulaco:~# tune2fs /dev/mapper/l5disk -U f8d74bc4-a994-4f5c-86b0-34f4929e4d2f
tune2fs 1.44.4 (18-Aug-2018)
Setting UUID on a checksummed filesystem could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) <proceeding>
root@sulaco:~# mount /dev/mapper/l5disk /mnt
root@sulaco:~# vi /mnt/etc/crypttab
root@sulaco:~# vi /mnt/etc/fstab
root@sulaco:~# blkid | grep sdb
/dev/sdb1: UUID="55f622fb-738d-4765-9979-77b040a8c29c" TYPE="ext2" PARTUUID="c0625aba-01"
/dev/sdb2: UUID="040fa73a-aa27-458e-a8cc-7fba8ced031c" TYPE="crypto_LUKS" PARTUUID="c0625aba-02"
root@sulaco:~# blkid | grep l5disk
/dev/mapper/l5disk: UUID="f8d74bc4-a994-4f5c-86b0-34f4929e4d2f" TYPE="ext4"
root@sulaco:~# umount /mnt
root@sulaco:~# cryptsetup close l5disk
root@sulaco:~# mount ${SRC_IMG}p1 /mnt
mount: /mnt: WARNING: device write-protected, mounted read-only.
root@sulaco:~# cp /mnt/initrd.img-5.16.0-1-librem5 /media/ripley/55f622fb-738d-4765-9979-77b040a8c29c/
root@sulaco:~# cp /mnt/vmlinuz-5.16.0-1-librem5 /media/ripley/55f622fb-738d-4765-9979-77b040a8c29c/
root@sulaco:~# umount /mnt
root@sulaco:~# losetup -d ${SRC_IMG}
root@sulaco:~#
Unless you have coincidentally encountered a hardware fault at the same time as you performed the update it should be possible to get back up and running by pulling files from the boot partition of a recent image file.
If you have any questions or require clarification on any of the steps above, feel free to ask, now I have done once on the phone, I’m an expert 
4 Likes
Awesome. Thanks for going through all this to help me out. Just home from work, so about to give it a shot.
Ok, I’m most of the way through here. Edited the text files as I thought they should have been edited, but it sems like the UUID for sdb1 didn’t stick:
Did I miss place that one?
sdb1 is the /boot partition so should not be changed unless you are going to be re-imaging the entire partition.
So the entry for the /boot partition in fstab should also not be changed.
2 Likes