-
-
Notifications
You must be signed in to change notification settings - Fork 199
Create_boot_multiple_kernel.md #795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mrobinson-opi
wants to merge
3
commits into
armbian:main
Choose a base branch
from
mrobinson-opi:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,90 @@ | ||
| # Using Multiple Kernels on SBC with Armbian via SD Cards | ||
|
|
||
| A common and effective way to use multiple kernels on a single-board computer (SBC) running Armbian is to use separate SD cards. This method is especially useful for testing new kernels, different versions of a kernel, or different Linux distributions without risking your primary, stable system. It also simplifies the process by leveraging the standard SBC boot sequence, which typically checks for a bootable SD card first. | ||
|
|
||
| This tutorial will walk you through the process of setting up multiple SD cards with different Armbian kernels. | ||
|
|
||
| --- | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| Before you begin, you'll need a few things: | ||
|
|
||
| - **Your SBC**: A compatible single-board computer (e.g., Orange Pi, Rock Pi, Odroid). | ||
| - **Multiple SD cards**: One for each kernel or system you want to run. Use reliable, high-speed cards from a reputable brand. | ||
| - **A computer** to write the images to the SD cards. | ||
| - **A reliable power supply** for your SBC. | ||
| - **Armbian images**: The specific Armbian images for your board, each with the desired kernel version (`current`, `edge`, or `legacy`). You can download these from the [official Armbian website](https://www.armbian.com/download/). | ||
|
|
||
| --- | ||
|
|
||
| ## Step 1: Prepare the SD Cards 💾 | ||
|
|
||
| Each SD card must be flashed with a different Armbian image. | ||
|
|
||
| 1. **Download the Images** | ||
| Go to the official Armbian download page and find the images for your specific SBC model. | ||
| Example: one with the `current` kernel and another with the `edge` kernel. | ||
|
|
||
| 2. **Flash the SD Cards** | ||
| Use a flashing tool like **BalenaEtcher** or the `dd` command-line utility. | ||
|
|
||
| ### Using BalenaEtcher | ||
| - Insert an SD card into your computer. | ||
| - Open Etcher, select the downloaded Armbian image file. | ||
| - Select your SD card from the list of drives. | ||
| - Click **Flash!** to start the process. | ||
| - Repeat for each SD card and image. | ||
|
|
||
| ### Using `dd` (Linux/macOS users) | ||
| - Unzip the Armbian image file (`.xz`). | ||
| - Identify your SD card's device name with `lsblk` or `diskutil list`. | ||
| - Run: | ||
| ```bash | ||
| sudo dd if=/path/to/armbian-image.img of=/dev/sdX bs=1M status=progress && sync | ||
| ``` | ||
| Replace `/path/to/armbian-image.img` and `/dev/sdX` with the correct path and device name. | ||
| - **Be extremely careful** to select the right device to avoid data loss. | ||
|
|
||
| --- | ||
|
|
||
| ## Step 2: Initial Boot and Configuration ⚙️ | ||
|
|
||
| After flashing, each SD card is a self-contained, bootable system. | ||
|
|
||
| 1. **Insert and Boot** | ||
| Insert one SD card into your SBC and connect power. The SBC’s bootloader (usually U-Boot) will detect and boot from it. | ||
|
|
||
| 2. **Initial Setup** | ||
| On first boot, Armbian will: | ||
| - Resize the filesystem | ||
| - Prompt for a root password | ||
| - Prompt to create a new user | ||
|
|
||
| Complete these steps for each SD card. | ||
|
|
||
| 3. **Shut Down and Swap** | ||
| - Power down the SBC. | ||
| - Remove the first SD card. | ||
| - Insert the second SD card. | ||
| - Repeat the boot and setup process. | ||
|
|
||
| --- | ||
|
|
||
| ## Step 3: Managing and Using Different Kernels 🧑💻 | ||
|
|
||
| Now you have multiple independent systems on separate SD cards. | ||
|
|
||
| - **Swapping SD Cards** | ||
| To switch kernels, power down, swap SD cards, and power back up. The bootloader handles everything automatically. | ||
|
|
||
| - **Testing and Development** | ||
| - Use one SD card for a stable, “production” kernel. | ||
| - Use another for experimental or development kernels. | ||
| - If something fails, swap back to your stable card instantly. | ||
|
|
||
| - **Kernel Version Management** | ||
| While Armbian’s `armbian-config` tool allows kernel management inside a single installation, using separate SD cards gives **full isolation**. | ||
| This prevents conflicts between kernel versions and ensures a clean test environment. | ||
|
|
||
| --- | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix dd instructions for macOS compatibility; split Linux/macOS with correct flags and steps
The current dd example won’t work on macOS (BSD dd doesn’t support status=progress and typically uses bs=1m; device is /dev/rdiskN). Also, “Unzip” is inaccurate for .xz images—use “decompress”. Propose a precise, safe rewrite.
🧰 Tools
🪛 LanguageTool
[style] ~47-~47: As an alternative to the over-used intensifier ‘extremely’, consider replacing this phrase.
Context: ...rrect path and device name. - Be extremely careful to select the right device to avoid d...
(EN_WEAK_ADJECTIVE)
🪛 markdownlint-cli2 (0.17.2)
39-39: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
43-43: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
45-45: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leggewie Thank you for confirming! The suggested changes will help make the dd instructions much more accurate and usable for both Linux and macOS users. The split approach with platform-specific commands, proper device naming conventions, and the correction about decompressing .xz files (rather than "unzipping") will definitely improve the documentation quality.
/_________\
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!