🐛 Reset doesnt work on rpi #1486

Itxaka · 2023-06-07T09:58:16Z

Kairos version:
master

CPU architecture, OS, and Version:
rpi

Describe the bug
Reset doesnt work on rpi as we cannot infer where the recovery/oem partitions are, becuase they are mounted on LVM and ghw doesnt work with lvm

To Reproduce
enter recovery on rpi and try to reset, it will fail

Expected behavior
it works

Logs

Additional context
there is also the state.yaml which hints the installer where the partitions are but that is generated on installation and Im not sure if that would work.

Fix is fixing the sdk so it searches for lvm partitions as well and tries to identify them

jimmykarily · 2023-06-12T08:55:41Z

With this PR now merged, let's give it a retry (we need to bump kairos-agent to a version that includes the fix, or try that locally first).

jimmykarily · 2023-06-12T12:06:28Z

kairos is using the main branch of kairos-agent by default. And kairos-agent main already points to the kairos-sdk 0.0.7 which has the fix. So building from kairos main branch should be enough to get the fix in. I'll give it a try.

jimmykarily · 2023-06-13T09:57:40Z

I see 3 issues:

The persistent partition didn't expand after first boot. The rootfs.after stage didn't seem to run at all (

kairos/overlay/files/system/oem/00_rootfs.yaml

Line 151 in b8c7f6d

- if: '[ ! -f /run/cos/recovery_mode ] && [ ! -f /run/cos/live_mode ]'

)
When booting into recovery, I see an error about persistent partition not being found (I got to grab the text on the next try)
running kairos-agent reset produces errors:

WARNING: jsonschema: '' does not validate with file:///home/kairos/schema.json#/required: missing properties: 'users'
INFO[2023-06-13T09:55:05Z] kairos-agent version v2.1.3                  
WARN[2023-06-13T09:55:05Z] failed reading installation state: open /run/initramfs/cos-state/state.yaml: no such file or directory 
failed initializing reset spec: recovery partition not found

Itxaka · 2023-06-13T10:36:03Z

I see 3 issues:

1. The persistent partition didn't expand after first boot. The rootfs.after stage didn't seem to run at all (https://github.com/kairos-io/kairos/blob/b8c7f6dee46c1ec8ce3f4968c24c7c6ccbcf7925/overlay/files/system/oem/00_rootfs.yaml#L151
   )

2. When booting into recovery, I see an error about persistent partition not being found (I got to grab the text on the next try)

3. running `kairos-agent reset` produces errors:

WARNING: jsonschema: '' does not validate with file:///home/kairos/schema.json#/required: missing properties: 'users'
INFO[2023-06-13T09:55:05Z] kairos-agent version v2.1.3                  
WARN[2023-06-13T09:55:05Z] failed reading installation state: open /run/initramfs/cos-state/state.yaml: no such file or directory 
failed initializing reset spec: recovery partition not found

