You are not logged in.

Pages: 1

#1 2021-01-02 07:52:33

Potato
Member
Registered: 2021-01-01
Posts: 17

[SOLVED] Crashes just before login. plymouth failing? fstab issue?

So after sorting a kernel issue, I now have failure just before login, with the

"Oh no! Something went wrong!
Please contact a system administrator".

Looking through the journalctl -xb, which can be found here  https://dpaste.com/GU362XBBT, at the bottom there is a 

Jan 02 16:25:31 6400d-137059-l systemd[378]: rescue.service: Executable /usr/bin/plymouth missing, skipping: No such file or directory
░░ Subject: Process /usr/bin/plymouth could not be executed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The process /usr/bin/plymouth could not be executed and failed.
░░ 
░░ The error number returned by this process is ERRNO.

Searching for solutions to this seems to exclusively return "you have a problem in your fstab file, and are incorrectly booting something". I cannot see any problem in mine, here is /etc/fstab:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=61ba00af-6441-4aba-a739-0b33faad6035	/         	ext4      	rw,relatime	0 1

# /dev/sda1
UUID=DD13-4592      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/sda4
UUID=088313c2-faf5-4286-939c-206eeda77723	/home     	ext4      	rw,relatime	0 2

# /dev/sda3
UUID=fee4693b-fd78-400a-92d1-5a93bb48dd94	none      	swap      	defaults  	0 0

and here is the lsblk -f to compare UUID, which all seem to match:

NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                           
├─sda1 vfat   FAT32       DD13-4592                             461.2M    10% /boot
├─sda2 ext4   1.0         61ba00af-6441-4aba-a739-0b33faad6035   54.2G    39% /
├─sda3 swap   1           fee4693b-fd78-400a-92d1-5a93bb48dd94                [SWAP]
└─sda4 ext4   1.0         088313c2-faf5-4286-939c-206eeda77723  472.4G    36% /home
sr0

So I am stumped. Is there a problem in my fstab that I don't see? Or is the crash due to something else?

Last edited by Potato (2021-01-02 22:31:33)

Offline

#2 2021-01-02 15:02:47

twelveeighty
Member
Registered: 2011-09-04
Posts: 1,456

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

Potato wrote:
Executable /usr/bin/plymouth missing

Either try to connect via SSH or otherwise a LiveCD and mount the disk and make sure that /usr/bin/plymouth actually exists?

Offline

#3 2021-01-02 17:04:35

Khere
Member
From: Italy
Registered: 2020-03-04
Posts: 170

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

Potato wrote:
The process /usr/bin/plymouth could not be executed and failed.

Chroot in your system with a livecd and check if plymouth exist or not.
If exist post the output of 

systemctl list-unit-files | grep plymouth

I remember there was a problem with grub that at boot showed the same error as you. Do you use grub?

Last edited by Khere (2021-01-02 17:06:00)

Fan of Giorgio Moroder & Mohammad Ammax enemy

Offline

#4 2021-01-02 17:24:10

loqs
Member
Registered: 2014-03-06
Posts: 19,027

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

rescue.service: Executable /usr/bin/plymouth missing, skipping: No such file or directory

rescue.service will use plymouth if present.  The issue happened before that when whatever triggered rescue.target to be invoked.

Jan 02 16:25:26 6400d-137059-l systemd[1]: Queued start job for default target Rescue Mode.

Why is the default target set to rescue.target?  Please do not use the -x flag when posting journalctl output it is effectively adding spam.

Online

#5 2021-01-02 21:41:11

Potato
Member
Registered: 2021-01-01
Posts: 17

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

twelveeighty wrote:
Potato wrote:
Executable /usr/bin/plymouth missing

Either try to connect via SSH or otherwise a LiveCD and mount the disk and make sure that /usr/bin/plymouth actually exists?

`ls /usr/bin/ | grep plymouth' returns nothing.

Khere wrote:

Chroot in your system with a livecd and check if plymouth exist or not.
If exist post the output of

systemctl list-unit-files | grep plymouth

I remember there was a problem with grub that at boot showed the same error as you. Do you use grub?

plymouth doesn't exist from what I can tell. I never installed it, `pacman -Q plymouth' returns nothing, `systemctl list-unit-files | grep plymouth' returns nothing, it doesn't seem to exist yet is being looked for.

