You are not logged in.
I ran an update yesterday and didn't pay much attention to the output.
Looking at my pacman.log it looks like mkinitcpio failed because of 'no space left on device' which is odd because there is 37gb left on that partition. In any case, when I turned my PC on today I got a:
kernel panic failed to execute /init error -13
Forgive the lack of full logs I'm writing this from another machine pictures are the best I have. this is the pacman.log I got from chroot'ing.
the last image shows that /boot/initramfs-linux-fallback.img got created.
How do I fix this? Is it as simple as running mkinitpco again or something? One complication is the arch live cd I booted from said arch UEFI iso at the prompt, and my bootloader is legacy grub. Any help would be great. thanks
Last edited by Cryptix_00 (2017-07-27 23:34:05)
Offline
the output of df -h can show your disk space. It's possible your /tmp (especially /tmp if you use Yaourt) or root partition might be full which causes the no space left error.
Either way I'm sure the output could be some of help
Last edited by Zeox101 (2017-07-27 23:00:06)
The Hidden Secret of Arch Linux Forums:
No. No one here really uses archlinux. Arch Sucks.
We're just a bunch of neckbeards who tinker with arch linux in our mom's basement during our free time ... which we have a lot of because we are unemployed. ~ Trilby
Offline
I posted the pacman.log output in the link if that's helpful. I just tried booting the fallback img (there;s an entry in my grub.cfg that seems to use it) and I got the same error.
here is the kernel panic error, apologies for the blurriness
edit: should i be booting from 'arch iso uefi' or 'efi default loader' on the liveusb if I my system is configured as legacy grub boot. does it matter?
edit2: df -h shows 37G available on the root partition, my root and /boot are on the same partition. It's possible /tmp had quite a bit in it when I ran the update command so that could be the reason for the lack of space.
Last edited by Cryptix_00 (2017-07-27 23:11:25)
Offline
If you have enough space, then mkinitcpio inside arch-chroot from the live-cd should do it. Since you don't want to modify the bootloader/manager, it most likely won't matter how you boot the cd.
While the cd is booted, I'd also verify that the systemd package passes pacman -Qkk.
Last edited by progandy (2017-07-27 23:25:45)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Well, I don't really wanna cause more harm than good, so I can really only give advice on what I'm confident about, which is the "no space left error" since I had an issue with that too a while back.
If you do fear that your /tmp is full (which is what your logs seem to be saying), then you can chroot into your system and type this
for i in /tmp/* ; do rm -r "$i" ; done
This will clear your /tmp.
Then running mkinitcpio again "should" work, if /tmp being full was the cause of the error.
Also as far I know, it shouldn't matter that you have legacy boot for the Arch Iso.
The Hidden Secret of Arch Linux Forums:
No. No one here really uses archlinux. Arch Sucks.
We're just a bunch of neckbeards who tinker with arch linux in our mom's basement during our free time ... which we have a lot of because we are unemployed. ~ Trilby
Offline
so just a:
mkinitcpio -p linux
?
here's the pacman.log: https://pastebin.com/9Xeh4xeq
I was able to find another usb drive and pull that out while chrooted
edit: /tmp appears to be empty now
Last edited by Cryptix_00 (2017-07-27 23:25:58)
Offline
OK I'm back up again, that seemed to have worked. thanks ![]()
Offline
Out of curiosity, did you actually run the little script I gave, or was /tmp empty to begin with?
The Hidden Secret of Arch Linux Forums:
No. No one here really uses archlinux. Arch Sucks.
We're just a bunch of neckbeards who tinker with arch linux in our mom's basement during our free time ... which we have a lot of because we are unemployed. ~ Trilby
Offline
/tmp was empty so there wasn't any need. I assume it gets cleared at boot? I thought that /tmp was a ramfs, it seems odd to me that I chewed through all my ram and 37 gb of storage in tmp...
Offline
/tmp should be a tmpfs with up to half of your ram by default, so its contents are lost on shutdown. Maybe you set something smaller in your fstab? You can check the size and type with "df -h"
We don't know what you did in your /tmp since the last reboot, so it could be possible that something created a huge amount of temporary data. Maybe building a few large AUR packages like a chromium variant?
Last edited by progandy (2017-07-28 10:58:05)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
tmpfs is indeed 7.9 gb, half of my RAM.
there's a torrent streaming client called webtorrent that I was using, I believe it stores the completed portion of the torrent in /tmp. I was watching a fairly large video, I think that, along with the build, probably caused the out of storage errors.
Offline