Linux failed to start journal service

Arch Linux

Hi i’m new to Arch Linux, i’m trying to install it following the wiki.
Every 3 minutes , or so, i’m having this error:

[240.285293] INFO: task kworker/u8:3:102 blocked for more than 120 seconds. [240.285293] Not tainted 4.5.1-1-ARCH #1 [240.285293] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Is something wrong? Is this normal?

[2174.021888] systemd[1]: Failed to start Journal Service. 

Solution:
It is a bug whit AMD cpu and kernel 4.5.
I make a booteable usb with an older version on archiso (2016.03.01) and installed it.
After that I followed this

Last edited by Manfred (2016-05-09 06:34:27)

#2 2016-05-07 07:36:50

Re: [Solved ]Not tainted 4.5.1-1-ARCH and Failed to start Journal Service.

This warning basically says that you have some unusually slow I/O device. The real info here is «task $foo blocked for more than 120 seconds», not the «not tainted» part.

What are you trying to install Arch Linux on? Some older SD card perhaps?

If your target device is indeed very slow, then you can ignore this warning. But if you’re installing on a regular SSD, for example, connected by SATA, then this warning should not show up.

#3 2016-05-07 15:28:38

Re: [Solved ]Not tainted 4.5.1-1-ARCH and Failed to start Journal Service.

I’m trying to install it in a laptop , it is not too old.
Then I should not worry about the message?

#4 2016-05-07 15:28:54

Re: [Solved ]Not tainted 4.5.1-1-ARCH and Failed to start Journal Service.

What Vain said. This may not be what you want to hear, but you can effectively ignore this error. In fact,

[240.285293] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

The error gives you a way to disable it. Run that command in another TTY (CTRL+ALT+F_) and you should be good to go.

«You know what, there’s only one video game in the world that’s worth playing, and it’s Tony Hawk’s Pro Skater 4. The rest are just cheap knock-offs.»

#5 2016-05-07 16:07:53

Re: [Solved ]Not tainted 4.5.1-1-ARCH and Failed to start Journal Service.

I’d probably ignore the warning for now, but I’d also check the output of smart for the drive in question. The warning you’re seeing right now could be caused by a failing drive.

Also watch out for real I/O errors. Regularly check your log files, i.e. run `dmesg` or have a look at systemd’s journal. I/O errors can look something like this:

[ 4859.199016] blk_update_request: I/O error, dev sdc, sector 0 [ 4859.199019] Buffer I/O error on dev sdc, logical block 0, async page read

However, if you’re getting those, it might already be too late.

By the way, I’m seeing your warning regularly when I copy large amounts of data to an external USB hard drive — that’s an example of a «slow» device. I also see it on servers with waaaaaay too much load. The warning itself is usually harmless. Still, you should not get it when writing data to the hard drive of a modern laptop, hence the advice on checking your hardware.

Источник

Как правильно загружать Ubuntu в 2022 году?

Каждое второе включение Ubuntu ломается с примерно вот с такой ошибкой:

[FAILED] Failed to start Load Kernel Modules. [FAILED] Failed to start Journal Service. [DEPEND] Dependency failed for Flus…Journal to Persistent Storage. [FAILED] Failed to start NFS block layout mapping daemon. [FAILED] Failed to start Journal Service. 

Оборудование брендовое, Lenovo ThinkCentre Tiny m700 на Core i3 6100T.

