Bug#1116125: marked as done (linux-image-amd64: system booted into emergency mode after upgrade to 6.12.48)
Your message dated Fri, 26 Sep 2025 21:11:05 +0200
with message-id <aNblSRkXe63UESSa@eldamar.lan>
and subject line Re: Bug#1116125: linux-image-amd64: system booted into emergency mode after upgrade to 6.12.48
has caused the Debian Bug report #1116125,
regarding linux-image-amd64: system booted into emergency mode after upgrade to 6.12.48
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
1116125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116125
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-amd64
Version: 6.12.48-1
Severity: normal
Upgraded the kernel from linux-image-6.12.43+deb13-amd64 to linux-image-6.12.48+deb13-amd64 via apt.
On reboot into the new kernel, system was unreachable via SSH. Upon checking the console, the system entered emergency mode awaiting password to enter the emergency shell. Rebooting did not clear the fault.
Upon checking further, the system could not mount two file systems, /boot and /boot/efi, which are both stored on onboard eMMC. All other FS are stored on various other disks. When logged into the emergency shell, I verified that device nodes /dev/mmcblk* did not exist hence the above from /etc/fstab could not be mounted. Multiple reboots into the new kernel could not clear the fault.
I booted into the old kernel 6.12.43 and the system booted normally. All filesystems mounted as expected.
I then booted into the new kernel 6.12.48 again and the system booted normally. Unable to reproduce after this point.
I initially suspected hardware failure but this made no sense, as the eMMC disk it was unable to detect contained the bootloader, kernel, and initrd it was successfully running from to partially boot. So GRUB could see it just fine, but the kernel could not.
Relevant dmesg:
[ 1.530670] mmc1: SDHCI controller on PCI [0000:00:1c.0] using ADMA 64-bit
[ 1.533312] mmc0: SDHCI controller on PCI [0000:00:1b.0] using ADMA 64-bit
[ 1.677950] mmc1: new DDR MMC card at address 0001
[ 1.695380] mmcblk1: mmc1:0001 004GA0 3.69 GiB
[ 1.698606] mmcblk1: p1 p2
[ 1.699469] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB
[ 1.700699] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB
[ 1.701879] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (244:0)
[ 8.356788] systemd[1]: Expecting device dev-mmcblk1p2.device - /dev/mmcblk1p2...
[ 9.875619] EXT4-fs (mmcblk1p2): mounting ext2 file system using the ext4 subsystem
Relevant lspci:
00:1b.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SDXC/MMC Host Controller (rev 0b)
00:1c.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series eMMC Controller (rev 0b)
--- End Message ---
--- Begin Message ---
Hi Lloyd,
On Thu, Sep 25, 2025 at 11:35:05PM +0000, Lloyd wrote:
> Salvatore Bonaccorso wrote:
>
> > As I understand you are not able to reproduce anymore the problem.
> > Before we though close the bug, can you report back if it makes a
> > difference if you do a cold boot of 6.12.48 or a reboot from
> > 6.12.43-1?
> >
> > I.e. please test both variants rebooting from 6.12.43-1 to 6.12.48-1
> > and then a cold boot into 6.12.48-1.
>
> Hi Sal - I tried multiple different ways and still am unable to
> reproduce. It only occurred in the reboot post-install of the new
> kernel, and subsequent 3-4 warm reboots into the new kernel.
>
> Once I booted the old kernel once (warm reboot), subsequent boots
> into either kernel (cold & warm) have not presented any issues.
>
> The only other detail I could recall was running 'apt autoremove'
> before the initial reboot to perform cleanup as 4 installed kernels
> were present.
>
> Unfortunately I did not think to check for lsmod of mmc_core during
> the event, to understand why /dev/mmc* device nodes were missing.
Thanks for reporting back, in this case I will close now the bug.
*But* if you manage to re-trigger it, then please do reopen it,
providing the fresh information so we can have another look.
Regards,
Salvatore
--- End Message ---
Reply to: