Re: [gentoo-user] dependancy poppler and xorg-server
On Wed, 28 Jan 2015 15:45:30 +1100, Adam Carter wrote: (x11-base/xorg-server-1.13.4-r1:0/1.13.4::gentoo, installed) pulled in by x11-base/xorg-server:0/1.13.4= required by (x11-drivers/xf86-input-mouse-1.9.0:0/0::gentoo, installed) ^^ (and 5 more I would just unmerge xf86-input-mouse, update xorg-server, merge xf86-input-mouse. The preferred option is to use x11-drivers/xf86-input-evdev and remove the separate mouse and keyboard drivers. -- Neil Bothwick Become a gynaecologist, look up a friend today. pgpymbXx3nlbw.pgp Description: OpenPGP digital signature
Re: [gentoo-user] ffmpeg-2: when getting stable? [SOLVED]
On 01/28/2015 12:07 AM, Jan Sever wrote: I found the bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=510340 So marking as SOLVED. Thank you, Jan Sever P.S. Btw. poli in politics is from latin word polis = a place, not poly = many. But it's a nice parallel. Both a greek words, not latin. polis = city poly = many/much
Re: [gentoo-user] ffmpeg-2: when getting stable? [SOLVED]
On 01/27/2015 11:48 PM, Neil Bothwick wrote: On Tue, 27 Jan 2015 23:07:15 +0100 (CET), Jan Sever wrote: P.S. Btw. poli in politics is from latin word polis = a place, not poly = many. But it's a nice parallel. Yes, and a tic is a nervous twitch, the blood sucking parasite is a tick, but when did jokes have to be linguistically accurate? Sorry, I didn't mean to spoil the joke, I really enjoyed it, I've not heard such a good joke recently. Thanks for redirecting me to the bugzilla. On 01/28/2015 1:24 AM, Thanasis wrote: Both a greek words, not latin. polis = city poly = many/much Thanks for correcting, I don't know why I had fixed in mind that polis is from latin and poly from greek. But I thought polis should be a city and wondered why it wasn't (in latin). Jan Sever
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 21:36, Tom H wrote: My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. But IIRC the 'tree' output that you'd posted, you shouldn't have the leading '\EFI'. the EFI is under /boot/efi from my trial and error today - # ls -l /boot/efi/EFI/* /boot/efi/EFI/gentoo: total 113 -rwxr-xr-x 1 root root 115712 28. Jan 19:39 grubx64.efi /boot/efi/EFI/grub_uefi: total 113 -rwxr-xr-x 1 root root 115712 28. Jan 19:42 grubx64.efi
Re: [gentoo-user] grub - gummiboot: good
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.01.2015 21:42, Neil Bothwick wrote: On Wed, 28 Jan 2015 21:34:31 +0100, Stefan G. Weichinger wrote: Would you mind sharing the tree of your /boot ... ? I tried booting grub and it didn't work yet. To answer this and your previous question. I already had a 1 GB ESP mounted at /boot. Grub's files live in /boot/EFI/GRUB2. hmm. No luck here so far with chosing grub_uefi. It skips to gummiboot somehow. # efibootmgr -v BootCurrent: 0008 Timeout: 0 seconds BootOrder: 0001,0008,,0002,0003,0004,0007,0005,0006 Boot* Linux Boot Manager HD(1,800,2f000,47853772-63b0-4140-868a-4af5fe448f25)File(\EFI\gummiboot\gummibootx64.efi) Boot0001* grub_uefi HD(1,800,2f000,47853772-63b0-4140-868a-4af5fe448f25)File(\EFI\grub_uefi\grubx64.efi) Boot0002* USB Floppy/CD Vendor(b6fef66f-1495-4584-a836-3492d1984a8d,050001)AMBO Boot0003* ATAPI CD-ROM Drive Vendor(b6fef66f-1495-4584-a836-3492d1984a8d,030001)AMBO Boot0004* USB Hard Drive Vendor(b6fef66f-1495-4584-a836-3492d1984a8d,020001)AMBO Boot0005* Unknown DeviceBIOS(2,0,00)AMGOAMNOo.S.a.m.s.u.n.g. .S.S.D. .8.4.0. .E.V.O. .2.5.0.G.BA.....Gd-.;.A..MQ..L.1.S.B.D.S.N.D.B.1.B.4.6.3.1. .M. . . . ......AMBOAMNOo.H.i.t.a.c.h.i. .H.D.S.7.2.1.0.1.0.C.L.A.6.3.2A.....Gd-.;.A..MQ..L. . . . . . .P.J.9.2.0.4.8.J.1.3.S.4.V.G......AMBOAMNOo.S.T.3.1.0.0.0.5.2.4.A.SA.....Gd-.;.A..MQ..L. . . . . . . . . . . . .V.9.D.P.1.H.0.D......AMBOAMNO..K.i.n.g.m.a.x. .U.S.B.2...0. .F.l.a.s.h.D.i.s.k.1.1.0.0A.N..Gd-.;.A..MQ..L.K.i.n.g.m.a.x. .U.S.B.2...0. .F.l.a.s.h.D.i.s.k.1.1.0.0......AMBO Boot0006* Unknown DeviceBIOS(3,0,00)AMGOAMNOo.h.p. . . . . . . .C.D.D.V.D.W. .T.S.-.H.6.5.3.T.NA.....Gd-.;.A..MQ..L.8.R.G.L.G.6.B.F.7.A.4.8.2.4. . . . . . ......AMBO Boot0007* UEFI: Kingmax USB2.0 FlashDisk1100 ACPI(a0341d0,0)PCI(1c,5)PCI(0,0)USB(1,0)USB(4,0)USB(4,0)HD(1,1,f09fff,000d2d9d)AMBO Boot0008* gummiboot HD(1,800,2f000,47853772-63b0-4140-868a-4af5fe448f25)File(\EFI\gummiboot\gummibootx64.efi) - --- # tree /boot/ /boot/ ??? e55a6b6a09bd2b1c50216272545a8d1f ? ??? 3.18.3-gentoo ? ??? initrd ? ??? kernel ??? efi ? ??? boot ? ? ??? bootx64.efi ? ? ??? x86_64-efi ? ? ??? acpi.mod ? ? ??? adler32.mod ? ? ??? affs.mod [...] ? ??? EFI ? ? ??? gentoo ? ? ? ??? grubx64.efi ? ? ??? grub_uefi ? ? ??? grubx64.efi ? ??? gentoo ? ? ??? grubx64.efi ? ??? grub ? ? ??? ascii.pf2 ? ? ??? grub ? ? ??? grub.cfg ? ? ??? unicode.pf2 ? ??? gummiboot ? ??? gummibootx64.efi ??? grub ? ??? fonts ? ? ??? unicode.pf2 ? ??? grub ? ??? grubenv ? ??? locale ? ? ??? de.mo ? ??? themes ? ? ??? starfield ? ? ??? blob_w.png ? ? ??? boot_menu_c.png [...] ??? loader ??? entries ? ??? e55a6b6a09bd2b1c50216272545a8d1f-3.18.3-gentoo.conf ? ??? gentoo.conf ??? loader.conf -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUyUuLAAoJEClcuD1V0PzmX10P/0ZP+aFzHQFA3LHp8/skUq+Q me1wJgCG91a5hIqMFi9PguDhLH0KzDujQXNI3xDLcDk+XXmWnOEMFcYCdyDlf3nv kpd/5KmYlJrZlzD/fMgwV4g0eZDJ6oZp3jUgSuZrJt8Lta7zTW8ES3U8SA1eQ7X5 JgKIwwvEND9r8eZdoCrlP42+h+rZ9A/DLQ+SEWtkXAAJhyOJVADg3W+tIuV7kIeA CrylOV1MlfpWXTepofwKt8QNUPcCHz/G8wRQ2UpPyXtBQDitk9An6WJj/BuMOGau R0PxlgAjq1p0SvFUqX91VVQ5/p5sjCqSPLDn7Q2kBVDpxAmh6JkDh+mDtsGZT41B lppdpEY2UKG2bNejXa7DbuZUP/ZL+5GQzoMbAOJodSu+M4TstLRuQOQgi3MXWCUj Nl00VqQLXeVKc0OELJ1UTa64zwS4FaEyMpNC5lo2xFbentniOPqcplXVhhukPich Ld+3myywZn5+mwE/9tGSiZJknU2dLpVJGnq93X4CQc1qipYqPgfuhuT17ozXxbY1 ByMhRX2yQgcv+ReSjwqVSnHAgU/BhqgKdT5FsQrNjEnoK0jokHFTZFOoM9nVvWkI /5KVBvzhYTDarO/zu41Ew1ss1XNF9F7Jo+CZIfdGW/Z43cbJ7abAogRUsOgYbwEO j98rD8lAnJ8N8huxzwfv =i/yB -END PGP SIGNATURE-
Re: [gentoo-user] Ghost cyber threat
On Tue, Jan 27, 2015 at 7:25 PM, Philip Webb purs...@ca.inter.net wrote: I'm running 2.19-r1 , installed 140802 ; vulnerable are 2.18 . Linux systems are at risk only when admins don't keep versions upto-date. Unless the patch was backported, distros like debian stable are potentially vulnerable. Gentoo should be fine unless you haven't been keeping up with updates for quite a while. -- Rich
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 21:31, Stefan G. Weichinger wrote: My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. tried your command and rebooted, worked, thanks! I now have: # efibootmgr BootCurrent: 0008 Timeout: 0 seconds BootOrder: 0008,,0001,0002,0003,0004,0007,0005,0006 Boot* Linux Boot Manager Boot0001* grub_uefi Boot0002* USB Floppy/CD Boot0003* ATAPI CD-ROM Drive Boot0004* USB Hard Drive Boot0005* Unknown Device Boot0006* Unknown Device Boot0007* UEFI: Kingmax USB2.0 FlashDisk1100 Boot0008* gummiboot So and 0008 point to the same UEFI app ... anyway. - Would you mind sharing the tree of your /boot ... ? I tried booting grub and it didn't work yet. Not urgent but interesting.
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 3:31 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 20:47, Tom H wrote: On Wed, Jan 28, 2015 at 2:02 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 19:50, Stefan G. Weichinger wrote: On 28.01.2015 19:44, Stefan G. Weichinger wrote: So now Linux Boot Manager is gummiboot ... and grub is grub ;) And for the records: renaming Linux Boot Manager to gummiboot was done by: # efibootmgr -b -B # efibootmgr -c -L gummiboot nice! sorry, did NOT work for me ... but the label is cosmetic. I do # efibootmgr -c -L gummiboot -l '\EFI\gummiboot\gummibootx64.efi' and I have # efibootmgr BootCurrent: 0004 Timeout: 0 seconds BootOrder: ,0001,0002,0003 Boot* gummiboot Boot0001* grub Boot0002* vanilla Boot0003* vivid Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network vanilla = self-compiled 3.19 kernel vivid = default Ubuntu 15.04 kernel ok ... worth a try. My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. But IIRC the 'tree' output that you'd posted, you shouldn't have the leading '\EFI'.
Re: [gentoo-user] grub - gummiboot: good
On Wed, 28 Jan 2015 21:34:31 +0100, Stefan G. Weichinger wrote: Would you mind sharing the tree of your /boot ... ? I tried booting grub and it didn't work yet. To answer this and your previous question. I already had a 1 GB ESP mounted at /boot. Grub's files live in /boot/EFI/GRUB2. -- Neil Bothwick Set phasers to extreme itching! pgpRqLKeno35w.pgp Description: OpenPGP digital signature
Re: [gentoo-user] grub - gummiboot: good
On Wed, 28 Jan 2015 21:50:19 +0100, Stefan G. Weichinger wrote: To answer this and your previous question. I already had a 1 GB ESP mounted at /boot. Grub's files live in /boot/EFI/GRUB2. hmm. No luck here so far with chosing grub_uefi. It skips to gummiboot somehow. # efibootmgr -v BootCurrent: 0008 Timeout: 0 seconds BootOrder: 0001,0008,,0002,0003,0004,0007,0005,0006 Boot* Linux Boot Manager HD(1,800,2f000,47853772-63b0-4140-868a-4af5fe448f25)File(\EFI\gummiboot\gummibootx64.efi) Boot0001* grub_uefi HD(1,800,2f000,47853772-63b0-4140-868a-4af5fe448f25)File(\EFI\grub_uefi\grubx64.efi) Which could be because Grub can't find it's files. It installed them in /boot/EFI/GRUB2 here. % ls -1 /boot/EFI/**/*.efi /boot/EFI/Boot/bootx64.efi /boot/EFI/GRUB2/grubx64.efi /boot/EFI/GRUB2/x86_64-efi/core.efi /boot/EFI/GRUB2/x86_64-efi/grub.efi /boot/EFI/gummiboot/gummibootx64.efi -- Neil Bothwick Men who have playful kittens shouldn't sleep in the nude. pgp3g6KJfb3R7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] grub - gummiboot: good
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.01.2015 22:16, Neil Bothwick wrote: Which could be because Grub can't find it's files. It installed them in /boot/EFI/GRUB2 here. % ls -1 /boot/EFI/**/*.efi /boot/EFI/Boot/bootx64.efi /boot/EFI/GRUB2/grubx64.efi /boot/EFI/GRUB2/x86_64-efi/core.efi /boot/EFI/GRUB2/x86_64-efi/grub.efi /boot/EFI/gummiboot/gummibootx64.efi my status: # ls -1 /boot/EFI/**/*.efi /boot/EFI/boot/bootx64.efi /boot/EFI/gentoo/grubx64.efi /boot/EFI/gummiboot/gummibootx64.efi It seems it's too late for me to get that fixed today .. long and busy day (and currently still doing job work) ... tired ... Thanks so far, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUyVX1AAoJEClcuD1V0Pzm4Q8P/R5WVRt5z0AMv4QZbK5fcZXt rp9i+W7qTqXw2fjQfcJPQBGk6BDOgkWg0uYhtrwjSTPRIosP9q9Gx7gk2VxGPMN+ m/DNmP14Nmts9XLNE4hEAT9hdoUrE9fm1nEeUUafajEuIZTgXSMVnG0oGM4II5k5 uE5rpXJKm32EuE/B1fUlaxsB8RjT0gS8CJit7tPLO8N1xlaF0Px5MKClkssQZA6x b+l06uu9aaHDSOVMiAicmc/4QRfq1Y/yXKR7BNcec79fDLE6Opv2yAurNz+irK7z YHh+uaVq4A5hObQD8pFsXm05JAAoshLLjeA0uCrjdMC1hRRJWljGS7/HFfGOESN1 LnXPYVA71bG2pMjgcNPItUkuq1w9eLlIoLiyUMQz1HR52PsQ/sfnhS1D08Crkdq2 e5CnumRX1y24pMTjTFHyeRX7Ltx2AHkBaZsM1rP2ppGKqjyRdvpJ45XCVEeJZyGE swiWIcnjCBOVm0Zfl+12il0ipH1+DY7Re418m839sETwlbAxWyJpEEXgt06rEyv+ reycRtwBDvT+yxFKdnUg9ezd4wf2T4YVnPQBP38HRB4mOcK461smxx1Pk47VsTP4 8tt41IUM/qXD88FHmYGJaN6OlK88x0fTaRyygue980jyJNdwb5Lrc2uU/3m7QmO1 F1yuwcBfyklm/AffkAp2 =8HKb -END PGP SIGNATURE-
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 3:34 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 21:31, Stefan G. Weichinger wrote: My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. tried your command and rebooted, worked, thanks! You're welcome. Would you mind sharing the tree of your /boot ... ? I tried booting grub and it didn't work yet. Not urgent but interesting. # ls -RF .: System.map-3.18.0-11-generic abi-3.18.0-11-generic config-3.18.0-11-generic efi/ initrd.img-3.18.0-11-generic memtest86+.bin memtest86+_multiboot.bin vmlinuz-3.19.0-rc6 System.map-3.19.0-rc6 abi-3.19.0-rc6 config-3.19.0-999-generic grub/ initrd.img-3.19.0-rc6 memtest86+.elf vmlinuz-3.18.0-11-generic ./efi: 3.18.0-11-generic/ 3.19.0-rc6/ EFI/ loader/ ./efi/3.18.0-11-generic: initrd* vmlinuz* ./efi/3.19.0-rc6: initrd* vmlinuz* ./efi/EFI: gummiboot/ ubuntu/ ./efi/EFI/gummiboot: gummibootx64.efi* ./efi/EFI/ubuntu: MokManager.efi* grub.cfg* grubx64.efi* shimx64.efi* ./efi/loader: entries/ loader.conf* ./efi/loader/entries: 3.18.0-11.conf* 3.19.0-rc6.conf* ./grub: fonts/ grub.cfg grubenv locale/ unicode.pf2 x86_64-efi/ ./grub/fonts: unicode.pf2 ./grub/locale: ./grub/x86_64-efi: snip
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 3:38 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 21:36, Tom H wrote: My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. But IIRC the 'tree' output that you'd posted, you shouldn't have the leading '\EFI'. the EFI is under /boot/efi I was confused. You need the leading '\EFI'. from my trial and error today - # ls -l /boot/efi/EFI/* /boot/efi/EFI/gentoo: total 113 -rwxr-xr-x 1 root root 115712 28. Jan 19:39 grubx64.efi /boot/efi/EFI/grub_uefi: total 113 -rwxr-xr-x 1 root root 115712 28. Jan 19:42 grubx64.efi You need a 'grub.cfg' in '/boot/efi/EFI/grub_uefi'. I've deleted your email with the 'tree' output. I'm going to have to look it up in the archives because you shouldn't have 'efi' in your path if the ESP mountpoint is '/boot'.
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 22:37, Stefan G. Weichinger wrote: thanks, I will go through this asap (hopefully tomorrow). Just in case someone else is motivated right now ;-) - mine (with definitely too much grub-content in there) should I go for it and format the ESP ... remount and re-install both gummiboot and grub2 ?? I think I will do.
[gentoo-user] Re: Ghost cyber threat
Philip Webb purslow at ca.inter.net writes: 150127 Joseph wrote: Does anybody know more about this security flaw in the open-source Linux GNU C Library : http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 Acc to this, it was patched 2013 today threatens only long-term systems : http://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679 I'm running 2.19-r1 , installed 140802 ; vulnerable are 2.18 . Linux systems are at risk only when admins don't keep versions upto-date. Maybe it's time to looking into some of the work the gentoo hardened devs have going on: http://wiki.gentoo.org/wiki/Project:Hardened_musl hth, James
[gentoo-user] Re: ffmpeg-2: when getting stable? [SOLVED]
On 01/27/2015 02:48 PM, Neil Bothwick wrote: but when did jokes have to be linguistically accurate? When they're being compiled, silly.
Re: [gentoo-user] Re: ffmpeg-2: when getting stable? [SOLVED]
On Tue, 27 Jan 2015 15:10:12 -0800, walt wrote: On 01/27/2015 02:48 PM, Neil Bothwick wrote: but when did jokes have to be linguistically accurate? When they're being compiled, silly. I never compile my own taglines, I let someone else do that and then steal them ;-) -- Neil Bothwick Just when you got it all figured out: An UPGRADE! pgp529BBR8yKn.pgp Description: OpenPGP digital signature
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 20:47, Tom H wrote: On Wed, Jan 28, 2015 at 2:02 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 19:50, Stefan G. Weichinger wrote: On 28.01.2015 19:44, Stefan G. Weichinger wrote: So now Linux Boot Manager is gummiboot ... and grub is grub ;) And for the records: renaming Linux Boot Manager to gummiboot was done by: # efibootmgr -b -B # efibootmgr -c -L gummiboot nice! sorry, did NOT work for me ... but the label is cosmetic. I do # efibootmgr -c -L gummiboot -l '\EFI\gummiboot\gummibootx64.efi' and I have # efibootmgr BootCurrent: 0004 Timeout: 0 seconds BootOrder: ,0001,0002,0003 Boot* gummiboot Boot0001* grub Boot0002* vanilla Boot0003* vivid Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network vanilla = self-compiled 3.19 kernel vivid = default Ubuntu 15.04 kernel ok ... worth a try. My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI.
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 22:32, Tom H wrote: On Wed, Jan 28, 2015 at 3:34 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 21:31, Stefan G. Weichinger wrote: My command lead to a non-booting machine ... the gummiboot-entry was removed from UEFI. tried your command and rebooted, worked, thanks! You're welcome. Would you mind sharing the tree of your /boot ... ? I tried booting grub and it didn't work yet. Not urgent but interesting. # ls -RF .: System.map-3.18.0-11-generic abi-3.18.0-11-generic thanks, I will go through this asap (hopefully tomorrow). Just in case someone else is motivated right now ;-) - mine (with definitely too much grub-content in there) # ls -RF .: e55a6b6a09bd2b1c50216272545a8d1f/ efi/ grub/ loader/ ./e55a6b6a09bd2b1c50216272545a8d1f: 3.18.3-gentoo/ ./e55a6b6a09bd2b1c50216272545a8d1f/3.18.3-gentoo: initrd* kernel* ./efi: boot/ EFI/ gentoo/ grub/ gummiboot/ ./efi/boot: bootx64.efi* x86_64-efi/ ./efi/boot/x86_64-efi: acpi.mod* disk.mod* gcry_whirlpool.mod* lzopio.mod* part_sunpc.mod* test_blockarg.mod* adler32.mod* div_test.mod* geli.mod* macbless.mod* parttool.lst* testload.mod* affs.mod* dm_nv.mod*gettext.mod* macho.mod*parttool.mod* test.mod* afs.mod* echo.mod* gfxmenu.mod* mdraid09_be.mod* password.mod* testspeed.mod* ahci.mod* efifwsetup.mod* gfxterm_background.mod* mdraid09.mod* password_pbkdf2.mod* tftp.mod* all_video.mod* efi_gop.mod* gfxterm_menu.mod* mdraid1x.mod* pata.mod* tga.mod* aout.mod* efinet.mod* gfxterm.mod* memdisk.mod* pbkdf2.mod* time.mod* appleldr.mod* efi_uga.mod* gptsync.mod* memrw.mod*pbkdf2_test.mod* trig.mod* archelp.mod* ehci.mod* gzio.mod* minicmd.mod* pcidump.mod* tr.mod* ata.mod* elf.mod* halt.mod* minix2_be.mod*play.mod* true.mod* at_keyboard.mod* eval.mod* hashsum.mod* minix2.mod* png.mod* udf.mod* backtrace.mod* exfat.mod*hdparm.mod* minix3_be.mod*priority_queue.mod* ufs1_be.mod* bfs.mod* exfctest.mod* hello.mod* minix3.mod* probe.mod*ufs1.mod* bitmap.mod*ext2.mod* help.mod* minix_be.mod* procfs.mod* ufs2.mod* bitmap_scale.mod* extcmd.mod* hexdump.mod* minix.mod*progress.mod* uhci.mod* blocklist.mod* fat.mod* hfs.mod* mmap.mod* raid5rec.mod* usb_keyboard.mod* boot.mod* file.mod* hfspluscomp.mod* moddep.lst* raid6rec.mod* usb.mod* bsd.mod* fixvideo.mod* hfsplus.mod* morse.mod*read.mod* usbms.mod* btrfs.mod* font.mod* http.mod* mpi.mod* reboot.mod* usbserial_common.mod* bufio.mod* fshelp.mod* iorw.mod* msdospart.mod*regexp.mod* usbserial_ftdi.mod* cat.mod* fs.lst* iso9660.mod* multiboot2.mod* reiserfs.mod* usbserial_pl2303.mod* cbfs.mod* functional_test.mod* jfs.mod* multiboot.mod*relocator.mod*usbserial_usbdebug.mod* cbls.mod* gcry_arcfour.mod* jpeg.mod* nativedisk.mod* romfs.mod*usbtest.mod* cbmemc.mod*gcry_blowfish.mod*keylayouts.mod* net.mod* scsi.mod* verify.mod* cbtable.mod* gcry_camellia.mod*keystatus.mod* newc.mod* search_fs_file.mod* video_bochs.mod* cbtime.mod*gcry_cast5.mod* ldm.mod* nilfs2.mod* search_fs_uuid.mod* video_cirrus.mod* chain.mod* gcry_crc.mod* legacycfg.mod* normal.mod* search_label.mod* video_colors.mod* cmdline_cat_test.mod* gcry_des.mod* legacy_password_test.mod* ntfscomp.mod* search.mod* video_fb.mod* cmp.mod* gcry_dsa.mod* linux16.mod* ntfs.mod* serial.mod* videoinfo.mod* command.lst* gcry_idea.mod*linux.mod* odc.mod* setjmp.mod* video.lst* configfile.mod*gcry_md4.mod* loadbios.mod* offsetio.mod* setjmp_test.mod* video.mod* cpio_be.mod* gcry_md5.mod* loadenv.mod* ohci.mod* setpci.mod* videotest_checksum.mod* cpio.mod* gcry_rfc2268.mod* loopback.mod* part_acorn.mod* sfs.mod* videotest.mod* cpuid.mod* gcry_rijndael.mod*lsacpi.mod* part_amiga.mod* signature_test.mod* xfs.mod* crc64.mod* gcry_rmd160.mod* lsefimmap.mod* part_apple.mod* sleep.mod*xnu.mod* cryptodisk.mod*gcry_rsa.mod* lsefi.mod* part_bsd.mod*
Re: [gentoo-user] Question about flakey RAM
On 28/01/2015 01:28, walt wrote: Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. RAM, like everything else made in a factory, is built to tolerances. So is your CPU and motherboard. A positive result from memtest+ (something failed) is definitive - there really is a problem and it is likely the RAM. Or maybe your RAM just doesn't like your motherboard but this is rare. A negative result from memtest (nothing failed) is not definitive - it doesn't mean the RAM and your system is not faulty, it just means memtest+ didn't find anything. Sometimes you have to run memtest+ for 48 hours to trip over the problem whereas your running OS does it immediately (it's a computer, go figure) Keep in mind memtest+ is an artifical testbed - it tries it's best to find issues but it's not the same thing as your running system. And there's lots of variables: Have you overclocked? Over or under volted? Is your PSU OK, could the running system stress it out? Or maybe timing tolerances between that RAM stick your motherboard are close to the edge. I think your machine just didn;t like that RAM and it would work fine in 999 other machines. It happens sometimes, manufacturing and test rigs are not 100 perfect. They are close, but never 100% -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: [Extremely OT] Ansible/Puppet replacement
Alec Ten Harmsel alec at alectenharmsel.com writes: Assuming that disks are formatted, a stage3 has been freshly extracted, bossman is installed, and the role/config files are on a mounted filesystem, it should be similar to the role below: I think the list needs to be expanded, generically first: /var/lib/portage/world /etc/* /usr/local/* just to name a few to clone a system. I'll work on a comprehensive list of require and optional. Automating the bootstrapping of a node is reasonably complicted, even harder on Gentoo than on RHEL. This is the type of thinking I want to do, and I'm working on doing this with my CentOS box that runs ssh, Jenkins, postgres, and Redmine. I'm going to work through the ansible gentoo install method previously outlined. Once I try that for new installs, it should be easy to add what robust workstaion has added since it was installed, as the second step in the process. That way, part A of the install is a raw/virgin install on new (wiped) hardware. part B would be to upgrade that virgin install to basically be a clone of an existing workstation. This all requires similar if not identical hardware, which is a common occurrence in large installation environment.
[gentoo-user] USE=X
Howdy, So I was reading PGO (Planet.Gentoo.org) and Patrick's post got thinking. Yep, X was set in make.conf, like I have done for a very long time on any gentoo workstation. Now it may be time to rethink this flag. The gist of what I understand is that X is set, per profile, if appropriate. On my workstations I usually just set the minimimum profile (architecture) like so: # eselect profile list [1] default/linux/amd64/13.0 * On so I run lxde and I experiment with lxqt as the desktop. In light of Patricks post on PGO, do I have to now bump up the profile to [3] default/linux/amd64/13.0/desktop What if I'm building a hardened base lxde (lxqt) workstation set the profile to [19] hardened/linux/amd64 and unset X in the make.conf file? # euse -i X This list does not look like I need to set X any more in make.conf? A side note: it had this line in the output: dev-java/icedtea: Make X buildtime-only depenency. !!! Metadata cache not found. You need to run !!! 'egencache --repo=java --update' !!! to generate metadata for your overlays Very cool that portage picked up this need by euse -i X. All input is welcome, James
[gentoo-user] Question about flakey RAM
Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers.
Re: [gentoo-user] dependancy poppler and xorg-server
The preferred option is to use x11-drivers/xf86-input-evdev and remove the separate mouse and keyboard drivers. OP, you will need CONFIG_INPUT_EVDEV enabled in your kernel, but the ebuild will notify you if its not enabled.
Re: [gentoo-user] USE=X
On 27/01/2015 20:54, James wrote: Howdy, So I was reading PGO (Planet.Gentoo.org) and Patrick's post got thinking. Yep, X was set in make.conf, like I have done for a very long time on any gentoo workstation. Now it may be time to rethink this flag. The gist of what I understand is that X is set, per profile, if appropriate. On my workstations I usually just set the minimimum profile (architecture) like so: # eselect profile list [1] default/linux/amd64/13.0 * On so I run lxde and I experiment with lxqt as the desktop. In light of Patricks post on PGO, do I have to now bump up the profile to [3] default/linux/amd64/13.0/desktop What if I'm building a hardened base lxde (lxqt) workstation set the profile to [19] hardened/linux/amd64 and unset X in the make.conf file? # euse -i X This list does not look like I need to set X any more in make.conf? A side note: it had this line in the output: dev-java/icedtea: Make X buildtime-only depenency. !!! Metadata cache not found. You need to run !!! 'egencache --repo=java --update' !!! to generate metadata for your overlays Very cool that portage picked up this need by euse -i X. All input is welcome, There's nothing magic about a profile. All it does is set a bunch of variables and possibly specify some extra apps to be merged. It's a convenience, and there's nothing to stop you from finding out what those variables are and adding them to USE yourself, and adding the packages to world yourself. You can continue to do things exactly as you always did, and nothing will break or change. Nothing forces you to use a desktop profile. Personally I use a desktop profile and also have X in USE - I like to be explicit with my stuff. I know that one of those config setting is redundant :-) The X USE flasg doe NOT mean install xorg-x11. It means build X11 support into apps that have optional support for X11. Example vim. The flag adds xterm support so vim can modify the xterm titlebar. Without USE=X you get plain old vim that runs in a shell as normal and doesn't communicate with the gui system in any way. The xorg-x11 package is pulled by you if you merge it, or by any WM/DE you install which obviously requires X11[1]. For hardened, there is no hardened desktop profile. Apparently that was a world of pain for the devs. Adding desktop software to a hardened system is easy, hardening a desktop system is harder. So I'd say chose a hardened profile, then add X to USE and merge your choice of WM/DE Alan [1] When wayland becomes a first-class Linux citizen, this will likely change -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 5:20 PM, Stefan G. Weichinger li...@xunil.at wrote: I rm`ed the ESP and started over. gummiboot boots fine again. I added some entries to /etc/grub.d/40_custom (some pointers to isos etc) and ran grub2-mkconfig -o /boot/efi/EFI/grub_uefi/grub.cfg When I chose grub_uefi at boot time ... it skips again and boots via gummiboot (nice in the end .. but .. ) How?! And they say things get *easier* !!! ;-) # ls -RF .: e55a6b6a09bd2b1c50216272545a8d1f/ EFI/ grub/ loader/ There's no longer an 'efi' so that's good. ./e55a6b6a09bd2b1c50216272545a8d1f: 3.19-rc6/ ./e55a6b6a09bd2b1c50216272545a8d1f/3.19-rc6: initrd* kernel* ./EFI: Boot/ EFI/ gummiboot/ ./EFI/Boot: BOOTX64.EFI* All OK. ./EFI/EFI: grub_uefi/ ./EFI/EFI/grub_uefi: grub.cfg* grubx64.efi* Why two EFIs? One of them's unnecessary but if you want to have both, you have to have them both in the efibootmgr invocation. ./EFI/gummiboot: gummibootx64.efi* ./grub: fonts/ grubenv* locale/ themes/ x86_64-efi/ ./grub/fonts: unicode.pf2* ./grub/locale: de.mo* ./grub/themes: starfield/ ./grub/themes/starfield: blob_w.png*boot_menu_nw.png* COPYING.CC-BY-SA-3.0* [...] ./grub/x86_64-efi: acpi.mod* disk.mod* geli.mod* macbless.mod* parttool.lst* test.mod* adler32.mod* div_test.mod* gettext.mod* macho.mod* [...] ./loader: entries/ loader.conf* ./loader/entries: e55a6b6a09bd2b1c50216272545a8d1f-3.19-rc6.conf* All OK again. Can you create an entry for your kernel in 40_custom and test it? Take a look at grub.cfg. I doubt that grub-mkconfig looks for a kernel in '/boot/machine_id/kernel_version/' or that it recognizes 'kernel' and 'initrd' as valid names for a kernel and an initramfs.
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 22:55, Tom H wrote: You need a 'grub.cfg' in '/boot/efi/EFI/grub_uefi'. I've deleted your email with the 'tree' output. I'm going to have to look it up in the archives because you shouldn't have 'efi' in your path if the ESP mountpoint is '/boot'. forget the old mail. I rm`ed the ESP and started over. gummiboot boots fine again. I added some entries to /etc/grub.d/40_custom (some pointers to isos etc) and ran grub2-mkconfig -o /boot/efi/EFI/grub_uefi/grub.cfg When I chose grub_uefi at boot time ... it skips again and boots via gummiboot (nice in the end .. but .. ) And they say things get *easier* !!! ;-) -- # ls -RF .: e55a6b6a09bd2b1c50216272545a8d1f/ EFI/ grub/ loader/ ./e55a6b6a09bd2b1c50216272545a8d1f: 3.19-rc6/ ./e55a6b6a09bd2b1c50216272545a8d1f/3.19-rc6: initrd* kernel* ./EFI: Boot/ EFI/ gummiboot/ ./EFI/Boot: BOOTX64.EFI* ./EFI/EFI: grub_uefi/ ./EFI/EFI/grub_uefi: grub.cfg* grubx64.efi* ./EFI/gummiboot: gummibootx64.efi* ./grub: fonts/ grubenv* locale/ themes/ x86_64-efi/ ./grub/fonts: unicode.pf2* ./grub/locale: de.mo* ./grub/themes: starfield/ ./grub/themes/starfield: blob_w.png*boot_menu_nw.png* COPYING.CC-BY-SA-3.0* [...] ./grub/x86_64-efi: acpi.mod* disk.mod* geli.mod* macbless.mod* parttool.lst* test.mod* adler32.mod* div_test.mod* gettext.mod* macho.mod* [...] ./loader: entries/ loader.conf* ./loader/entries: e55a6b6a09bd2b1c50216272545a8d1f-3.19-rc6.conf*
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 23:51, Tom H wrote: Why two EFIs? One of them's unnecessary but if you want to have both, you have to have them both in the efibootmgr invocation. I don't know why. What I did: cd /boot rm -fr * gummiboot install grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub_uefi --recheck (and maybe run kerninst to actually put a kernel and its initrd there) The grub2-install-command was just taken from shell history. It might be *wrong* ... yes. At least it says it runs without errors. When I run: # grub2-install --target=x86_64-efi --bootloader-id=grub_3 --recheck Installing for x86_64-efi platform. grub2-install: error: cannot find EFI directory. Can you create an entry for your kernel in 40_custom and test it? Take a look at grub.cfg. I doubt that grub-mkconfig looks for a kernel in '/boot/machine_id/kernel_version/' or that it recognizes 'kernel' and 'initrd' as valid names for a kernel and an initramfs. grub2-mkconfig did not detect any kernel, yes. That doesn't matter btw ... the reason to have grub2 in parallel is just the feature to boot iso-files (rescue media ...). All this additional grub2-fiddlery is basically learning how to make it work and getting the convenience of not having to insert a CD now and then. For daily work I am perfectly happy with gummiboot *just* booting my kernel(s) ... which works already! thanks, regards, Stefan (leaving now ... late here as mentioned)
[gentoo-user] Digital Cinema 4k (4096x2160@60Hz) SST mode display and xf86-video-ati
Hi folks, has anybody experiences with 4k monitors and the open source ATI video driver? I wanna buy a LG 31MU97-B monitor. My GPUs will be a Sapphire Radeon R7 250E and in a second machine a Sapphire Vapor-X R9 280X. Does anybody know if the xf86-video-ati driver is capable to handle such high resolutions without problems? Regards wabe
Re: [gentoo-user] grub - gummiboot: good
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.01.2015 01:36, Neil Bothwick wrote: On Wed, 28 Jan 2015 00:40:32 +0100, Stefan G. Weichinger wrote: No need for chainloading with UEFI. Set Gummiboot as the default boot option and hold down Esc (or whichever key your motherboard uses, it would have been nice if UEFI had standardised that too) when booting if you want Grub instead So I would have to have grub-2.x and gummiboot installed in parallel? Both as UEFI-boot-entries, right? Yes. When I first tried Gummiboot, I left Grub as the default until I was happy with Gummiboot, then I changed the default with efibootmgr. And what is your partitioning and fstab? gummiboot wants all inside the ESP and this mounted at /boot: # grep boot /etc/fstab UUID=E004-1D89 /boot vfatauto1 2 The gentoo GRUB2 wiki tells me to mount that at /boot/efi ... And grub2 fails to install now (with or without --boot-directory): # grub2-install --target=x86_64-efi --boot-directory=/boot Installing for x86_64-efi platform. grub2-install: error: cannot find EFI directory. I am *sure* that I have some crap in my ESP ... from my initial fiddling back then. See the current tree: boot # tree . ├── e55a6b6a09bd2b1c50216272545a8d1f │ ├── 3.18.3-gentoo │ │ ├── initrd │ │ └── kernel │ └── 3.19-rc6 │ ├── initrd │ └── kernel ├── efi │ ├── boot │ │ ├── bootx64.efi │ │ ├── grub.cfg │ │ └── x86_64-efi │ │ ├── acpi.mod │ │ ├── adler32.mod │ │ ├── affs.mod │ │ ├── afs.mod │ │ ├── [...] │ ├── gentoo │ │ └── grubx64.efi │ ├── grub │ │ ├── ascii.pf2 │ │ └── unicode.pf2 │ └── gummiboot │ └── gummibootx64.efi ├── grub │ └── grub └── loader ├── entries │ ├── e55a6b6a09bd2b1c50216272545a8d1f-3.18.3-gentoo.conf │ ├── e55a6b6a09bd2b1c50216272545a8d1f-3.19-rc6.conf │ └── gentoo.conf └── loader.conf Note: the stuff in efi/boot configured grub2 until a few days ago. - - And current efibootmgr: # efibootmgr ** Warning ** : Boot000a is not EFI 1.10 compliant (lowercase hex in name) ** Warning ** : please recreate these using efibootmgr to remove this warning. BootCurrent: 0008 Timeout: 0 seconds BootOrder: 0008,0001,0002,0009,,0005,0006,000A Boot* Linux Boot Manager Boot0001* USB Floppy/CD Boot0002* USB Hard Drive Boot0005 USB Floppy/CD Boot0006 Hard Drive Boot0008* UEFI: Samsung SSD 840 EVO 250GB Boot0009* ATAPI CD-ROM Drive Boot000a Unknown Device I would appreciate any help to clean that up and get both gummiboot and GRUB2 installed as parallel UEFI applications. Currently gummiboot works very well! Thanks, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUySk2AAoJEClcuD1V0PzmEkMP+wS4Xu2RfTsUSXctzRi5KR65 eHxlvOf6vSXGcFFwPmmFHi0AHF6ZdzrMUtSK7/b1laxnEZtKHDpMqthB5u99nlnC LVDUIu4+s/wfhrurX7+Po2YLVD6p51/0JSA3vOBErKiHaCf8/GBZ1WNAUuUbNYNy CJrgHibxiCH+Kxh4v6t7nFRL2X0deJYu/Bl5FnKkd3na7fXwOvIdv67Gvqir8Mim Z97AYIDOd7BO8uGCBDULK7HRoUDzrDAJ9mtDrRO/EjSml+9m6iFzNosOPqeNfFYC aOHF8jpt47dv2moy0zMS5QG81V3mdUZFkoz6yhct3OQB4b189sTPbkbo7E/rNcPn PyxyfQXyDgI8Zjj9w9ee7tP+IamSQqRe5cc0sSdp60SNzVNiBwrJVwS2Eh8tm7IT cBa39Ib7m7A7Y6MOrOPBKnkZnQcckAgi/VDLO1powfsskh+UBuSJea6TcR1Zb8kZ Cc3l9P1xTzwdf4EHLikYA2/yK2RQmNN/SuzMQ+A8uqdnH611EEEqP+gKH5z5Z6ab Yyo9UtG6UqY78wyyNqNEpCcr2M9GyachWEHWuPGDLDNlGSGI5S+5s5xvkZq+GqtC 2tomsm4BDolqMuW/eFB2Hdh8DtG/i3ytjnmGMjp+36dUSGNGbackvC9caZjqgu0c NVWrQb7vkm7ssESUey3x =mFKy -END PGP SIGNATURE-
Re: [gentoo-user] grub - gummiboot: good
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This worked now : # grub2-install --target=x86_64-efi --efi-directory=/boot/efi cleaning up the entries ... I get # grub2-install --target=x86_64-efi --efi-directory=/boot/efi Installing for x86_64-efi platform. efibootmgr: Could not set variable Boot0003: No space left on device efibootmgr: Could not prepare boot variable: No space left on device Installation finished. No error reported. I once had that it worked after rebooting .. so I am afk for a moment. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUyStwAAoJEClcuD1V0Pzm9aUP/16DcCxySR8GVZi4nhEz/Ib2 sWATpyp2MJmVMeu+oRGeezcDIceL/NBlDgfypSCo5mlDbOzelEGlspe/ZMQpnuuH dSUF+zHuLE4WBU2azHiWrFFitxUt8/Qf1ILW+F3sn7cEnOLljF/pfP7Ngp/HzHhK A9chqXLTHB8MtmFde/t6pAQPTXUroiaPLYWhPx3Ezwrc2M0lacc52sa1QRnwg9Ta v/RIVOUKCTQnOkd9TRbCdm9ubtwpi/1Hzlo9wYoFbXVtSR6tJNJv0f9JN4i2Ty1y xakoNnTnJbQx7ShuxGMPGrMFjhbWUX5EDF5M1/du2w4MEFQuQaRIwcP9yzxgVgfw 58y+AwW7W7Fk9JENhTUzoHSX/OKJw0GHEDjG2e9rX6KCBBQK7o8d/qHNi4oC1VAd AxWLVXT/I+YqSUtkgS2WRdfVyP4U5JxBEGGsSr8KbPlodxXhmTCl9Wi+d60OTgkQ NL/aIld0/605qhWlZy8Ynnl9Rk8dMsD3Xyp5SmFGgj9ZSUQdPMP55OvKAYwI4zsS iYNHSvMLbskY9O5g8CE5WsfEXwuFHboTJscqEOIRpddyootP2ZQR5HDmTYsfiRZt f6crIQJeahLQTs2Fm0/s2CLdnIxBM7XYj9ZBFb5gmS1vxrvuRLQXxuv9mcxuIIqt AzKHjAKFHLcDlkqiXnvx =pXCn -END PGP SIGNATURE-
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 19:38, Tom H wrote: Try to add '--efi-directory=/boot' to your grub-install invocation although I wonder whether grub-mkconfig will find your kernels and initramfs's if they aren't in the root of '/boot'. Thanks. Got it already - # rm /sys/firmware/efi/efivars/dump-type0-* # grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub_uefi --recheck Installing for x86_64-efi platform. Installation finished. No error reported. # efibootmgr BootCurrent: Timeout: 0 seconds BootOrder: 0001 Boot* Linux Boot Manager Boot0001* grub_uefi Boot0003* UEFI: Samsung SSD 840 EVO 250GB Boot0004* ATAPI CD-ROM Drive Boot0006* USB Floppy/CD Boot0007* Hard Drive So now Linux Boot Manager is gummiboot ... and grub is grub ;) thanks
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 1:23 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 01:36, Neil Bothwick wrote: On Wed, 28 Jan 2015 00:40:32 +0100, Stefan G. Weichinger wrote: No need for chainloading with UEFI. Set Gummiboot as the default boot option and hold down Esc (or whichever key your motherboard uses, it would have been nice if UEFI had standardised that too) when booting if you want Grub instead So I would have to have grub-2.x and gummiboot installed in parallel? Both as UEFI-boot-entries, right? Yes. When I first tried Gummiboot, I left Grub as the default until I was happy with Gummiboot, then I changed the default with efibootmgr. And what is your partitioning and fstab? gummiboot wants all inside the ESP and this mounted at /boot: # grep boot /etc/fstab UUID=E004-1D89 /boot vfatauto1 2 The gentoo GRUB2 wiki tells me to mount that at /boot/efi ... And grub2 fails to install now (with or without --boot-directory): # grub2-install --target=x86_64-efi --boot-directory=/boot Installing for x86_64-efi platform. grub2-install: error: cannot find EFI directory. Try to add '--efi-directory=/boot' to your grub-install invocation although I wonder whether grub-mkconfig will find your kernels and initramfs's if they aren't in the root of '/boot'.
Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. It's not necessarily a fast moving target. RHEL 7 uses an upstream-maintained 208 stable (and AFAIR Debian 8 will also use it). For embedded systems that never used sysvinit, systemd is unlikely ever to be an option but for others anyone can claim either that systemd is the best choice possible or that it's the worst choice possible without any proof either way.
Re: [gentoo-user] ffmpeg-2: when getting stable? [SOLVED]
On 01/28/2015 05:12 PM, Jan Sever wrote: On 01/28/2015 1:24 AM, Thanasis wrote: Both a greek words, not latin. polis = city poly = many/much Thanks for correcting, I don't know why I had fixed in mind that polis is from latin and poly from greek. But I thought polis should be a city and wondered why it wasn't (in latin). Jan Sever It's getting a bit off-topic, but FWIW, actual words are written like so: πόλις (polis) πολύ (poly)
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 19:44, Stefan G. Weichinger wrote: So now Linux Boot Manager is gummiboot ... and grub is grub ;) And for the records: renaming Linux Boot Manager to gummiboot was done by: # efibootmgr -b -B # efibootmgr -c -L gummiboot nice!
Re: [gentoo-user] grub - gummiboot: good
On Tue, Jan 27, 2015 at 5:31 PM, Mick michaelkintz...@gmail.com wrote: ... and if you have no need for multi-booting then the kernel efi stub is very simple to configure and still works reliably (with openrc and no initrd here). No need to install a separate boot manager. It's not just multi-booting that might need a boot manager or a boot loader. Using efibootmgr is OK but you then have to go to the firmware in order to choose to boot in single-user mode or with a non-default kernel.
Re: [gentoo-user] grub - gummiboot: good
On 28.01.2015 19:50, Stefan G. Weichinger wrote: On 28.01.2015 19:44, Stefan G. Weichinger wrote: So now Linux Boot Manager is gummiboot ... and grub is grub ;) And for the records: renaming Linux Boot Manager to gummiboot was done by: # efibootmgr -b -B # efibootmgr -c -L gummiboot nice! sorry, did NOT work for me ... but the label is cosmetic. Enough for today ... maybe I find the time to correctly place grub.cfg tomorrow.
Re: [gentoo-user] ffmpeg-2: when getting stable? [SOLVED]
On 01/28/2015 08:06 PM, Thanasis wrote: On 01/28/2015 05:12 PM, Jan Sever wrote: On 01/28/2015 1:24 AM, Thanasis wrote: Both a greek words, not latin. polis = city poly = many/much Thanks for correcting, I don't know why I had fixed in mind that polis is from latin and poly from greek. But I thought polis should be a city and wondered why it wasn't (in latin). Jan Sever It's getting a bit off-topic, but FWIW, actual words are written like so: πόλις (polis) πολύ (poly) Thanks, of course it would be in greek alphabet. I remember it thanks to Math. Always pleasure to find another information next to what man's looking for. It's very helpful for widening knowledge. Jan Sever
Re: [gentoo-user] grub - gummiboot: good
On Wed, Jan 28, 2015 at 2:02 PM, Stefan G. Weichinger li...@xunil.at wrote: On 28.01.2015 19:50, Stefan G. Weichinger wrote: On 28.01.2015 19:44, Stefan G. Weichinger wrote: So now Linux Boot Manager is gummiboot ... and grub is grub ;) And for the records: renaming Linux Boot Manager to gummiboot was done by: # efibootmgr -b -B # efibootmgr -c -L gummiboot nice! sorry, did NOT work for me ... but the label is cosmetic. I do # efibootmgr -c -L gummiboot -l '\EFI\gummiboot\gummibootx64.efi' and I have # efibootmgr BootCurrent: 0004 Timeout: 0 seconds BootOrder: ,0001,0002,0003 Boot* gummiboot Boot0001* grub Boot0002* vanilla Boot0003* vivid Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network vanilla = self-compiled 3.19 kernel vivid = default Ubuntu 15.04 kernel