I have never installed grub, it doesn't seem to exist in any bin or anything so I assume I am not using grub? Unless it is hidden away somewhere that I don't know about.

loqs wrote:
Potato wrote:
rescue.service: Executable /usr/bin/plymouth missing, skipping: No such file or directory

rescue.service will use plymouth if present.  The issue happened before that when whatever triggered rescue.target to be invoked.

The thing is that plymouth doesn't seem to exist. I have no idea why it is looking for it. Everything is up to date via pacman -Syy, pacman -Syu, reinstalled linux via pacman -S linux, then recreated  the image mkinitcpio -P... but for whatever reason it still seems to be searching for something that does not exist.

loqs wrote:

Why is the default target set to rescue.target?  Please do not use the -x flag when posting journalctl output it is effectively adding spam.

Sorry that was just the recommendation by the prompt. Here it is without -x:
https://dpaste.com/BUEPHVXZP

Offline

#6 2021-01-02 21:48:04

loqs
Member
Registered: 2014-03-06
Posts: 19,027

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

Jan 02 17:59:16 6400d-137059-l kernel: Command line: \\vmlinuz-linux rw root=/dev/disk/by-partuuid/767e1cec-c300-4fd1-b64f-0d2d0f968916 single initrd=\initramfs-linux.img
man systemd wrote:

       rescue, rd.rescue, single, s, S, 1
Boot into rescue mode. This is equivalent to systemd.unit=rescue.target or rd.systemd.unit=rescue.target,  respectively, and provided for compatibility reasons and to be easier to type.

You specified to boot to single which under systemd is rescue.target and systemd brought you to rescue.target.
Rescue.service would use plymouth if it existed but you are only triggering rescue.service because you reached rescue.target and that happened because that is what systemd was told to boot to.

Online

#7 2021-01-02 21:52:50

Potato
Member
Registered: 2021-01-01
Posts: 17

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

loqs wrote:
Jan 02 17:59:16 6400d-137059-l kernel: Command line: \\vmlinuz-linux rw root=/dev/disk/by-partuuid/767e1cec-c300-4fd1-b64f-0d2d0f968916 single initrd=\initramfs-linux.img
man systemd wrote:

       rescue, rd.rescue, single, s, S, 1
Boot into rescue mode. This is equivalent to systemd.unit=rescue.target or rd.systemd.unit=rescue.target,  respectively, and provided for compatibility reasons and to be easier to type.

You specified to boot to single which under systemd is rescue.target and systemd brought you to rescue.target.
Rescue.service would use plymouth if it existed but you are only triggering rescue.service because you reached rescue.target and that happened because that is what systemd was told to boot to.

Ok now I am getting confused -- I am attempting a normal boot, which then crashes right before login. I am then booting in single user and rescue mode to look at the journals. journalctl -b is just returning the log from the single user rescue mode? I thought it would have had the crash info in it from the normal login...

Let me crash it, then boot from live USB and pull the journal...

Offline

#8 2021-01-02 22:09:26

Potato
Member
Registered: 2021-01-01
Posts: 17

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

Ok then surely this is the journal of the crashed boot, not the boot used to check the journal (stupid of me!)... I crashed it as normal, I booted from a usb, journalctl -b clearly seems to return the iso boot, so I have used journalctl -b -1 to return what *should* be the journal of the crash. Here it is:

https://dpaste.com/HEDAWXLTQ

Edit: So it seems like the gnome shell is being killed for some reason

Last edited by Potato (2021-01-02 22:15:55)

Offline

#9 2021-01-02 22:19:26

loqs
Member
Registered: 2014-03-06
Posts: 19,027

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

