You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
KiroCrew pack EBS volume attached but not mounted or mapped. #105
in KiroCrew pack, the EBS attached volume is attached but not mounted. shoud also be auto-mounted and mapped so that the agent /home/ec2-user/workplace is mapped there so we have more space
11:28 concluded root cause — packs/kirocrew/manifest.yaml and packs/registry.yaml declare data_volume_gb: 0, so deploy/bootstrap.sh skips the EBS mount; its only data bind mount is the OpenClaw-specific .openclaw path, with no KiroCrew agent workspace mapping
11:28 confirmed the attached-but-unused path — CloudFormation can attach data device when DataVolumeSize is nonzero, while bootstrap still follows the KiroCrew registry value and logs that no data volume was requested
11:28 next — update the KiroCrew data-volume metadata, regenerate the derived registry, add the KiroCrew workplace bind mount, and add regression coverage before opening the same PR
11:32 opened PR #107 from b63df9a; the PR includes Fixes #105, the EBS-backed workplace mount, service write access, and the regression test
11:40 addressed the P1 review finding in 72fb265: the dependent workplace bind mount is non-fatal when the persistent data mount is unavailable, remains ordered after it, and legacy fstab state is migrated safely; focused validation passed
11:41 post-push reconciliation — all current check-run entries pass; the PR is mergeable and clean, with no new review or requester activity; legacy status API has zero contexts and remains pending, so the PR stays open for human review/merge
Activity
royosherove commentedon Aug 26, 2026
👻 Bode is on this · Kiro Crew Issue Radar
awaiting-merge · PR #107 · updated 14:07 UTC
progress
11:28claimed — issue KiroCrew pack EBS volume attached but not mounted or mapped. #105 is a targeted pack/bootstrap bug, not a duplicate; existing KiroCrew history covers other installer concerns and no prior EBS/workplace fix11:28concluded root cause —packs/kirocrew/manifest.yamlandpacks/registry.yamldeclaredata_volume_gb: 0, sodeploy/bootstrap.shskips the EBS mount; its only data bind mount is the OpenClaw-specific.openclawpath, with no KiroCrewagent workspacemapping11:28confirmed the attached-but-unused path — CloudFormation can attachdata devicewhenDataVolumeSizeis nonzero, while bootstrap still follows the KiroCrew registry value and logs that no data volume was requested11:28next — update the KiroCrew data-volume metadata, regenerate the derived registry, add the KiroCrew workplace bind mount, and add regression coverage before opening the same PR11:32opened PR #107 fromb63df9a; the PR includesFixes #105, the EBS-backed workplace mount, service write access, and the regression test11:40addressed the P1 review finding in72fb265: the dependent workplace bind mount is non-fatal when the persistent data mount is unavailable, remains ordered after it, and legacy fstab state is migrated safely; focused validation passed11:41post-push reconciliation — all current check-run entries pass; the PR is mergeable and clean, with no new review or requester activity; legacy status API has zero contexts and remains pending, so the PR stays open for human review/merge14:07handed issue KiroCrew pack EBS volume attached but not mounted or mapped. #105 to human review — the permittedcrew: needs humanlabel is now applied; PR fix(kirocrew): mount EBS-backed workspace #107 remains open and unmerged with all check-run entries passing