View Single Post
Posts: 1,335 | Thanked: 3,931 times | Joined on Jul 2010 @ Brittany, France
#357
Oh my. Is seems I have solved it by myself (this is the miraculous part) after multiple attempts. It's late so I won't detail/analyze what I did now, but for the record, below is the history of the recovery shell showing a session where rootfs still didn't mount:

Code:
     Jolla Recovery v2.0
-----------------------------
Welcome to the recovery tool!
The available options are:
1) Reset device to factory state
2) Reboot device
3) Shell
4) Perform file system check
5) Run sshd
6) Exit
Type the number of the desired action and press [Enter]: 
3

If you continue, this may void your warranty. Are you really SURE? [y/N] y
  /dev/mmcblk0rpmb: read failed after 0 of 4096 at 0: Input/output error
  2 logical volume(s) in volume group "sailfish" now active
mount: mounting /dev/sailfish/root on /rootfs failed: Invalid argument
[WARNING] Root file system unaccessible, bypassing device lock check.
/ # df -h
Filesystem                Size      Used Available Use% Mounted on
none                      1.3G      4.0K      1.3G   0% /dev
none                     10.0M         0     10.0M   0% /tmp
none                    256.0K     12.0K    244.0K   5% /var/run
/ # ls
bin     etc     lib     proc    root    run     sys     usr
dev     init    mnt     res     rootfs  sbin    tmp     var
/ # resize2fs /dev/sailfish/root
resize2fs 1.43.1 (08-Jun-2016)
Resizing the filesystem on /dev/sailfish/root to 1164288 (4k) blocks.
resize2fs: Can't read a block bitmap while trying to resize /dev/sailfish/root
Please run 'e2fsck -fy /dev/sailfish/root' to fix the filesystem
after the aborted resize operation.
/ # mke2fs -n /dev/sailfish/root
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
291456 inodes, 1164288 blocks
58214 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304
36 block groups
32768 blocks per group, 32768 fragments per group
8096 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736
/ # lvm
lvm> vgs
  /dev/mmcblk0rpmb: read failed after 0 of 4096 at 0: Input/output error
  VG       #PV #LV #SN Attr   VSize  VFree
  sailfish   1   2   0 wz--n- 22.25g    0 
lvm> lvscan
  ACTIVE            '/dev/sailfish/root' [4.44 GiB] inherit
  ACTIVE            '/dev/sailfish/home' [<17.81 GiB] inherit
lvm> lvs
  LV   VG       Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home sailfish -wi-a----- <17.81g                                                    
  root sailfish -wi-a-----   4.44g                                                    
lvm> exit
  Exiting.
/ # resize2fs /dev/sailfish/home 17G
resize2fs 1.43.1 (08-Jun-2016)
Resizing the filesystem on /dev/sailfish/home to 4456448 (4k) blocks.
The filesystem on /dev/sailfish/home is now 4456448 (4k) blocks long.

/ # lvm
-----------------------------
     Jolla Recovery v2.0
-----------------------------
Welcome to the recovery tool!
The available options are:
1) Reset device to factory state
2) Reboot device
3) Shell
4) Perform file system check
5) Run sshd
6) Exit
Type the number of the desired action and press [Enter]: 
2
Rebooting...
And unfortunately I can't see the history of what I did that fixed it, because I typed "exit" to return to the Recovery mode main menu and rebooted; it didn't keep the history.

From what I remember, I did something like the following (please don't paste those commands blindly, I'm not sure this is correct):

Code:
resize2fs /dev/sailfish/home 17G
lvm
vgs
lvresize -L -2048M /dev/sailfish/home
lvresize -l +100%FREE /dev/sailfish/root
lvscan
exit
resize2fs /dev/sailfish/home
resize2fs /dev/sailfish/root
exit
Still didn't work, went back to Recovery shell, rootfs still failed to mount:

Code:
resize2fs /dev/sailfish/home 15G
lvm
vgs
lvresize -L -2048M /dev/sailfish/home
lvresize -l +100%FREE /dev/sailfish/root
lvscan
exit
resize2fs /dev/sailfish/home
resize2fs /dev/sailfish/root
exit
And this time it worked. Again, please, don't reproduce these steps unless you want to bork your Xperia X. I am absolutely not sure what I listed is accurate since I may not remember exactly all commands I ran. However, it seems that the issue came from the 11G I used initially when following the Xperia X how-to I quoted, while maybe 15G was more appropriate for my device (either because the X Compact has different partition sizes, or because I had too much data on $HOME).

Last edited by Kabouik; 2018-12-05 at 08:45.
 

The Following 3 Users Say Thank You to Kabouik For This Useful Post: