Boot initramfs linux img

Arch Linux

You are not logged in.

#1 2015-07-17 16:10:09

[SOLVED] Systemd-boot does not like initramfs-linux.img

Hello everyone,
today I decided to switch back from the LTS kernel to the official kernel. I installed the linux package and created a new entry for the boot loader:

Unfortunately after a reboot all I got was:

Since this is the same entry that I use for the LTS kernel (excluded the filenames) it must works.
Out of ideas, I copied «initramfs-linux.img» to «initramfs-linux.img2», rebooted and, at the boot menu, edited the command line changing initrd to point to «initramfs-linux.img2». Surprisingly the system booted correctly.

I have no idea why I can’t use «initramfs-linux.img». What can be happening ? .

As you can see «initramfs-linux.img2» is the same:

Notes:
I’m using EFI so the hard disk is partitioned in GPT and the boot partition is vfat; fsck do not reports any errors.
I already did a clean reinstall of mkinitcpio and recreated the images many times.
I’m using an 840EVO SSD with the old firmware (not the new one that caused corruption on linux a while ago).

Last edited by samebutdifferent (2015-07-19 18:45:17)

#2 2015-07-17 16:13:22

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

You are simply giving it filenames when it needs paths (relative to the ESP).

#3 2015-07-17 16:24:24

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

You mean that I should add backslashes ?

That does not change the outcome.

#4 2015-07-17 16:33:19

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

*nix doesn’t use backslashes for paths.

If simply renaming it works, that’s probably not the issue. I guess it assumes the root of the ESP if no path is given?

Try regenerating the initramfs.

Last edited by Scimmia (2015-07-17 16:39:55)

#5 2015-07-17 16:58:57

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

*nix doesn’t use backslashes for paths.

Yes, but according to the documentation EFI need those.

Try regenerating the initramfs.

I have already did that a couple times («mkinitcpio -p linux» right ?).

#6 2015-07-17 17:06:54

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

The nvram entry may need backslashes, but systemd-boot would use forward slashes.

I keep asking things you’ve already tried, don’t I? I really need to slow down and read better.

I wonder if deleting it then regenerating it would make a difference? It would change some things in the filesystem that wouldn’t be changed by just overwriting it.

#7 2015-07-17 17:44:16

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Deleted and regenerated, but «initramfs-linux.img» is still not visible by the boot loader.
In addition now I’m using the correct slashes.

#8 2015-07-17 22:03:23

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Can you boot via a direct NVRAM entry?

Select this entry from your UEFI boot menu.

By the way, NVRAM entries will accept either forward- or back-slashes

#9 2015-07-17 23:03:24

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Can you boot via a direct NVRAM entry?

Select this entry from your UEFI boot menu.

Unfortunately I can’t boot directly using efistub. If I could I wouldn’t be using systemd-boot.
I think the reason is that the arguments (-u . ) are not passed to the loader (-l . ) because of a bug in the UEFI firmware of my laptop (dell e5420, from 2011).
What I see when I run your entry is: kernel panic unable to mount root fs on unknown-block(0 0) .

#10 2015-07-18 12:30:17

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Today I explored all options in my bios and found that it shows my initramfs with an old dos name for some unknow reason.
Since removing and renaming has no effect, I formatted the partiton and regenerated everything.
Now «initramfs-linux.img» can be loaded correctly but not «initramfs-linux-fallback.img» because it’s viewed as «INITRA

Note that the initramfs for the LTS version are all correct . What can be happening to that particular filename ?

Last edited by samebutdifferent (2015-07-18 12:31:07)

#11 2015-07-18 14:37:26

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

This probably has do to with the FAT filesystem.

Every file with a long filename (LFN) has a corresponding 8.3 entry in the FAT-table .
VFAT takes care of keeping the connection between the 8.3 entry and it’s LFN counterpart intact.

Sometimes creating/copying breaks that connection and the link between the 8.3 FAT-entry and it’s LFN-entry is gone.
Then the only working reference to the file is the 8.3 entry.

The VFAT problems could be caused by mobo firmware, SSD firmware or the linux kernel.

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
Did you use the guided installer ? If yes, I can’t help you.

(A works at time B) && (time C > time B ) ≠ (A works at time C)

#12 2015-07-18 17:41:10

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Sometimes creating/copying breaks that connection and the link between the 8.3 FAT-entry and it’s LFN-entry is gone.
Then the only working reference to the file is the 8.3 entry.