Jan 03 08:53:24 6400d-137059-l gnome-session[3863]: gnome-session-binary[3863]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-session-binary[3863]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-session[3863]: gnome-session-binary[3863]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-session-binary[3863]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-session[3863]: gnome-session-binary[3863]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-session-binary[3863]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Jan 03 08:53:24 6400d-137059-l gnome-shell[4041]: Settings schema 'org.gnome.mutter.wayland' does not contain a key named 'xwayland-disable-extension'
Jan 03 08:53:24 6400d-137059-l kernel: show_signal: 5 callbacks suppressed
Jan 03 08:53:24 6400d-137059-l kernel: traps: gnome-shell[4041] trap int3 ip:7f3b8a703b28 sp:7ffd7c6c1df0 error:0 in libglib-2.0.so.0.6600.4[7f3b8a6c6000+8c000]
Jan 03 08:53:24 6400d-137059-l kernel: audit: type=1701 audit(1609624404.352:66): auid=120 uid=120 gid=120 ses=3 pid=4041 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=5 res=1
Jan 03 08:53:24 6400d-137059-l audit[4041]: ANOM_ABEND auid=120 uid=120 gid=120 ses=3 pid=4041 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=5 res=1
Jan 03 08:53:24 6400d-137059-l audit: BPF prog-id=20 op=LOAD
Jan 03 08:53:24 6400d-137059-l audit: BPF prog-id=21 op=LOAD
Jan 03 08:53:24 6400d-137059-l systemd[1]: Started Process Core Dump (PID 4064/UID 0).
Jan 03 08:53:24 6400d-137059-l audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-4064-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 03 08:53:24 6400d-137059-l kernel: audit: type=1334 audit(1609624404.362:67): prog-id=20 op=LOAD
Jan 03 08:53:24 6400d-137059-l kernel: audit: type=1334 audit(1609624404.362:68): prog-id=21 op=LOAD
Jan 03 08:53:24 6400d-137059-l kernel: audit: type=1130 audit(1609624404.362:69): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-4064-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 03 08:53:25 6400d-137059-l systemd-coredump[4066]: Process 4041 (gnome-shell) of user 120 dumped core.
                                                       
                                                       Stack trace of thread 4041:
                                                       #0  0x00007f3b8a703b28 g_log_structured_array (libglib-2.0.so.0 + 0x59b28)
                                                       #1  0x00007f3b8a704146 g_log_default_handler (libglib-2.0.so.0 + 0x5a146)
                                                       #2  0x00007f3b8a705219 g_logv (libglib-2.0.so.0 + 0x5b219)
                                                       #3  0x00007f3b8a7054c0 g_log (libglib-2.0.so.0 + 0x5b4c0)
                                                       #4  0x00007f3b8a914612 n/a (libgio-2.0.so.0 + 0xde612)
                                                       #5  0x00007f3b8a9161cc g_settings_get_flags (libgio-2.0.so.0 + 0xe01cc)
                                                       #6  0x00007f3b89aaf3d6 n/a (libmutter-7.so.0 + 0x773d6)
                                                       #7  0x00007f3b8a80e841 g_type_create_instance (libgobject-2.0.so.0 + 0x30841)
                                                       #8  0x00007f3b8a7feffe n/a (libgobject-2.0.so.0 + 0x20ffe)
                                                       #9  0x00007f3b8a80013d g_object_new_with_properties (libgobject-2.0.so.0 + 0x2213d)
                                                       #10 0x00007f3b8a800c42 g_object_new (libgobject-2.0.so.0 + 0x22c42)
                                                       #11 0x00007f3b89a8d574 n/a (libmutter-7.so.0 + 0x55574)
                                                       #12 0x00007f3b89b047c7 meta_init (libmutter-7.so.0 + 0xcc7c7)
                                                       #13 0x0000561bdb07d138 n/a (gnome-shell + 0x2138)
                                                       #14 0x00007f3b89895152 __libc_start_main (libc.so.6 + 0x28152)
                                                       #15 0x0000561bdb07d60e n/a (gnome-shell + 0x260e)
                                                       
                                                       Stack trace of thread 4051:
                                                       #0  0x00007f3b8996246f __poll (libc.so.6 + 0xf546f)
                                                       #1  0x00007f3b8a75093f n/a (libglib-2.0.so.0 + 0xa693f)
                                                       #2  0x00007f3b8a6fb2b1 g_main_context_iteration (libglib-2.0.so.0 + 0x512b1)
                                                       #3  0x00007f3b8a6fb302 n/a (libglib-2.0.so.0 + 0x51302)
                                                       #4  0x00007f3b8a729ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                                                       #5  0x00007f3b88f123e9 start_thread (libpthread.so.0 + 0x93e9)
                                                       #6  0x00007f3b8996d293 __clone (libc.so.6 + 0x100293)
                                                       
                                                       Stack trace of thread 4063:
                                                       #0  0x00007f3b8a80e729 g_type_create_instance (libgobject-2.0.so.0 + 0x30729)
                                                       #1  0x00007f3b8a7feffe n/a (libgobject-2.0.so.0 + 0x20ffe)
                                                       #2  0x00007f3b8a8008a4 g_object_new_valist (libgobject-2.0.so.0 + 0x228a4)
                                                       #3  0x00007f3b8a800c1a g_object_new (libgobject-2.0.so.0 + 0x22c1a)
                                                       #4  0x00007f3b8a92893a n/a (libgio-2.0.so.0 + 0xf293a)
                                                       #5  0x00007f3b8a933e15 g_bus_get_sync (libgio-2.0.so.0 + 0xfde15)
                                                       #6  0x00007f3b8aa16530 n/a (libdconfsettings.so + 0x6530)
                                                       #7  0x00007f3b8aa1670c n/a (libdconfsettings.so + 0x670c)
                                                       #8  0x00007f3b8a6fca84 g_main_context_dispatch (libglib-2.0.so.0 + 0x52a84)
                                                       #9  0x00007f3b8a7509b1 n/a (libglib-2.0.so.0 + 0xa69b1)
                                                       #10 0x00007f3b8a6fb2b1 g_main_context_iteration (libglib-2.0.so.0 + 0x512b1)
                                                       #11 0x00007f3b8aa15c0e n/a (libdconfsettings.so + 0x5c0e)
                                                       #12 0x00007f3b8a729ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                                                       #13 0x00007f3b88f123e9 start_thread (libpthread.so.0 + 0x93e9)
                                                       #14 0x00007f3b8996d293 __clone (libc.so.6 + 0x100293)
                                                       
                                                       Stack trace of thread 4054:
                                                       #0  0x00007f3b89967d5d syscall (libc.so.6 + 0xfad5d)
                                                       #1  0x00007f3b8a749a9b g_cond_wait_until (libglib-2.0.so.0 + 0x9fa9b)
                                                       #2  0x00007f3b8a6cc853 n/a (libglib-2.0.so.0 + 0x22853)
                                                       #3  0x00007f3b8a72cecb n/a (libglib-2.0.so.0 + 0x82ecb)
                                                       #4  0x00007f3b8a729ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                                                       #5  0x00007f3b88f123e9 start_thread (libpthread.so.0 + 0x93e9)
                                                       #6  0x00007f3b8996d293 __clone (libc.so.6 + 0x100293)
                                                       
                                                       Stack trace of thread 4055:
                                                       #0  0x00007f3b8996246f __poll (libc.so.6 + 0xf546f)
                                                       #1  0x00007f3b8a75093f n/a (libglib-2.0.so.0 + 0xa693f)
                                                       #2  0x00007f3b8a6fbfd3 g_main_loop_run (libglib-2.0.so.0 + 0x51fd3)
                                                       #3  0x00007f3b8a937fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
                                                       #4  0x00007f3b8a729ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                                                       #5  0x00007f3b88f123e9 start_thread (libpthread.so.0 + 0x93e9)
                                                       #6  0x00007f3b8996d293 __clone (libc.so.6 + 0x100293)

Looks like gnome shell to me as well.  Sorry gnome is not my area,  I have no clue what the cause is.

Online

#10 2021-01-02 22:31:17

Potato
Member
Registered: 2021-01-01
Posts: 17

Re: [SOLVED] Crashes just before login. plymouth failing? fstab issue?

loqs wrote:

Looks like gnome shell to me as well.  Sorry gnome is not my area,  I have no clue what the cause is.

No problem, it had the simple solution of just reinstalling all gnome packages via `pacman -S gnome'.

Thanks everyone, sorry for the runaround and the waste of time.

Offline

Pages: 1

Board footer

Powered by FluxBB