mtd device must be supplied (device name is empty)

Status changed to 'Confirmed' because the bug affects multiple users.

I started seeing this recently also in 22.04. However, my system is using UEFI.

we have the same issue on all our systems with 22.04 and completely different hardware

fred@z690-jammy:~$ sudo dmesg | grep mtd
[sudo] password for fred:
[ 2.761808] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 2.769635] mtd device must be supplied (device name is empty)

running Jammy 22.04 on z690 system.
system does boot after error.

Same message as "oldfred", but using Ubuntu Kinetic Kudu (development branch)

Same message as others. This is on kinetic (VM), and two jammy (hardware) installs. One of the jammy versions boots via coreboot, not UEFI.

All are booting normally after the error.

Same message
I'm on a very old Celeron/Conroe/i945 desktop machine without UEFI
running Xubuntu 22.04

Same problem here on 22.04 z370 system, however it is also preventing my from booting into the system. It definitely has something to do with a recent update. I just tried a fresh install and after rebooting from updates, I saw the error. I'm on a SSD and running UEFI, which based on Google results, seems to be more commonly associated with those that are unable to get past the boot sequence.

Hi,

This is in fact caused by the recent systemd SRU, which includes a patch to systemd-pstore.service [1]. The issue appears to be quite benign, but if anyone has experienced side effects as a result of this change (besides the dmesg error), please let us know.

In the mean time, you can work around this issue:

EDIT: This will NOT fix any system that is not booting, because the "mtd device must be supplied (device name is empty)" message is not the cause of failed boots. This work around is only for those who are annoyed by the error message, but are otherwise not experiencing any issues.

# cp /{lib,etc}/systemd/system/systemd-pstore.service
# sed -i '<email address hidden> //' /etc/systemd/system/systemd-pstore.service
# systemctl daemon-reload

[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-jammy&id=d990b13612810a296246011ad66a165b30166702

I wouldn't describe it as benign. If you do some searching, you'll see that many aren't able to get past the boot sequence at all due to this error.

Are you referring to https://ubuntuforums.org/showthread.php?t=2476796? If not, please share the links you are referring to.

It seems unlikely to me that failing to load `mtdpstore` is the problem preventing boot. Note that systemd-pstore.service only starts if `/sys/fs/pstore` is not empty, i.e. after a kernel crash. This leads me to believe something else is causing the boot failure.

buswedg - Are you able to provide any logs (journalctl, dmesg) from your affected system?

Yes, that thread is how I found my way here.

Also see -
https://askubuntu.com/questions/1417618/mtd-device-must-be-supplied-device-name-is-empty
"I tried installing it on a WD SSD and it jiust failed to boot."

And there was another thread I believe on reddit, which indicated something similar for a 22.04 install on a SSD.

logs - not right now unfortunately. Perhaps on the weekend I can do some exploring.

What exactly happens if I run these commands? Can you explain?

# cp /{lib,etc}/systemd/system/systemd-pstore.service
# sed -i '<email address hidden> //' /etc/systemd/system/systemd-pstore.service
# systemctl daemon-reload

Don't like work arounds. Like systems that works.

The workaround prevents systemd-pstore.service from trying to load the mtdpstore module, but it will still try to load several others which should allow systemd-pstore to function normally.

If you have not experienced any adverse side effects, you can also safely ignore the log message.

Hi, i'm getting same message with Ubuntu 22.04 fresh install but only at a new Thinkpad T14 (AMD 7pro, SSD M.2) with dual boot.
Also i can not suspend SO because when wake up crash with message:

EXT4-fs error (device nvme0n1p6): __ext4_find_entry:1612: inode #170139: comm gmain: reading directory lblock 0

and

systemd-journald[403]: Failed to write entry (9 items, 326 bytes), ignoring: Read-only file system

Just a blackscreen with this messages over and over. So the only option i have is to force power-off.

With the old Thinkpad T430 (I5, SSD) Ubuntu 22.04 upgraded from 20.04 everything it's fine.

I faced exactly the same problem. I tried all the options mentioned here, but without success.
As the error started after editing HDD prtitions (to adjust name and mount point),
so I decided to check the partition table and found that there was inconsistency in the partitions edited by me. I solved the problem by editing and fixing directly in /etc/fstab via emergency mode.

I Have the same issue but the diffrence is that my device wont boot after getting this eror message
Ps:im using kubuntu on a 4460 core i5 cpu and nvidia proprietary drivers

Same message here on « regular » Ubuntu 22.04 installed in legacy mode on an UEFI capable bios.

No nvme/M2 here - system on SSD + data on HDD.

See attached file for dmesg it's line 941 at [ 6.780126]

Wonder if « failed » messages regarding sdb later at lines 980 and following [ 35.056956] are anyhow related ?

 Same “issue” here, system boots as expected and seem to work just fine, but might taque a second or two more time to boot since y notice the error, but not sure.
I have ‘vanilla’ 22.04 with 5.15.0-41-generic kernel.
Worth mention that besides the M2 nvme ssd from wich I boot and / is, I also have 2 wd hdd's in linux raid 0 so there is a /dev/md device.

$ ls /dev/md*
/dev/md0 /dev/md0p1
/dev/md:
0 0p1

Relevan mount output lines:

$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=14299692k,nr_inodes=3574923,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=2866956k,mode=755,inode64)
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17979)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=2866952k,nr_inodes=716738,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,noexec,relatime,size=2866956k,mode=755,inode64)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/md0p1 on /mnt/cipher type ext4 (rw,nosuid,nodev,relatime,stripe=256)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=2866952k,nr_inodes=716738,mode=700,uid=1000,gid=1000,inode64)

