Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#61334 - [systemd] fail to find device when booting

Attached to Project: Arch Linux
Opened by Syrone Wong (wongsyrone) - Thursday, 10 January 2019, 05:59 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 10 January 2019, 12:43 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

Screen shows:

starting version 240
ERROR: device 'UUID=xxxxxx' not found. Skipping fsck.
mount: /new_root: can't find UUID=xxxxx.
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off
[rootfs ]#

At first I thought it was caused by linux kernel, and I downgrade it.

[2019-01-10 11:18] [ALPM] downgraded linux (4.20.arch1-1 -> 4.19.10.arch1-1)

Then I tried reinstall 'systemd libsystemd systemd-sysvcompat' and regenerate initramfs
via 'mkinitcpio -p linux'

Tried switch to LABEL instead of UUID, the error changed to:

starting version 240
ERROR: device '/dev/sda1' not found. Skipping fsck.
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off
[rootfs ]#


Finally, I downgrade systemd to previous version:

[2019-01-10 11:37] [ALPM] downgraded libsystemd (240.0-3 -> 239.303-1)
[2019-01-10 11:37] [ALPM] downgraded systemd (240.0-3 -> 239.303-1)
[2019-01-10 11:37] [ALPM] downgraded systemd-sysvcompat (240.0-3 -> 239.303-1)

It boots, hooray!

Additional info:
* package version(s)
* config and/or log files etc.

cpuinfo:

processor : 31
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping : 2
microcode : 0x3d
cpu MHz : 1361.112
cache size : 20480 KB
physical id : 1
siblings : 16
core id : 7
cpu cores : 8
apicid : 31
initial apicid : 31
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5191.11
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:


Steps to reproduce:
- Use systemd 240
- Boot as usual
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 10 January 2019, 12:43 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#61328 
Comment by Pascal (Lacsapix) - Thursday, 10 January 2019, 08:12 GMT
Same happens here just like you said!
My screen also shows
[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb000020 (or later)
initramfs unpacking failed: junk in compressed archive

After that I also get dropped into an emergency root shell but my keyboard is unresponsive.
Comment by bhaallord (bhaallord) - Thursday, 10 January 2019, 10:20 GMT
I am also affected by this bug. I have updated 3 systems since yesterday and none of them was runnable after the update.

To solve the problem temporally, I add all modules that were loaded by a live usb-stick to the mkinitcpio.conf.
After that, the systems could find the root partition.
Comment by Dave Reisner (falconindy) - Thursday, 10 January 2019, 12:43 GMT
I'm marking this as a dupe of  FS#61328  because there seems to be a more general problem of udev still not properly recognizing hardware in the initramfs, which might be related to module probing.

Loading...