Re: [gentoo-user] ISO verification question.
在 2020/12/24 上午10:29, Γιώργος Κωστόπουλος 写道: Στις Πέμ, 24 Δεκ 2020 στις 2:34 π.μ., ο/η Michael έγραψε: Hi Γιώργος, On Wednesday, 23 December 2020 20:00:28 GMT Γιώργος Κωστόπουλος wrote: Hi! :-) I just downloaded the minimal installation ISO and I was trying the verification instructions. I admit that I'm not any kind of gpg expert, so the results are somewhat confusing to me. Can someone shed some light on them? Here's console's output: gpg --verify install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc gpg: Signature made Tue Dec 22 17:01:06 2020 EET gpg:using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) " [unknown] This is telling you the 'install-amd64- minimal-20201222T005811Z.iso.DIGESTS.asc' file which contains hashes of the various files listed in it, has a valid signature - i.e. the hashes of these files have not been tampered with and they have been signed by the owner of the Gentoo Release Engineering key. Have a look here for the published developer keys: https://wiki.gentoo.org/wiki/Project:RelEng gpg: WARNING: This key is not certified with a trusted signature! This is telling you the above public key has not been marked as trusted in your own gpg keyring. gpg: There is no indication that the signature belongs to the owner. This is to be expected, unless you have checked the fingerprint of the imported key yourself against the keys published in the URL I provided above and thereafter edited the key's level of trust to mark it as trusted in your gpg keyring; e.g. you'd need to run: gpg --edit-key and follow the options available for this gpg subcommand to edit the key's trust level. This is not necessary for a key you'll only use once, as long as you satisfy yourself the key fingerprint below matches what is published on the RelEng project page. Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 043D gpg: WARNING: not a detached signature; file 'install-amd64-minimal-20201222T005811Z.iso.DIGESTS' was NOT verified! and: sha512sum -c install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc install-amd64-minimal-20201222T005811Z.iso: OK install-amd64-minimal-20201222T005811Z.iso: FAILED install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: OK install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: FAILED sha512sum: WARNING: 14 lines are improperly formatted sha512sum: WARNING: 2 computed checksums did NOT match TIA! :-) Giorgos. . So the above output checked the sha512 hashes of all listed files and found some to be correct - you can use 'install-amd64-minimal-20201222T005811Z.iso' for your installation. The failed checks above refer to a different hash e.g. sha256. HTH. THANKS Michael for your help!!! What confused me, was the "failed" results and the warnings of the sha512sum command. THANKS AGAIN for the clarification!!! :-) G. The handbook said, With the cryptographic signature validated, next verify the checksum to make sure the downloaded ISO file is not corrupted. The.DIGESTS.ascfile contains multiple hashing algorithms, so one of the methods to validate the right one is to first look at the checksum registered in the.DIGESTS.ascfile. For instance, to get the SHA512 checksum: |user $||grep -A 1 -i sha512 install-amd64-minimal-20141204.iso.DIGESTS.asc| # SHA512 HASH 364d32c4f8420605f8a9fa3a0fc55864d5b0d1af11aa62b7a4d4699a427e5144b2d918225dfb7c5dec8d3f0fe2cddb7cc306da6f0cef4f01abec33eec74f3024 install-amd64-minimal-20141204.iso -- # SHA512 HASH 0719a8954dc7432750de2e3076c8b843a2c79f5e60defe43fcca8c32ab26681dfb9898b102e211174a895ff4c8c41ddd9e9a00ad6434d36c68d74bd02f19b57f install-amd64-minimal-20141204.iso.CONTENTS In the above output, two SHA512 checksums are shown - one for theinstall-amd64-minimal-20141204.isofile and one for its accompanying.CONTENTSfile. Only the first checksum is of interest, as it needs to be compared with the calculated SHA512 checksum which can be generated as follows: |user $||sha512sum install-amd64-minimal-20141204.iso| 364d32c4f8420605f8a9fa3a0fc55864d5b0d1af11aa62b7a4d4699a427e5144b2d918225dfb7c5dec8d3f0fe2cddb7cc306da6f0cef4f01abec33eec74f3024 install-amd64-minimal-20141204.iso As both checksums match, the file is not corrupted and the installation can continue. you just missed to grep sha512 hash from the file :-) so get some results of un-related lines. -- bobwxc OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] ISO verification question.
Στις Πέμ, 24 Δεκ 2020 στις 2:34 π.μ., ο/η Michael έγραψε: > > Hi Γιώργος, > > On Wednesday, 23 December 2020 20:00:28 GMT Γιώργος Κωστόπουλος wrote: > > Hi! :-) > > > > I just downloaded the minimal installation ISO and I was trying the > > verification instructions. > > I admit that I'm not any kind of gpg expert, so the results are > > somewhat confusing to me. > > Can someone shed some light on them? > > > > Here's console's output: > > >gpg --verify install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc > > > > gpg: Signature made Tue Dec 22 17:01:06 2020 EET > > gpg:using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D > > gpg: Good signature from "Gentoo Linux Release Engineering (Automated > > Weekly Release Key) " [unknown] > > This is telling you the 'install-amd64- > minimal-20201222T005811Z.iso.DIGESTS.asc' file which contains hashes of the > various files listed in it, has a valid signature - i.e. the hashes of these > files have not been tampered with and they have been signed by the owner of > the Gentoo Release Engineering key. > > Have a look here for the published developer keys: > > https://wiki.gentoo.org/wiki/Project:RelEng > > > > gpg: WARNING: This key is not certified with a trusted signature! > > This is telling you the above public key has not been marked as trusted in > your own gpg keyring. > > > > gpg: There is no indication that the signature belongs to the > > owner. > > This is to be expected, unless you have checked the fingerprint of the > imported key yourself against the keys published in the URL I provided above > and thereafter edited the key's level of trust to mark it as trusted in your > gpg keyring; e.g. you'd need to run: > > gpg --edit-key > > and follow the options available for this gpg subcommand to edit the key's > trust level. This is not necessary for a key you'll only use once, as long as > you satisfy yourself the key fingerprint below matches what is published on > the RelEng project page. > > > > Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E > > 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 > > 043D gpg: WARNING: not a detached signature; file > > 'install-amd64-minimal-20201222T005811Z.iso.DIGESTS' was NOT verified! > > > > and: > > >sha512sum -c install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc > > > > install-amd64-minimal-20201222T005811Z.iso: OK > > install-amd64-minimal-20201222T005811Z.iso: FAILED > > install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: OK > > install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: FAILED > > sha512sum: WARNING: 14 lines are improperly formatted > > sha512sum: WARNING: 2 computed checksums did NOT match > > > > > > TIA! :-) > > Giorgos. > > . > > So the above output checked the sha512 hashes of all listed files and found > some to be correct - you can use 'install-amd64-minimal-20201222T005811Z.iso' > for your installation. The failed checks above refer to a different hash e.g. > sha256. > > HTH. THANKS Michael for your help!!! What confused me, was the "failed" results and the warnings of the sha512sum command. THANKS AGAIN for the clarification!!! :-) G.
Re: [gentoo-user] ISO verification question.
Hi Γιώργος, On Wednesday, 23 December 2020 20:00:28 GMT Γιώργος Κωστόπουλος wrote: > Hi! :-) > > I just downloaded the minimal installation ISO and I was trying the > verification instructions. > I admit that I'm not any kind of gpg expert, so the results are > somewhat confusing to me. > Can someone shed some light on them? > > Here's console's output: > >gpg --verify install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc > > gpg: Signature made Tue Dec 22 17:01:06 2020 EET > gpg:using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D > gpg: Good signature from "Gentoo Linux Release Engineering (Automated > Weekly Release Key) " [unknown] This is telling you the 'install-amd64- minimal-20201222T005811Z.iso.DIGESTS.asc' file which contains hashes of the various files listed in it, has a valid signature - i.e. the hashes of these files have not been tampered with and they have been signed by the owner of the Gentoo Release Engineering key. Have a look here for the published developer keys: https://wiki.gentoo.org/wiki/Project:RelEng > gpg: WARNING: This key is not certified with a trusted signature! This is telling you the above public key has not been marked as trusted in your own gpg keyring. > gpg: There is no indication that the signature belongs to the > owner. This is to be expected, unless you have checked the fingerprint of the imported key yourself against the keys published in the URL I provided above and thereafter edited the key's level of trust to mark it as trusted in your gpg keyring; e.g. you'd need to run: gpg --edit-key and follow the options available for this gpg subcommand to edit the key's trust level. This is not necessary for a key you'll only use once, as long as you satisfy yourself the key fingerprint below matches what is published on the RelEng project page. > Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E > 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 > 043D gpg: WARNING: not a detached signature; file > 'install-amd64-minimal-20201222T005811Z.iso.DIGESTS' was NOT verified! > > and: > >sha512sum -c install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc > > install-amd64-minimal-20201222T005811Z.iso: OK > install-amd64-minimal-20201222T005811Z.iso: FAILED > install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: OK > install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: FAILED > sha512sum: WARNING: 14 lines are improperly formatted > sha512sum: WARNING: 2 computed checksums did NOT match > > > TIA! :-) > Giorgos. > . So the above output checked the sha512 hashes of all listed files and found some to be correct - you can use 'install-amd64-minimal-20201222T005811Z.iso' for your installation. The failed checks above refer to a different hash e.g. sha256. HTH. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] pycharm-community crashed on the first start
On Wed, 23 Dec 2020 22:33:59 +0200 gevisz wrote: > I have just installed pycharm-community 2020.1.3 (marked stable) with > its default settings (that is with +bundled-jdk use flag) on my newly > installed Gentoo system and tried to start it using the following > command: > /opt/pycharm-community/bin/pycharm.sh > > Unfortunately, pycharm crashed on the start reporting the following > error: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x, pid=26676, tid=26725 > # > # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build > 11.0.7+10-b765.64) # Java VM: OpenJDK 64-Bit Server VM > (11.0.7+10-b765.64, mixed mode, tiered, compressed oops, concurrent > mark sweep gc, linux-amd64) # Problematic frame: > # C 0x > # > # Core dump will be written. Default location: /home/gevis/core > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > A longer error report from /home/gevis/java_error_in_PYCHARM_26676.log > tells me nothing meaningful. :( > > I have no other Java JDK installed on my system. > > Is it a known problem? Shall I try to install pycharm with > - use flag? No crashes here with the same pycharm version and bundled-jdk enabled. I have dev-java/icedtea-bin installed in the system but pycharm does not use it (About dialog show the same java env. as yours - 11.0.7+10-b765.64). Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
[gentoo-user] pycharm-community crashed on the first start
I have just installed pycharm-community 2020.1.3 (marked stable) with its default settings (that is with +bundled-jdk use flag) on my newly installed Gentoo system and tried to start it using the following command: /opt/pycharm-community/bin/pycharm.sh Unfortunately, pycharm crashed on the start reporting the following error: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x, pid=26676, tid=26725 # # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10-b765.64) # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10-b765.64, mixed mode, tiered, compressed oops, concurrent mark sweep gc, linux-amd64) # Problematic frame: # C 0x # # Core dump will be written. Default location: /home/gevis/core # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. A longer error report from /home/gevis/java_error_in_PYCHARM_26676.log tells me nothing meaningful. :( I have no other Java JDK installed on my system. Is it a known problem? Shall I try to install pycharm with -bundled-jdk use flag?
[gentoo-user] ISO verification question.
Hi! :-) I just downloaded the minimal installation ISO and I was trying the verification instructions. I admit that I'm not any kind of gpg expert, so the results are somewhat confusing to me. Can someone shed some light on them? Here's console's output: >gpg --verify install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc gpg: Signature made Tue Dec 22 17:01:06 2020 EET gpg:using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 043D gpg: WARNING: not a detached signature; file 'install-amd64-minimal-20201222T005811Z.iso.DIGESTS' was NOT verified! > and: >sha512sum -c install-amd64-minimal-20201222T005811Z.iso.DIGESTS.asc install-amd64-minimal-20201222T005811Z.iso: OK install-amd64-minimal-20201222T005811Z.iso: FAILED install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: OK install-amd64-minimal-20201222T005811Z.iso.CONTENTS.gz: FAILED sha512sum: WARNING: 14 lines are improperly formatted sha512sum: WARNING: 2 computed checksums did NOT match > TIA! :-) Giorgos. .
Re: [gentoo-user] Asterisk 13.36 - ast_db_put: Couldn't execute statement: attempt to write a readonly database
On 12/23/2020 12:47 PM, the...@sys-concept.com wrote: > When I try to register provision/register equipment to asterisk I get an > error message: > > [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute > statement: SQL logic error > -- Registered SIP 'pstn-5665' at 10.0.0.110:5060 >> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer > pstn-5665 > [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute > statement: SQL logic error > -- Registered SIP 'pstn-1270' at 10.0.0.110:5060 >> Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer > pstn-1270 > [Dec 23 12:32:51] NOTICE[21685]: chan_sip.c:24776 handle_response_peerpoke: > Peer 'pstn-5665' is now Reachable. (61ms / 2000ms) > [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute > statement: attempt to write a readonly database > -- Registered SIP '369' at 10.0.0.110:5060 > > /var/lib/asterisk > -rw-r--r-- 1 root root 16384 Dec 23 12:10 astdb.sqlite3 > > In my old asterisk-11.25 this file has owner "asterisk:astersik" but > changing the ownership of that file doesn't solve the problem, still getting > the same error: > > ast_db_put: Couldn't execute statement: attempt to write a readonly database To solve it, I tried to follow the steps from: https://community.asterisk.org/t/asterisk-warning/78443 But it didn't help.
[gentoo-user] Asterisk 13.36 - ast_db_put: Couldn't execute statement: attempt to write a readonly database
When I try to register provision/register equipment to asterisk I get an error message: [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute statement: SQL logic error -- Registered SIP 'pstn-5665' at 10.0.0.110:5060 > Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer pstn-5665 [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute statement: SQL logic error -- Registered SIP 'pstn-1270' at 10.0.0.110:5060 > Saved useragent "Audiocodes-Sip-Gateway-/v.5.80A.032.003" for peer pstn-1270 [Dec 23 12:32:51] NOTICE[21685]: chan_sip.c:24776 handle_response_peerpoke: Peer 'pstn-5665' is now Reachable. (61ms / 2000ms) [Dec 23 12:32:51] WARNING[21685]: db.c:350 ast_db_put: Couldn't execute statement: attempt to write a readonly database -- Registered SIP '369' at 10.0.0.110:5060 /var/lib/asterisk -rw-r--r-- 1 root root 16384 Dec 23 12:10 astdb.sqlite3 In my old asterisk-11.25 this file has owner "asterisk:astersik" but changing the ownership of that file doesn't solve the problem, still getting the same error: ast_db_put: Couldn't execute statement: attempt to write a readonly database
Re: [gentoo-user] Re: Big USB disks
On Wednesday, 23 December 2020 18:56:37 GMT Mark Knecht wrote: > On Wed, Dec 23, 2020 at 11:25 AM Peter Humphrey > > wrote: > > On Wednesday, 23 December 2020 09:54:36 GMT Nikos Chantziaras wrote: > > > On 22/12/2020 14:58, Peter Humphrey wrote: > > > > Greetings, > > > > > > > > Just a quickie - is there a way to enable a machine built on an MSDOS > > BIOS > > > > A *what* BIOS? Do mean you run MS-DOS as on OS? > > > > What would you call it? > > > > $ file /boot/boot.0800: DOS/MBR boot sector. > > > > -- > > Regards, > > Peter. > > Are you possibly conflating BIOS which is computer code in ROM on the > motherboard and what the CPU runs on power up with the MBR which resides on > the hard drive you are booting from? > > - Mark The file boot.0800 appears to be a backup of the MBR bootloader code and I bet it is 512B in size. It reflects dev with major number 08 and minor number 00, e.g. /dev/hda1, or /dev/sda1. I would also bet this was created by LILO, which is polite enough to back up the existing MBR before dumping its own code in the first sector of a hard disk. Characteristically, MSWindows is not that accommodating for other persons' bootloader codes. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Big USB disks
On Wed, Dec 23, 2020 at 11:25 AM Peter Humphrey wrote: > > On Wednesday, 23 December 2020 09:54:36 GMT Nikos Chantziaras wrote: > > On 22/12/2020 14:58, Peter Humphrey wrote: > > > Greetings, > > > > > > Just a quickie - is there a way to enable a machine built on an MSDOS BIOS > > > > A *what* BIOS? Do mean you run MS-DOS as on OS? > > What would you call it? > > $ file /boot/boot.0800: DOS/MBR boot sector. > > -- > Regards, > Peter. Are you possibly conflating BIOS which is computer code in ROM on the motherboard and what the CPU runs on power up with the MBR which resides on the hard drive you are booting from? - Mark
Re: [gentoo-user] Re: Big USB disks
On Wednesday, 23 December 2020 09:54:36 GMT Nikos Chantziaras wrote: > On 22/12/2020 14:58, Peter Humphrey wrote: > > Greetings, > > > > Just a quickie - is there a way to enable a machine built on an MSDOS BIOS > > A *what* BIOS? Do mean you run MS-DOS as on OS? What would you call it? $ file /boot/boot.0800: DOS/MBR boot sector. -- Regards, Peter.
Re: [gentoo-user] Is a USB-key-to-hard-drive-tap-dance-boot possible?
On Tue, 22 Dec 2020 23:05:28 -0500, Walter Dnes wrote: > Situation; I have a Dell XPS8940 with that abomination known as UEFI, > and no "legacy boot". UEFI claims there are no bootable partitions on > the hard drive (/dev/sda). Have you set up a partition of type EFI System (EF00)? This Dell XPS laptop boots perfectly from a UEFI system partition with no need for GRUB. -- Neil Bothwick Bumper Sticker: If you can read this, you are in phaser range. pgpQ1ZgeLTj9z.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Is a USB-key-to-hard-drive-tap-dance-boot possible?
On Wednesday, 23 December 2020 05:37:01 GMT Walter Dnes wrote: > On Wed, Dec 23, 2020 at 04:16:46AM -, Grant Edwards wrote > > > Does the UEFI BIOS recognize that /dev/sda1 exists, but just isn't > > bootable? If yes, then it should be possible to install Grub on a USB > > key and boot a kernel on /dev/sda1. It might be simpler to just put > > the kernel and initrd on the USB key also. Though boot time might be > > slightly slower that way, it won't affect performance after that. > > The point of this excercise is to bypass UEFI BIOS as much as > possible. >From what I've read in the interwebs Intel have been moving to UEFI Class-3 without the legacy BIOS Compatibility Support Module (CSM). Dell who are mostly a Wintel shop would be early adopters I imagine. With no CSM one has to use UEFI and an ESP partition to boot from. Any applications/drivers requiring 16-bit BIOS will no longer work on bare metal. I suppose they should work in QEMU with sgabios.bin as long as QEMU can emulate the interface to the hardware. As far as I know, Intel have not made Secure Boot mandatory, so no need to use Microsoft-RHL keys to sign your kernel images, but either way you will need to drop these in the ESP VFAT formatted partition under an EFI/ directory, or EFI// subdirectory. At some point in this /progress/ towards UEFI Class-3, Dell disabled booting internal drives with CSM. Only external drives/media can be booted if CSM is enabled - I think you need to press F12 to select the external bootable device. > The machine will happily automatically boot from the Gentoo > minimal install USB key, which I believe is grub, so that works. And > the minimal install does indeed recognize /dev/sda, which is why I was > able to install linux in the first place. What I'm looking for is the > grub "recipie" to automatically hand off control to /dev/sda1 at bootup. > This will require leaving a USB key permanently in one of the 6 USB > ports in the back of the machine. You could install GRUB to a USB device, you need to pass the '--removable' option to the grub-install command. > I've been using lilo for 20 years plus, so I don't have a clue about > grub and how it works. I generally have 2 kernels available on the lilo > boot menu, "production" and "experimental". I test the "expermental" > kernel for a while before copying it over the "production" kernel. My > menu normally waits up to 15 seconds. If no keypress, it defaults to > the "production" kernel. Grub would need to load one of > /boot/kernel.experimental or /boot/kernel.production. I could > re-arrange the layout if necessary. Here's my current /boot layout... > > [d531][waltdnes][~] ll /boot > total 18412 > drwxr-xr-x 2 root root4096 Dec 22 21:42 . > drwxr-xr-x 21 root root4096 Oct 24 12:14 .. > -rw-r--r-- 1 root root 0 Oct 11 19:55 .keep > -rw-r--r-- 1 root root 0 Oct 13 05:57 .keep_sys-boot_lilo-0 > -rw--- 1 root root 139264 Dec 22 21:42 .map > -rw-r--r-- 1 root root 2979997 Dec 21 19:31 System.map.experimental > -rw-r--r-- 1 root root 2991033 Oct 13 06:03 System.map.production > -rw-r--r-- 1 root root 512 Oct 13 06:04 boot.0800 > -rw-r--r-- 1 root root 90538 Dec 21 19:31 config.experimental > -rw-r--r-- 1 root root 90579 Oct 13 06:03 config.production > -rw-r--r-- 1 root root 6214192 Dec 21 19:31 kernel.experimental > -rw-r--r-- 1 root root 6271536 Oct 13 06:03 kernel.production GRUB will install its UEFI image grubx64.efi in the ESP partition and then boot with that any OS kernel images you have included in the ESP partition. GRUB will scan the ESP partition and create its grub.cfg file to include in its boot menu automagically any kernel/initramfs images, when you run update- grub. Alternatively, instead of booting a mini OS (UEFI firmware), to boot another mini OS (GRUB), to boot your intended OS (Gentoo), you can skip GRUB altogether and just use efibootmgr to manipulate the UEFI firmware boot menu for your kernel images in the ESP partition. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Big USB disks
On 22/12/2020 14:58, Peter Humphrey wrote: Greetings, Just a quickie - is there a way to enable a machine built on an MSDOS BIOS A *what* BIOS? Do mean you run MS-DOS as on OS?
Re: [gentoo-user] ERROR: asterisk failed to start
On 12/22/2020 11:52 PM, the...@sys-concept.com wrote: !!! existing preserved libs found run emerge @preserved-rebuild. It's got libraries from a package you removed that are needed by one or more packages left. @preserved-rebuild will rebuild the packages that own the library files in question, then they won't be "preserved" anymore. -- Dan Egli From my Test Server
