| View previous topic :: View next topic |
| Author |
Message |
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2965
Location: Edge of marsh USA
|
 Posted: Sun Jan 28, 2024 10:25 pm Post subject: |
 |
|
Can you change in the BIOS setup to BIOS booting versus UEFI, repartition the new drive in MBR/DOS mode, and install GRUB into the MBR?
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
 |
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Sun Jan 28, 2024 10:34 pm Post subject: |
|
|
Thank you for your tip, but grub does recognize the UEFI partition, as mentioned before on the EDIT of my last reply. But you probably wrote that at the same time I was editing it. xD
But here it is:
| Sokrovenno wrote: | Hey, I don't know if it matters, but when I installed grub I remember I had to use this code:
| Code: | | grub-install --target=x86_64-efi --efi-directory=/efi --removable |
without the --removable it was not detected.
I was looking here and it seems that is because my motherboard.
| Quote: | Some motherboard manufacturers with poor UEFI implementations seem to only support the /EFI/BOOT directory location for the .EFI file in the EFI System Partition (ESP). The GRUB installer can create the .EFI file in this location automatically by appending the --removable option to the install command. Ensure the ESP has been mounted before running the following command; presuming it is mounted at /efi (as defined earlier), run:
root #grub-install --target=x86_64-efi --efi-directory=/efi --removable
This creates the 'default' directory defined by the UEFI specification, and then creates a file with the default name: BOOTX64.EFI. |
Is there something like this for efibootmgr?
Sorry I did not mentioned that before, but I completely forgot about it. |
EDIT:
| Pietinger wrote: | | I have to ask how OP was able to create the other (old) UEFI entries. |
I think I may have "discovered" the source of the problem. I'm really sorry Pietinger.  |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Sun Jan 28, 2024 11:01 pm Post subject: |
|
|
| sokrovenno wrote: | EDIT: Hey, I don't know if it matters, but when I installed grub I remember I had to use this code:
| Code: | | grub-install --target=x86_64-efi --efi-directory=/efi --removable |
[...]
Is there something like this for efibootmgr?
Sorry I did not mentioned that before, but I completely forgot about it. |
No need to say sorry. 
Yes, I have seen that there was also a \EFI\boot\bootx64.efi ... it will be created when you use the parameter "--removable" ... BUT ... it was surely not necessary ... maybe you had an other problem at that time ... e.g. If you want use "efibootmgr" you must boot with an UEFI-capable medium; the kernel must have support for efivarfs; this efivarfs must be mounted. If one of these is missing then grub-install will also fail.
Usually grub-install starts efibootmgr to create an entry for its own \EFI\gentoo\grubx64.efi when not using this paramter; WITH this parameter it copies its own grubx64.efi AS bootx64.efi AND dont try to create an UEFI entry, because \EFI\boot\bootx64.efi is a "hardcoded" name that every UEFI must recognize - EVEN without an entry pointing to this.
So, yes, you can boot an USB stick with a \EFI\boot\bootx64.efi on it WITHOUT an UEFI entry pointing to it (nobody would be happy if they must create an UEFI entry before they are able to boot form a stick  )... this is also the sense of this hardcoded name (and from here comes the name "removable"). Using it on a harddisk is not the primary goal for this hardcoded name. It is only used on (old) UEFI systems which are crappy and dont accept a new entry (there has been also some really bad UEFI systems where the start of Windows was hardcoded and didnt allow any new/other entry).
NOW ... you surely dont have such a crappy system, BECAUSE you have been managed to create some new entries and boot directly a stub kernel.
The last successfully boot was with entry number 0006 POINTING to \EFI\GENTOO\BZIMAGE.EFI (see post: https://forums.gentoo.org/viewtopic-p-8814675.html#8814675 )
So please forget GRUB ... and forget even more the parm "--removable". I am convinced that you had another problem at that time (when installing grub).
My questions now:
Have you deleted the 3 entries ?
Have you give new partlabels to all 3 partitions of SSD ?
Then after shutdown and power off AND booting with GentooAdminCD:
NOW, what says "efibootmgr" ? Have you now tried to create again an entry ?
Maybe try to power off after this. Start again into BIOS. Which choices it gives you now ?
...
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
skellr
l33t
Joined: 18 Jun 2005
Posts: 976
Location: The Village, Portmeirion
|
| Posted: Sun Jan 28, 2024 11:14 pm Post subject: |
|
|
| sokrovenno wrote: | EDIT: Hey, I don't know if it matters, but when I installed grub I remember I had to use this code:
| Code: | | grub-install --target=x86_64-efi --efi-directory=/efi --removable |
without the --removable it was not detected.
I was looking here and it seems that is because my motherboard.
| Quote: | Some motherboard manufacturers with poor UEFI implementations seem to only support the /EFI/BOOT directory location for the .EFI file in the EFI System Partition (ESP). The GRUB installer can create the .EFI file in this location automatically by appending the --removable option to the install command. Ensure the ESP has been mounted before running the following command; presuming it is mounted at /efi (as defined earlier), run:
root #grub-install --target=x86_64-efi --efi-directory=/efi --removable
This creates the 'default' directory defined by the UEFI specification, and then creates a file with the default name: BOOTX64.EFI. |
Is there something like this for efibootmgr?
Sorry I did not mentioned that before, but I completely forgot about it. |
Yes, The UEFI firmware will look for EFI/BOOT/BOOT64.EFI as a fallback to boot if you just select a device to boot from.
You could try copying /EFI/SSD/BZIMAGE.EFI to EFI/BOOT/BOOTX64.EFI as a temporary workaround.
When you reboot there is a key to press to access the boot device menu, maybe F10, and then just select the SSD to boot.
When you see the boot device options is there an option to "boot from efi file", sometimes you can use this to browse to a specific file in the ESP to boot.
Last edited by skellr on Mon Jan 29, 2024 3:06 am; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Sun Jan 28, 2024 11:17 pm Post subject: |
|
|
| sokrovenno wrote: | EDIT:
| Pietinger wrote: | | I have to ask how OP was able to create the other (old) UEFI entries. |
I think I may have "discovered" the source of the problem. I'm really sorry Pietinger. |
???
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
skellr
l33t
Joined: 18 Jun 2005
Posts: 976
Location: The Village, Portmeirion
|
| Posted: Sun Jan 28, 2024 11:17 pm Post subject: |
|
|
| pietinger wrote: | | skellr wrote: | I had an old HP laptop that wouldn't remember a newly created entry unless it was powered off. They wouldn't stick on a "reboot".
You could try again and then halt the system instead of rebooting. |
I greatly appreciate your information, but I am skeptical because I have to ask how OP was able to create the other (old) UEFI entries. But of course it's always worth a try.
(I'm sorry, I'm in a bad mood because this might be the first UEFI system I fail.  ) |
I'm not sure why it's trying to hold on to the old ESP partition that was deleted. The old identifiers went from HD(*) to VenHw(*).
Buggy/hardcoded Firmware? |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Sun Jan 28, 2024 11:24 pm Post subject: |
|
|
| Quote: | | Have you deleted the 3 entries? |
Yes
| Quote: | | Have you give new partlabels to all 3 partitions of SSD ? |
Yes
| Quote: | | Then after shutdown and power off AND booting with GentooAdminCD: |
I'm currently on GentooLiveCD. My computer is useless until we can solve this.
| Quote: | | NOW, what says "efibootmgr" ? Have you now tried to create again an entry ? |
| Code: | gentoo@livecd / $ efibootmgr
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0009
Boot0009* UEFI: SanDisk Cruzer Blade 1.26 PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(2,GPT,4d4c68f9-3e96-4eda-998e-d69950fba76d,0x234,0x1680)0000424f
|
| Quote: | | Maybe try to power off after this. Start again into BIOS. Which choices it gives you now ? |
I tried poweroff instead of rebooting, but to no avail. The only options at my BIOS is my USB stick with the GentooLiveCD.
| Quote: | | If you want use "efibootmgr" you must boot with an UEFI-capable medium; the kernel must have support for efivarfs; this efivarfs must be mounted |
Sorry, but I did not understood what you meant. But looks like my kernel supports efivarfs
| Code: | gentoo@livecd / $ grep -i efivar /mnt/gentoo/usr/src/linux/.config
CONFIG_EFIVAR_FS=y
|
EDIT: Now I see. There is an Gentoo AdminCD. I'll try to put it on my USB stick.
After booting the Gentoo AdminCD efbootmgr gave the same message above. Only my USB appears.
Last edited by sokrovenno on Mon Jan 29, 2024 12:29 am; edited 5 times in total |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Sun Jan 28, 2024 11:26 pm Post subject: |
|
|
| pietinger wrote: | | sokrovenno wrote: | EDIT:
| Pietinger wrote: | | I have to ask how OP was able to create the other (old) UEFI entries. |
I think I may have "discovered" the source of the problem. I'm really sorry Pietinger. |
??? |
Oh forget it. I thought it was the grub thing, but you already said it is not. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Mon Jan 29, 2024 1:02 am Post subject: |
|
|
sokrovenno,
because I am out of ideas at the moment (and you said you need the notebook to work with it) I would suggest to do what @skellr suggested:
| skellr wrote: | Yes, The UEFI firmware will look for EFI/BOOT/BOOT64.EFI as a fallback to boot if you just select a device to boot from.
You could try copying /EFI/SSD/BZIMAGE.EFI to EFI/BOOT/BOOT64.EFI as a temporary workaround.
When you reboot there is a key to press to access the boot device menu, maybe F10, and then just select the SSD to boot.
When you see the boot device options is there an option to "boot from efi file", sometimes you can use this to browse to a specific file in the ESP to boot. |
If this works, then there is - at the moment - no need to "re-create" the first partition of the (old) hd. I will think about the problem ... maybe I get some ideas ... 
(In the mean time please make sure that "fast boot" in your BIOS remains disabled (forever); also CSM mode must stay disabled)
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Mon Jan 29, 2024 1:35 am Post subject: |
|
|
Because I can't sleep ...
... I have checked so far:
1. SSD has "gpt"
2. First partition of SSD has ESP-flag on (says parted)
3. It has FAT32 (says parted and blkid)
4. There is only one directory named "EFI" on this partition.
5. In this dir is a dir named "ssd" and
6. In there is a "bzImage.efi" (so, yes, it has also the correct suffix "efi")
7. We use the correct command (with correct parms) to create an UEFI entry for this kernel:
| Code: | | # efibootmgr -c -d /dev/nvme0n1 -L "SSD" -l "\EFI\ssd\bzImage.efi" |
8. Because OP was able to see it once in the output of "efibootmgr" ...
( in this post: https://forums.gentoo.org/viewtopic-p-8814705.html#8814705 )
... I know he used this command correct !
(once I had a problem with somebody who tried to give the partition to efibootmgr instead the device: "-d /dev/nvme0n1p1" )
The last thing I have not checked is the KERNEL itself ...
If I ask my bzImage I get these answers:
| Code: | # file bzImage.efi
bzImage.efi: Linux kernel x86 boot executable bzImage, version 6.7.2-gentoo (root@sun) #1 SMP PREEMPT_DYNAMIC Fri Jan 26 17:05:31 CET 2024, RO-rootFS, swap_dev 0X9, Normal VGA
#
# objdump -h bzImage.efi
bzImage.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .setup 00003000 0000000000001000 0000000000001000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00997000 0000000000004000 0000000000004000 00004000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .data 00000400 000000000099b000 000000000099b000 0099b000 2**4
CONTENTS, ALLOC, LOAD, DATA |
The file format MUST be a pei-x86-64 ! If it is not THEN this is missing:
| Code: | Processor type and features --->
[*] EFI runtime service support
[*] EFI stub support |
(I have not checked before, because OP said he used the same kernel as before; only with a different "root=" in built-in kernel command line)
If all this is correct, then I come to the conclusion that "something" in UEFI-BIOS is "hard-connected" to the harddisk ... but I have never heard about such a thing before and I cannot believe it ...
I dont want believe it .... 
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Mon Jan 29, 2024 2:33 am Post subject: |
|
|
P.P.S.: There is a typo in the post of @skellr... BOOTX64.EFI is correct ... NOT BOOT64.EFI
(just have seen it ... yes, blind again  )
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Mon Jan 29, 2024 2:42 am Post subject: |
|
|
I have another problem. As I have only one USB sticker 8G, I had to burn the Gentoo AdminCD on it. So I downloaded the AdminCD and the latest release of the Live GUI USB Image in an old notebook. So I burned and booted the AdminCD got the information @Pietinger asked and later burned the latest release of the LiveGUI on my USB sticker. NOW when I boot the latest release of the Gentoo LiveGUI USB I cannot connect to the internet because it says something about 'I do not have permission to access wifi'. I cannot control backlight and other things. Looks like it have some weird bug (at least with my hardware). I have older version of the Gentoo LiveCD on my HDD on the new notebook. But I cannot burn it on my USB sticker again because it is the only way I have to access my HDD (on new notebook). If I want to burn the older version that I have on my HDD I should somehow boot and copy it to my older notebook to burn it again. But as I mentioned the only way I have to do this is with this one USB sticker.
Definitely today is not my luck day xD
I'm sorry if it is confusing, but that is all can do with my poor english.
Is there a place where I can find older versions of the Gentoo LiveCD? I had to burn a LinuxMint on my USBsticker in order to access wifi. 
@Pietinger
| Code: | [*] EFI runtime service support
[*] EFI stub support |
| Code: |
file /efi/efi/ssd/bzImage.efi
bzImage.efi: Linux kernel x86 boot executable bzImage, version 6.1.67-gentoo (root@hive) #3 SMP PREEMPT_DYNAMIC Sun Jan 28 10:29:29 -03 2024, RO-rootFS, swap_dev 0XC, Normal VGA
objdump -h /mnt/gentoo/usr/src/linux/arch/x86/boot/bzImage
/mnt/gentoo/usr/src/linux/arch/x86/boot/bzImage: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .setup 000039e0 0000000001000200 0000000001000200 00000200 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .reloc 00000020 0000000001003be0 0000000001003be0 00003be0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .text 00cc2640 0000000001003c00 0000000001003c00 00003c00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
Now I'm going to sleep cause I'm very tired and frustrated.
I hope we can solve this eventually. But I'm considering trying to install Gentoo on my SSD.
Last edited by sokrovenno on Mon Jan 29, 2024 5:37 pm; edited 2 times in total |
|
| Back to top |
|
|
skellr
l33t
Joined: 18 Jun 2005
Posts: 976
Location: The Village, Portmeirion
|
| Posted: Mon Jan 29, 2024 3:06 am Post subject: |
|
|
| pietinger wrote: | P.P.S.: There is a typo in the post of @skellr... BOOTX64.EFI is correct ... NOT BOOT64.EFI
(just have seen it ... yes, blind again ) |
Thanks, good eye.
I can at least edit that comment |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2965
Location: Edge of marsh USA
|
| Posted: Mon Jan 29, 2024 3:12 am Post subject: |
|
|
You should be able to do everything you need to do with Linux Mint on your USB stick.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Mon Jan 29, 2024 10:20 am Post subject: |
|
|
| figueroa wrote: | | You should be able to do everything you need to do with Linux Mint on your USB stick. |
Oh, okay. I was taking a look on the Handbook and looks like they implemented some things for better compatibility. So I thought it was better to use it. It's good to know it is not necessary. |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Mon Jan 29, 2024 12:31 pm Post subject: |
|
|
Thank you @skellr and @Pietinger. The work around really worked out. I'm able to boot the SSD now. 
But I'm really curious to know what is going on with my UEFI. I tried to add new entries to no avail. I reading the wiki on efibootmgr and the installation process on the Handbook.
| Pietinger wrote: | | If all this is correct, then I come to the conclusion that "something" in UEFI-BIOS is "hard-connected" to the harddisk ... |
If that is the case, we should get an UEFI entry for my HDD again, right? |
|
| Back to top |
|
|
skellr
l33t
Joined: 18 Jun 2005
Posts: 976
Location: The Village, Portmeirion
|
| Posted: Tue Jan 30, 2024 12:02 am Post subject: |
|
|
| sokrovenno wrote: | Thank you @skellr and @Pietinger. The work around really worked out. I'm able to boot the SSD now.
But I'm really curious to know what is going on with my UEFI. I tried to add new entries to no avail. I reading the wiki on efibootmgr and the installation process on the Handbook.
| Pietinger wrote: | | If all this is correct, then I come to the conclusion that "something" in UEFI-BIOS is "hard-connected" to the harddisk ... |
If that is the case, we should get an UEFI entry for my HDD again, right? |
Good news! This will make it easier to reboot into you system without needing to use "live media/USB".
One problem that I have with my UEFI is that it won't let me add more than 3 'custom' entries. maybe you have a similar issue?
I'm not sure where your entries for Boot0007* Backup and Boot0008* Secure are coming from. Maybe they are using some of your "quota"?
If you have no intention of using them again from your old HDD you could try deleting them with efibootmgr?
What does efibootmgr show you now? |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Tue Jan 30, 2024 11:30 am Post subject: |
|
|
| Quote: | | One problem that I have with my UEFI is that it won't let me add more than 3 'custom' entries. maybe you have a similar issue? |
Apparently not. It won't let me have any custom entry.
| Quote: | | I'm not sure where your entries for Boot0007* Backup and Boot0008* Secure are coming from. Maybe they are using some of your "quota"? |
The Backup and Secure entries came from this article. But they no longer exist.
| Quote: | | If you have no intention of using them again from your old HDD you could try deleting them with efibootmgr? |
I already deleted them as Pietinger instructed me here.
| Quote: | | What does efibootmgr show you now? |
| Code: | efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001
Boot0001* UEFI OS HD(1,GPT,acd6ee6e-d58a-5e43-a9ef-86793a1034c4,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f |
One thing that stood out to me is that the Boot0001 is using my /dev/sda1 to create the entry above. Take a look here:
Boot0001* UEFI OS HD(1,GPT,acd6ee6e-d58a-5e43-a9ef-86793a1034c4,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
blkid: /dev/sda1: UUID="C0C9-CE0C" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="acd6ee6e-d58a-5e43-a9ef-86793a1034c4"
And the File is appearing in uppercase, but when I try create a new entry it appears in lower case. But all my entries before this problem started were uppercase too (as you can see here.)
Boot0001* UEFI OS HD(1,GPT,acd6ee6e-d58a-5e43-a9ef-86793a1034c4,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Here is an example; I just added this entry:
| Code: | doas efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l "\efi\ssd\bzImage.efi"
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0001* UEFI OS HD(1,GPT,acd6ee6e-d58a-5e43-a9ef-86793a1034c4,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0000* Gentoo HD(1,GPT,1c6dcbae-af8d-b24f-b096-b626e61cfdcf,0x800,0x200000)/File(\efi\ssd\bzImage.efi) |
In addition to that the "lower case" File it does not appear a code like the Boot0001: File(\EFI\BOOT\BOOTX64.EFI)0000424f
I'll just try to create a new entry with the whole path upper case just to see how it goes. e.g (doas efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l "\EFI\SSD\BZIMAGE.EFI")
EDIT: I just removed the /dev/sda1 and can no longer boot my SSD. xD
I`ll try make the entry at my SSD instead.
EDIT 2: Now I'm booting on my SSD again.
I just added the new entry:
| Code: | doas efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l "\efi\ssd\bzImage.efi"
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0001* UEFI OS HD(1,GPT,1c6dcbae-af8d-b24f-b096-b626e61cfdcf,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0000* Gentoo HD(1,GPT,1c6dcbae-af8d-b24f-b096-b626e61cfdcf,0x800,0x200000)/File(\efi\ssd\bzImage.efi) |
EDIT 4: LOOKS LIKE THE PROBLEM IS SOLVED NOW!
| Code: | efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0000* Gentoo HD(1,GPT,1c6dcbae-af8d-b24f-b096-b626e61cfdcf,0x800,0x200000)/File(\EFI\SSD\BZIMAGE.EFI)
Boot0001* UEFI OS HD(1,GPT,1c6dcbae-af8d-b24f-b096-b626e61cfdcf,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f |
Well I had excluded /dev/sda1 before, as Pietinger instructed me, and things did not worked. So I created it again after we tried to no avail create an entry for the SSD.
Now I excluded it again and tried to add a new entry and things just worked out. I don't know what happened, but now everything is on track again.
Thank you everyone that helped. I wouldn't have done it without you.
Best regards,
sokrovenno. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Tue Jan 30, 2024 1:54 pm Post subject: |
|
|
sokrovenno,
I guess you made these steps:
1. Booting from SSD with a \EFI\BOOT\BOOTX64.EFI (which should work always; and it worked also in your case)
2. Removing sda1
3. Creating an entry for \efi\ssd\bzImage.efi (pointing to /nvme0n1p1)
4. Now your UEFI accepts this entry
If this is true THEN:
It looks like that your UEFI accepts only (new) entries pointing to a DISK from which the system has booted. As long as you dont boot from it, it dont accepts entries pointing to other disks. Maybe ... only maybe you are NOW not allowed to create a new entry pointing to an image on sda1.
If this is true, it is a clear violation of the UEFI specifications.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
sokrovenno
n00b
Joined: 23 Aug 2023
Posts: 65
|
| Posted: Tue Jan 30, 2024 2:24 pm Post subject: |
|
|
Yeah, I thougt something similar. Maybe it was not accepted before because UEFI never used it/recognized it. And after recognizing, it goes 'Hey it is actually possible to use this thing!'
| Quote: | | ... you are NOW not allowed to create a new entry pointing to an image on sda1. |
Well, we could test it... But my idea is to use my HDD to store things and keep my SSD as clean as possible, in order to avoid writing things on it to extend it's life expectancy. (I think I'm becoming a little paranoid. )
Hey, I'm curious about a thing and maybe you can give me an answer. As I read the Handbook again yesterday, I noticed that now they recommend using xfs instead of ext4. And I was thinking; is it possible to change the filesystem type in a trivial way? (like just 'mkfs.xfs /dev/sda3' without risk of losing data). Not that I intend to change the fs. I never had a problem with ext4 and I'm glad with it. It's just a question that crossed my mind. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Tue Jan 30, 2024 2:29 pm Post subject: |
|
|
| sokrovenno wrote: | | [...] And I was thinking; is it possible to change the filesystem type in a trivial way? (like just 'mkfs.xfs /dev/sda3' without risk of losing data).[...] |
Every formatting will give you a formated and clean partition. Yes, you can easily format it with "mkfs.xfs". No, after this the partition is empty.
(BTW: I am using also ext4 and will not change it. Please take a look into: https://forums.gentoo.org/viewtopic-t-1117706-start-0.html )
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4253
Location: Bavaria
|
| Posted: Tue Jan 30, 2024 2:37 pm Post subject: |
|
|
| sokrovenno wrote: | | Well, we could test it... But my idea is to use my HDD to store things and keep my SSD as clean as possible, [...] |
If you want you can test just the creating of an entry (pointing to sda1) ... dont forget you can always format some partitions and copy back all you want
I am using my HD as storage for seldom used files (movies) ... and when I partitioned it I made 4 partitions without any data in it ... for testing in the future ... and the future is now for me: I am testing bcachefs with the first two of them:
| Code: | # parted -l
Modell: ATA ST4000DM004-2U91 (scsi)
Festplatte /dev/sda: 4001GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 17,2GB 17,2GB primary
2 17,2GB 34,4GB 17,2GB primary
3 34,4GB 68,7GB 34,4GB primary
4 68,7GB 137GB 68,7GB ext4 Dist
5 137GB 1512GB 1374GB ext4 Hd
6 1512GB 4001GB 2489GB ext4 Test
Modell: Samsung SSD 980 PRO 1TB (nvme)
Festplatte /dev/nvme0n1: 1000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 268MB 267MB fat32 Boot boot, esp
2 268MB 4295MB 4027MB linux-swap(v1) Swap
3 4295MB 1000GB 996GB ext4 Root |
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