lenovo kernel: RIP: 0010:diRead+0x62/0x210 [jfs] lenovo kernel: Code: 8d 8c 24 e8 fd ff ff 4d 8b 74 24 80 4c 89 cf 4c 89 4d d0 e8 10 ec 04 ea 8d 73 01 45 31 c0 ba 00 10 00 00 49 8b be 20 08 00 00 8b 47 28 48 8b 80 98 03 00 00 0f bf 48 4e d3 e6 31 c9 48 63 f6 lenovo kernel: RSP: 0018:ffffb8d2c05abac8 EFLAGS: 00010246 lenovo kernel: RAX: ffff8af5c0f8ca41 RBX: 00000000000000f5 RCX: ffff8af5d6af1548 lenovo kernel: RDX: 0000000000001000 RSI: 00000000000000f6 RDI: 0000000000000000 lenovo kernel: RBP: ffffb8d2c05abb00 R08: 0000000000000000 R09: ffff8af5d85b5ef0 lenovo kernel: R10: ffff8af5c6d90000 R11: ffffdee1c41b6400 R12: ffff8af5d85b6108 lenovo kernel: R13: ffff8af5c319af00 R14: ffff8af5d6f48000 R15: ffff8af5c6d94830 lenovo kernel: FS: 00007f86a1731fc0(0000) GS:ffff8afcddd00000(0000) knlGS:0000000000000000 lenovo kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 lenovo kernel: CR2: 0000000000000028 CR3: 00000001115ba004 CR4: 00000000003706e0 lenovo kernel: Call Trace: lenovo kernel: lenovo kernel: ? iget_locked+0x1aa/0x1c0 lenovo kernel: jfs_iget+0x3a/0x150 [jfs] lenovo kernel: jfs_lookup+0xb5/0xc0 [jfs] lenovo kernel: ? d_alloc_parallel+0x238/0x4d0 lenovo kernel: ? zap_pmd_range.isra.0+0x1d4/0x2b0 lenovo kernel: ? sock_def_readable+0x4b/0x80 lenovo kernel: ? __d_lookup+0x7b/0x140 lenovo kernel: lookup_open.isra.0+0x1be/0x5c0 lenovo kernel: open_last_lookups+0x3b6/0x420 lenovo kernel: ? path_init+0x2c1/0x3f0 lenovo kernel: path_openat+0x8d/0x2b0 lenovo kernel: do_filp_open+0xa2/0x140 lenovo kernel: ? __check_object_size+0x1c/0x20 lenovo kernel: do_sys_openat2+0x9b/0x150 lenovo kernel: __x64_sys_openat+0x55/0x90 lenovo kernel: do_syscall_64+0x61/0xb0 lenovo kernel: ? do_syscall_64+0x6e/0xb0 lenovo kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae lenovo kernel: RIP: 0033:0x7f86a1f8e66b lenovo kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 2b 0c 25 lenovo kernel: RSP: 002b:00007fff1b24c820 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 lenovo kernel: RAX: ffffffffffffffda RBX: 000055ec5eb442d0 RCX: 00007f86a1f8e66b lenovo kernel: RDX: 0000000000080000 RSI: 000055ec5eb45260 RDI: 00000000ffffff9c lenovo kernel: RBP: 000055ec5eb45260 R08: 0000000000000008 R09: 0000000000000001 lenovo kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080000 lenovo kernel: R13: 000055ec5d155034 R14: 000055ec5eb44bb0 R15: 00007f86a23b7c40 lenovo kernel: lenovo kernel: Modules linked in: msr parport_pc ppdev auth_rpcgss nfs_acl lockd lp grace parport sunrpc ip_tables x_tables autofs4 uas usb_storage jfs btrfs blake2b_generic zstd_compress hid_generic usbhid hid raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops crct10dif_pclmul cec crc32_pclmul rc_core ghash_clmulni_intel aesni_intel crypto_simd cryptd i2c_i801 i2c_smbus xhci_pci drm xhci_pci_renesas e1000e ahci libahci wmi video lenovo kernel: CR2: 0000000000000028 lenovo kernel: ---[ end trace 05d96bb36fcf281d ]--- lenovo kernel: RIP: 0010:diRead+0x62/0x210 [jfs] lenovo kernel: Code: 8d 8c 24 e8 fd ff ff 4d 8b 74 24 80 4c 89 cf 4c 89 4d d0 e8 10 ec 04 ea 8d 73 01 45 31 c0 ba 00 10 00 00 49 8b be 20 08 00 00 8b 47 28 48 8b 80 98 03 00 00 0f bf 48 4e d3 e6 31 c9 48 63 f6 lenovo kernel: RSP: 0018:ffffb8d2c05abac8 EFLAGS: 00010246 lenovo kernel: RAX: ffff8af5c0f8ca41 RBX: 00000000000000f5 RCX: ffff8af5d6af1548 lenovo kernel: RDX: 0000000000001000 RSI: 00000000000000f6 RDI: 0000000000000000 lenovo kernel: RBP: ffffb8d2c05abb00 R08: 0000000000000000 R09: ffff8af5d85b5ef0 lenovo kernel: R10: ffff8af5c6d90000 R11: ffffdee1c41b6400 R12: ffff8af5d85b6108 lenovo kernel: R13: ffff8af5c319af00 R14: ffff8af5d6f48000 R15: ffff8af5c6d94830 lenovo kernel: FS: 00007f86a1731fc0(0000) GS:ffff8afcddd00000(0000) knlGS:0000000000000000 lenovo kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 lenovo kernel: CR2: 0000000000000028 CR3: 00000001115ba004 CR4: 00000000003706e0 lenovo systemd[1]: systemd-modules-load.service: Main process exited, code=killed, status=9/KILL lenovo systemd[1]: systemd-modules-load.service: Failed with result 'signal'. 