For 1:
Can you paste the /run/immucore/* logs?

For 3:

Can you paste the kairos-agent state output? I thougth this should be fixed as I tested it on an lvm system, and it returned the proper partition...:sob: also the kairos-agent version --long ?

jimmykarily · 2023-06-13T11:06:58Z

is actually this known bug . I thought we merged a fix but turns out we didn't. Let's do that after the release.

I will try your suggestion for 3. now

jimmykarily · 2023-06-13T11:09:33Z

This is kairos-agent state output (while in normal boot):

kairos@localhost:~> kairos-agent state
uuid: c310be105cacb6597368ba9e642eb452-localhost
persistent:
    mounted: true
    name: /dev/mmcblk0p4
    label: unknown
    filesystemlabel: COS_PERSISTENT
    mount_point: /usr/local
    size_bytes: 67108864
    type: ext4
    read_only: false
    found: true
    uuid: unknown
recovery:
    mounted: false
    name: /dev/mapper/KairosVG-recovery
    label: ""
    filesystemlabel: COS_RECOVERY
    mount_point: ""
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
oem:
    mounted: true
    name: /dev/mapper/KairosVG-oem
    label: ""
    filesystemlabel: COS_OEM
    mount_point: /oem
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
state:
    mounted: true
    name: /dev/mmcblk0p2
    label: unknown
    filesystemlabel: COS_STATE
    mount_point: /run/initramfs/cos-state
    size_bytes: 6501171200
    type: ext4
    read_only: true
    found: true
    uuid: unknown
boot: active_boot
system:
    meta:
        version: 0.9.5
        timestamp: 2023-06-13T11:07:33.000187878Z
    node:
        hostname: localhost
        machineid: c310be105cacb6597368ba9e642eb452
        hypervisor: ""
        timezone: Etc/UTC
    os:
        name: openSUSE Leap 15.4
        vendor: opensuse-leap
        version: "15.4"
        release: ""
        architecture: ""
    kernel:
        release: 5.14.21-150400.24.63-default
        version: '#1 SMP PREEMPT_DYNAMIC Tue May 2 15:49:04 UTC 2023 (fd0cc4f)'
        architecture: aarch64
    product:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
    board:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    chassis:
        type: 3
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    bios:
        vendor: U-Boot
        version: "2021.01"
        date: 04/19/2021
    cpu:
        vendor: ""
        model: ""
        speed: 0
        cache: 0
        cpus: 0
        cores: 0
        threads: 4
    memory:
        type: ""
        speed: 0
        size: 0
    storage:
        - name: mmcblk0
          driver: mmcblk
          vendor: ""
          model: ""
          serial: ""
          size: 64
    network:
        - name: eth0
          driver: bcmgenet
          macaddress: e4:5f:01:d9:c2:28
          port: tp/mii
          speed: 1000
        - name: wlan0
          driver: brcmfmac
          macaddress: e4:5f:01:d9:c2:2a
          port: ""
          speed: 0
kairos:
    flavor: opensuse-leap
    version: v2.2.0-rc7

and this is the version:

kairos@localhost:~> kairos-agent version --long
{Version:v2.1.3 GitCommit:none GoVersion:go1.20.2}

did you mean the kairos-agent state while in recovery? Does that make any difference?

jimmykarily · 2023-06-13T11:12:57Z

btw, while booting into recovery I grabbed the error for 2. It's about the recovery partition not persistent:

[   34.420177] immucore[662]:  <initramfs-hook> (background: false) (weak: false) (run: false)
[   34.450338] immucore[662]: <nil> INF Setting sentinel file to=recovery_mode
[   34.569816] immucore[662]: <nil> INF mount done options=["rw"] type=tmpfs what=tmpfs where=/tmp
[   34.683985] immucore[662]: <nil> ERR error="no such device" options=["ro"] type= what=/dev/disk/by-label/COS_RECOVERY where=/sysroot/run/initramfs/cos-state
[   36.038126][  T681] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[   36.048711] immucore[662]: <nil> INF mount done options=["ro"] type= what=/dev/disk/by-label/COS_RECOVERY where=/sysroot/run/initramfs/cos-state
[   36.609127][  T776] loop: module loaded
[   36.620675][  T775] loop0: detected capacity change from 0 to 4096000

jimmykarily · 2023-06-13T11:13:44Z

And this is the output for kairos-agent state while booted into recovery:

kairos@cos-recovery:~> kairos-agent state
uuid: d6afb79d617105ad45af995d642eb459-cos-recovery
persistent:
    mounted: false
    name: /dev/mmcblk0p4
    label: unknown
    filesystemlabel: COS_PERSISTENT
    mount_point: ""
    size_bytes: 67108864
    type: ext4
    read_only: true
    found: true
    uuid: unknown
recovery:
    mounted: true
    name: /dev/mapper/KairosVG-recovery
    label: ""
    filesystemlabel: COS_RECOVERY
    mount_point: /run/initramfs/cos-state
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
oem:
    mounted: true
    name: /dev/mapper/KairosVG-oem
    label: ""
    filesystemlabel: COS_OEM
    mount_point: /oem
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
state:
    mounted: false
    name: /dev/mmcblk0p2
    label: unknown
    filesystemlabel: COS_STATE
    mount_point: ""
    size_bytes: 6501171200
    type: ext4
    read_only: true
    found: true
    uuid: unknown
boot: recovery_boot
system:
    meta:
        version: 0.9.5
        timestamp: 2023-06-13T11:13:15.000580415Z
    node:
        hostname: cos-recovery
        machineid: d6afb79d617105ad45af995d642eb459
        hypervisor: ""
        timezone: Etc/UTC
    os:
        name: openSUSE Leap 15.4
        vendor: opensuse-leap
        version: "15.4"
        release: ""
        architecture: ""
    kernel:
        release: 5.14.21-150400.24.63-default
        version: '#1 SMP PREEMPT_DYNAMIC Tue May 2 15:49:04 UTC 2023 (fd0cc4f)'
        architecture: aarch64
    product:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
    board:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    chassis:
        type: 3
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    bios:
        vendor: U-Boot
        version: "2021.01"
        date: 04/19/2021
    cpu:
        vendor: ""
        model: ""
        speed: 0
        cache: 0
        cpus: 0
        cores: 0
        threads: 4
    memory:
        type: ""
        speed: 0
        size: 0
    storage:
        - name: mmcblk0
          driver: mmcblk
          vendor: ""
          model: ""
          serial: ""
          size: 64
    network:
        - name: eth0
          driver: bcmgenet
          macaddress: e4:5f:01:d9:c2:28
          port: tp/mii
          speed: 1000
        - name: wlan0
          driver: brcmfmac
          macaddress: e4:5f:01:d9:c2:2a
          port: ""
          speed: 0
kairos:
    flavor: opensuse-leap
    version: v2.2.0-rc7

jimmykarily · 2023-06-13T11:17:07Z

regarding the error:

failed reading installation state: open /run/initramfs/cos-state/state.yaml: no such file or directory

here is what I have in that directory:

kairos@cos-recovery:~> ls /run/initramfs/cos-state/
cOS  etc  grub2  lost+found

jimmykarily · 2023-06-13T11:25:01Z

state.yaml is created on installation, which never happens for rpi. I guess that warning can be ignored (?). Then the only problem is it can't find the recovery partition.

jimmykarily · 2023-06-13T11:42:44Z

kairos-agent fails to detect the recovery partition:

WARNING: jsonschema: '' does not validate with file:///home/kairos/schema.json#/required: missing properties: 'users'
INFO[2023-06-13T11:39:10Z] kairos-agent version v2.1.3-dirty            
WARN[2023-06-13T11:39:10Z] failed reading installation state: open /run/initramfs/cos-state/state.yaml: no such file or directory 
parts = [0x40003bfc00 0x40003bfc80 0x40003bfd00 0x40003bfd80]
*p = {Name:mmcblk0p1 FilesystemLabel:COS_GRUB Size:96 FS:vfat Flags:[] MountPoint: Path:/dev/mmcblk0p1 Disk:/dev/mmcblk0}
*p = {Name:mmcblk0p2 FilesystemLabel:COS_STATE Size:6200 FS:ext4 Flags:[] MountPoint: Path:/dev/mmcblk0p2 Disk:/dev/mmcblk0}
*p = {Name:mmcblk0p3 FilesystemLabel:unknown Size:4264 FS:LVM2_member Flags:[] MountPoint: Path:/dev/mmcblk0p3 Disk:/dev/mmcblk0}
*p = {Name:mmcblk0p4 FilesystemLabel:COS_PERSISTENT Size:64 FS:ext4 Flags:[] MountPoint: Path:/dev/mmcblk0p4 Disk:/dev/mmcblk0}
ep.Recovery by name = <nil>
ep.Recovery by Label = <nil>
ep = {BIOS:<nil> EFI:0x40003bfc00 OEM:<nil> Recovery:<nil> State:0x40003bfc80 Persistent:0x40003bfd80}
failed initializing reset spec: recovery partition not found
kairos@cos-recovery:~> sudo blkid
/dev/mapper/KairosVG-recovery: LABEL="COS_RECOVERY" UUID="a2ad34b7-b549-4478-b140-d554d69ce565" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mmcblk0p3: UUID="sk4ejQ-VD41-TNRh-AE1u-rSTz-ka2g-nCbhAH" TYPE="LVM2_member"
/dev/mmcblk0p1: LABEL_FATBOOT="COS_GRUB" LABEL="COS_GRUB" UUID="02F4-8891" BLOCK_SIZE="512" TYPE="vfat"
/dev/mmcblk0p4: LABEL="COS_PERSISTENT" UUID="720dd26f-631d-4932-ac4b-f9f6516bf04f" BLOCK_SIZE="1024" TYPE="ext4"
/dev/mmcblk0p2: LABEL="COS_STATE" UUID="91f4366e-c209-4c38-9d37-f3ad1ac56f6d" BLOCK_SIZE="4096" TYPE="ext4"
/dev/loop0: LABEL="COS_SYSTEM" UUID="d3e0c49f-e7a2-4045-ad56-02ba0385c56a" BLOCK_SIZE="4096" TYPE="ext2"
/dev/mapper/KairosVG-oem: LABEL="COS_OEM" UUID="c0396a83-c538-41a5-b073-539d643b4bc8" BLOCK_SIZE="1024" TYPE="ext4"

(added debug output here: kairos-io/kairos-agent@86976e5)

Itxaka · 2023-06-13T11:52:43Z

And this is the output for kairos-agent state while booted into recovery:

kairos@cos-recovery:~> kairos-agent state
uuid: d6afb79d617105ad45af995d642eb459-cos-recovery
persistent:
    mounted: false
    name: /dev/mmcblk0p4
    label: unknown
    filesystemlabel: COS_PERSISTENT
    mount_point: ""
    size_bytes: 67108864
    type: ext4
    read_only: true
    found: true
    uuid: unknown
recovery:
    mounted: true
    name: /dev/mapper/KairosVG-recovery
    label: ""
    filesystemlabel: COS_RECOVERY
    mount_point: /run/initramfs/cos-state
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
oem:
    mounted: true
    name: /dev/mapper/KairosVG-oem
    label: ""
    filesystemlabel: COS_OEM
    mount_point: /oem
    size_bytes: 0
    type: ext4
    read_only: false
    found: true
    uuid: ""
state:
    mounted: false
    name: /dev/mmcblk0p2
    label: unknown
    filesystemlabel: COS_STATE
    mount_point: ""
    size_bytes: 6501171200
    type: ext4
    read_only: true
    found: true
    uuid: unknown
boot: recovery_boot
system:
    meta:
        version: 0.9.5
        timestamp: 2023-06-13T11:13:15.000580415Z
    node:
        hostname: cos-recovery
        machineid: d6afb79d617105ad45af995d642eb459
        hypervisor: ""
        timezone: Etc/UTC
    os:
        name: openSUSE Leap 15.4
        vendor: opensuse-leap
        version: "15.4"
        release: ""
        architecture: ""
    kernel:
        release: 5.14.21-150400.24.63-default
        version: '#1 SMP PREEMPT_DYNAMIC Tue May 2 15:49:04 UTC 2023 (fd0cc4f)'
        architecture: aarch64
    product:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
    board:
        name: rpi
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    chassis:
        type: 3
        vendor: raspberrypi
        version: ""
        serial: ""
        assettag: ""
    bios:
        vendor: U-Boot
        version: "2021.01"
        date: 04/19/2021
    cpu:
        vendor: ""
        model: ""
        speed: 0
        cache: 0
        cpus: 0
        cores: 0
        threads: 4
    memory:
        type: ""
        speed: 0
        size: 0
    storage:
        - name: mmcblk0
          driver: mmcblk
          vendor: ""
          model: ""
          serial: ""
          size: 64
    network:
        - name: eth0
          driver: bcmgenet
          macaddress: e4:5f:01:d9:c2:28
          port: tp/mii
          speed: 1000
        - name: wlan0
          driver: brcmfmac
          macaddress: e4:5f:01:d9:c2:2a
          port: ""
          speed: 0
kairos:
    flavor: opensuse-leap
    version: v2.2.0-rc7

Weird, so the state fix works and can identify the recovery as expected. But then reset should work...

Itxaka · 2023-06-13T11:54:02Z

Are you running the reset from the recovery? Does debug show anything extra when failing?

jimmykarily · 2023-06-13T11:58:23Z

I'm running that in recovery. See my comment above. I think ghw library doesn't properly detect LVM partitions.

jimmykarily · 2023-06-13T12:23:55Z

ghw looks up partition information in this path: https://github.com/jaypipes/ghw/blob/36ff37eb3bdfcb8de352217a6406f12b31746e56/pkg/linuxpath/path_linux.go#L93

In my case, this is the information of COS_STATE:

sh-4.4$ cat /run/udev/data/b179:2
S:disk/by-id/mmc-EC1S5_0x59a95dc6-part2
S:disk/by-uuid/91f4366e-c209-4c38-9d37-f3ad1ac56f6d
S:disk/by-label/COS_STATE
S:disk/by-path/platform-fe340000.emmc2-part2
I:64798299
E:ID_SERIAL=0x59a95dc6
E:ID_NAME=EC1S5
E:ID_PATH=platform-fe340000.emmc2
E:ID_PATH_TAG=platform-fe340000_emmc2
E:ID_PART_TABLE_TYPE=dos
E:ID_FS_LABEL=COS_STATE
E:ID_FS_LABEL_ENC=COS_STATE
E:ID_FS_UUID=91f4366e-c209-4c38-9d37-f3ad1ac56f6d
E:ID_FS_UUID_ENC=91f4366e-c209-4c38-9d37-f3ad1ac56f6d
E:ID_FS_VERSION=1.0
E:ID_FS_TYPE=ext4
E:ID_FS_USAGE=filesystem
E:ID_PART_ENTRY_SCHEME=dos
E:ID_PART_ENTRY_TYPE=0x83
E:ID_PART_ENTRY_NUMBER=2
E:ID_PART_ENTRY_OFFSET=204800
E:ID_PART_ENTRY_SIZE=12697600
E:ID_PART_ENTRY_DISK=179:0
G:systemd
Q:systemd
V:1

and this is the one of COS_RECOVERY (lvm group):

sh-4.4$ cat /run/udev/data/b179:3
S:disk/by-id/mmc-EC1S5_0x59a95dc6-part3
S:disk/by-id/lvm-pv-uuid-sk4ejQ-VD41-TNRh-AE1u-rSTz-ka2g-nCbhAH
S:disk/by-path/platform-fe340000.emmc2-part3
I:64729892
E:ID_SERIAL=0x59a95dc6
E:ID_NAME=EC1S5
E:ID_PATH=platform-fe340000.emmc2
E:ID_PATH_TAG=platform-fe340000_emmc2
E:ID_PART_TABLE_TYPE=dos
E:ID_FS_UUID=sk4ejQ-VD41-TNRh-AE1u-rSTz-ka2g-nCbhAH
E:ID_FS_UUID_ENC=sk4ejQ-VD41-TNRh-AE1u-rSTz-ka2g-nCbhAH
E:ID_FS_VERSION=LVM2 001
E:ID_FS_TYPE=LVM2_member
E:ID_FS_USAGE=raid
E:ID_PART_ENTRY_SCHEME=dos
E:ID_PART_ENTRY_TYPE=0x8e
E:ID_PART_ENTRY_NUMBER=3
E:ID_PART_ENTRY_OFFSET=12902400
E:ID_PART_ENTRY_SIZE=8732672
E:ID_PART_ENTRY_DISK=179:0
E:SYSTEMD_READY=1
E:SYSTEMD_ALIAS=/dev/block/179:3
E:ID_MODEL=LVM PV sk4ejQ-VD41-TNRh-AE1u-rSTz-ka2g-nCbhAH on /dev/mmcblk0p3
E:SYSTEMD_WANTS=lvm2-pvscan@179:3.service
G:systemd
Q:systemd
V:1

see? There is not enough information about labels and such.

jimmykarily · 2023-06-13T12:25:13Z

otoh, there is a file that has the needed information:

sh-4.4$ cat /run/udev/data/b254\:1 
S:disk/by-uuid/a2ad34b7-b549-4478-b140-d554d69ce565
S:mapper/KairosVG-recovery
S:KairosVG/recovery
S:disk/by-id/dm-uuid-LVM-69P3G2Su2sooas9Timbsq01TCFJyPTWZ5y8pJbAFpJaurBeEqR9WJXbzkyoCorR3
S:disk/by-label/COS_RECOVERY
S:disk/by-id/dm-name-KairosVG-recovery
I:33639501
E:DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E:DM_UDEV_PRIMARY_SOURCE_FLAG=1
E:DM_UDEV_RULES_VSN=2
E:DM_ACTIVATION=1
E:DM_NAME=KairosVG-recovery
E:DM_UUID=LVM-69P3G2Su2sooas9Timbsq01TCFJyPTWZ5y8pJbAFpJaurBeEqR9WJXbzkyoCorR3
E:DM_SUSPENDED=0
E:DM_VG_NAME=KairosVG
E:DM_LV_NAME=recovery
E:DM_LV_LAYER=
E:ID_FS_LABEL=COS_RECOVERY
E:ID_FS_LABEL_ENC=COS_RECOVERY
E:ID_FS_UUID=a2ad34b7-b549-4478-b140-d554d69ce565
E:ID_FS_UUID_ENC=a2ad34b7-b549-4478-b140-d554d69ce565
E:ID_FS_VERSION=1.0
E:ID_FS_TYPE=ext4
E:ID_FS_USAGE=filesystem
G:systemd
Q:systemd
V:1

jimmykarily · 2023-06-13T12:28:02Z

And it looks up the wrong file because it's using the wrong disk name:

sh-4.4$ cat /sys/class/block/dm-0/dev 
254:0
sh-4.4$ cat /sys/class/block/mmcblk0/dev
179:0

Itxaka · 2023-06-13T12:34:15Z

I'm running that in recovery. See my comment above. I think ghw library doesn't properly detect LVM partitions.

yep, that why the fix to the sdk. I think I assumed we were using the sdk to find the partitions on reset, but of course, its elemental libs, so they are not, they just using ghw 🤦

So I fixed it in the wrong place. I mean, still good becuase we need that for the state, but its not fixing the reset stuff :D

Itxaka · 2023-06-13T12:35:41Z

FYI getting ghw to detect and report the lvm stuff properly is a bit of a mess, I had a look before. UDEV has all the info available and ghw already reports some dm devices IIRC properly. But incorporating that in there its not easy due to all the devices, dms, vgs, labels and such.

Itxaka · 2023-06-13T12:39:00Z

same fix as we did on the state could be done in GetAllPartitions under the agent pkg/utils/getpartitions.go file as a workaround for now.

This was the fix to sdk https://github.com/kairos-io/kairos-sdk/pull/28/files

jimmykarily · 2023-06-13T14:16:04Z

I don't see the reason to use both ghw and lsblk since lsblk can already return all partitions. I tried something here but it's not ready yet:

https://github.com/kairos-io/kairos-agent/compare/dk-debug-recovery-partition?expand=1

I still need to populate the Disk field.

Itxaka · 2023-06-13T14:30:43Z

I don't see the reason to use both ghw and lsblk since lsblk can already return all partitions. I tried something here but it's not ready yet:

kairos-io/kairos-agent@dk-debug-recovery-partition?expand=1 (compare)

I still need to populate the Disk field.

lsblk requires the binary everywhere and the implementation changes across distros. GHW uses no external tools as it consumes data from UDEV directly which is much more standard across systems and can be even used on minimal init systems in which only udev/eudev has run.

But we dont have a good alternative I think. Unless we send patches upstream to identify this data in ghw and have 1 lib across everywhere...

We could also just use the sdk for this utils. After all the idea was to move the partitioner into the sdk, so having fs utils in there so everything trying to get the partitions gets the same list would be nice.

jimmykarily · 2023-06-13T14:33:39Z

ghw "almost" returns the lvm partitions. It lists the disks but fails to return the partitions when they are lvm. Might not be that hard to fix. Otoh, upstreaming it might take a while in any case, so we can do both. Have a solution on our side and try to upstream. I agree it should be in the sdk.

Itxaka added bug Something isn't working arm/rpi labels Jun 7, 2023

jimmykarily mentioned this issue Jun 12, 2023

✨ Identify lvm partitions for state kairos-io/kairos-sdk#28

Merged

jimmykarily added the ARM label Jun 12, 2023

jimmykarily self-assigned this Jun 12, 2023

This was referenced Jun 14, 2023

List LVM partitions properly to allow detection of recovery on arm kairos-io/kairos-agent#60

Merged

📢 Kairos release v2.3.0 #1066

Closed

jimmykarily closed this as completed in kairos-io/kairos-agent#60 Jun 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

🐛 Reset doesnt work on rpi #1486

🐛 Reset doesnt work on rpi #1486

Itxaka commented Jun 7, 2023

jimmykarily commented Jun 12, 2023

jimmykarily commented Jun 12, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

🐛 Reset doesnt work on rpi #1486

🐛 Reset doesnt work on rpi #1486

Comments

Itxaka commented Jun 7, 2023

jimmykarily commented Jun 12, 2023

jimmykarily commented Jun 12, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023

Itxaka commented Jun 13, 2023

jimmykarily commented Jun 13, 2023