I don’t think the problem is a broken reference because I can rename or remove both the long and the short filename without problems.

#13 2015-07-19 15:18:46

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

samebutdifferent, I’ll try to be more clear .

FAT system uses 1 table that links 8.3 filenames with their physical location.
ALL files on a FAT system can only be accessed through the underlying FAT table that ONLY holds 8.3 filenames.

VFAT maintains a separate table that links LFN entries with their 8.3 counterpart.
basically any LFN will be shortened to fit in an 8.3 scheme, VFAT will create that shortened entry in the FAT-Table if it doesn’t exist yet.
VFAT handles both LFN and 8.3 filenames.

Vfat-aware code will always call the VFat routines to access any file, regardless of LFN or 8.3

However, any non-vfat aware code calls the fat routines directly, messing things up.
Buggy VFAT code can also have this effect.

The screenshot you posted clearly shows an INITRA

2.IMG , this is the 8.3 reference created for an LFN entry.
At some point VFAT/FAT connection for that specific LFN got messed up.

The problem is detected during boot, likely by systemd-boot code, but can have been caused by any code accessing the ESP.
Troubleshooting this further won’t be easy.

Last edited by Lone_Wolf (2015-07-19 15:20:14)

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
Did you use the guided installer ? If yes, I can’t help you.

(A works at time B) && (time C > time B ) ≠ (A works at time C)

#14 2015-07-19 18:12:32

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

I think I got it.
After a lot of tests I found that the error occurs when I create consecutively 5 long filenames that begin in the same way.
It seems the crappy firmware of my Dell can’t even read correctly the FAT partition (in addition to not passing parameters to the EFI executables)

In the end I decided to remove linux-lts completely and keep only 2 initramfs to not trigger the problem.

If someone feels to try to recreate the problem on his computer, post below the results, I’m curious to know if this happens on others brands.

#15 2015-07-19 18:50:35

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

I think I got it.
After a lot of tests I found that the error occurs when I create consecutively 5 long filenames that begin in the same way.
It seems the crappy firmware of my Dell can’t even read correctly the FAT partition (in addition to not passing parameters to the EFI executables)

In the end I decided to remove linux-lts completely and keep only 2 initramfs to not trigger the problem.