The error mesage:

$ sudo dmesg | grep mtd
[ 3.248501] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 3.258680] mtd device must be supplied (device name is empty)

@Nick Rosbrook (enr0n): Your suggestion (https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1981622/comments/10) doesn't work on Kubuntu 22.04 fresh install, fully patched, probably because <email address hidden> doesn't appear in the file. I have tried commenting out everything that isn't a descriptor but sadly I still can't boot.

Richard - I edited my above comment to clarify. That workaround is not an attempt to fix boot on any systems.

To anyone that is experiencing boot issues, please open a separate bug with your journal logs and dmesg logs. The "mtd device must be supplied (device name is empty)" error is not the cause of your boot issues, and should be ignored. The reason you all are seeing this error message is that `systemd-pstore.service` is trying to recover kernel crash data from `/sys/fs/pstore` *after* a kernel crash. It happens that the mtdpstore module cannot be loaded, but systemd-pstore.service (and the rest of the system) will happily move along without it.

my system just updated and upon restart was presented with the same mtd device must be supplied (device name is empty)" error. However it does not go away and does not allow me to continue to boot. if there is a workaround it would be great so i can get back onto the system or do we need to run from USB in the meantime?

Ubuntu 22.04 LTS was a two week old fresh install loaded on a SATA SSD, Optiplex 380 in Legacy Bios, if it makes a difference.

Update: i am at least able to boot from USB and get to my files.. sadly not too familiar with Linux as i just recently started diving into it so that is about as far as i can go other than backing everything up to another USB and starting fresh.

can't get past cp /{lib,etc}/systemd/system/systemd-pstore.service permission denied even though i entered my pw

is there a way to roll back the update? need my machine up and running please as i am sure others do as well.

Wtf...now i am getting DMAR:failed to map dmar0... fantastic.

Is there a version of Ubuntu that does not follow the Microsoft update standard of breaking after updates?

Jamie - yes, Debian

Thank you buswedg, not sure how, but i managed to somehow reinstall and repair my installation. All my files are intact but it's now pulling down 334mb of updates so hopefully it doesn't break again, otherwise i will be making a beeline for Debian. And also need to figure out the DMAR error..

Edit: so now after the update DMAR:failed to map dmar0 is still showing as well as three flashes of the error device name is empty again, however this time it completes booting...

Ditto-
Boots just fine but barks about mtd device must be supplied (device name is empty).

OS: Ubuntu 22.04 LTS x86_64
Host: Dell OptiPlex 9020 00
Kernel: 5.15.0-41-generic
CPU: Intel i5-4570S (4) @ 3.600GHz
GPU: Intel HD Graphics
Memory: 7859MiB

Having this problem as well, I was able to boot into my system when I choose the "5.15.0-25-generic" kernel, the one that breaks for me is "5.15.0-41-generic"

Status changed to 'Confirmed' because the bug affects multiple users.

