3.3.0 Rokua patching status?

[ghost]

Has anyone yet tested if 3.3.0 patches, flashes and works fine? Please report. 👀
btw. @g7 I donated to your paypal, thank you for this work 👍

[lentemoore]

The OTA update worked perfectly (including FDE). Don't know about patching and flashing though.

[teleshoes]

rokua marks the first time image failed to build for me

keep getting:
error: Failed dependencies: libreadline.so.8 is needed by zypper-1.14.6+git4-1.5.1.jolla.armv7hl

[teleshoes]

(fix was easy #14)

[teleshoes]

with the above, patch seems to work correctly in chroot, but the repacking fails

I: Syncing back the patched tree
I: Repacking
/tmp/sailfish-image-patcher/Sailfish_OS-Jolla-3.3.0.16-f5121-0.2.1.25/patcher-tmp/work /tmp/sailfish-image-patcher/Sailfish_OS-Jolla-3.3.0.16-f5121-0.2.1.25
0+0 records in
0+0 records out
0 bytes copied, 0.000164125 s, 0.0 kB/s
  Physical volume "/dev/loop0" successfully created.
  Volume group "sailfish" successfully created
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop1: 25063/116640 files (0.1% non-contiguous), 264442/466176 blocks
We got ourselves root blocks _ 398289 _
after maths size _ 1631391744 _
  Rounding up size to full physical extent 1.52 GiB
  Logical volume "root" created.
  1 logical volume(s) in volume group "sailfish" now active
398289+0 records in
398289+0 records out
1631391744 bytes (1.6 GB, 1.5 GiB) copied, 7.78859 s, 209 MB/s
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
home: 83/7328 files (3.6% non-contiguous), 13285/16198 blocks
We got ourselves home size _ 13290 _
  Rounding up size to full physical extent 52.00 MiB
  Logical volume "home" created.
  2 logical volume(s) in volume group "sailfish" now active
13290+0 records in
13290+0 records out
54435840 bytes (54 MB, 52 MiB) copied, 0.163591 s, 333 MB/s
  0 logical volume(s) in volume group "sailfish" now active
1+0 records in
1+0 records out
1 byte copied, 0.00015447 s, 6.5 kB/s
Usage: mkfs.ext4 [-c|-l filename] [-b block-size] [-C cluster-size]
	[-i bytes-per-inode] [-I inode-size] [-J journal-options]
	[-G flex-group-size] [-N number-of-inodes] [-d root-directory]
	[-m reserved-blocks-percentage] [-o creator-os]
	[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
	[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
	[-t fs-type] [-T usage-type ] [-U UUID] [-e errors_behavior][-z undo_file]
	[-jnqvDFSV] device [blocks-count]
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open fimage.img

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

resize2fs 1.43.4 (31-Jan-2017)
resize2fs: Bad magic number in super-block while trying to open fimage.img
Couldn't find valid filesystem superblock.
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
umount: /tmp/sailfish-image-patcher/Sailfish_OS-Jolla-3.3.0.16-f5121-0.2.1.25/patcher-tmp/work/tmp.Y3VaMPjpIX: not mounted
rmdir: failed to remove '/tmp/sailfish-image-patcher/Sailfish_OS-Jolla-3.3.0.16-f5121-0.2.1.25/patcher-tmp/work/tmp.Y3VaMPjpIX': Directory not empty
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open fimage.img

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

resize2fs 1.43.4 (31-Jan-2017)
resize2fs: Bad magic number in super-block while trying to open fimage.img
Couldn't find valid filesystem superblock.

[teleshoes]

it cant find the UUID, it seems, and is running mkfs.ext4 -U fimage

in generated repack.sh:

# For some reason loop files created by imager don't shrink properly when
# running resize2fs -M on them. Hence manually growing the loop file here
# to make the shrinking work once we have the image populated.
dd if=/dev/zero bs=1 seek=1400000000 count=1 of=fimage.img; mkfs.ext4 -U  fimage.img
e2fsck -f -y fimage.img
resize2fs -f fimage.img

[teleshoes]

damn, fimage uuid is no longer in fstab.

from rokua changelog:

jolla-common-configurations

Updated : 0.8.21.1-1.15.1.jolla -- 0.8.27-1.14.1.jolla
....
[fstab] remove fimage from fstab.

[teleshoes]

actually, does this mean we just dont care about the uuid anymore since its not hardcoded into fstab now?
ill test using a random one and see if it works

[teleshoes]

worked! image built and flashed successfully (havent test much yet, just the basics. boot and setup works, jolla account login works, android support works, etc etc)

=> pull request #14 fixes all rokua problems for me

[henning-schild]

I just did the OTA. First download failed, a later download worked. Choosing "install" the phone rebooted and is now stuck on a white screen with a SONY logo.

Is that encryption taking very long and it is expected? It is there since about 15min, did not dare to touch it yet. Sure hope i will not have to reflash ... Will keep it running hopefully until i receive feedback from someone here, or the device ...

[henning-schild]

Mhh still stuck, power button did not want to turn it off. LED is blinking green.

Connecting it to a laptop it is an ethernet interface that serves DHCP. The DHCP servers IP lets me in over ssh

$ ssh nemo@192.168.2.15
"System is booting up. See pam_nologin(8)"
Connection closed by 192.168.2.15 port 22

[henning-schild]

smells like sailfish is still somewhere in there ...

[henning-schild]

Managed to get back to the old firware eventually. Press vol-up and power for a while

[henning-schild]

And managed to update manually from the command line.

[g7]

Great to hear, sorry for the delay. And thanks to @teleshoes for its findings and fixes :)