You could also change the naming scheme for these files. mkinitcpio reads the names from /etc/mkinitcpio.d/*.preset

#16 2016-04-09 19:39:23

Re: [SOLVED] Systemd-boot does not like initramfs-linux.img

Troubleshooting this further won’t be easy.

Indeed it hasn’t been here.
I cross-checked plenty of times ESP partition: mtools, this script, in windows.
They all retrieved consistently both short and long names.

And I could rule out it was something with systemd-boot, since it also happened with the straightforward EFISTUB.

Then I started to wonder why GRUB worked on the other hand.
And albeit I was sure it was using the same options of systemd-boot, I spotted from live system that the kernel was receiving completely different parameters.
I realized then those must have been specific options, probably related to its bios roots, which in turn would explain why it doesn’t even pass (and need) initrd flag.
And last, in its rescue shell ls still managed to list files correctly. And here’s when I noticed that GRUB had loaded its own modules to handle fat32.

Contemporarily, I dd-ed whole /boot partition and I tried to check if VMWare Workstation own efi shell experienced the problem
The answer was negative. Then the epiphany:

. TL;DR: I started EFI shell on my laptop (shellx64.efi), loaded EDK2 driver, unloaded AMI File System Driver, connected FAT File System Driver and.. Worked!
I could even exit shell and boot with the normally malfunctioning entries.

.
Now, I sit here, after I extracted said allegedly broken driver wondering what to do.

EDIT: ideas
EDIT2: and another
EDIT3: hacking around uefi modules seems really easy it must be said.

EDIT4: anyway, AMI seems to have fixed the bug somewhere in 2012 (or at least I noticed such effect when switching from asus K53U 223 bios to K53BE 212)

Last edited by mirh (2018-10-03 17:33:39)

Источник

Загрузчик и частота обновления образов initramfs-linux.img и vmlinuz-linux

# 4 года, 5 месяцев назад (отредактировано 4 года, 5 месяцев назад)

Собственно дело было так. Я три раза переустанавливал Arch Linux из консоли пока не добился желаемого результата и на последнем этапе забыл подмонтировать /dev/sda1, а так как у меня используется спаренная система типа Clover EFI bootloader :: MacOS + Windows + Archlinux, то grub установился в созданную для неуспешного монтирования директорию /boot/ . Соответственно все образы системы и остались на разделе EXT4, который нативным железом подцепить не получится, а загрузка системы осуществляется с помощью Clover.

Трогать заново установку grub желания совсем нет так как у меня при указании путей до целевого раздела в виде UUID и путей до initramfs-linux.img и vmlinuz-linux система ArchLinux прекрасно стартует и средствами Clover.

Вопрос: как часто обновляются такие файлы образы и какого их значение меняется при обновлении системы? Grub у меня на EFI разделе тупо удален ибо мне не нужен лишний пункт меню загрузки, который не скрывается ни в какую.

На сколько рисковано бросать осиротевшие образы initramfs-linux.img и vmlinuz-linux и как часто их нужно будет обновлять? Можно ли мне оставить все как есть и класть эти образы периодически в EFI вручную или стоит озаботится переустановкой grub на раздел EFI?

Лучше добиться автоматического «выкладывания» куда нужно, ибо образы обновляются в случае:

• Установки драйверов
• Обновления ядра (которое довольно частое)
• Возможно, по каким-то еще причинам, о которых я запамятовал, но которые могут возникнуть.

# 4 года, 5 месяцев назад (отредактировано 4 года, 5 месяцев назад)

Такого. Матчасть учить не желаем, желаем умничать?
initramfs-linux.img — грубо говоря загрузочный образ ядра;
vmlinuz-linux — собственно ядро.
Обновляться как минимум и то и другое будет при каждом обновлении пакета linux, т.б. ядра. Плюс варианты ручной пересборки образа, ядра и т.д.

Понял. Значит буду отслеживать обновление ядра и драйверов и напишу небольшой баш для автоматического копирования на EFI.
Такой вопрос: mkinitcpio это и делает? Или это делает grub?

Просто мне grub нахрен не нужен вообще .

p.s.: сам себе ответил. не нужен мне grub вообще.

Не нужен — не устанавливайте, это опционально.

xShift
буду отслеживать обновление ядра и драйверов и напишу небольшой баш для автоматического копирования на EFI.

Это не нужно. В /etc/mkinitcpio.d/linux.preset прописываете пути к ядру и образу. А модули (драйвера) вообще находятся в /usr/lib/modules/*

Aivar
Это не нужно. В /etc/mkinitcpio.d/linux.preset прописываете пути к ядру и образу.

Aivar
Это не нужно. В /etc/mkinitcpio.d/linux.preset прописываете пути к ядру и образу.

Только там прописывается: куда ложить образ и откуда брать ведро.
А данный вопрос решается правильным монтированием разделов.

С кловером граб с ядром никак не пересекаются, поэтому можно автоматически монтировать безбоязненно.
# 4 года, 5 месяцев назад (отредактировано 4 года, 5 месяцев назад)

pztrn
С кловером граб с ядром никак не пересекаются, поэтому можно автоматически монтировать безбоязненно.

В общем замечено следующее: после монтирования EFI в Linux и установки grub все файлы в папке созданной на Mac OS теряют свои настройки «порядка». Вот например делаю arange by name и все строится в красивую сеточку и все файлики в порядке под Mac Os X, но после установки граба в той же папке наичнается бардак и потом сортировка не работает вообще. Каким образом Linux умудрился залезти в .DS_Store совсем не ясно, но очевидно что дело в xattrs(extended attributes of files). Эти ксатры есть на почти любой системе, например на Mac OS на этих атрибутах висит файловый антивирус песочница и перед запуском каждого файла происходит автоматическая проверка на «все в порядке».

На удивление у меня Arch Linux смог подмонтировать разделы HFS+, но, к счастью, только для чтения. Дело в том, что формат xattrs для Linux и Mac OS различный и смешивание доступа из разных систем ломает логику других систем.

Я не параноик, но сторонник того, чтобы эти фишки не пересекались вообще. У меня на папке EFI прицеплена «вирусная» иконка работающая через xattrs, которая не дает без лишних действий навредить структуре папок внутри, но она ломается из-за доступа системы Linux.

В общем как-то так. Не доверяю я линуксовым xattr, коли они даже просто при доступе к ФС приводят файлы в беспорядок.

Источник