I have this problem message on both a laptop and desktop with old spinning disks, not SSDs but both boot to a fully working OS of Xubuntu 22.04. Both machines also have fully updated Focal 20.04 versions running,neither of which display the message.

When I was first aware of this on my laptop I did not see it on the desktop though that had not been updated for several days. After updating the desktop machine which included several systemd packages I immediately started to see this on the desktop machine as well as the laptop perhaps pointing to a link with the systemd packages?

I have also tried a 22.10 install in KVM/QEMU virtual install and that also shows the message but also boots and runs well.

Some dmesg outputs from same machine running 20.04 and 22.04 :

########## 20.04 ##########

django@ASGARD:~$ dmesg | grep -Ei "ata4|sector|mtd"
[ 0.668757] ata4: SATA max UDMA/133 abar m2048@0xf7d1a000 port 0xf7d1a280 irq 29
[ 0.985537] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 0.986510] ata4.00: ATA-8: Hitachi HDS721010CLA332, JP4OA3MA, max UDMA/133
[ 0.986812] ata4.00: ATA Identify Device Log not supported
[ 0.986815] ata4.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 0.990241] ata4.00: ATA Identify Device Log not supported
[ 0.990245] ata4.00: configured for UDMA/133
[ 0.990254] ata3.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA

django@ASGARD:~$ dmesg | grep -Ei "erro|warn|fail"
[ 0.461495] RAS: Correctable Errors collector initialized.
[ 0.637675] ACPI Warning: SystemIO range 0x0000000000001828-0x000000000000182F conflicts with OpRegion 0x0000000000001800-0x000000000000187F (\PMIO) (20210730/utaddress-204)
[ 0.637701] ACPI Warning: SystemIO range 0x0000000000001C40-0x0000000000001C4F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20210730/utaddress-204)
[ 0.637717] ACPI Warning: SystemIO range 0x0000000000001C30-0x0000000000001C3F conflicts with OpRegion 0x0000000000001C00-0x0000000000001C3F (\GPRL) (20210730/utaddress-204)
[ 0.637723] ACPI Warning: SystemIO range 0x0000000000001C30-0x0000000000001C3F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20210730/utaddress-204)
[ 0.637741] ACPI Warning: SystemIO range 0x0000000000001C00-0x0000000000001C2F conflicts with OpRegion 0x0000000000001C00-0x0000000000001C3F (\GPRL) (20210730/utaddress-204)
[ 0.637746] ACPI Warning: SystemIO range 0x0000000000001C00-0x0000000000001C2F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20210730/utaddress-204)
[ 0.987186] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.988437] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT5._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.991691] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.994698] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT5._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 5.955272] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro. Quota mode: none.

########## 22.04 ##########

django@ASGARD:~$ sudo dmesg | grep -Ei "ata4|sector|mtd"
[sudo] Mot de passe de django :
[ 0.749555] ata4: SATA max UDMA/133 abar m2048@0xf7d1a000 port 0xf7d1a280 irq 29
[ 1.063160] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.064160] ata4.00: ATA-8: Hitachi HDS721010CLA332, JP4OA3MA, max UDMA/133
[ 1.064490] ata4.00: ATA Identify Device Log not supported
[ 1.064502] ata4.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
 [ 1.065584] ata3.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 1.065959] ata4.00: ATA Identify Device Log not supported
[ 1.065962] ata4.00: configured for UDMA/133
 [ 5.500484] systemd[1]: Starti...

Seems fixed in or not affecting other distributions :

https://ubuntuforums.org/showthread.php?t=2476796&page=3&p=14104102#post14104102

This bug was fixed in the package systemd - 251.2-2ubuntu2