Вот что теперь с этим делать? Очевидные «переустановить систему» можно не предлагать: я на JFS больше 10 лет сижу и ничего. Такое ощущение, что такая фигня преследует со знакомства с Ubuntu 18.10 и systemd. Или мне кажется?

Я бы понял, если бы ломалось насмерть, но когда работает «через раз», то складывается ощущение, что кто-то не смог в многопоток и/или асинхронщину.

Перемещено xaizek из talks

Источник

Arch Linux

error (which I ran into last weekend) to maybe save one or two among you a couple of hours of your time:

The error is described here https://bbs.archlinux.org/viewtopic.php?id=151012 as well as in several other threads in other language boards / in other forums etc. It is usually (as in the linked thread) ‘solved’ by reinstalling the system — good old Windows magic, also useful when dealing with systemd.

The Problem with this error is that you do not get into your system. Instead, systemd will print you the mentioned «Failed to start Journal Service» error message a couple of million times. There are also no logs that you could retrieve (when booting from a livesystem) and that would give you any helpful hints, since journal is systemd’s logging service, old-style system logs are not kept, and the dmesg log doesn’t survive the reboot with default settings.

As pointed out in the above mentioned thread, you will see a few more instructive error messages when adding ’emergency’ to the kernel line in the bootloader config.
Now there may be plenty of reasons why the systemd journal service might not work. The most common and most annoying, however, appears to be this one:
In this case you will see that the problem actually lies in

systemd[1]: Cannot open /etc/machine-id: No such file or directory

Now, ‘man machine-id’ reveals that «the /etc/machine-id file contains the unique machine id of the local system that is set during installation. (. ) The machine ID is usually generated from a random source (. )». It is obviously perfectly justified to refuse to boot the system because an absolutely insignificant random number is missing. As far as systemd is concerned anyway.

Usually, it seems, the /etc/machine-id is set by /usr/bin/systemd-machine-id-setup during installation or system upgrade. It is not documented anywhere that this is a rather important step and that you should better check if this was or was not actually done before rebooting. Obviously (but for no apparent reasons) systemd fails to run this (or to run this successfully) sometimes.
Also to be recommended: Always retain (back up) your old kernel and initramfs and edit your bootloader config appropriately to be able to boot with your old kernel again . just to have one or two options left to get back into the system in case of running into an unpleasant surprise from the side of systemd or other packages.

The solution is, obviously, to create this file /etc/machine-id . You probably want to do that from a livesystem (if you want to try it from the emergency shell, you would need to remount / (i.e. root) as rw and hope that systemd will not punish you for that) by just running the program that was designed for creating this file manually: /usr/bin/systemd-machine-id-setup
http://permalink.gmane.org/gmane.comp.s … devel/7528 states that it might also work with merely creating the file ‘touch /etc/machine-id’. Though I didn’t try that since I had enough fun with systemd for one week and didn’t want to break my system again just to see if that works.

We are exactly the people our parents always warned us about.

Источник