Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On Tue, Jun 13, 2023 at 10:38 AM Grant Edwards wrote: > On 2023-06-12, Wol wrote: > > On 09/06/2023 21:16, Grant Edwards wrote: > >> On 2023-06-09, Daniel Pielmeier wrote: > >> > >>> If it is only about gemato then temporary disable the rsync-verify flag > >>> which pulls it in. > >>> > >>> # USE="-rsync-verify" emerge sys-apps/portage > >> > >> The problem I ran into is that you never know how many issues there > >> are standing in the way of upgrading. The one time I decided to muscle > >> my way through updating an "obsolete" Gentoo install, [...] > >> > >> You do learn alot about how portage/emerge works... > >> > > Learning that is a good idea maybe :-) > > > > But last time I had a well-out-of-date system, it was a long and > > messy process ... > > > > What I did was, every time portage said "giving up" or "conflict found" > > or whatever, I just took a note of as many of the packages I could > > remember that portage said it could emerge, and then manually updated > > them "emerge --update --one-shot". > > > > And any conflicts, if I dared, I simply deleted then "emerge -C > --one-shot". > > IIRC, at one point Python was one of those problems, and I stupidly > removed Python before realizing what that meant... > > Hilarity ensued. > > Removing/skipping as many of the non-essential "big" packages and > their dependancies and getting the base system updated is indeed the > best way to go. I second this approach. When rescuing a Gentoo system, my first step would be to deselect any and every non-critical package from @world, then try to get @system updated through any means necessary. In the past, I've removed packages instead of deselecting them, but I've had cases where depclean refused to do anything because there were already dependency problems, and sometimes it's hard to know what's safe to unmerge with "-C".
Re: [gentoo-user] Bespoke terminal font
I use either Droid Sans Mono or Inconsolata (one is a fallback for unsupported glyphs in the other, but I forget which one's which), and I have nothing inside my zeros. Zero is distinguished by having flattened / vertical sides, while the capital letter 'O' is rounded. On Mon, Jun 5, 2023 at 1:37 PM Mark Knecht wrote: > > > On Mon, Jun 5, 2023 at 10:31 AM Mark Knecht wrote: > > > > > > > > On Mon, Jun 5, 2023 at 9:43 AM Matt Connell wrote: > > > > > > On Mon, 2023-06-05 at 08:54 -0700, Mark Knecht wrote: > > > > There's a terminal font called 'hack' that doesn't have anything > > > > inside the zero. > > > > > > Is this the right one? > > > > > > https://github.com/source-foundry/Hack > > > > Bummer. Looks like he might have changed it. > > > > I'm starting to have old-person type eye problems and > > found this article: > > > > https://itsfoss.com/fonts-linux-terminal/ > > > > which from the example has nothing inside the zero, > > but the picture on the github page looks like it does. > > > > Mark > > > As for other fonts to explore AI suggests: > > Droid Sans Mono > Inconsolata > Liberation Mono > > I see some example pages that look ok but > I don't have time to explore and test. > > HTH, > Mark > Source Code Pro >
Re: [gentoo-user] updating /boot directory EFI
You can probably use a portage hook to do it. I haven't tested it, but
something along the lines of creating a file at
"/etc/portage/env/sys-boot/grub" which contains an implementation of the
"post_pkg_postinst()" function. Then, you can copy the logic from the
ebuild to determine whether the version number has changed. Realistically
though, I'd probably skip the conditional logic and let the hook run
grub-install every time.
Some ebuilds print rather important messages, and if you're updating
software regularly, there shouldn't be tons of messages in
/var/log/portage/elog/summary.log. At the very least, I would configure it
to email me a copy of the messages so that I can review them as soon as I
can.
On Mon, Apr 17, 2023 at 4:26 PM Dr Rainer Woitok
wrote:
> Mitch,
>
> On Monday, 2023-04-17 08:15:51 -0400, you wrote:
>
> > I just took a quick glance at the ebuild, and it looks like it should
> print
> > a reminder ("Re-run grub-install to update installed boot code!") every
> > time you upgrade from an older version to a newer one, but it also looks
> > like the reminder gets skipped if you're re-emerging the same version.
> >
> >
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.06-r4.ebuild#n314
>
> Thankyou very much for this information. But is there anyone out there
> who skims through tons of SUCCESSFUL emerge log files after every rou-
> tine upgrade? Personally, I only check the logs in case of build fai-
> lures or conflicts.
>
> By the way, I only see this message in the build logs for versions 2.06-
> r4 and 2.06-r6, but not in older logs. So maybe that's a rather new ad-
> dition to the ebuild file?
>
> Since I do my routine upgrades via a script anyway, I now retrieve the
> name of the most recent Grub build log before I really start "emerge"
> and after "emerge" finished, and if the two names differ and the newer
> file contains this "Re-run ..." message, I now run "grub-install" from
> within this script. Problem solved.
>
> But I have the vague feeling there should be a more foolproof solution.
>
> Sincerely,
> Rainer
>
Re: [gentoo-user] updating /boot directory EFI
Grub and Windows Boot Manager are bootloaders, and they can be "on" a
drive, but efibootmgr is not. Your EFI is part of your motherboard, and
efibootmgr is just a tool that helps you configure your EFI. The actual EFI
configuration is stored on your motherboard, not on either drive. For what
it's worth, I vaguely remember a similar tool available in Windows. If you
change your configuration in efibootmgr, you would see the changes in the
Windows tool, too, because you only have one EFI (which both tools can
access).
On Mon, Apr 17, 2023, 09:32 Mark Knecht wrote:
>
>
> On Mon, Apr 17, 2023 at 4:57 AM Michael wrote:
> >
> > On Monday, 17 April 2023 00:29:49 BST Arsen Arsenović wrote:
> > > Wol writes:
> > > > On 16/04/2023 22:30, Mitch D. wrote:
> > > >> Wol, can you elaborate on why you think Grub is deprecated on EFI
> > > >> systems?
> > > >
> > > > Because EFI is a boot manager?
> > >
> > > That is not the case any more than the classic IBM PC boot procedure
> is.
> > > There is technical capability for UEFI firmware to act in such a
> manner,
> > > but, in practice, this is not at all the case.
> > >
> > > The technical capability comes from the fact that boot entities have a
> > > lil' bit of metadata attached to them.
> >
> > The ability of UEFI to boot linux kernels, as long as they are built
> with the
> > EFI boot stub enabled, may render 3rd party boot managers and their boot
> > loaders redundant. However, as already mentioned below, the flexibility
> and
> > customisability of GRUB and other boot manager exceeds any UEFI firmware
> I've
> > come across.
> >
> >
> > > > Why chain-load boot managers?
> > >
> > > In theory, EFI implementations should provide boot
> > > managers. Unfortunately, in practice these boot managers are often so
> > > poor as to be useless. The worst I've personally encountered is on
> > > Gigabyte's Hybrid EFI, which provides you with no boot options
> > > whatsoever, beyond choosing the boot device (hard disk vs. optical
> disc,
> > > for instance). I've heard of others that are just as bad. For this
> > > reason, a good EFI boot manager—either standalone or as part of a boot
> > > loader—is a practical necessity for multi-booting on an EFI
> > > computer. That's where rEFInd comes into play.
> > > - https://rodsbooks.com/refind/
> >
> > I've stopped using GRUB and have been using the UEFI firmware to boot
> directly
> > Gentoo for more than 10 years now. Given I have also flashed some of the
> > MoBos' chipset with new UEFI firmware a dozen times or more, I have not
> > experienced any MoBo failures as yet. Also, the ESP partition formatted
> with
> > FAT32 has remained quite resilient too. No loss of data or fs
> corruption yet
> > (keeps fingers crossed and checks backups).
> >
> > My particular systems setup and use case suits this approach, but I
> appreciate
> > people who multiboot daily/frequently, or need to boot LiveISOs off the
> disk
> > may find GRUB and friends to be a more suitable solution.
> >
> >
>
> My needs are quite simple but efibootmgr, set up by the Kubuntu install
> on a separate M.2 from the Windows install the machine came with, works
> for
> me. I always start the day in Kubuntu, then reboot to Windows if I'm
> working
> on music:
>
> 1) The simple view of the two installations:
>
> mark@science2:~$ efibootmgr
> BootCurrent: 0003
> Timeout: 1 seconds
> BootOrder: 0003,
> Boot* Windows Boot Manager
> Boot0003* ubuntu
> mark@science2:~$
>
> 2) The more complicated view with GUIDs and such:
>
> mark@science2:~$ efibootmgr -v
> BootCurrent: 0003
> Timeout: 1 seconds
> BootOrder: 0003,
> Boot* Windows Boot Manager
> HD(1,GPT,2052c843-0057-494a-a749-e8ec3676514a,0x800,0x32000)/File(\EF
>
> I\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4
> .e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}
> Boot0003* ubuntu
> HD(1,GPT,2052c843-0057-494a-a749-e8ec3676514a,0x800,0x32000)/File(\EFI\UBUNTU
> \SHIMX64.EFI)
> mark@science2:~$
>
> 3) To get to Windows I can choose it in the OS screen if I'm sitting there
> but the most reliable way for me to get from Kubuntu to Windows is to just
> tell the system to go to Windows at the next boot using a batch file in
> Kubuntu:
>
> mark@science2:~$ cat bin/RebootWindows
> sudo efibootmgr -n
> reboot
> mark
Re: [gentoo-user] updating /boot directory EFI
I just took a quick glance at the ebuild, and it looks like it should print
a reminder ("Re-run grub-install to update installed boot code!") every
time you upgrade from an older version to a newer one, but it also looks
like the reminder gets skipped if you're re-emerging the same version.
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.06-r4.ebuild#n314
I don't see a USE flag to automate the process after all, so I must have
been misremembering. It might be difficult to automate, and perhaps more
importantly, it's not always reversible. Installing grub to an MBR will
clobber anything else that was previously there. Another challenge is for
portage to reliably identify the target device. For example, using software
RAID, grub-install probably needs to be run multiple times, once targeting
each physical disk. Overall, I think it's possible, but it's not trivial,
and it would probably need a config file.
Should you worry? Probably not. Version 2.04 was stabilized in January
2020, so the version number has only increased once since then, maybe twice
if you originally installed Gentoo in 2019. The rest of the upgrades were
ebuild revisions. Since ebuild revisions can include patches and have other
important corrections, I would rerun grub-install if I were you, but I
wouldn't say it's urgent.
On Mon, Apr 17, 2023, 05:55 Dr Rainer Woitok
wrote:
> Mitch,
>
> On Sunday, 2023-04-16 07:16:09 -0400, you wrote:
>
> > ...
> > "grub-install" copies Grub from your Gentoo installation to your hard
> drive
> > / SSD / etc. This has nothing to do with your kernel, it only involves
> > Grub. Rerun this command when you emerge updates to Grub.
>
> Is this really necessary to be done manually? Shouldn't this be the job
> of the Grub ebuild? My gut feeling is that having to look out for Grub
> updates and then to manually run "grub-install" every time is not really
> Gentoo-like ...
>
> To be honest, I've run this command once during my initial Gentoo in-
> stall three and a half years back, but never since. And according to my
> logs I've since then upgraded Grub ten times and rebuilt it four times.
> Should I worry? Can this be automated?
>
> > ...
> > NOTE: if I remember correctly, there are USE flags that can be enabled to
> > automatically run grub-install and grub-mkconfig when updates are
> installed
> > for Grub and for kernels, respectively.
>
> Checking the USE flags for Grub and Portage I didn't find anything for
> automatically running "grub-install". Where else to look?
>
> Sincerely,
> Rainer
>
Re: [gentoo-user] updating /boot directory EFI
Wol, can you elaborate on why you think Grub is deprecated on EFI systems? On Sun, Apr 16, 2023, 15:17 hitachi303 wrote: > Am 16.04.23 um 21:11 schrieb Mitch D.: > > A minimal EFI bootloader can show an updated menu for the new kernels > > without needing to make regular writes to the EFI variable storage. I > > didn't know Grub was deprecated, but there are other options. rEFInd is > > pretty. Syslinux is flexible. > > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader > > Default: GRUB > >
Re: [gentoo-user] updating /boot directory EFI
There is a catch related to using EFI without a conventional bootloader. If you want your boot menu to include details such as kernel versions, then it would be necessary to run efibootmgr every time you update the kernel. I'm not sure if the EFI variable storage is resilient to repeated writes, so this could be dangerous. The alternative is to have a couple generic EFI boot entries, such as "Gentoo" and "Gentoo (Old Kernel)", which point to consistent paths, then you replace the kernel at those paths without needing to update the boot entry each time. A minimal EFI bootloader can show an updated menu for the new kernels without needing to make regular writes to the EFI variable storage. I didn't know Grub was deprecated, but there are other options. rEFInd is pretty. Syslinux is flexible. It's probably not a huge issue, but I doubt the EFI data chip on the motherboard has been chosen for its write endurance. On Sun, Apr 16, 2023, 14:31 Wol wrote: > On 16/04/2023 18:43, the...@sys-concept.com wrote: > > > > On 4/16/23 08:49, Lee K wrote: > >> Also, learn how to boot a kernel from the grub cli, and keep a printed > >> version of these instructions in a handy place. This has saved my butt > >> countless times. :) > > > > Thanks Lee, that is really helpful hint. > > > Or, seeing as grub is deprecated with EFI, learn how to boot using EFI. > > Don't worry, I haven't really learned either :-) I just keep a Slack > live-CD handy ... > > Cheers, > Wol > >
Re: [gentoo-user] updating /boot directory EFI
When you emerge grub, Gentoo compiles and "installs" grub (and some grub-related tools) to a directory inside your Gentoo installation, just like other applications. The catch is that grub isn't like other applications... it needs to run outside of Gentoo, before Linux starts. This means that Grub isn't very useful sitting inside your Gentoo installation. "grub-install" copies Grub from your Gentoo installation to your hard drive / SSD / etc. This has nothing to do with your kernel, it only involves Grub. Rerun this command when you emerge updates to Grub. "efibootmgr" tells your motherboard's (U)EFI firmware where to find Grub (or any other bootloader or EFI tool). When you emerge an update for Grub (and run grub-install), the path shouldn't change, so there's no need to rerun efibootmgr. This also has nothing to do with your kernel. "grub-mkconfig" generates a configuration file that Grub reads while the computer is booting, and generally tells Grub what options to include in the menu Grub displays. When you update your kernel, you want to update that menu, so you SHOULD rerun "grub-mkconfig" at this time. All EFI systems are supposed to have an EFI system partition (ESP). Some people use the ESP as their boot partition, while other people keep them as two separate partitions and mount the boot partition as /boot and the ESP as /boot/EFI. Either way, it's not related to dual-booting. NOTE: if I remember correctly, there are USE flags that can be enabled to automatically run grub-install and grub-mkconfig when updates are installed for Grub and for kernels, respectively. -Hypoon On Sun, Apr 16, 2023, 00:19 wrote: > On 4/15/23 22:01, the...@sys-concept.com wrote: > > After installing new kernel how to update /boot EFI directory? > > > > From my notes, I have: > > grub-mkconfig -o /boot/grub/grub.cfg > > grub-install --target=x86_64-efi --efi-directory=/boot > > > > or should it be: > > grub-mkconfig -o /boot/grub/grub.cfg > > efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Gentoo" -l > /boot/grub/x86_64-efi/core.efi > > > > Boot partition is: > > /dev/nvme0n1p1 = /boot > > This is not dual boot system, so I don't know why /boot has EFI directory > > >
Re: [gentoo-user] How to restart/fix frozen XFCE4
I don't remember if it was tied to a specific popular Linux distribution, but this used to be the common response to new Linux-converts when they asked for the Linux version of Ctrl+Alt+Delete (to kill a hanging process). I remember some modifier keys and escape, but I can't confirm that it was exactly "Ctrl+Alt+Esc". The key combination would launch "xkill", which now shows a skull-and-crossbones cursor instead of an "X" (on my machine, at least). Using the skull-and-crossbones to click on a window will kill the process corresponding to that window. On Sun, Apr 2, 2023 at 12:09 PM wrote: > On 4/2/23 05:33, Alexe Stefan wrote: > > Other possible solutions are killing xfce through telnet/ssh or from > another tty. Another is using the sysrq key, but that is to be avoided. > > > > dum., 2 apr. 2023, 08:28 the...@sys-concept.com>> a scris: > > > > > > At time to time my XFCE4 freezes. The screen is responding to the > keyboard, mouse pointer is moving on the screen but nothing is responding. > > I just lookup some solutions and found this one: > > > > - press: CTRL+Alt+T (to get to terminal) > > - pidof xfce4-panel > > - kill -9 pid > > > > xfwm4 --replace & > > > > Any other solutions? > > I ask ChatGPT for a solution to this and I got: > > 1.) Try using the keyboard shortcut Ctrl+Alt+Esc. This will turn your > mouse cursor into an X symbol, allowing you to click on the window that's > causing the freeze and kill it. > > 2.) If the keyboard shortcut doesn't work, try switching to a virtual > terminal by pressing Ctrl+Alt+F2. Log in with your username and password. > > 3.) Once you're logged in, use the top or htop command to identify the > process that's causing the freeze. You can sort the list of processes by > CPU usage or memory usage to make it easier to find the offending process. > > 4.) Use the kill command followed by the process ID (PID) to terminate the > process. For example, if the PID is 1234, you would use the command kill > 1234. > > 5.) Switch back to your X session by pressing Ctrl+Alt+F7. Your XFCE4 > desktop environment should now have restarted, and you can log in as usual. > > "Ctrl+Alt+Esc" doesn't work, and I've never seen this solution; where > does it come from? > > > Thelma > >
