Skip to main content
correction of partition name
Source Link
epposan
  • 139
  • 6

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

In my case, I worked around the issue by not using the UUID's as partition identifiers, but instead using the partition names (/dev/mmcblk0p1 and /dev/mmcblkp2mmcblk0p2) as identifiers in /etc/fstab and /boot/cmdline.txt

It would also have been also possible to simply change the UUID's of the cloned SD card. Note however, that the UUID's to be used as identifiers are the partition UUID's, which can be displayed using: lsblk -o name,partuuid

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

In my case, I worked around the issue by not using the UUID's as partition identifiers, but instead using the partition names (/dev/mmcblk0p1 and /dev/mmcblkp2) as identifiers in /etc/fstab and /boot/cmdline.txt

It would also have been also possible to simply change the UUID's of the cloned SD card. Note however, that the UUID's to be used as identifiers are the partition UUID's, which can be displayed using: lsblk -o name,partuuid

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

In my case, I worked around the issue by not using the UUID's as partition identifiers, but instead using the partition names (/dev/mmcblk0p1 and /dev/mmcblk0p2) as identifiers in /etc/fstab and /boot/cmdline.txt

It would also have been also possible to simply change the UUID's of the cloned SD card. Note however, that the UUID's to be used as identifiers are the partition UUID's, which can be displayed using: lsblk -o name,partuuid

Added information on how the issue was solved in my particular case.
Source Link
epposan
  • 139
  • 6

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

In my case, I worked around the issue by not using the UUID's as partition identifiers, but instead using the partition names (/dev/mmcblk0p1 and /dev/mmcblkp2) as identifiers in /etc/fstab and /boot/cmdline.txt

It would also have been also possible to simply change the UUID's of the cloned SD card. Note however, that the UUID's to be used as identifiers are the partition UUID's, which can be displayed using: lsblk -o name,partuuid

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?

In my case, I worked around the issue by not using the UUID's as partition identifiers, but instead using the partition names (/dev/mmcblk0p1 and /dev/mmcblkp2) as identifiers in /etc/fstab and /boot/cmdline.txt

It would also have been also possible to simply change the UUID's of the cloned SD card. Note however, that the UUID's to be used as identifiers are the partition UUID's, which can be displayed using: lsblk -o name,partuuid

Source Link
epposan
  • 139
  • 6

Although not a direct answer to this question, this problem has been solved and the answer may help other users having problems with kernel and/or bootloader upgrades.

In this specific case, the problem was caused by an additional USB card reader inserted into one of the free USB ports of the remote Pi, containing a 'perfect' clone of the master SD card from which the Pi boots.

Being a 'perfect' clone, the UUID's of the partitions on the master SD card and the partitions on the cloned SD card were identical. This 'confused' the boot process, which, after booting from the master SD card, mounted the boot partition of the cloned SD card on /boot, while the root partition of the master SD card was mounted on '/'.

During an upgrade of raspberrypi-kernel and bootloader, the boot partition on the cloned SD card would get updated instead of the boot partition of the master SD card.

For more information see: How does the pi select the device to boot from?