---------------
systemd (251.2-2ubuntu2) kinetic; urgency=medium

  [ Lukas Märdian ]
  * Remove restart limit on the modprobe@.service (LP: #1982462)
    File: debian/patches/units-remove-the-restart-limit-on-the-modprobe-.service.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=46c36d4c73df8980f6b6137142fb16ba90465a94

  [ Nick Rosbrook ]
  * core,firstboot: workaround timezone issues on Ubuntu Core (LP: #1981042)
    Thanks to Robert Ancell for preparing the patch.
    File: debian/patches/lp1981042-core-firstboot-workaround-timezone-issues-caused-by-Ubunt.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9a435d43e753f39531c9a5517a85e8eb259e18f1
  * pstore: do not try to load mtdpstore (LP: #1981622)
    File: debian/patches/lp1978079-pstore-Run-after-modules-are-loaded.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=38d8d12be924477f0eecb64f3737e07b03d73a42

 -- Nick Rosbrook <email address hidden> Fri, 22 Jul 2022 15:23:45 -0400

I have the same issue on Ubuntu 22.04:

[ 4.528478] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 4.533051] mtd device must be supplied (device name is empty)
[ 4.833395] mtd device must be supplied (device name is empty)

Just received 22.4.1 updates and back to the same issue. 167.047420 MTD device name must be supplied (device name is empty) stuck at username prompt.

Managed to live boot from USB
/dev/sda1 biosgrub
/dev/sda2 EFI
/dev/sda3 ext4 Ubuntu 22.04.1 LTS

Paste.ubuntu.com/p/PfJv5t94q7

if a fix was released how is it broken again?

> if a fix was released how is it broken again?

The fix has not been released to 22.04 yet, it has only been fixed in the development release.

Oh thank you! Is there anyway i can apply the fix manually? Currently machine has been down for two days...

I am having the same problem and not able to boot.
If i remove my hdd entry from fstab than it boots without problem.
It looks like manual entry of hdd partition in fstab is preventing me from booting into Ubuntu 22.04.
Aldo when i edit fstab and remove entry it lets me boot in and hdd works without problem, so i do not know what is causing this problem.

I have applied the patch in
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=38d8d12be924477f0eecb64f3737e07b03d73a42
successfully to an x86_64 KVM/Qemu w/BIOS Ubuntu 22.04.1 system.

sudo cp /lib/systemd/system/systemd-pstore.service /etc/systemd/system/systemd-pstore.service
sudo emacs /etc/systemd/system/systemd-pstore.service
(remove <email address hidden> from two lines)

@sonicboom247 as for unbootable systems have you tried?
https://help.ubuntu.com/community/Boot-Repair

Just had this message on Ubuntu 22.04.1 (5.15.0-46-generic) - was unable to boot. Related or not, the suggesting to update /etc/fstab in the comments above got me able to boot again.

So it's been over a month now. The fix is out on the development branch. What's the timetable of getting it out on existing releases?

Anyone tell me how to fix it?
I'm new user using ubuntu

Hello pelm, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I have installed and tested the proposed package and my system is NOT booting up as before.

Ubuntu 22.04.1 LTS
systemd: 249.11-0ubuntu3.5
kernel: 5.15.0-47-generic (tested also on 5.15.0-25-generic with the same result)

I get into the maintenance mode, reboot into the recovery and try to fix things at this stage.

The bug seems to cause Maple's authentication to fail. It uses the host-id, which returns empty.

systemd 249.11-0ubuntu3.5 got rid of the error messages.

From the bug definition:
"This will NOT fix a system that is not booting, because the "mtd device must be supplied (device name is empty)" message is not the cause of failed boots."

Hi. I have same error.

---
:~$ sudo dmesg | grep mtd
[ 6.992949] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 7.028962] mtd device must be supplied (device name is empty)
[ 7.073396] systemd[1]: <email address hidden>: Deactivated successfully.
[ 7.076597] systemd[1]: Finished Load Kernel Module mtdpstore.
[ 8.719446] mtd device must be supplied (device name is empty)
[ 8.992816] mtd device must be supplied (device name is empty)
----

Hello pelm, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I have verified this fix using systemd 249.11-0ubuntu3.6 from jammy-proposed:

nr@six:~$ apt-cache policy systemd
systemd:
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     249.11-0ubuntu3.4 500
        500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     249.11-0ubuntu3 500
        500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
nr@six:~$ systemctl status systemd-pstore.service
● systemd-pstore.service - Platform Persistent Storage Archival
     Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2022-09-12 16:02:11 EDT; 1min 8s ago
       Docs: man:systemd-pstore(8)
    Process: 695 ExecStart=/lib/systemd/systemd-pstore (code=exited, status=0/SUCCESS)
   Main PID: 695 (code=exited, status=0/SUCCESS)
        CPU: 6ms

Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290109001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290109001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290108001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290108001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290107001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290107001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290106001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290106001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290105001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290105001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290104001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290104001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290103001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290103001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290102001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290102001
Sep 12 16:02:11 six systemd-pstore[695]: PStore dmesg-efi-166301290101001 moved to /var/lib/systemd/pstore/166301290/dmesg-efi-166301290101001
Sep 12 16:02:11 six systemd[1]: Finished Platform Persistent Storage Archival.
nr@six:~$ sudo dmesg | grep mtd
nr@six:~$

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.6) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

