Max Nikulin (HE12025-03-28):
> Approximately a decade ago I
> noticed that new entries were not added to some history file, I do not
> remember if it was .bash_history or for some other tool, but the owner of
> the file was root. It was the reason why I
On 26/03/2025 18:55, Greg Wooledge wrote:
"sudo -i" is meant to approximate the behavior of "su -". Before buster,
nobody would have used that on a Debian system. It's horrible. The
fact that people are now embracing it as a norm is even worse.
It seems I have to clarify why I suggested name
number of minor problems.
Though I also found out that *Timeshift* keeps not only /root but also
/boot folder (even if it is physically on the other disk)! Thanks Universe
So I just copied files from the timeshift /boot backup to the new *ESP*
folder and *GRUB *showed the OS correctly.
There were also
On 2025-03-28, David Wright wrote:
>
> As end-users are the people that computers are built and run
> for, I don't know why you'd find people's use of the term
> "slightly pejorative". (I assume you aren't calling out me
> in particular.)
I was calling myself out, not you. You have always been he
On Wed, Mar 26, 2025 at 15:46:15 +0100, Nicolas George wrote:
> $ su
> # make install
>
> Whoopsie! The Makefile just pwned you.
That's a COMPLETELY separate discussion. Obviously I was referring to
software from reputable sources.
> $ make DESTDIR=/tmp/i install
> $ sud
On Thu 27 Mar 2025 at 22:14:03 (-0400), Michael Stone wrote:
> On Thu, Mar 27, 2025 at 08:29:50PM -0500, David Wright wrote:
> > Excellent, that solves the problem for those on old terminals or
> > lacking copy/paste. As for me, I'll continue to use /bin/su --login,
> > as I have for nigh on three
On Thu, Mar 27, 2025 at 08:29:50PM -0500, David Wright wrote:
Excellent, that solves the problem for those on old terminals or
lacking copy/paste. As for me, I'll continue to use /bin/su --login,
as I have for nigh on three decades, so that I land in my preferred,
consistent cwd, /root.
su -
do
On Thu 27 Mar 2025 at 17:05:56 (-), Greg wrote:
> On 2025-03-26, David Wright wrote:
> >
> > As posted earlier today, a file in sudoers.d/ makes trivial admin
> > tasks like monitoring and logging easier, particularly where the
> > programs concerned can cause damage if the wrong options are us
On Thu 27 Mar 2025 at 13:58:10 (-0400), Greg Wooledge wrote:
> On Thu, Mar 27, 2025 at 12:48:35 -0500, David Wright wrote:
> > It could be argued that it would be simple enough to communicate
> > the user's cwd to root, as a workaround, so that it didn't have to
> > be retyped.
>
> You know what d
On 2025-03-26, David Wright wrote:
>
> As posted earlier today, a file in sudoers.d/ makes trivial admin
> tasks like monitoring and logging easier, particularly where the
> programs concerned can cause damage if the wrong options are used.
I'm certain sudo has its use cases, but all I do persona
On Thu, Mar 27, 2025 at 12:48:35 -0500, David Wright wrote:
> It could be argued that it would be simple enough to communicate
> the user's cwd to root, as a workaround, so that it didn't have to
> be retyped.
You know what does that for you? sudo -s. Or su if you've configured
it with a one-lin
On Thu 27 Mar 2025 at 12:23:26 (+0200), Anssi Saari wrote:
> David Wright writes:
>
> > host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$
> > /bin/su --login
> > Password:
> > bullseye on /dev/sda5 toto05
> > host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/p
Anssi Saari wrote:
> David Wright writes:
>
> > host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$
> > /bin/su --login
> > Password:
> > bullseye on /dev/sda5 toto05
> > host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/program-1.2.3
> > host 09:58:08 /somew
On 3/26/25 6:55 AM, Greg Wooledge wrote:
[SNIP]
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
I don't understand the reference to some "brokenness" of "su".
I've not closely followed this thread so I may
On Wed 26 Mar 2025 at 16:37:41 (-), Greg wrote:
> On 2025-03-26, Richard Owlett wrote:
> >
> > I assumed it was effectively the same as power down and then logging in
> > as root on power-up.
>
> It is. But it's unnecessary and dangerous to run your entire DE as root.
> Or maybe you log in t
Greg Wooledge (HE12025-03-26):
> This caused ALL KINDS of problems. People would do things like:
>
> $ su
> # apt update
> # apt install somepkg
>
> And the postinstall script for somepkg would fail because it couldn't
> find commands that are in /sbin or /usr/sbin, because those dir
So, in most cases* sudo -s* is better? Any downsides?
ср, 26 мар. 2025 г. в 16:10, Greg Wooledge :
> On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> > On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > > I normally use "sudo -s", which is the closest sudo approximation to
> > > the trad
On Wed, Mar 26, 2025 at 07:55:33AM -0400, Greg Wooledge wrote:
[...]
> I normally use "sudo -s", which is the closest sudo approximation to
> the traditional behvior of "su" (before it was broken in buster).
>
> "sudo -i" is meant to approximate the behavior of "su -". Before buster,
> nobody w
On 2025-03-26, Richard Owlett wrote:
>
> I assumed it was effectively the same as power down and then logging in
> as root on power-up.
It is. But it's unnecessary and dangerous to run your entire DE as root.
Or maybe you log in to the console and use startx to run Mate?
At any rate, I do follo
On 2025-03-26, Greg Wooledge wrote:
>>
>> Does this "brokenness" of "su" have any potential effect on my usage?
>
> Maybe. If you haven't created an /etc/default/su file, then something
> like this:
If he hasn't noticed yet, I doubt it.
I noticed when I finally erased Stretch and installed Boo
On 2025-03-26, Richard Owlett wrote:
>> If he hasn't noticed yet, I doubt it.
>
> I agree.
> If I understand what people want to accomplish by using command-line
> options, I would likely have gone to System->Log Out ... and then logged
> in as root.
Not recommended.
On Wed 26 Mar 2025 at 10:03:59 (-0500), Richard Owlett wrote:
> On 3/26/25 9:55 AM, Greg wrote:
> > On 2025-03-26, Richard Owlett wrote:
> >
> > > > If he hasn't noticed yet, I doubt it.
> > >
> > > I agree.
> > > If I understand what people want to accomplish by using command-line
> > > options
On Wed 26 Mar 2025 at 16:24:21 (+0300), J wrote:
> ср, 26 мар. 2025 г. в 16:10, Greg Wooledge :
> > On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> > > On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > > > I normally use "sudo -s", which is the closest sudo approximation to
> > > > the t
On 3/26/25 9:55 AM, Greg wrote:
On 2025-03-26, Richard Owlett wrote:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what people want to accomplish by using command-line
options, I would likely have gone to System->Log Out ... and then logged
in as root.
Not recommended.
On 3/26/25 9:04 AM, Greg wrote:
On 2025-03-26, Greg Wooledge wrote:
Does this "brokenness" of "su" have any potential effect on my usage?
Maybe. If you haven't created an /etc/default/su file, then something
like this:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what
On Wed, Mar 26, 2025 at 04:19:37PM +0300, J wrote:
> >
> > > work with* root?* I will try to test.
> >
> > I fully expect it to, yes.
> >
>
> Oh, yes, it works. I just had to use *sudo su* and not not
I think you never need "sudo su". "sudo -i" and "sudo -s" will do your
bidding, depending on you
>
> > work with* root?* I will try to test.
>
> I fully expect it to, yes.
>
Oh, yes, it works. I just had to use *sudo su* and not not
*su - *
Also it's bad that Wiki doesn't clarify* how to* 'boot the rescue system
including the kernel option "efi=runtime" and mount the EFI variables
before pro
On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > I normally use "sudo -s", which is the closest sudo approximation to
> > the traditional behvior of "su" (before it was broken in buster).
>
> I don't understand the reference to some "brok
On Wed, Mar 26, 2025 at 12:23:38 +0100, to...@tuxteam.de wrote:
> On Wed, Mar 26, 2025 at 02:15:03PM +0300, J wrote:
> > And i thought *sudo -i*, you speaking about, is something like
> > *--interactive*, which is not, how i see now...
>
> The long form is "--login", not interactive. But the "-i"
On Wed, Mar 26, 2025 at 02:15:03PM +0300, J wrote:
> > In my opinion, "sudo -i" might be added to the wiki articles. I would
> > prefer to see a warning concerning compound shell commands in *sudo* docs.
> >
> > J, my impressions is that you read some docs strongly suggesting to
> > prefix every co
> In my opinion, "sudo -i" might be added to the wiki articles. I would
> prefer to see a warning concerning compound shell commands in *sudo* docs.
>
> J, my impressions is that you read some docs strongly suggesting to
> prefix every command instead of just becoming root.
Actually it is easier
There were also some minor problems which I solved with *apt update/upgrade*
> while being in *chroot*.
>
In particular, there was for some reason no internet connection after I
booted to the restored system. Something wrong was with firmware and/or
initramfs i guess.
On 25/03/2025 19:47, J wrote:
Notice that the page suggests "# for i in /dev /dev/pts /proc "
so it is assumed that users should run
$ sudo -i
sudo *SH -c '...' -* as mentioned above. But it is not written in WIki.
In my opinion, "sudo -i" might be added to the wiki articles. I wo
On Wed, Mar 26, 2025 at 09:25:01AM +0700, Max Nikulin wrote:
> On 25/03/2025 19:47, J wrote:
> > Notice that the page suggests "# for i in /dev /dev/pts /proc "
> > so it is assumed that users should run
> >
> > $ sudo -i
> >
> > sudo *SH -c '...' -* as mentioned above. But it is not
>
> Notice that the page suggests "# for i in /dev /dev/pts /proc "
> so it is assumed that users should run
>
> $ sudo -i
>
sudo *SH -c '...' - *as mentioned above. But it is not written in WIki.
I am thinking about if i should propose the Wiki update.
> The error suggests that you forgot to m
debian.org/GrubEFIReinstall#Using_the_rEFInd_rescue_media
In the context of bind-mounts the link is confusing. In some cases
rEFInd should be able to boot *installed* Linux in the case of troubles
system firmware, e.g. missed boot entry. No chroot is required for grub
reinstall. However you wrot
> sudo sh -c '...'
>
Didn't know such a thing. Wasn't mention in the wiki.
Have you considered doing something crazy like creating the mount points?
>
Can't say so. I have fixed my problem a few days ago (see above about
mounting), now i am discussing with Max if Wiki is correct.
https://wiki.d
I have rechecked.
It doesn't work with sudo also.
Not in a one line, not when i tried to make line breaks with \, not in a
bash script.
user@debian:~$ sudo for i in /dev /dev/pts /proc /sys
/sys/firmware/efi/efivars /run; do mount -B $i /mnt/$i; done
bash: syntax error near unexpected token `do'
first installation.
But before this oopsie deletion I have saved as a back-up at least
something from /boot folder, or maybe even everything. There is a Microsoft
folder, /grub folder with bootx64.efi and bootx64.efi.grb (though EMPTY!)
and /Debian folder with shimx64.efi etc…
I have tried to fix the
do a full powercycle.
I just happened to have a cheap USB3 that fails on attempt to boot when
it is plugged into the USB2 port of my old laptop.
A variation is: not the same hub as keyboard and mouse.
grub> echo $cmdpath
(hd2,gpt1)/EFI/debian
grub> echo $fw_path
### no
g the stick into another USB port (e.g. USB2 instead of
USB3 or vice versa)? Try full power cycle, not just reboot.
All the 10 USB ports on my T5820 are specified as USB 3.1 Gen 1. I always do a
full powercycle.
To figure out what happens in your case you may try the following commands:
gru
On Tue, Dec 17, 2024 at 03:32:03PM +0100, Thomas Schmitt wrote:
Roger Price wrote:
To check for bad USB stick, I downloaded debian-12.8.0-amd64-DVD-1.iso and
built a new 12.8 USB installation stick using command
dd if=debian-12.8.0-and64-DVD-1.iso of=/dev/sdj1 bs=4M && sync
The "1" in "/dev/s
small to take a DVD ISO.
Is this the same USB stick as the one with Debian 12.7.0 netinst ?
If so, did you run a partition editor to create a new partition 1 ?
> I tried booting this and got to a GRUB command line. This time ls -l
> reports that (hd0) has "no known filesystem detected&q
On 16/12/2024 15:45, Roger Price wrote:
So I re-inserted the USB installation stick to redo the installation.
This took me to the GRUB command line.
Am I right that you have internal SSD (SATA? NVME?) and a USB stick?
Have you tried to plug the stick into another USB port (e.g. USB2
instead
On Tue, 17 Dec 2024, Thomas Schmitt wrote:
Roger Price wrote:
I got the message error: file '/install.amd/vmlinux' not found
So perhaps:
grub> set root=(hd0)
grub> linux/install.amd/vmlinuz vga=788 --- quiet
grub> initrd /install.amd/gtk/initrd.gz
grub> boot
Hi,
i proposed for booting from the now reluctant USB stick:
> > grub> linux/install.amd/vmlinuz vga=788 --- quiet
> > grub> initrd /install.amd/gtk/initrd.gz
> > grub> boot
Roger Price wrote:
> I got the message error: file '/install.amd/vmlinux'
On Mon, 16 Dec 2024, Thomas Schmitt wrote:
Does the USB stick yield the proper checksum when inspected on a running
GNU/Linux system ?
Will check.
grub> cat (hd0,msdos2)/efi/debian/grub.cfg
set prefix-($root)/boot/grub
I see "=" instead of "-" in this file when t
On Mon, 16 Dec 2024 09:45:59 +0100 (CET)
Roger Price wrote:
> But I did create a
> small FAT32 partition to be mounted on /boot/efi if one day I needed
> it.
Which option in the installer's partitioner did you use, one of the FAT
options, or the EFI one? The latter will create a partition with
On Mon, 16 Dec 2024 18:50:02 +
Joe wrote:
> So I gave up, and just installed bookworm clean. No bootable OS found.
> I'll cut it short: it wouldn't boot because a /boot/efi/EFI directory
> did not contain a Microsoft directory containing bootmgfw.efi.
> Previously, it had been happy to boot f
On 12/16/24 10:50, Joe wrote:
I would add that many modern computers are almost hardwired for
Windows. ...
So I gave up, and just installed bookworm clean. No bootable OS found.
I'll cut it short: it wouldn't boot because a /boot/efi/EFI directory
did not contain a Microsoft directory containing
On Mon, 16 Dec 2024 09:39:22 -0800
David Christensen wrote:
> On 12/16/24 00:45, Roger Price wrote:
> > I have a Dell T5820 workstation. I had already installed Debian 12
> > in a spare partition on a Transcend SSD dating from 2017 using a
> > USB memory stick. I left in place the existing Wind
On 12/16/24 00:45, Roger Price wrote:
I have a Dell T5820 workstation. I had already installed Debian 12 in a
spare partition on a Transcend SSD dating from 2017 using a USB memory
stick. I left in place the existing Windows SSD that came with the
workstation. All went well - a very smooth i
l test command does not
yield "IT MATCHES", then some change has happened to the ISO on the USB
stick. (You may check file debian-12.7.0-amd64-netinst.iso the same way
as /dev/sdc to check whether already the ISO image was altered.)
> grub> cat (hd0,msdos2)/efi/debian/grub.cfg
und."
So I re-inserted the USB installation stick to redo the installation. This took
me to the GRUB command line. I typed a few commands: (I have removed all
details of hd1, hd2... reported as No known filesystem detected, or Filesystem
cannot be accessed)
grub> ls -l
Device hd0:
On Sat 09 Nov 2024 at 17:03:53 (-0700), pe...@easthope.ca wrote:
> From: David Wright
> Date: Fri, 25 Oct 2024 21:12:21 -0500
> > So you need to boot into your bullseye system, and run
> > # grub-install /dev/sdX
> > where X is probably a, your first disk.
&g
The ThinkCentre has one blue and one black, as in the 2nd photo here.
https://en.wikipedia.org/wiki/USB#System_design
> * With the adapter labeled USB 2.0, why is plugging in USB 3 necessary
> to boot the external system?
From: David Wright
Date: Sun, 3 Nov 2024 22:43:19 -0600
Who knows
this list that USB3 connections cost more because (1) different
controller and (2) more wires to run and (3) signals to manage.
* With the adapter labeled USB 2.0, why is connection to a USB 3
socket necessary to boot the external system?
Perhaps grub only boots from USB3? I have no idea if th
peter composed on 2024-11-09 11:35 (UTC-0700):
> * Why does the ThinkCentre have differing USB sockets?
Monkey see, monkey do applies in the competitive field of motherboard
manufacturing. Most computers with 3.x USB have also 2.0 ports. 3.x has a
manufacturing cost that 1.x and 2.0 devices have
From: David Wright
Date: Fri, 25 Oct 2024 21:12:21 -0500
> So you need to boot into your bullseye system, and run
> # grub-install /dev/sdX
> where X is probably a, your first disk.
Done. Resulting menu here.
https://easthope.ca/GrubMenu1.jpg
For reference, this was the ear
nect a USB hub before dealing with the Void drive.
Noticed the USB socket where the Void drive was connected had a black
plastic contact carrier and another socket had a blue carrier. Blue is
USB 3. So plugged the USB adapter with the Void drive into the blue
socket. Voila; grub was able t
the blue socket. Voila; Grub was able to boot the Void system
reliably. Spent the better part of a day investigating when a USB plug
just needed moving. =8~/
In case anyone is interested, these topics remain.
* Why does the ThinkCentre have differing USB sockets?
* With the adapter labeled
e0n1 disk,
> or copying partitions nvme0n1p1, nvme0n1p2, etc, or just recursive
> copies of the files in each partition into new filesystems created
> on sda.
>
> That information might well yield the reason that the installation
> stick wouldn't boot correctly. After reading
sda.
That information might well yield the reason that the installation
stick wouldn't boot correctly. After reading Thomas's post about
which partition is which on the stick, I think that:
grub> set root=(hd0)
grub> linux install.amd/vmlinuz
grub> initrd install.amd/i
On Mon, Nov 4, 2024 at 12:17 PM Chris Green wrote:
>
> On Mon, Nov 04, 2024 at 08:31:41AM -0500, Felix Miata wrote:
> [...]
> > Is a BIOS update available?
> >
> Possibly, but I bet I'd need an MS-Windows system to do the update.
This situation sucks. My father has an Acer laptop like it -- the
I have found how to get it to install, I removed the other (SATA SSD)
disk drive. It now boots successfully, phew!
I've no idea why that second drive breaks things. I installed it when
I was still running xubuntu 24.04 and that OS could see the drive OK.
I actually copied the whole of my old (xu
I have found how to get it to install, I removed the other (SATA SSD)
disk drive. It now boots successfully, phew!
I've no idea why that second drive breaks things. I installed it when
I was still running xubuntu 24.04 and that OS could see the drive OK.
I actually copied the whole of my old (xu
d apple2 is because viewing
> gdisk debian-12.7.0-amd64-netinst.iso
> as a GPT partition table gives a listing with only partition 2.
debian-12.7.0-amd64-netinst.iso has three partition tables:
- A valid MBR ("msdos") partition table with unusual layout.
Partition 1 begin
Chris Green composed on 2024-11-04 14:49 (UTC):
> Felix Miata wrote:
>> You might try pre-partitioning the NVME in GPT mode with ESP partition
>> instead
>> of the current MBR mode.
You seem to have skipped addressing this directly. It appears from your Grub
shell
ls output
On Mon, Nov 04, 2024 at 11:19:50AM -0500, Stefan Monnier wrote:
> > If I boot from the USB stick (isohybrid image) in Legacy mode then it
> > all **appears** to work, installation completes, but then the system
> > won't boot.
>
> What kind of boot loader did you i
ntinues from my "Failed Debian 12 install..." thread earlier
> > > > today.
> > > >
> > > > I can't get the USB Installation stick to boot into the Debian
> > > > installation process when I load it in UEFI mode. If I boot the USB
>
> If I boot from the USB stick (isohybrid image) in Legacy mode then it
> all **appears** to work, installation completes, but then the system
> won't boot.
What kind of boot loader did you install? `grub-efi`, `grub-pc`,
something else?
Does your Debian install's boot fail
> today.
> > >
> > > I can't get the USB Installation stick to boot into the Debian
> > > installation process when I load it in UEFI mode. If I boot the USB
> > > stick in UEFI mode it just takes me to the grub prompt.
> >
> > It may help
k to boot into the Debian
> > installation process when I load it in UEFI mode. If I boot the USB
> > stick in UEFI mode it just takes me to the grub prompt.
>
> It may help to know whether that's a grub> prompt
> or a grub rescue> prompt. The latter takes a bi
t the USB
> stick in UEFI mode it just takes me to the grub prompt.
It may help to know whether that's a grub> prompt
or a grub rescue> prompt. The latter takes a bit more
work to recover from.
Whichever, does typing ls produce a listing of some sort?
Basically, you have to l
> - Always boot using UEFI.
> - Boot the install using legacy BIOS, then manually change the install
> to use grub-efi, then reboot into my EFI config to "activate" the
> right `.efi` installed into the EFI partition.
>
> I started with the first choice, and then a
the Debian
> > installation process when I load it in UEFI mode. If I boot the USB
> > stick in UEFI mode it just takes me to the grub prompt.
>
> > I suspect that this is why, when I boot from the USB stick in BIOS
> > compatibility mode the resulting installation doe
out that if the installation media is booted in "legacy BIOS"
mode, then it can't do an install that boots via UEFI.
IOW I had 3 choices:
- Always boot using legacy BIOS mode.
- Always boot using UEFI.
- Boot the install using legacy BIOS, then manually change the install
to use gr
gt; stick in UEFI mode it just takes me to the grub prompt.
> I suspect that this is why, when I boot from the USB stick in BIOS
> compatibility mode the resulting installation doesn't work.
> Any ideas what I need to do to get the USB stick to boot properly in
> USB mode?
This has
gt; stick in UEFI mode it just takes me to the grub prompt.
> I suspect that this is why, when I boot from the USB stick in BIOS
> compatibility mode the resulting installation doesn't work.
> Any ideas what I need to do to get the USB stick to boot properly in
> USB mode?
This has
connect a USB hub before dealing with the Void drive.
> Noticed the USB socket where the Void drive was connected had a black
> plastic contact carrier and another socket had a blue carrier. Blue is
> USB 3. Black isn't? So plugged the USB adapter with the Void drive
> into the b
This continues from my "Failed Debian 12 install..." thread earlier
today.
I can't get the USB Installation stick to boot into the Debian
installation process when I load it in UEFI mode. If I boot the USB
stick in UEFI mode it just takes me to the grub prompt.
I suspect that th
drive
> into the blue socket. Voila; Grub was able to boot the Void system
> reliably. Spent the better part of a day investigating when a USB plug
> just needed moving. =8~/
>
> In case anyone is interested, these topics remain.
>
> * Why does the ThinkCentre have dif
On 27/10/2024 21:56, David Wright wrote:
On Sat 26 Oct 2024 at 20:55:11 (-0700), pe...@easthope.ca wrote:
A Web search
found mention of grub command nativedisk which I added.
I don't know anything about nativedisk or the distinctions between
various types of driver.
[...]
nativ
socket where the Void drive was connected had a black
plastic contact carrier and another socket had a blue carrier. Blue is
USB 3. Black isn't? So plugged the USB adapter with the Void drive
into the blue socket. Voila; Grub was able to boot the Void system
reliably. Spent the better pa
On Thu, Oct 31, 2024 at 23:10:22 -0500, David Wright wrote:
> On Mon 28 Oct 2024 at 07:08:12 (-0400), Greg Wooledge wrote:
> > On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
> > > type
> > > set -x
> > > before you run os-prober and
> > > set +x
> > > afterwards, and track what it
On Mon 28 Oct 2024 at 07:08:12 (-0400), Greg Wooledge wrote:
> On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
> > type
> > set -x
> > before you run os-prober and
> > set +x
> > afterwards, and track what it does.
>
> os-prober is a script, so that won't work as written. You'd ei
] || ls
"$dir"/usr/lib*/ld*.so*) >/dev/null 2>/dev/null; then
The comments preceding it tell you why this test comes about last,
and what the difficulties are. I would hazard a guess that Void
linux fails this test.
> Where is "set"?
It's a shell built-in. Greg&
a lazy way:
> type
> set -x
> before you run os-prober and
> set +x
> afterwards, and track what it does. You'd probably want to
> capture the output as it could be voluminous; it looks for
> linux systems just about last.
You've lost me there. Which first test? W
On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
> type
> set -x
> before you run os-prober and
> set +x
> afterwards, and track what it does.
os-prober is a script, so that won't work as written. You'd either
need to modify os-prober (change the second line from "set -e" to
"set -
On Sun 27 Oct 2024 at 11:26:12 (-0700), pe...@easthope.ca wrote:
> A search of "os-prober security" finds several pages. os-prober is
> disabled by default in Archlinux and other respected distributions.
>
> For interest, I enabled os-prober again in /etc/default/grub a
From: David Wright
Date: Sun, 27 Oct 2024 09:56:45 -0500
> That earlier installation is presumably the bookworm that
> wrote (hd0,gpt2)/boot/grub/grub.cfg with the Grub deb12u1,
> which I pointed out in my first post, but wasn't confirmed
> by your follow-up.
Yes, the
On Sat 26 Oct 2024 at 20:55:11 (-0700), pe...@easthope.ca wrote:
> Tim & all,
>
> From: Tim Woodall
> Date: Fri, 25 Oct 2024 22:35:50 +0100 (BST)
> > It's possibly not reading the grub.cfg you think it is reading. I've
> > hit this problem before
Tim & all,
From: Tim Woodall
Date: Fri, 25 Oct 2024 22:35:50 +0100 (BST)
> It's possibly not reading the grub.cfg you think it is reading. I've
> hit this problem before - IIRC grub uses the grub.cfg from the *first*
> place it finds one - this can even be a par
On Fri 25 Oct 2024 at 23:50:05 (-0400), Felix Miata wrote:
> David Wright composed on 2024-10-25 14:08 (UTC-0500):
> > On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:
>
> >> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel
> >> addit
David Wright composed on 2024-10-25 14:08 (UTC-0500):
> On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:
>> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel
>> addition or
>> removal causes its regeneration anew based upon the content of
On Fri 25 Oct 2024 at 13:30:25 (-0700), pe...@easthope.ca wrote:
> From: David Wright
> Date: Fri, 25 Oct 2024 14:13:50 -0500
> > You took out the tail!
>
> Appears we're at crossed purposes. You catted /etc/grub.d/40_custom.
> I posted /boot/grub/grub.cfg.
reful
monkeying.
Thanks, ... P.
It's possibly not reading the grub.cfg you think it is reading. I've
hit this problem before - IIRC grub uses the grub.cfg from the *first*
place it finds one - this can even be a partition (or in my case a LV)
t
ntries 07_custom refers to are not duplicated by
> 41_custom
> after every time whatever Grub package providing it is updated.
Do you mean that the previously inserted copies of custom.cfg are
preserved, and a new copy inserted, each time grub-mkconfig runs?
If that's not the case,
From: David Wright
Date: Fri, 25 Oct 2024 14:13:50 -0500
> You took out the tail!
Appears we're at crossed purposes. You catted /etc/grub.d/40_custom.
I posted /boot/grub/grub.cfg.
My 40_custom has the "exec tail" line as you posted and produces a
stanza in /
d/ I copy 41_custom to 07_custom. Then I empty 41_custom and
>> make it
>> immutable so that the entries 07_custom refers to are not duplicated by
>> 41_custom
>> after every time whatever Grub package providing it is updated.
> Do you mean that the previously inserted co
1 - 100 of 1614 matches
Mail list logo
