Lerking/rpi-clone
1
0
Fork 0
Code Issues 129 Pull Requests 10 Packages Projects Releases Wiki Activity

Which command to see what device is booted from? #129

New Issue
Open
opened 2021-11-15 09:04:03 +01:00 by Barabba11 · 7 comments
Barabba11 commented 2021-11-15 09:04:03 +01:00 (Migrated from github.com)
Copy Link

Hi, I've cloned to USB and rebooted, the SD still inserted, now how can I determine from which device has booted? There is any command "sudo rpi-clone -check" that may tell me the situation? Thanks
I've opened cmdline.txt but there is nothing interesting there, only "root=PARTUUID=b6b3f6b9-02" but what it is I don't know

Hi, I've cloned to USB and rebooted, the SD still inserted, now how can I determine from which device has booted? There is any command "sudo rpi-clone -check" that may tell me the situation? Thanks I've opened cmdline.txt but there is nothing interesting there, only "root=PARTUUID=b6b3f6b9-02" but what it is I don't know
framps commented 2021-11-15 09:11:26 +01:00 (Migrated from github.com)
Copy Link

Use mountand blkid

Use `mount`and `blkid`
Barabba11 commented 2021-11-15 11:26:05 +01:00 (Migrated from github.com)
Copy Link

Use mountand bklid

thanks, may you please write me step by step ech command to type? sorry I'm not really expert here

> > > Use `mount`and `bklid` thanks, may you please write me step by step ech command to type? sorry I'm not really expert here
framps commented 2021-11-15 12:14:03 +01:00 (Migrated from github.com)
Copy Link

With mount you detect which partitions are used for /boot and / (rootfs). With blkd you get the UUIDs used by these partitions.

Example I executed on one of my Raspberries:

pi@idefix:~ $ mount | grep -E " (/|/boot) "
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
pi@idefix:~ $ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="e181e42f-01"
/dev/mmcblk0p2: UUID="50a65405-e5a5-40eb-9fbf-254b09eb432c" TYPE="ext4" PARTUUID="e181e42f-02"

Example of a PXE booted Raspberry:

pi@raspberrypi-buster-pxe-1:~ $ mount | grep -E " (/|/boot) "
192.168.0.9:/volume1/pxe_nfs/87f728f5 on / type nfs (rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.0.9)
192.168.0.9:/volume1/pxe_tftp/87f728f5 on /boot type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.0.9)
pi@raspberrypi-buster-pxe-1:~ $ blkid
With mount you detect which partitions are used for `/boot` and `/` (rootfs). With `blkd` you get the UUIDs used by these partitions. Example I executed on one of my Raspberries: ``` pi@idefix:~ $ mount | grep -E " (/|/boot) " /dev/mmcblk0p2 on / type ext4 (rw,noatime) /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) pi@idefix:~ $ blkid /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="e181e42f-01" /dev/mmcblk0p2: UUID="50a65405-e5a5-40eb-9fbf-254b09eb432c" TYPE="ext4" PARTUUID="e181e42f-02" ``` Example of a PXE booted Raspberry: ``` pi@raspberrypi-buster-pxe-1:~ $ mount | grep -E " (/|/boot) " 192.168.0.9:/volume1/pxe_nfs/87f728f5 on / type nfs (rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.0.9) 192.168.0.9:/volume1/pxe_tftp/87f728f5 on /boot type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.0.9) pi@raspberrypi-buster-pxe-1:~ $ blkid ```
Barabba11 commented 2021-11-22 11:30:21 +01:00 (Migrated from github.com)
Copy Link

thank you for your kind answer :)
May I also ask, how exacly rpi-clone works? For example:
I have cloned with "sudo rpi-clone -f -v sda"

  1. the Pi bios will always boot as SD first priority drive, if nothing is found on SD slot then it tries to boot fromt he first USB device recognized.
  2. if there is an SD, then it checks some files in it, and if there is written to boot from USB it will boot from USB, SD will be mounted then into /media/pi
  3. if in SD it's written to boot from USB but USB is not present, the system will keep boot from SD..

This is helpful to understand how I can quickly manage a failure with a backup. Thank you!

EDIT: reading back instructions I think here is the trick, but sorry I can't understand it well, maybe better rewriting it in a more clear way.
-l - leave SD card to USB boot alone when cloning to SD card mmcblk0
from a USB boot. This preserves a SD card to USB boot setup
by leaving the SD card cmdline.txt using the USB root. When
cloning to USB from SD card this option sets up the SD card
cmdline.txt to boot to the USB disk.

so if I?m cloning from SD to USB and I use -l the next reboot will use the boot partition of SD, but the rootfs partition od USB. Will the SD rootfs be mounted too?
From USB to SD, it keeps as well the rootfs of USB.
Now if I want to change just the boot method, should I do a full clone or there is a quicker way to set only boot flags?
And, as before, if for example I set the USB for rootfs but it is not present, they system will not boot?

