Your message dated Fri, 26 Sep 2025 21:11:05 +0200
with message-id <[email protected]>
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 [email protected]
immediately.)
--
1116125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116125
Debian Bug Tracking System
Contact [email protected] 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 ---
