You are not logged in.
Pages: 1
I've recently decided to install the Grsec patched kernel along with the mainline one, but when I try to boot into the grsec kernel, the bootloader (systemd-bootctl aka gummiboot) says:
\vmlinuz-linux-grsec not found and doesn't boot. The mainline kernel, however, works perfectly…
This is my /boot/loader/entries/arch-grsec.conf
title Arch Linux-Grsec
linux /vmlinuz-linux-grsec
initrd /initramfs-linux-grsec.img
options root=/dev/sda2 rw quiet Both vmlinuz-linux and vmlinuz-linux-grsec, as well as the initramfs' are in the /boot directory.
Offline
Just to make sure, is the /boot directory also your ESP, or do you mount the ESP to somewhere like /boot/EFI?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Yes, it is my $ESP. As I said, the configuration for both kernels is identical. This would be my "working" kernel:
/boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/sda2 rw quiet rcutree.rcu_idle_gp_delay=1Offline
What is the output of `mount`?
Offline
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=3983952k,nr_inodes=995988,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda2 on / type btrfs (rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
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)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/sda4 on /home/spacelander/virtual_disks type ext4 (rw,nosuid,nodev,noexec,noatime,discard,data=ordered)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,discard)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=797416k,mode=700,uid=1000,gid=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)I have the root folder on a btrfs partition, if that is why you're asking.
Last edited by spacelander (2015-11-10 22:43:53)
Offline
I was actually wondering about a number of things. Double mounts, mount options, etc. Everything looks good, though.
Anything interesting in `ls -la /boot`? I remember one case of something like this that involved truncated 8.3 filenames. Something strange the firmware was doing.
Offline
Oh, I didn't give to much thought to the FAT file system limitations… This is the output of `ls -lash /boot`
1,0K drwxr-xr-x 5 root root 1,0K ian 1 1970 .
16K drwxr-xr-x 1 root root 154 oct 6 00:59 ..
512 drwxr-xr-x 6 root root 512 iul 15 12:34 EFI
19M -rwxr-xr-x 1 root root 19M nov 4 01:42 initramfs-linux-fallback.img
18M -rwxr-xr-x 1 root root 18M nov 10 14:58 initramfs-linux-grsec-fallback.img
4,1M -rwxr-xr-x 1 root root 4,1M nov 10 14:58 initramfs-linux-grsec.img
4,2M -rwxr-xr-x 1 root root 4,2M nov 4 01:42 initramfs-linux.img
512 drwxr-xr-x 3 root root 512 iul 15 12:40 loader
512 drwxr-xr-x 2 root root 512 mar 26 2015 syslinux
4,1M -rwxr-xr-x 1 root root 4,1M oct 27 08:14 vmlinuz-linux
4,0M -rwxr-xr-x 1 root root 4,0M nov 10 07:07 vmlinuz-linux-grsecOffline
Please post the output of:
# bootctlJin, Jîyan, Azadî
Offline
output of `bootctl`
System:
Firmware: UEFI 2.00 (American Megatrends 4.635)
Secure Boot: disabled
Setup Mode: user
Loader:
Product: systemd-boot 227
Partition: /dev/disk/by-partuuid/dd18e251-d1d8-4969-bacf-38305322384b
File: └─/EFI/systemd/systemd-bootx64.efi
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/dd18e251-d1d8-4969-bacf-38305322384b
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 227)
File: └─/EFI/Boot/bootx64.efi (systemd-boot 227)
Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/dd18e251-d1d8-4969-bacf-38305322384b
File: └─/EFI/systemd/systemd-bootx64.efi
Title: opensuse-secureboot
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/dd18e251-d1d8-4969-bacf-38305322384b
File: └─/EFI/opensuse/shim.efi
Title: shell
ID: 0x0004
Status: active, boot-order
Partition: /dev/disk/by-partuuid/dd18e251-d1d8-4969-bacf-38305322384b
File: └─/EFI/shellx64.efiOffline
Will a custom NVRAM entry boot?
# efibootmgr -d /dev/sda -p 1 -c -L "Arch grsec" -l /vmlinuz-linux-grsec -u "root=/dev/sda2 rw quiet initrd=/initramfs-linux-grsec.img"The entry will be called "Arch grsec"
Jin, Jîyan, Azadî
Offline
I've added the entry and it doesn't boot. However, I've managed to boot the kernel from the GRUB command line. I don't currently use grub, but I still have it on the ESP from a previous installation of openSUSE. Though it boots up, it can't mount the root partition.
http://imgur.com/4JakNVY
Last edited by spacelander (2015-11-11 12:28:01)
Offline
I figured it out. It was because the file name vmlinuz-linux-grsec was apparently too long for the FS. Copying the kernel to another file with a shorter name solved the problem. Can anybody tell me how to change the config to always save the kernel with the shorter name when I update?
Offline
Pages: 1