thank you for your kind answer :) May I also ask, how exacly rpi-clone works? For example: I have cloned with "sudo rpi-clone -f -v sda" 1) the Pi bios will always boot as SD first priority drive, if nothing is found on SD slot then it tries to boot fromt he first USB device recognized. 2) if there is an SD, then it checks some files in it, and if there is written to boot from USB it will boot from USB, SD will be mounted then into /media/pi 3) if in SD it's written to boot from USB but USB is not present, the system will keep boot from SD.. This is helpful to understand how I can quickly manage a failure with a backup. Thank you! EDIT: reading back instructions I think here is the trick, but sorry I can't understand it well, maybe better rewriting it in a more clear way. -l - leave SD card to USB boot alone when cloning to SD card mmcblk0 from a USB boot. This preserves a SD card to USB boot setup by leaving the SD card cmdline.txt using the USB root. When cloning to USB from SD card this option sets up the SD card cmdline.txt to boot to the USB disk. so if I?m cloning from SD to USB and I use -l the next reboot will use the boot partition of SD, but the rootfs partition od USB. Will the SD rootfs be mounted too? From USB to SD, it keeps as well the rootfs of USB. Now if I want to change just the boot method, should I do a full clone or there is a quicker way to set only boot flags? And, as before, if for example I set the USB for rootfs but it is not present, they system will not boot?
framps commented 2021-11-22 19:25:00 +01:00 (Migrated from github.com)
Copy Link

how exacly rpi-clone works?

I haven't checked the code in detail. I wrote my own backup tool.

> how exacly rpi-clone works? I haven't checked the code in detail. I wrote my own backup tool.
Barabba11 commented 2021-11-22 22:36:30 +01:00 (Migrated from github.com)
Copy Link

I've checked myself, to be honest the author explained it, but maybe too deep )) I mean, there are too many concepts and words, and it's easy to get in trouble/don't be sure. In this care are better the examples in my opinion, what I understood is:

the parameter -l will always set the boot to USB, to do that, as the Pi always will use SD (if present) as the first boot device, it's needed to change the boot on SD to tell the raspbian to jump suddenly on USB. That means the USB will always work as boot device, even if the SD is extracted, as a second valid priority boot device, but to make the SD boot on itself again it's needed to change back its boot.
Luckly the author made it really easy, just rename the original cmdline.txt.boot to cmdline.txt, (backup the existing one to cmdline.txt.usb if you want to boot again from usb in future).
As the author used PARTUUID to identify the boot device, and as the PARTUUID changes for every device (it's like a serial number) I suppose the system will be bootable with only that USB, if the SD card will still inserted (remove it then, to use another USB, ot repeat the clone to a new USB again with -l)

I've checked myself, to be honest the author explained it, but maybe too deep )) I mean, there are too many concepts and words, and it's easy to get in trouble/don't be sure. In this care are better the examples in my opinion, what I understood is: the parameter -l will always set the boot to USB, to do that, as the Pi always will use SD (if present) as the first boot device, it's needed to change the boot on SD to tell the raspbian to jump suddenly on USB. That means the USB will always work as boot device, even if the SD is extracted, as a second valid priority boot device, but to make the SD boot on itself again it's needed to change back its boot. Luckly the author made it really easy, just rename the original cmdline.txt.boot to cmdline.txt, (backup the existing one to cmdline.txt.usb if you want to boot again from usb in future). As the author used PARTUUID to identify the boot device, and as the PARTUUID changes for every device (it's like a serial number) I suppose the system will be bootable with only that USB, if the SD card will still inserted (remove it then, to use another USB, ot repeat the clone to a new USB again with -l)
geerlingguy commented 2022-01-21 00:14:36 +01:00 (Migrated from github.com)
Copy Link

To check which device is used for boot, I typically run lsblk, which if I have a USB drive plugged in but am booting off microSD or eMMC looks like:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 232.9G  0 disk 
mmcblk0     179:0    0 119.1G  0 disk 
├─mmcblk0p1 179:1    0   256M  0 part /boot
└─mmcblk0p2 179:2    0 118.8G  0 part /

Typically the MOUNTPOINT is / and /boot for the two partitions the boot device is using (in this case mmcblk0).

After I used rpi-clone to clone to sda, shut down, pulled out the microSD card, and rebooted, I saw:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 232.9G  0 disk 
├─sda1   8:1    0   256M  0 part /boot
└─sda2   8:2    0 232.6G  0 part /
To check which device is used for boot, I typically run `lsblk`, which if I have a USB drive plugged in but am booting off microSD or eMMC looks like: ``` $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 232.9G 0 disk mmcblk0 179:0 0 119.1G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 118.8G 0 part / ``` Typically the `MOUNTPOINT` is `/` and `/boot` for the two partitions the boot device is using (in this case `mmcblk0`). After I used rpi-clone to clone to `sda`, shut down, pulled out the microSD card, and rebooted, I saw: ``` $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 232.9G 0 disk ├─sda1 8:1 0 256M 0 part /boot └─sda2 8:2 0 232.6G 0 part / ```
👍 2
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
invalid
question
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Lerking
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Lerking/rpi-clone#129
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?