stunnel4/3:5.63-1build1 (amd64)
munin/2.0.57-1ubuntu2 (amd64)
corosync/unknown (s390x)
conntrack-tools/unknown (s390x)
exim4/4.95-4ubuntu2.1 (ppc64el)
umockdev/0.17.7-1 (armhf)
netplan.io/0.104-0ubuntu2.1 (amd64)
initramfs-tools/0.140ubuntu13 (amd64)
dovecot/unknown (s390x)
network-manager/1.36.6-0ubuntu2 (amd64)
cups/unknown (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

The autopkgtest regressions for systemd 249.11-0ubuntu3.6 in jammy-proposed were all resolved with retries.

This update didn't fix the issue on my Ubuntu 22.04. I still get error message mtd device must be supplied (device name is empty) during boot

Onuh - are you running with -proposed enabled? This update hasn't been released yet.

Yesterday during my upgrade from the terminal, systemd 249.11-0ubuntu3.6 was part of the installed update. I thought the fix was in systemd 249.11-0ubuntu3.6

Same here, recent upgrade message appears.

I don't see an upload for focal either in the unapproved queue or in proposed. Am I confused? resetting the status for focal to in progress in any case.

Onuh and David - Please share the output from the following commands:

$ apt-cache policy systemd
$ systemctl list-dependencies systemd-pstore.service
$ systemctl list-dependencies --reverse <email address hidden>
$ systemd-analyze unit-files systemd-pstore.service

Nick

#apt-cache policy systemd

systemd:
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://ci.archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     249.11-0ubuntu3.4 500
        500 http://ci.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     249.11-0ubuntu3 500
        500 http://ci.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

#systemctl list-dependencies systemd-pstore.service

systemd-pstore.service
● ├─-.mount
○ ├─modprobe@chromeos_pstore.service
○ ├─modprobe@efi_pstore.service
○ ├─<email address hidden>
○ ├─modprobe@pstore_blk.service
○ ├─modprobe@pstore_zone.service
○ ├─<email address hidden>
● └─system.slice

#systemctl list-dependencies --reverse <email address hidden>

<email address hidden>
○ └─systemd-pstore.service

#systemd-analyze unit-files systemd-pstore.service

ids: systemd-pstore.service → /etc/systemd/system/systemd-pstore.service
aliases: systemd-pstore.service ← systemd-pstore.service

Thanks, Onuh. It looks like you have overridden the systemd-pstore.service file with one in /etc/systemd/system/systemd-pstore.service, so the one shipped by the systemd package (/lib/systemd/system/systemd-pstore.service) is not being used. Please remove the one in /etc/, and run systemctl daemon-reload. That should resolve your problem.

Thanks Nick, the issue is now fixed.

This bug was fixed in the package systemd - 249.11-0ubuntu3.6

---------------
systemd (249.11-0ubuntu3.6) jammy; urgency=medium

  * Deny-list TEST-58-REPART on ppc64el (LP: #1988994)
    File: debian/patches/lp1988994-Deny-list-TEST-58-REPART-on-ppc64el.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=d2ed3cc1d223bf35015b15ff83b50156b58f0f38

systemd (249.11-0ubuntu3.5) jammy; urgency=medium

  [ Nick Rosbrook ]
  * Ensure dns_search_domain_unlink_marked removes all marked domains (LP: #1975667)
    File: debian/patches/lp1975667-Ensure-dns_search_domain_unlink_marked-removes-all-marked.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=919d5ddedd5bb8b45ab9437bf42d66c2821bb074
  * core,firstboot: workaround timezone issues on Ubuntu Core (LP: #1981042)
    Thanks to Robert Ancell for preparing the patch.
    File: debian/patches/lp1981042-core-firstboot-workaround-timezone-issues-caused-by-Ubunt.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b15546361b549217908fb6ca5d473be23d7fa757
  * network: do not remove localhost address (LP: #1979951)
    File: debian/patches/lp1979951-network-do-not-remove-localhost-address.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=2cd88391cce9fe95a486ae6dd214c12f236f3881
  * units: remove the restart limit on the modprobe@.service (LP: #1982462)
    File: debian/patches/lp1982462-units-remove-the-restart-limit-on-the-modprobe-.service.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=8f0acd1b2fbb8eed1259c34963e5e9b201bef900
  * pstore: do not try to load mtdpstore (LP: #1981622)
    File: debian/patches/lp1978079-efi-pstore-not-cleared-on-boot.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=15225032c3657f5906ee49d48929f9295a8664a0
  * core/mount: downgrade log level about several mkdir failures (LP: #1979952)
    Files:
    - debian/patches/lp1979952-Revert-core-mount-fail-early-if-directory-cannot-be-creat.patch
    - debian/patches/lp1979952-core-mount-downgrade-log-level-about-several-mkdir-failur.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ee8cfcf500698fab2e990de291ecf4c3ab87a4ae
  * debian/control: add Recommends: systemd-hwe-hwdb to udev.
    The systemd-hwe-hwdb brings in additional hwdb rules for HWE, so we want
    those installed with udev by default.
    File: debian/control
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=4a7a3258c33201cca305956820fcc6bcd6052d76
  * hwdb: implement --root option for systemd-hwdb query (LP: #1988078)
    Files:
    - debian/libsystemd0.symbols
    - debian/patches/lp1988078-hwdb-implement-root-option-for-systemd-hwdb-query.patch
    - debian/patches/lp1988078-sd-hwdb-add-sd_hwdb_new_from_path.patch
    - debian/patches/lp1988078-sd-hwdb-include-sys-stat.h-in-hwdb-internal.h.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=937fef96c858f2f2042bf71032f315647c14add0

  [ Luca Boccassi ]
  * Enable systemd-repart and ship it in a new s...

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hi,
on 21.09.2022 updating ubuntu broke it with this bug.
Running on i386, dell latitude e7450 with ssd and ubuntu22.04.1, kernel 5.15.0-48 generic, x86.

After booting, I get the mtd device must be supplied etc etc error, and I am left with a terminal only version.

I have an important hint: as suggested above, it's a problem with some authentication stuff. Yesterday after the bad upgrade, I put the pc in suspend mode. When I re opened it, I failed to log in into my account (the graphical session was otherwise normal) in a funny way: when propmted the password, it was as if the Enter key was continuosly being pressedm and I could at most enter one single word.

I have seen from a link provided above that the i386 version has not been tested, which is indeed my version.

Running apt-cache policy systemd returns (roughly, cannot copy and past as I'm from another machine):
Installed 249.11-0ubuntu3.4
Candidate same

version tables has entries:
249.11-ubuntu3.4 500
249.11-ubuntu3

I have tried the other suggested actions but none worked.
I have failed in installing the proposed ubuntu3.6 version of systemd, goes beyond my skills, I would need more detailed instructions.
Otherwise is it possible to undo the update of 21.09.22?

@mmariorrossi, please retest with the version 249.11-0ubuntu3.6 in updates.

apt -o APT::Get::Always-Include-Phased-Updates=true upgrade

Also note this comment from earlier:
In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

@dbungert

Updated to 249-11-0ubuntu3.6 using normal repository.
The error " mtd device must be supplied (device name is empty)" disappeared.
[actually with normal sudo apt upgrade nothing was being upgraded saying "The following packages have been kept back: <packages etc etc includingsystemd>. Solution 2 here did the job https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it ]

Yet, I am left with an emergency terminal and no graphical interface.
I can log in and use this minimal terminal.

I will open another thread, as the initial bug seems not related to the major breakdown of the whole graphical interface.

*UPDATE* I found that, in my case (may absolutely be not reproducible), the whole gdm3 (gnome graphical engine) graphical interface was missing.
A simple "sudo apt install gmd3" fixed the issue and gave me back the graphical interface.
My best guess so far is that I closed the lid of my laptop exactly while the gdm3 was being upgraded (during a normal daily update/upgrade), so the old version was already removed but the new one not installed yet.
So not really a bug, but a failure on the human side.

I reported the bug here: https://bugs.launchpad.net/ubuntu/+bug/1990723

Seems to affect quite some people (via other discussions), please help.

*Update* issue fixed, in my case was not really a bug