Remove existing rauc.db from a data disk on the first boot #3737
Conversation
If data disk is adopted on Yellow using the mechanism added in #3686, it contains RAUC version information that is very likely invalid. In such case, remove the file on first boot and have it recreated by the raucdb-update service.
📝 WalkthroughWalkthroughA new systemd service file named Changes
Sequence Diagram(s)sequenceDiagram
participant System
participant raucService as RAUC Service
participant raucdbFirstBoot as RAUC DB First Boot Service
participant raucdbUpdate as RAUC DB Update Service
System->>raucService: Start RAUC Service
raucService-->>System: Service Running
System->>raucdbFirstBoot: Start RAUC DB First Boot Service
raucdbFirstBoot-->>System: Check /mnt/data/rauc.db
alt File Exists
raucdbFirstBoot->>System: Remove /mnt/data/rauc.db
end
System->>raucdbUpdate: Start RAUC DB Update Service
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service (2)
1-8: Consider adding additional conditions for robustnessThe unit configuration looks good, but consider adding these conditions for extra safety:
ConditionPathIsMountPoint=/mnt/data- Explicitly verify the mount point is activeOnFailure=emergency.target- Handle critical failures appropriately[Unit] Description=Remove adopted rauc.db on first boot After=rauc.service Before=raucdb-update.service RequiresMountsFor=/mnt/data ConditionFirstBoot=yes ConditionFileNotEmpty=/mnt/data/rauc.db +ConditionPathIsMountPoint=/mnt/data +OnFailure=emergency.target
9-11: Enhance service configuration with status tracking and loggingConsider adding these improvements to the service configuration:
RemainAfterExit=yes- Helps track service completion status- Logging to capture operation result
[Service] Type=oneshot -ExecStart=/bin/rm -f /mnt/data/rauc.db +RemainAfterExit=yes +ExecStart=/bin/sh -c 'rm -f /mnt/data/rauc.db && echo "Successfully removed rauc.db" || echo "Failed to remove rauc.db"'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service(1 hunks)
🔇 Additional comments (2)
buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service (2)
13-14: Installation target looks good
The multi-user.target is appropriate for this system service.
1-14: Verify service integration in the build system
The service implementation looks correct, but let's verify its integration:
- Ensure the service is properly enabled in the build system
- Check for any conflicting services
✅ Verification successful
Service integration looks correct with proper sequencing
The service implementation and integration appear to be well-designed:
raucdb-first-boot.serviceruns afterrauc.serviceand beforeraucdb-update.serviceraucdb-update.servicehandles the subsequent database updates- Both services have proper mount requirements and target dependencies
- No conflicting services found, the two services work together in sequence
The service ordering ensures that:
- On first boot,
raucdb-first-boot.serviceremoves the existing database - Then
raucdb-update.servicecreates a fresh database with version information
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if service is enabled in build system and look for potential conflicts
# Look for service enablement in build files
rg -l "raucdb-first-boot.service" buildroot-external/
# Check for other services that might interact with rauc.db
rg -l "rauc.db" buildroot-external/rootfs-overlay/usr/lib/systemd/system/
Length of output: 289
Script:
#!/bin/bash
# Let's check the content of raucdb-update.service to understand the interaction
cat buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-update.service
# Check if these services are enabled in any package configurations
rg -l "enable.*raucdb" buildroot-external/package/
Length of output: 379
| @@ -0,0 +1,14 @@ | |||
| [Unit] | |||
| Description=Remove adopted rauc.db on first boot | |||
| After=rauc.service | |||
There was a problem hiding this comment.
Why is this actually After? I see that this is the case for raucdb-update.service as well, but I am wondering? 🤔
If data disk is adopted on Yellow using the mechanism added in #3686, it contains RAUC version information that is very likely invalid. In such case, remove the file on first boot and have it recreated by the raucdb-update service.
Summary by CodeRabbit
New Features
Bug Fixes