[gentoo-user] [SOLVED} Exact setting in grub to default to a kernel by name?
On Tue, Jun 15, 2021 at 02:56:48PM +0100, Neil Bothwick wrote
> On Mon, 14 Jun 2021 16:25:00 -0400, Walter Dnes wrote:
>
> > Unfortunately, just like the standard grub.cfg, it's a tiny-looking
> > text font on my 1920x1080 monitor that I have to squint at. Next
> > step... what do I do to get a functioning GUI?
>
> Set up a theme, you can use one of the supplied examples as a base, with
> a larger font.
>
> https://www.gnu.org/software/grub/manual/grub/grub.html#Fonts
After more reboots than I want to remember, I'm finally where I want
to be. Thanks for everybody's help. I found a thread on Stackexchange
https://unix.stackexchange.com/questions/31672/can-grub-font-size-be-customised
which supplied the final piece of the puzzle. That thread was started
9 years, 4 months ago. grub1 is now a distant memory, so change all
mentions of "grub2" to plain "grub". As per the Stackexchange thread,
there's a grub-mkfont command that can translate ttf files to pf2 files
readable by grub. ***AND YOU CAN RESIZE THE FONT WHILE YOURE AT IT***.
So I ran grub-mkfont, with "-s 64" which means 64 pixels high...
grub-mkfont -s 64 -o /boot/grub/fonts/HonkingBigFont.pf2
/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf
My grub.cfg follows. Yours would obviously differ in details.
search --set=root --label rootfs
sleep 2
set timeout=15
set gfxmode=640x480
set gfxpayload=keep
loadfont /boot/grub/fonts/HonkingBigFont.pf2
insmod all_video
insmod gfxterm
terminal_output gfxterm
menuentry 'Linux Experimental' {
linux /vmlinuz-experimental root=/dev/sda2 ro noexec=on net.ifnames=0
intel_pstate=disable ipv6.disable=1
}
menuentry 'Linux Experimental Recovery' {
linux /vmlinuz-experimental root=/dev/sda2 ro
}
menuentry 'Linux Production' {
linux /vmlinuz-production root=/dev/sda2 ro noexec=on net.ifnames=0 i
ntel_pstate=disable ipv6.disable=1
}
menuentry 'Linux Production Recovery' {
linux /vmlinuz-production root=/dev/sda2 ro
}
The menu output is Y-U-U-U-U-U-GE, which makes it nice and readable on
my 1920x1080 monitor. There's a cosmetic problem in that this font
doesn't have "line-drawing characters"...
1) The box around the menu is composed of garbage characters.
2) The bit about using up-arrow and down-arrow keys to select also shows
the same garbage characters.
grub-mkfont man page says "Convert common font file formats into PF2",
so I may look at other character sets that have line-drawing characters.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] cryptsetup close and device in use when it is not
If the "umount" command seems to be hanging next time, it is most likely due to cache writebacks. You can monitor this like so: $ watch "grep 'Dirty\|Writeback' /proc/meminfo" -Ramon On 15/06/2021 17:26, Dale wrote: Jack wrote: On 6/15/21 10:21 AM, Dale wrote: Ramon Fischer wrote: Hello Dale, this also happens to me sometimes and the culprit was an open process still accessing the hard drive. Maybe you can solve it like this: $ lsof /mnt/8tb zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb $ kill 8390 $ lsof /mnt/8tb After that, you should be able to close the drive via "cryptsetup". -Ramon On 14/06/2021 06:50, Dale wrote: root@fireball / # cryptsetup close 8tb Device 8tb is still in use. root@fireball / # mount | grep 8tb root@fireball / # I've tried lsof before, for both mount point and device, it shows nothing open. It's weird. When this happened last night, just before I posted, I let the drive sit there while I was doing updates. Later on, I tried to close it again and it closed just fine. I hadn't done anything except let it sit there. While I was glad it closed, I wonder why it did it. Did udev finally catch up to the state of the drive? Did some other device update and allow it to close? This is weird. Everything says it is ready to be closed but it thinks something is open. I'm not sure what to point too for the problem. Yet anyway. Thanks for the tip. It was worth mentioning. Dale Is it possible it was still syncing cache out to the physical drive? I wonder if iotop would show any activity for that drive if that's the case? Jack I may try that next time but the light had stopped blinking for several minutes. Since it is a SMR drive, I always leave it running until I can't feel the heads bumping around. I don't think it would be that but, it's worth a try. It may lead to something. Will update when it does it again. Thanks. Dale :-) :-) -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user]
[gentoo-user] Re: cryptsetup close and device in use when it is not
Dale wrote on 15/06/2021 16:21: > Ramon Fischer wrote: >> Hello Dale, >> >> this also happens to me sometimes and the culprit was an open process >> still accessing the hard drive. Maybe you can solve it like this: >> >> $ lsof /mnt/8tb >> zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb >> $ kill 8390 >> $ lsof /mnt/8tb >> >> After that, you should be able to close the drive via "cryptsetup". >> >> -Ramon >> > > I've tried lsof before, for both mount point and device, it shows > nothing open. It's weird. When this happens here, it's because I accessed the drive over NFS. The NFS server sometimes keeps mount points active, and they don't show up in the output of lsof probably because the NFS server is in-kernel, so there are no processes associated with it. Restarting the NFS server allows unmounting. -- Remy
Re: [gentoo-user] cryptsetup close and device in use when it is not
Jack wrote: > On 6/15/21 10:21 AM, Dale wrote: >> Ramon Fischer wrote: >>> Hello Dale, >>> >>> this also happens to me sometimes and the culprit was an open process >>> still accessing the hard drive. Maybe you can solve it like this: >>> >>> $ lsof /mnt/8tb >>> zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb >>> $ kill 8390 >>> $ lsof /mnt/8tb >>> >>> After that, you should be able to close the drive via "cryptsetup". >>> >>> -Ramon >>> >>> On 14/06/2021 06:50, Dale wrote: root@fireball / # cryptsetup close 8tb Device 8tb is still in use. root@fireball / # mount | grep 8tb root@fireball / # >> I've tried lsof before, for both mount point and device, it shows >> nothing open. It's weird. >> >> When this happened last night, just before I posted, I let the drive sit >> there while I was doing updates. Later on, I tried to close it again >> and it closed just fine. I hadn't done anything except let it sit >> there. While I was glad it closed, I wonder why it did it. Did udev >> finally catch up to the state of the drive? Did some other device >> update and allow it to close? >> >> This is weird. Everything says it is ready to be closed but it thinks >> something is open. I'm not sure what to point too for the problem. Yet >> anyway. >> >> Thanks for the tip. It was worth mentioning. >> >> Dale > > Is it possible it was still syncing cache out to the physical drive? > I wonder if iotop would show any activity for that drive if that's the > case? > > Jack > > > I may try that next time but the light had stopped blinking for several minutes. Since it is a SMR drive, I always leave it running until I can't feel the heads bumping around. I don't think it would be that but, it's worth a try. It may lead to something. Will update when it does it again. Thanks. Dale :-) :-)
Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed
Peter, On Tuesday, 2021-06-15 08:41:40 +0100, you wrote: > ... > ># eselect locale set 4 > ># env-update > > > >>>> Regenerating /etc/ld.so.cache... > > After that you need to source /etc/profile, no? Yes, if you want to continue working in this shell. But if I start my Gentoo update script from my unprivileged userid, it only depends on my own environment and on what "/etc/sudoers" allows through. But your remark made me curious about what was really changed in the environment. So I started a privileged shell using my own environment and then executed # env | sort > /tmp/env1 # . /etc/profile # env | sort > /tmp/env2 # diff -du /tmp/env* The trivial environment variable changes were for "LESS", "LS_COLORS" (which was added), "MANPATH", "PATH", and "PS1". However, the non-triv- ial environment variable change was: -LANG=en_GB.UTF-8 +LANG=en_GB.utf8 which sort of shocked me, because that effectively again unset the only variable setting that allowed building of package "/texlive-basic-2021": > ... > > So "en_GB.utf8" in "02locale" but "export LANG=en_GB.UTF-8" in my Shell > > script doing the Gentoo updates is the only working combination I've yet > > found. May this be some sort of bug in "glibc"? Utterly puzzled ... Rainer
Re: [gentoo-user] cryptsetup close and device in use when it is not
On 6/15/21 10:21 AM, Dale wrote: Ramon Fischer wrote: Hello Dale, this also happens to me sometimes and the culprit was an open process still accessing the hard drive. Maybe you can solve it like this: $ lsof /mnt/8tb zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb $ kill 8390 $ lsof /mnt/8tb After that, you should be able to close the drive via "cryptsetup". -Ramon On 14/06/2021 06:50, Dale wrote: root@fireball / # cryptsetup close 8tb Device 8tb is still in use. root@fireball / # mount | grep 8tb root@fireball / # I've tried lsof before, for both mount point and device, it shows nothing open. It's weird. When this happened last night, just before I posted, I let the drive sit there while I was doing updates. Later on, I tried to close it again and it closed just fine. I hadn't done anything except let it sit there. While I was glad it closed, I wonder why it did it. Did udev finally catch up to the state of the drive? Did some other device update and allow it to close? This is weird. Everything says it is ready to be closed but it thinks something is open. I'm not sure what to point too for the problem. Yet anyway. Thanks for the tip. It was worth mentioning. Dale Is it possible it was still syncing cache out to the physical drive? I wonder if iotop would show any activity for that drive if that's the case? Jack
Re: [gentoo-user] cryptsetup close and device in use when it is not
Ramon Fischer wrote: > Hello Dale, > > this also happens to me sometimes and the culprit was an open process > still accessing the hard drive. Maybe you can solve it like this: > > $ lsof /mnt/8tb > zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb > $ kill 8390 > $ lsof /mnt/8tb > > After that, you should be able to close the drive via "cryptsetup". > > -Ramon > > On 14/06/2021 06:50, Dale wrote: >> root@fireball / # cryptsetup close 8tb >> Device 8tb is still in use. >> root@fireball / # mount | grep 8tb >> root@fireball / # > I've tried lsof before, for both mount point and device, it shows nothing open. It's weird. When this happened last night, just before I posted, I let the drive sit there while I was doing updates. Later on, I tried to close it again and it closed just fine. I hadn't done anything except let it sit there. While I was glad it closed, I wonder why it did it. Did udev finally catch up to the state of the drive? Did some other device update and allow it to close? This is weird. Everything says it is ready to be closed but it thinks something is open. I'm not sure what to point too for the problem. Yet anyway. Thanks for the tip. It was worth mentioning. Dale :-) :-)
Re: [gentoo-user] Re: Exact setting in grub to default to a kernel by name?
On Mon, 14 Jun 2021 16:25:00 -0400, Walter Dnes wrote: > Unfortunately, just like the standard grub.cfg, it's a tiny-looking > text font on my 1920x1080 monitor that I have to squint at. Next > step... what do I do to get a functioning GUI? Set up a theme, you can use one of the supplied examples as a base, with a larger font. https://www.gnu.org/software/grub/manual/grub/grub.html#Fonts -- Neil Bothwick Bus: (n.) a connector you plug money into, something like a slot machine. pgpHR3bY8nLLj.pgp Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup close and device in use when it is not
Hello Dale, this also happens to me sometimes and the culprit was an open process still accessing the hard drive. Maybe you can solve it like this: $ lsof /mnt/8tb zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb $ kill 8390 $ lsof /mnt/8tb After that, you should be able to close the drive via "cryptsetup". -Ramon On 14/06/2021 06:50, Dale wrote: root@fireball / # cryptsetup close 8tb Device 8tb is still in use. root@fireball / # mount | grep 8tb root@fireball / # -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed
On Monday, 14 June 2021 17:36:11 BST Dr Rainer Woitok wrote: > Michael, > > On Sunday, 2021-06-13 18:23:54 +0100, you wrote: > > ... > > Yes, this looks odd, but I have not worked out how locale is sourced in > > > > detail. Have you added: > > LANG="en_GB.UTF-8" > > > > in your /etc/env.d/02locale for a system wide setting? > > No, this file still contains > >LANG="en_GB.utf8" > > However, if I change that line to > >LANG="en_GB.UTF-8" > > then I do get a new locale when running > ># env-update > >>>> Regenerating /etc/ld.so.cache... > ># eselect locale list >Available targets for the LANG variable: > [1] C > [2] C.utf8 > [3] POSIX > [4] en_GB.utf8 > [5] en_GB.UTF-8 * > [ ] (free form) ># > > but afterwards re-building package "texlive-basic" again fails until I > undo this change by executing > ># eselect locale set 4 ># env-update > >>>> Regenerating /etc/ld.so.cache... After that you need to source /etc/profile, no? ># eselect locale list >Available targets for the LANG variable: > [1] C > [2] C.utf8 > [3] POSIX > [4] en_GB.utf8 * > [ ] (free form) ># grep -v '^#' /etc/env.d/02locale >LANG="en_GB.utf8" ># > > So "en_GB.utf8" in "02locale" but "export LANG=en_GB.UTF-8" in my Shell > script doing the Gentoo updates is the only working combination I've yet > found. Explanations heartily welcome :-/ > > Sincerely, > Rainer -- Regards, Peter.
