-
#181
Мат.плата: MSI B450-A PRO MAX
Процессор: Athlon3000g
Райзера: 007s и 009s
Система стоит на USB
Операционная система: HiveOS
Ни обновления БИОСА, ни расширитель не помог подключить больше 5 карт.
Без расширителя максимум было 4 карт, хз что делать. Расширитель берет максимум две карты, больше — не видит
-
#182
монитор в это время подключен к ригу? что на экране? было такое — это не сетевуха у тебя гонит, а хайв завис
Монитор нет.
-
#183
Сегодня ночью опять такая фигня, но в этот раз сетевая мигала, а риг отвалился без ошибок. Флешки менял, ссд ставил. Куда еще смотреть?
-
#184
Сегодня ночью опять такая фигня, но в этот раз сетевая мигала, а риг отвалился без ошибок. Флешки менял, ссд ставил. Куда еще смотреть?
подключи моник и оставь и жди, когда отвалится в хайве — идешь смотришь на монитор, завис ХАЙВ или нет, от этого уже и плясать
-
#185
Мат плата:MSI B450-A PRO MAX
ЦП: Ryzen 3 1200 BOX
6 Карт работают все ок. в риге стоит 7 карт.
Ситуация следующая. 6 карт стартуют все ок. Все их видит. Проблема следующая как тока я добавляю 7 карту и включаю Hive OS не сартует пишет ошибку error: can’t allocate initrd.
Они все точно работают и определяются в слотах которых стоят будь то М2 или расширитель. Суть в количестве. Если их 6 он стартует, если их 7 то такая ошибка.
Проверял так любую из 7 выключаю, он работает, включаю 7 хер.
В биосе ковырял все что вы тут писали и 4г и Ген 1,2,3.
Все карты работают, провода, райзеры, разъемы всё работает.
Подскажите плиз, а то я точно знаю что в такой сборке спокойна запускается 8 карт.
А человек вон уже 9 тестит)
-
#186
ошибка хайва «can’t allocate initrd» говорит о кривых настройках биоса, что-то забыли выключить.
Решение
-
#187
Мат плата:MSI B450-A PRO MAX
Версию биоса материнки в студию!
-
#188
ребята подскажите, нагрузка на разъем как то имеет место быть?просто получается так, что надо будет повесить через разветвитель две 1660 и одну 3090, ничего страшного?
-
#189
нет такого понятия)) юсб есть юсб
-
#190
ошибка хайва «can’t allocate initrd» говорит о кривых настройках биоса, что-то забыли выключить.
Решение
Все как в Вашей инструкции. пошагово выполнено.
Версию биоса материнки в студию!
Последняя которая для Вин 11 типо. 7C52v3D2(Beta version)
Потому что без обновы нельзя было выбирать в PCe- Г»Gen».
-
#191
Все как в Вашей инструкции. пошагово выполнено.
Последняя которая для Вин 11 типо. 7C52v3D2(Beta version)
Потому что без обновы нельзя было выбирать в PCe- Г»Gen».
GEN выбирать не надо, авто хватает на 9 карт.
-
#192
GEN выбирать не надо, авто хватает на 9 карт.
Это я написал для примера, что без обвновы выбора не было этого
я пробывал и авто и выбирать все равно ошибка.
Может UEFI ковырять надо или еще что-то где-то. Нервов нет. уже
-
#193
Если начинаются траблы с подключением большого кол-ва карт ответ всегда один:
Либо проблема в райзерах и питании карт(райзеров), либо проблема в биосе.
Можно накинуть еще ОЗУ, до 8гб, если не 8, но это не критично.
Можно исключить М2 переходник и оставить только расширитель, но ты должен быть уверен, что он исправен.
-
#194
Все спасибо Всем!
Сам Осел как оказалось в прочем как и всегда
UEFI не стоял в OS
Поставил и сразу все стартануло.
-
#195
куча ригов на интеле, собрал 1 на этой параше АМДшной, виснет все время, уже и биос прошивал и делал все по пунктам, какая параша, на интеловских мамках вообще ничего не трогал аптайм по неделе и месяцу!!!
бп голд, разгон на картах стандартный, после переноса этойже фермы на интеловскую мать с теми же настройками по картам в хайве, вот уже 3ий день никаких повисонов делайте выводы, материнку в мусорку!
-
#196
куча ригов на интеле, собрал 1 на этой параше АМДшной, виснет все время, уже и биос прошивал и делал все по пунктам, какая параша, на интеловских мамках вообще ничего не трогал аптайм по неделе и месяцу!!!
бп голд, разгон на картах стандартный, после переноса этойже фермы на интеловскую мать с теми же настройками по картам в хайве, вот уже 3ий день никаких повисонов делайте выводы, материнку в мусорку!
Да нормальная мать, у меня тоже уходил риг гулять все время, потом понял какая карта его вешает, снизил память на 100 мгц и пошел аптайм, уже месяц не подхожу к ригу.
-
#197
Да нормальная мать, у меня тоже уходил риг гулять все время, потом понял какая карта его вешает, снизил память на 100 мгц и пошел аптайм, уже месяц не подхожу к ригу.
подскажи как смог вычислить нужную карту?
-
#198
подскажи как смог вычислить нужную карту?
При зависании рига у меня она отображалась либо в %100 вентилей либо с крестом в хайве , но не всегда. Я теперь делаю так если есть сомнения,добавляю карты по одной в риг и ищу оптимальный разгон, денек поработала , следующую засовываем и так далее.
-
#199
подскажи как смог вычислить нужную карту?
Самый быстрый и правильный способ запуска новых карт:
1) подключаем все карты, загружаем ОС, но не выставляем разгон. Как только все определилось, включаем майнер и смотрим, как карты отрабатывают без разгона. Аптайм больше 2-3х часов без инвалид шар, глюков и ошибок драйверов — можно приступать к разгону.
2) ставим «средний по палате» разгон для своей модели карт. Наблюдаем за отвалами драйверов. Если таковые имеются убираем с шагом (т.е. по памяти было 2500, ставим 2400 и т.д.).
3) не жадничаем — в погоне за скоростью вы теряете в качестве и соответственно в прибыли (валидных шар будет меньше)
-
#200
соответственно вычислить «глючную» карту можно точно таким же способом
The OS with Ubuntu 20.04.3 LTS Desktop 64-bit is located in the gpt2 partition with the filesystem NTFS.
This is the structure of the gpt1 partition with the filesystem FAT32:
.
├── boot
│ └── grub
│ └── grub.cfg
└── efi
└── boot
├── bootx64.efi
├── grubx64.efi
└── mmx64.efi
4 directories, 4 files
This is the grub menù of the NTFS partition (default grub.cfg):
if loadfont /boot/grub/font.pf2 ; then
set gfxmode=auto
insmod efi_gop
insmod efi_uga
insmod gfxterm
terminal_output gfxterm
fi
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set timeout=5
menuentry "Ubuntu" {
set gfxpayload=keep
linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---
initrd /casper/initrd
}
menuentry "Ubuntu (safe graphics)" {
set gfxpayload=keep
linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash nomodeset ---
initrd /casper/initrd
}
menuentry "OEM install (for manufacturers)" {
set gfxpayload=keep
linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed only-ubiquity quiet splash oem-config/enable=true ---
initrd /casper/initrd
}
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
exit 1
}
menuentry 'UEFI Firmware Settings' {
fwsetup
}
fi
If the grub.cfg file (FAT32 partition) contains:
search --no-floppy --set=root --fs-uuid 2E92F36515DD4A5A
chainloader /EFI/BOOT/BOOTx64.EFI
boot
After making a choice from the grub selection menu, placed in the default grub.cfg file (NTFS partition) which is the same as the default contained within an iso image of Ubuntu 20.04.3 LTS Desktop 64-bit, the error message appears:
error: can't allocate initrd.
Press any key to continue...
I have to underline that the NTFS partition bootloader starts correctly with the chainloader command, otherwise I would not have seen the grub selection menu, it is the initrd command that gives an error.
If instead the grub.cfg file (FAT32 partition) contains:
search --no-floppy --set=root --fs-uuid 2E92F36515DD4A5A
configfile /boot/grub/grub.cfg
After the selection menu, everything works correctly, therefore the initrd command no longer gives an error.
What’s wrong with running the NTFS partition bootloader to boot initrd using the default grub.cfg file inside it?
I have tested that if partition 2 has Windows, using chainloader everything works correctly.
UPDATE 1:
I tried to swap partitions, the error persists.
UPDATE 2:
I would like to get more detailed error output from the initrd command but I don’t know how to do it.
I have tried
linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed nosplash debug ignore_loglevel ---
initrd /casper/initrd
but the error output is still the same, no rows added.
UPDATE 3:
Summarizing and clarifying what I am going to do, I from the partition with FAT32 do the chainload of the bootloader located on the NTFS partition.
If I boot the NTFS partition directly from BIOS, everything works, if instead I chainload starting from the FAT32 partition, problems appear.
Everything works correctly even if I call the menu of the grub.cfg (NTFS partition) using the configfile command rather than the chainloader command inside the grub.cfg file of the FAT32 partition, of which I have already shown the lines it contains.
UPDATE 4:
I am going to use the chainloader command anyway for generalization reasons, even being able to use the configfile command that would solve the problem, because I would have the possibility to execute the same command both to start a partition with Windows and Ubuntu.
UPDATE 5:
The ntfs module is already built into the bootloader of both partitions. The lsmod command confirmed this. In any case I have tried to insert insmod ntfs in the grub.cfg files of both partitions and, as expected, the error does not change.
UPDATE 6:
I don’t boot NTFS partition directly from BIOS, because UEFI on older computers cannot read NTFS directly.
UPDATE 7:
I HAVE DISCOVERED AN ERROR! Before I didn’t notice it because it lasts a fraction of a second. But with a video from the phone, which I had to set to 60 fps to be able to catch the error, I recorded it, then took it to the PC, from the PC I took a screenshot of that video fragment, then rotated it and cropped with gimp.
The error is as follows:
error: can't find command `grub_platform`.
Here is the screenshot:
Ubuntu 20.04 don’t run with the new kernel.
When I choose the new kernel from GRUB menu I have the following errors during the loading ram disk:
can’t allocate initrd
And after pressing another button such as chiesto:
eri: EFI_MAMMAP is not enabled
The default Kernel installed work.
Could be the motherboard ?
I haven’t this problem on virtual machine with another PC.
Thanks
Matteo
Question information
I suggest you report a bug. You can boot old kernels by holding SHIFT at boot then choosing the older kernel
A possible reason for such message could be a failure during the update.
What are the version numbers of the failing and the working kernels?
What is the output of
ls -l /boot
The installed kernels are:
— 5.4.0-42-generic (default install)
— 5.4.10-rt5
— 5.8.0-41-generic (default install)
For each version are present the corispective files vmlinuz, System.map, initrd.img and config-5…
I have to use the 5.4.10-rt5 version, i tried this version on virtual machine and work.
I tried other version such as 5.1.13, 5.5.0 (also not RT kernel) and these also present this error.
I’m doing other tries now.
thanks
Now i tried the version 5.9.0-rt5 and in this case i have another error:
error: can’t allocate initrd
x86/cpu VMX (outside txt) disabled by BIOS
the errors change
Please provide the _full_ output of the commands
uname -a
lsb_release -crid
ls -l /boot
Why didn’t you just copy/paste the text into this question document? This would have been much easier for us.
Where did you get the *rt* kernels? As far as I know they are not provided by standard Ubuntu.
Wich one of the four versions does work and which one doesn’t?
5.4.0.42-generic
5.4-10-rt5
5.8.0-41-generic
5.9.1-rt20
Because I’m using another PC, sorry.
I took the *rt* kernels of the site : https://www.kernel.org/pub/linux/kernel/projects/rt/ indicated of the linux kernel archives site.
Yesterday I tried not rt version and i got the same error.
The versions that work are: 5.4.0.42-generic and 5.8.0-41-generic (default install).
The versions that not work are: 5.4-10-rt5 and 5.9.1-rt20.
All version work on virtual machine of another PC.
This is support for Ubuntu, and the Ubuntu kernels work well, only those from a foreign source don’t.
So this is not an Ubuntu problem and hence not really the right place.
«x86/cpu VMX (outside txt) disabled by BIOS»
Have you checked the BIOS of the system, if there is a switch to enable this?
Do you have the newest version of the BIOS available for your system?
I tried with VMX enable but is don’t work.
The BIOS isn’t updated.
Thanks everyone for the help.
I solved the problem.
The image wasn’t being loaded because the size was too big.
After reducing the size the new kernel is work.
Best regards
Description of problem: We use a rather large initrd, around 300-500MB for stateless systems. This is based on Fedora 27. Also tried with the current version in the repositories for 28, it gives the same error. Versions tested (grub2-efi-x64): 2.02-22.fc27 2.02-26.fc28 On a Dell XPS 15 9550 grub will state when loading initrd: error: can't allocate initrd. This is the first system we see this issue on, whilst we run this on a *lot* of different hardware configurations. One of the most notable differences is that this system actually has much more memory than usual. Most of the hardware has 4GB (this is our minimum requirement), occasionally there's hardware with 8GB. This system has 16GB provided by 2 * 8GB modules. How reproducible: Make a 300MB+ initrd (doubt the compression method matters, ours has this size after xz -9 compression, extracted it's ~1200MB), grab a stock Fedora kernel and try loading it from USB stick with grub2 (it does run below shim, for secureboot). For example, make a FAT32 formatted USB stick, mount it at /mnt/t and then: mkdir -p /mnt/t/EFI/BOOT cp /boot/efi/EFI/fedora/shimx64.efi /mnt/t/EFI/BOOT/bootx64.efi cp /boot/efi/EFI/fedora/grubx64.efi /mnt/t/EFI/BOOT/bootx64.efi cp /boot/vmlinuz-4.15.17-300.fc27.x86_64 /mnt/t/vmlinuz cp <300MB+ initrd> /mnt/t/initrd cat > /mnt/t/EFI/BOOT/grub.cfg <<< EOF echo Loading kernel to RAM linuxefi /vmlinuz echo Loading initrd to RAM initrdefi /initrd echo Attempting boot boot EOF And attempt booting from the stick. The error will appear immediately after the 'Loading initrd to RAM' message. The kernel will start, but fails with an kernel panic about not being able to find the root file system. Which is to be expected as it can not find the initrd. Please let me know if I can be of further assistance. I've filed this against 28. Not sure what the best approach is here. It's applicable to 27 as well. If I remember correctly the issue also occurred with the grub2 from 25 or 26. That also gave an allocation error, but did have something with HIGH or HIGH mem in the message.
Correction: cp /boot/efi/EFI/fedora/grubx64.efi /mnt/t/EFI/BOOT/bootx64.efi should be cp /boot/efi/EFI/fedora/grubx64.efi /mnt/t/EFI/BOOT/
FYI: Just tested with shim removed and secure boot disabled. Assuming the example above mv /mnt/t/bootx64.efi /mnt/t/shimx64.efi mv /mnt/t/grubx64.efi /mnt/t/bootx64.efi and attempted boot. Same error.
Just tested with a DIMM removed (tried twice, DIMM-A removed @1, DIMM-B removed @2), makes no difference.
Can you add a dump of the memory map before and after trying to load that initramfs?
Sure, but do you have some pointers for me on how to provide this? The secure boot version is stripped from quite a few functions. First things I found were displaymem -> not found, seems replaced with lsmmap in grub2 lsmmap -> not found dump -> requires me to specify an address (range?). Don't know what address(range) you require for this. Dumping 16GB byte for byte and typing it over seems quite painful :) Thanks :)
Hi Peter, created an efi image with grub-mkstandalone on my Gentoo system, as the secure boot version doesn't have lsmmap. This is based on Gentoo's grub 2.02-r1 package. Messages differ a bit (says out of memory instead of allocation error). What's also notable is that all grub versions I've tried showed me a 2TB disk. There is *no* 2TB disk in the system. The only thing I can imagine it's some RAMdisk, perhaps created by the firmware (or grub?). It's gone by the time linux has booted (doesn't show up in lsblk anyways). FYI: The system has a 250GB M.2 SSD and a 500GB SATA SSD. Both from Samsung. There's also a USB stick plugged in, from which I boot. The 2TB disk remains surprising. Maybe it's used for firmware flashing or something, but 2TB seems rather insane for that purpose, especially since it's backed by only 16GB of RAM. I had to type this over as this machine doesn't have serial and I don't have a magic XHCI cable :). Checked it several times, quite sure there's no typos. Will provide a photo too. 4k screen on 15" though, it's rather small :). One thing I do find surprising is in the output of lsmmap. The addresses keep increasing, like they are in order, until: base_addr = 0x100000000, length = 0x3be000000, available RAM after which it jumps back to base_addr = 0xa0000, length = 0x60000, reserved RAM Not sure if this is normal behaviour from grub. grub> insmod lsmmap grub> lsmmap base_addr = 0x0, length = 0x58000, available RAM base_addr = 0x58000, length = 0x1000, reserved RAM base_addr = 0x59000, length = 0x45000, available RAM base_addr = 0x9e000, length = 0x2000, reserved RAM base_addr = 0x100000, length = 0xb0cf000, available RAM base_addr = 0xb1cf000, length = 0x40000, available RAM base_addr = 0xb20f000, length = 0x13a89000, available RAM base_addr = 0x1ec98000, length = 0xa465000, available RAM base_addr = 0x290fd000, length = 0x525000, available RAM base_addr = 0x29622000, length = 0x1af2000, available RAM base_addr = 0x2b114000, length = 0x1000, ACPI non-valatile storage RAM base_addr = 0x2b115000, length = 0x4a000, reserved RAM base_addr = 0x2b15f000, length = 0x60000, available RAM base_addr = 0x2b1bf000, length = 0x8262000, available RAM base_addr = 0x33421000, length = 0x2f2f000, available RAM base_addr = 0x36350000, length = 0x1d0000, available RAM base_addr = 0x36520000, length = 0x741000, available RAM base_addr = 0x36c61000, length = 0x3bb000, reserved RAM base_addr = 0x3701c000, length = 0x3e000, ACPI reclaimable RAM base_addr = 0x3705a000, length = 0x655000, ACPI non-volatile storage RAM base_addr = 0x376af000, length = 0x2d7d000, reserved RAM base_addr = 0x3a42c000, length = 0xd3000, RAM holding firmware code base_addr = 0x3a4ff000, length = 0x1000, available RAM base_addr = 0x100000000, length = 0x3be000000, available RAM base_addr = 0xa0000, length = 0x60000, reserved RAM base_addr = 0x3a500000, length = 0x5b00000, reserved RAM base_addr = 0xe0000000, length = 0x10000000, reserved RAM base_addr = 0xfe000000, length = 0x110000, reserved RAM base_addr = 0xfec00000, length = 0x1000, reserved RAM base_addr = 0xfee00000, length = 0x1000, reserved RAM base_addr = 0xff000000, length = 0x1000000, reserved RAM grub> ls (memdisk) (hd0) (h1) (hd2) (hd3) grub> insmod part_msdos grub> ls (memdisk) (hd0) (hd0,msdos1) (hd1) (hd2) (hd3) grub> ls (hd0,msdos1)/ efi/ vmlinuz initrd <bunch of others> grub> insmod linux grub> linux (hd0,msdos1)/vmlinuz grub> initrd (hd0,msdos1)/initrd error: out of memory. grub> lsmmap base_addr = 0x0, length = 0x58000, available RAM base_addr = 0x58000, length = 0x1000, reserved RAM base_addr = 0x59000, length = 0x45000, available RAM base_addr = 0x9e000, length = 0x2000, reserved RAM base_addr = 0x100000, length = 0x1e60000, available RAM base_addr = 0x1f60000, length = 0xa0000, available RAM base_addr = 0x2000000, length = 0x1e60000, available RAM base_addr = 0x3e60000, length = 0x736f000, available RAM base_addr = 0xb1cf000, length = 0x40000, available RAM base_addr = 0xb20f000, length = 0x13a89000, available RAM base_addr = 0x1ec98000, length = 0xa465000, available RAM base_addr = 0x290fd000, length = 0x525000, available RAM base_addr = 0x29622000, length = 0x1af2000, available RAM base_addr = 0x2b114000, length = 0x1000, ACPI non-valatile storage RAM base_addr = 0x2b115000, length = 0x4a000, reserved RAM base_addr = 0x2b15f000, length = 0x60000, available RAM base_addr = 0x2b1bf000, length = 0x8262000, available RAM base_addr = 0x33421000, length = 0x2f2f000, available RAM base_addr = 0x36350000, length = 0x1d0000, available RAM base_addr = 0x36520000, length = 0x741000, available RAM base_addr = 0x36c61000, length = 0x3bb000, reserved RAM base_addr = 0x3701c000, length = 0x3e000, ACPI reclaimable RAM base_addr = 0x3705a000, length = 0x655000, ACPI non-volatile storage RAM base_addr = 0x376af000, length = 0x2d7d000, reserved RAM base_addr = 0x3a42c000, length = 0xd3000, RAM holding firmware code base_addr = 0x3a4ff000, length = 0x1000, available RAM base_addr = 0x100000000, length = 0x3be000000, available RAM base_addr = 0xa0000, length = 0x60000, reserved RAM base_addr = 0x3a500000, length = 0x5b00000, reserved RAM base_addr = 0xe0000000, length = 0x10000000, reserved RAM base_addr = 0xfe000000, length = 0x110000, reserved RAM base_addr = 0xfec00000, length = 0x1000, reserved RAM base_addr = 0xfee00000, length = 0x1000, reserved RAM base_addr = 0xff000000, length = 0x1000000, reserved RAM Concerning the 2TB disk that isn't in the system, ls gives some info on it (got the size from here). Not sure if there are commands to find out more about the phantom device. grub> ls (hd3) Device hd3: No known filesystem detected - Sector size 512B - Total size 2147483648KiB As discussed on chat, the video is horribly slow as well. Normally we don't really need speed there, so not really an issue for us. It took almost 17 minutes for lsefi to complete (return prompt / done with output) on this machine. If you'd like to look into this and need more information please let me know what's desired and I'll see if I can dig it up :).
Created attachment 1452956 [details]
Proposed patch that may help the allocation problem
Possibly something like this patch will help - can you give it a shot, or do you need me to do a test build?
Hi Peter,
Thanks a lot for your work :).
I've attempted to test with your patch. Cloned the current git, built it without the patch to first determine it still occurred with the git version.
It didn't occur, it loads fine now.
Checked the patch and sources, but it seems resolved in a whole different way as many of the lines of original code in the patch file can not be found in the current git clone version. Didn't check them all, but in short:
First file, grub-core/kern/efi/mm.c. Line 58 should read
grub_efi_boot_services_t *b;
According to patch. File I have from git clone has the following on line 58 (less -N):
58 grub_efi_physical_address_t address;
That's not expected. I find the line on 68, but don't see the to-be-patched if statement either:
68 grub_efi_boot_services_t *b;
69 struct efi_allocation *alloc;
70 grub_efi_status_t status;
71
72 b = grub_efi_system_table->boot_services;
73 status = efi_call_3 (b->allocate_pool, GRUB_EFI_LOADER_DATA,
74 sizeof(*alloc), (void**)&alloc);
75
76 if (status == GRUB_EFI_SUCCESS)
77 {
78 alloc->next = efi_allocated_memory;
79 alloc->address = address;
80 alloc->pages = pages;
81 efi_allocated_memory = alloc;
82 }
This seems rather different already. The to-be-patched if statement doesn't seem to exist at all any more and I suspect this to have been rewritten/restructured.
Didn't check all the others. Most import part is the 0x3fffffff address that is changed to GRUB_EFI_MAX_USABLE_ADDRESS in the patch on multiple lines of grub-core/loader/i386/linux.c. Read through the linux.c file, but to keep it short the only occurence of 0x3fffffff now is in a comment in the file:
[ferry@bcld-builder3 i386]$ pwd
/tmp/gs/grub/grub-core/loader/i386
[ferry@bcld-builder3 i386]$ grep -inr '0x3fff' linux.c
1082: 0x3fffffff. */
Full comment is:
1080 /* XXX in reality, Linux specifies a bogus value, so
1081 it is necessary to make sure that ADDR_MAX does not exceed
1082 0x3fffffff. */
It appears to me that there have been quite some changes to the memory allocation stuff already which seem to have resolved the issue.
It works with current git version. I presume we'll just have to wait for it to be officially released (we only use the secure boot version as some people have secure boot enabled and can't sign with anything the default EFI key stack trusts ;)).
For completeness, below how I built it (nothing special).
mkdir /tmp/gs; cd /tmp/gs
clone git://git.savannah.gnu.org/grub.git
cd grub
./configure --prefix=/opt/grub2-test --target=x86_64 --with-platform=efi
make
sudo -i
cd /tmp/gs/grub
make install
^D
cd /opt/grub2-test/bin
[ferry@bcld-builder3 bin]$ ./grub-mkstandalone --version
./grub-mkstandalone (GRUB) 2.03
./grub-mkstandalone --compress=xz -d /opt/grub2-test/lib/grub/x86_64-efi --modules="part_msdos linux lsmmap" -o /tmp/grub-test.efi -O x86_64-efi
[ferry@bcld-builder3 bin]$ ls -lh /tmp/grub-test.efi
-rw-rw-r--. 1 ferry ferry 1.2M Jun 21 10:55 /tmp/grub-test.efi
[ferry@bcld-builder3 bin]$ cd /run/media/ferry/BCLD-USB/EFI/BOOT
[ferry@bcld-builder3 BOOT]$ cp /tmp/grub-test.efi bootx64.efi
[ferry@bcld-builder3 BOOT]$ cd /
[ferry@bcld-builder3 /]$ umount /run/media/ferry/BCLD-USB
---
Is it still desirable to test with this patch? Any specific source tree version you want me to apply it to if it is?
Hi, it doesn't seem to work here. I was only able to obtain the said version via the https://bodhi.fedoraproject.org/updates/FEDORA-2018-2756e3a374 link, wasn't able to find in the repositories. Downloaded that version, extracted boot/efi/EFI/fedora/grubx64.efi from that and replaced /EFI/BOOT/grubx64.efi on the stick with it (bootx64.efi in that folder is shimx64.efi from fc28 - I didn't update that). It loads and drops me to grub prompt (as expected). linuxefi (hd0,msdos1)/vmlinuz throws error: error: ../../grub-core/loader/i386/efi/linux.c:217:cannot allocate kernel parameters Whilst looking in the repositories for this version I also found grub2-2.02-53.fc30. That gives me the same error. Downloaded an older package, grub2-efi-x64-2.02.22.fc27.x86_64.rpm, did the same with that, that does load the kernel, but doesn't load the large initrd (error: can't allocate initrd.) as expected with that version. I have tried specifying some bogus parameters, but this didn't help.
Does nor work either with grub2-2.02-53.fc30
grub2-2.02-57.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. Hi, still seem to have some issues with grub2-efi-x64-2.02-57.fc29.x86_64.rpm Both kernel (didn't load on the grub2-2.02-53.fc30 and grub2-2.02-52.fc30 versions) and initrd (had allocations issues with earlier versions) seem to load fine now. The prompt returns w/o any output after both linuxefi (hd0,msdos1)/vmlinuz initrdefi (hd0,msdos1)/initrd Then issued boot But it's been stuck there for quite some time now. No more output has appeared. Been waiting for ~10 minutes now. The initrd is xz compressed, should be unpacked in <30 secs on this system.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Я работаю над проектом, который требует, чтобы я PXEboot очень большой initrd (1.3G) для клиента, однако при использовании grub2 через uefi я сталкиваюсь с ошибкой:
Can't allocate initrd
Похоже, что grub пытается получить доступ за пределы своего адреса.
… что странно, потому что ограничение памяти должно быть намного выше на 64-битной машине с 32 ГБ ОЗУ.
PXE — уменьшенное изображение не подходит, так как NFSmounts ненадежны в моем месте.
Я не женат на Grub2, но не смог загрузить syslinux.efi после компиляции из исходного кода.
Есть ли способ заставить grub получить большой initrd?
PXE, передающий initrd 1.3 ГБ, — просто плохой дизайн.
Вам не нужно ретранслировать по NFS. Типичный подход — initrd 20/40 МБ с поддержкой сети, способной отображать общие ресурсы SMB или просто получать компоненты по HTTP (wget/curl). Этот метод используется при установке дистрибутивов отдельных компонентов, таких как Ubuntu Server или Live дистрибутивов, таких как Ubuntu Desktop Live. В вашем случае, если у вас есть все в вашем initrd, вы должны разделить его и преобразовать в отдельный файл squashfs.
К сожалению, syslinux.efi 6.03 все еще не на 100% надежен, а grub2 не очень дружелюбен.
Посмотрите, как Serva PXE загружает множество дистрибутивов Linux, что, несомненно, поможет вам загрузить ваши. (Я связан с развитием сервы)
Я смог решить эту проблему, создав образ Dracut со встроенными модулями livenet/network, и использовал корень squashfs.
Просто обратите внимание, что Dracut ожидает, что SquashFS будет отформатирован определенным образом:/LiveOS/rootfs.img Где rootfs.img — это отформатированная файловая система ext4, содержащая действительную файловую систему.