[Solved]The linux kernel with build in bootloader?

65kid · 2012-05-16 12:29:57

- oops, please delete -

Last edited by 65kid (2012-05-16 12:30:37)

the.ridikulus.rat · 2012-05-16 12:40:41

I meant

/etc/systemd/system/efistub_copy.path

[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition

[Path]
PathChanged=/boot/initramfs-linux-fallback.img
Unit=efistub_copy.service

[Install]
WantedBy=multi-user.target

/etc/systemd/system/efistub_copy.service

[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition
Requires=boot-efi.mount

[Service]
Type=simple
ExecStart=/etc/systemd/efistub_copy.sh

/etc/systemd/efistub_copy.sh

#!/usr/bin/env bash

cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-linux.efi
cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-linux.img
cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-linux-fallback.img

This works in my system, even when I manually run "mkinitcpio -p linux".

Last edited by the.ridikulus.rat (2012-05-16 15:34:08)

65kid · 2012-05-16 12:50:54

I stil don't get it.
/etc/mkinitcpio.d/linux.preset

# mkinitcpio preset file for the 'linux' package

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/efi/arch/initramfs-linux.img"
#default_options=""

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/efi/arch/initramfs-linux-fallback.img" 
fallback_options="-S autodetect"

This writes the initramfs to /boot/efi/arch/ directly, even if run "mkinitcpio -p linux" manually.

and btw, Type=OneShot in the service file is actually a mistake on my part. it's supposed to be Type=oneshot. With Type=OneShot it actually uses Type=simple instead. simple works just as well in this case, so you may also just remove the Type= line.

the.ridikulus.rat · 2012-05-16 13:58:18

65kid wrote:

I stil don't get it.
/etc/mkinitcpio.d/linux.preset
# mkinitcpio preset file for the 'linux' package

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/efi/arch/initramfs-linux.img"
#default_options=""

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/efi/arch/initramfs-linux-fallback.img" 
fallback_options="-S autodetect"
This writes the initramfs to /boot/efi/arch/ directly, even if run "mkinitcpio -p linux" manually.
and btw, Type=OneShot in the service file is actually a mistake on my part. it's supposed to be Type=oneshot. With Type=OneShot it actually uses Type=simple instead. simple works just as well in this case, so you may also just remove the Type= line.

I do not want files to be moved from /boot, but rather copied to UEFISYS while keeping the original files intact, for use with non-efistub bootloaders like grub2 etc. which can directly read /boot .

Last edited by the.ridikulus.rat (2012-05-16 13:58:51)

65kid · 2012-05-16 14:00:57

the.ridikulus.rat wrote:

I do not want files to be moved from /boot, but rather copied to UEFISYS while keeping the original files intact, for use with non-efistub bootloaders like grub2 etc. which can directly read /boot .

Ah ok, in this case it makes sense.

the.ridikulus.rat · 2012-05-16 14:17:08

I added my files and related info to wiki at https://wiki.archlinux.org/index.php/UE … ng_Systemd .

Last edited by the.ridikulus.rat (2012-05-16 14:18:12)

65kid · 2012-05-16 14:33:55

the.ridikulus.rat wrote:

I added my files and related info to wiki at https://wiki.archlinux.org/index.php/UE … ng_Systemd .

nice, thanks.
just one suggestion: If you set Type=oneshot you can specify multiple ExecStart= lines, so you won't need a separate script:

[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition

[Service]
Type=oneshot
ExecStart=/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-linux.efi
ExecStart=/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-linux.img
ExecStart=/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-linux-fallback.img

the.ridikulus.rat · 2012-05-16 14:39:27

65kid wrote:

the.ridikulus.rat wrote:
I added my files and related info to wiki at https://wiki.archlinux.org/index.php/UE … ng_Systemd .
nice, thanks.
just one suggestion: If you set Type=oneshot you can specify multiple ExecStart= lines, so you won't need a separate script:
[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition

[Service]
Type=oneshot
ExecStart=/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-linux.efi
ExecStart=/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-linux.img
ExecStart=/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-linux-fallback.img

Thanks for the info.

Anyway is "WantedBy" correct. Should it not be

WantedBy=boot-efi.mount

in normal case (ie. /boot and UEFISYS are separate and UEFISYS mounted at /boot/efi).

Last edited by the.ridikulus.rat (2012-05-16 14:40:04)

65kid · 2012-05-16 15:00:58

the.ridikulus.rat wrote:

Anyway is "WantedBy" correct. Should it not be
WantedBy=boot-efi.mount
in normal case (ie. /boot and UEFISYS are separate and UEFISYS mounted at /boot/efi).

Well the point of WantedBy=boot.mount is that the path unit is only started when /boot is mounted (i.e. automounted because mkinitcpio/pacman want to write to it). If you would simply start the path unit like other services via multi-user.target, systemd would also automatically mount /boot because the file you want to watch is on /boot. But since we don't want /boot to be mounted until it is actually needed, WantedBy=boot.mount makes more sense.

If /boot is not actually a separate partition and you mount the UEFI partition to /boot/efi, you would have to start the path unit when / is mounted, so WantedBy=-.mount . But then you could just as well set WantedBy=multi-user.target .

So WantedBy=boot-efi.mount is definitely wrong here because if /boot/efi is not mounted yet and mkinitcpio/pacman write to /boot, the path unit wouldn't be started yet.

the.ridikulus.rat · 2012-05-16 15:09:25

65kid wrote:

the.ridikulus.rat wrote:
Anyway is "WantedBy" correct. Should it not be
WantedBy=boot-efi.mount
in normal case (ie. /boot and UEFISYS are separate and UEFISYS mounted at /boot/efi).
Well the point of WantedBy=boot.mount is that the path unit is only started when /boot is mounted (i.e. automounted because mkinitcpio/pacman want to write to it). If you would simply start the path unit like other services via multi-user.target, systemd would also automatically mount /boot because the file you want to watch is on /boot. But since we don't want /boot to be mounted until it is actually needed, WantedBy=boot.mount makes more sense.
If /boot is not actually a separate partition and you mount the UEFI partition to /boot/efi, you would have to start the path unit when / is mounted, so WantedBy=-.mount . But then you could just as well set WantedBy=multi-user.target .
So WantedBy=boot-efi.mount is definitely wrong here because if /boot/efi is not mounted yet and mkinitcpio/pacman write to /boot, the path unit wouldn't be started yet.

In that case is this correct

[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition
After=boot-efi.mount

[Path]
PathChanged=/boot/initramfs-linux-fallback.img
Unit=efistub_copy.service

[Install]
WantedBy=boot.mount

Yes, the file we watch is in /boot, but the destination for the files (in case efistub_copy.sh is run) is /boot/efi . In that should we not ensure /boot/efi is mounted. Even in UEFI systems where /boot is not a separate partition (hence no boot.mount), boot-efi.mount should definitely exist (in normal case).

EDIT: I actually want this unit file started only if /boot/efi is mounted. Otherwise why do we need to track kernel file changes in the first place.

Last edited by the.ridikulus.rat (2012-05-16 15:14:22)

65kid · 2012-05-16 15:14:39

the.ridikulus.rat wrote:

In that case is this correct

[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition
After=boot-efi.mount

[Path]
PathChanged=/boot/initramfs-linux-fallback.img
Unit=efistub_copy.service

[Install]
WantedBy=boot.mount

In what case? if /boot is a separate partition, this is correct except that you can remove After=boot-efi.mount. /boot/efi will automatically be mounted as soon as /bin/cp tries to write to it.
If /boot is not a separate partition but part of / , WantedBy=multi-user.target would imho make most sense.

edit:
I'm assuming here that you actually enabled systemd automount in /etc/fstab.
You will always be on the safe side if you simply set WantedBy=multi-user.target . This just has the disadvantage that if /boot is a separate partition it will always be mounted at boot even if we don't need it (yet).

Last edited by 65kid (2012-05-16 15:18:40)

the.ridikulus.rat · 2012-05-16 15:20:37

65kid wrote:

the.ridikulus.rat wrote:
In that case is this correct
[Unit]
Description=Copy EFISTUB Kernel and Initramfs to UEFISYS Partition
After=boot-efi.mount

[Path]
PathChanged=/boot/initramfs-linux-fallback.img
Unit=efistub_copy.service

[Install]
WantedBy=boot.mount
In what case? if /boot is a separate partition, this is correct except that you can remove After=boot-efi.mount. /boot/efi will automatically be mounted as soon as /bin/cp tries to write to it.
If /boot is not a separate partition but part of / , WantedBy=multi-user.target would imho make most sense.

I do not understand. In my system I have separate /boot (ext3) and UEFISYS (FAT32) mounted at /boot/efi . You are talking from the point of view of file being watched. Make sure the unit is started only if boot.mount is started (if /boot is separate). I am talking from the point of view of destination. Since the files should be written to /boot/efi, make sure that is mounted before starting this unit. Now we need to incorporate both the requirements into the unit file because both are valid.

Last edited by the.ridikulus.rat (2012-05-16 15:24:08)

65kid · 2012-05-16 15:24:17

the.ridikulus.rat wrote:

I do not understand. In my system I have separate /boot (ext3) and UEFISYS (FAT32) mounted at /boot/efi . You are talking from the point of view of file being watched. Make sure the unit is started only if boot.mount is started (if /boot is separate). I am talking fro destination point of view. SInce the files should be written to /boot/efi, make sure that is mounted before starting this service. Now we need to incorporate both the requirements into the unit file becausze both are valid.

If you enabled automount for /boot/efi you won't have to make sure that /boot/efi is mounted when the service is executed because systemd will do this for you as soon as /bin/cp tries to write to /boot/efi.
If you don't have automount for /boot/efi (whyever that is), it would make more sense to specify Requires=boot-efi.mount in the service file.

Last edited by 65kid (2012-05-16 15:25:00)

the.ridikulus.rat · 2012-05-16 15:27:51

65kid wrote:

the.ridikulus.rat wrote:
I do not understand. In my system I have separate /boot (ext3) and UEFISYS (FAT32) mounted at /boot/efi . You are talking from the point of view of file being watched. Make sure the unit is started only if boot.mount is started (if /boot is separate). I am talking fro destination point of view. SInce the files should be written to /boot/efi, make sure that is mounted before starting this service. Now we need to incorporate both the requirements into the unit file becausze both are valid.
If you enabled automount for /boot/efi you won't have to make sure that /boot/efi is mounted when the service is executed because systemd will do this for you as soon as /bin/cp tries to write to /boot/efi.
If you don't have automount for /boot/efi (whyever that is), it would make more sense to specify Requires=boot-efi.mount in the service file.

Will /boot/efi be mounted automatically if s separate script file (with Type=simple) is used instead of ExecStart=/bin/cp (with Type=oneshot). Like in my case.

Last edited by the.ridikulus.rat (2012-05-16 15:28:44)

65kid · 2012-05-16 15:31:46

the.ridikulus.rat wrote:

Will /boot/efi be mounted automatically if s separate script file (with Type=simple) is used instead of ExecStart=/bin/cp (with Type=oneshot). Like in my case.

yes, that's the whole point of automount. If anything (not just systemd) tries to access something inside the mount directory, systemd will mount it. Even if mounting the device takes some time (because of fsck etc.) the process that wants to access the mount directory (in this case /bin/cp) will simply block/wait until the device is mounted.

alexcriss · 2012-06-05 09:58:19

Just curiosity:
anyone tried using the efi stub with 3.5 RC1? I get a load: error, while with previous kernels it worked fine.

RobertBuhren · 2012-06-06 07:38:13

Same here, i couldn't get it to work so far. Maybe this is a bug and should be reported upstream?

the.ridikulus.rat · 2012-06-06 07:52:24

alexcriss wrote:

Just curiosity:
anyone tried using the efi stub with 3.5 RC1? I get a load: error, while with previous kernels it worked fine.

I have no issues booting linux-mainline from [miffe] via rEFInd and with systemd.

alexcriss · 2012-06-06 09:08:32

Tried linux-mainline binaries from miffe's repo, same problem. Starting to wonder whether it is a UEFI problem of my Thinkpad, in which case I am screwed. Linus, why breaking my bootloader?

the.ridikulus.rat · 2012-06-06 09:20:58

alexcriss wrote:

Tried linux-mainline binaries from miffe's repo, same problem. Starting to wonder whether it is a UEFI problem of my Thinkpad, in which case I am screwed. Linus, why breaking my bootloader?

How are you booting? Via rEFInd, UEFI Shell or directly using efibootmgr ( https://wiki.archlinux.org/index.php/UE … tmgr_entry ) ?

alexcriss · 2012-06-06 10:14:55

I usually boot an entry that is added by efibootmgr. Using 3.5-rc1, instead of booting such entry, the UEFI BIOS moves to the next boot option, that is the UEFI shell. Then, from the UEFI shell, I boot with:

vmlinuz.efi initrd=initramfs-linux.img root=/dev/sdbx ...

and I get something like:

 Load: Error

(I have vmlinuz.efi and initramfs-linux.efi on /boot/efi on my machine, file names and paths are ok and the problem lies elsewhere, in fact that command works with 3.4)

Summarising, my boot order is:
1 - Arch Linux entry added by efibootmgr
2 - UEFI shell

With kernel 3.4 entry 1 is booted automatically, with 3.5-rc1 I am dropped to the UEFI shell of entry 2 and from there if I boot manually I get the error.

Last edited by alexcriss (2012-06-06 10:16:36)

RobertBuhren · 2012-06-06 10:32:51

I'm having a Thinkpad x220 with bios ver 1.29.

@the.ridikulus.rat What hardware do you have?

I tried booting with a UEFI entry via "efibootmgr" and via rEFInd. Both works with 3.4 but not with 3.5-rc1

alexcriss · 2012-06-06 10:35:42

Two Thinkpads don't work, bad correlation! Suggestions on how to report this on the Linux bugtracker? Just the thought of posting to the LKML scares me to death.

RobertBuhren · 2012-06-06 10:50:55

@alexcriss, maybe we can gather a little mor data, like machine type, bios ver, kernel config, bios configuration...

My system:
Thinkpad x220 4291-4CG

[root@robert-laptop robert]# dmidecode -t bios
# dmidecode 2.11
# SMBIOS entry point at 0xdaa9e000
SMBIOS 2.6 present.

Handle 0x000F, DMI type 0, 24 bytes
BIOS Information
	Vendor: LENOVO
	Version: 8DET59WW (1.29 )
	Release Date: 04/02/2012
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
	BIOS Revision: 1.29
	Firmware Revision: 1.20

Handle 0x002D, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Abbreviated
	Installable Languages: 1
		en-US
	Currently Installed Language: en-US

Kernel config:

http://pastebin.com/Jxn6fctE

alexcriss · 2012-06-06 11:04:38

Here are mines

Machine type: T420s 4170-32U

# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x000F, DMI type 0, 24 bytes
BIOS Information
	Vendor: LENOVO
	Version: 8CET51WW (1.31 )
	Release Date: 11/29/2011
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
	BIOS Revision: 1.31
	Firmware Revision: 1.18

Handle 0x002D, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Abbreviated
	Installable Languages: 1
		en-US
	Currently Installed Language: en-US

Kernel config at http://pastebin.com/jtN1upVB

Last edited by alexcriss (2012-06-06 11:05:35)

Arch Linux

#76 2012-05-16 12:29:57

Re: [Solved]The linux kernel with build in bootloader?

#77 2012-05-16 12:40:41

Re: [Solved]The linux kernel with build in bootloader?

#78 2012-05-16 12:50:54

Re: [Solved]The linux kernel with build in bootloader?

#79 2012-05-16 13:58:18

Re: [Solved]The linux kernel with build in bootloader?

#80 2012-05-16 14:00:57

Re: [Solved]The linux kernel with build in bootloader?

#81 2012-05-16 14:17:08

Re: [Solved]The linux kernel with build in bootloader?

#82 2012-05-16 14:33:55

Re: [Solved]The linux kernel with build in bootloader?

#83 2012-05-16 14:39:27

Re: [Solved]The linux kernel with build in bootloader?

#84 2012-05-16 15:00:58

Re: [Solved]The linux kernel with build in bootloader?

#85 2012-05-16 15:09:25

Re: [Solved]The linux kernel with build in bootloader?

#86 2012-05-16 15:14:39

Re: [Solved]The linux kernel with build in bootloader?

#87 2012-05-16 15:20:37

Re: [Solved]The linux kernel with build in bootloader?

#88 2012-05-16 15:24:17

Re: [Solved]The linux kernel with build in bootloader?

#89 2012-05-16 15:27:51

Re: [Solved]The linux kernel with build in bootloader?

#90 2012-05-16 15:31:46

Re: [Solved]The linux kernel with build in bootloader?

#91 2012-06-05 09:58:19

Re: [Solved]The linux kernel with build in bootloader?

#92 2012-06-06 07:38:13

Re: [Solved]The linux kernel with build in bootloader?

#93 2012-06-06 07:52:24

Re: [Solved]The linux kernel with build in bootloader?

#94 2012-06-06 09:08:32

Re: [Solved]The linux kernel with build in bootloader?

#95 2012-06-06 09:20:58

Re: [Solved]The linux kernel with build in bootloader?

#96 2012-06-06 10:14:55

Re: [Solved]The linux kernel with build in bootloader?

#97 2012-06-06 10:32:51

Re: [Solved]The linux kernel with build in bootloader?

#98 2012-06-06 10:35:42

Re: [Solved]The linux kernel with build in bootloader?

#99 2012-06-06 10:50:55

Re: [Solved]The linux kernel with build in bootloader?

#100 2012-06-06 11:04:38

Re: [Solved]The linux kernel with build in bootloader?

Board footer