Re: "Bug" in Debian Installer? S.W.A.G.
7My reason for suggesting changing debconf priority to low was that perhaps additional questions might have uncovered some strangeness in the installer. It was not intended to fix this bug but only as a means to further analyze the bug. Apparently those on this list failed to understand but that's understandable since trolls don't attempt to think through future probable outcomes of other's proposed actions. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sun, 16 Apr 2023, Geert Stappers wrote: > On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote: > > On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote: > > > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote: > > > > [1] I needed a websearch on S.W.A.G. Did find > > > > - Sharing Warmth Around the Globe > > > > - > > > > - > > > > > > > } Stopped searching upon > > > > Something We All Get (tired of hearing) > > > > > > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess". > > Yeah, I think it is. > > > > In my experience (and usage) it was "Scientific Wild Ass Guess". > > Acknowledge on scientific usage and scientific experience. > > > First appearance of S.W.A.G. in this thread was in a top post. > That made it a Silly Wild Ass Guess. > > Follow up message ( debconf/priority was not changed ) made > it a Stupid Wild Ass Guess. > > Back to "Sharing Warmth Around the Globe": > > Replying below previous text helps understanding each other. > > > Regards > Geert Stappers >
Re: Apt sources.list
On Sun, Apr 16, 2023 at 12:10:33AM -0400, Stefan Monnier wrote: > > On release day, bookworm -> "stable", > > So far so good. > > > "unstable" -> testing == trixie > > Really? I thought there was always a delay for packages to move from > unstable to testing. > Let's try this again because release day is "special" in the sense that all the links move down. Release day -1 (with luck, sometime in late May or early June 2023) "Oldstable" == Buster == Debian 10 "Stable" == Bullseye == Debian 11 "Stable-updates / Stable backports" -> the Bullseye target "Testing" == Bookworm (== Debian 12) [FROZEN for several months] "Unstable" == Sid (== Trixie == will be Debian 13) "Experimental == RC-Buggy" - stuff that's too unstable for Sid / not targetted for Testing eventually Release day when someone pushes the magic switch and the symlinks move :) "Oldoldstable" == Buster == Debian 10 "Oldstable" == Bullseye == Debian 11 "Stable" == Bookworm == Debian 12 "Testing-proposed-updates" is empty because that's been frozen for months [If there is anything in it, that now becomes stable updates for next point release for Bookworm] "Stable backports" for Buster are removed. "Stable-backports" for Bookworm is created as is a new T-P-U if needed. "Testing" == "Previous contents of Unstable" (== Trixie / Debian 13) "Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which will == Debian 14 eventually as Forky) "Experimental == RC-Buggy" The moves are instantaneous in one sense: once they're done, then the normal routine applies and updates intended for Trixie will be placed into Unstable and then move through downwards from then on. On release day, essentially Bookworm remains frozen and the codebase doesn't move again unless getting updates from either debian-security or stable backports (if that's what people want). No new code goes in at all. Testing is now an entirely separate distro which should be developing from now and will be released in ~two years. Hence the suggestion to ride with Bookworm until release day precisely and change at that point to Trixie: using the codenames is always preferable > > Stefan > All the very best, as ever, Andy
Re: Email clients and IMAP search support
On Sun, 2023-04-16 at 17:01 +0100, Andre Rodier wrote: > Hi, > > Is there any desktop email client on Debian, that supports server side IMAP > search, please ? > > I have an email server that support indexing attachment contents, and when I > run a query from the command line using > doveadm search or even TELNET, it is returning the correct email indexes. > > However, when I try the same search with a desktop client, nothing is > returned. I tried Thunderbird, Balsa, Claws and > Geary. None of them is satisfactory. > > Thanks for your help. > > Thanks, > André > OK, I am answering to myself, Gnome Evolution works, it is sending the search query to the server. Even in some advanced RTL languages like Arabic. Great!
Re: Apt sources.list
Frank writes: > Are you kidding? No way! Unstable is never pushed into testing just > like that. There are packages that will never move to testing at all! That's correct. Immediately after the release Testing and Stable are identical. Unstable is unchanged. When the freeze is lifted packages that have been waiting in Unstable begin to flow into Testing. Packages that have been bug-free in Unstable for ten days are linked into Testing provided all dependencies can be met and that no freeze is in effect. They are *not* removed from Unstable. Packages that have migrated to Testing remain in Unstable until they are replaced by new uploads. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Debian Bookworm RC 1 installer- a Bug?
On Sun 16 Apr 2023 at 07:19:18 (-0700), Peter Ehlert wrote: > On 4/9/23 08:57, David Wright wrote: > > On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote: > > > Debian Bookworm RC 1 installer > > > Damned nice, the improvements are appreciated. > > I ran rc1 in my usual manner, and the only difference I noticed was > > the one extra question about non-free firmware, to which I replied > > yes. (There may well be improvements under the hood, so to speak.) > > Oh, and the initrd is somewhat larger, as per usual. > > > > > using the new debian-bookworm-DI-rc1-amd64-netinst.iso > > > Legacy install, GPT partition > > I assume Legacy means BIOS booting. Same here, but only one disk. > correct. different term, same thing. Not UEFI > > > > > graphic install, manual partitioning > > > Mate Desktop (others were deselected) > > Non-graphical here, a suitable partition existed, and only > > standard and SSH server software was installed. > > > > > WiFi firmware: > > Untested as this machine is a 2006-vintage mini-tower lacking wifi. > > > > [ snipped narrative of later network-switching ] > > > > > Boot Loader: > > > all disk drives were detected, however the one with the bios_grub > > > partition was highlighted > > I can't recall seeing anything other than the first item highlighted, > > ie "Enter device manually", at least with the non-graphical installer > > in expert mode. I selected the (sole) hard drive, item 2. The only > > remaining item was the USB stick containing the installer ISO. > > > > As expected nowadays, when the machine rebooted, the Grub menu > > had only two lines, both pointing to the newly installed system. > > (I hadn't made any attempt to counteract GRUB_DISABLE_OS_PROBER > > during my installation.) So Grub was correctly installed in the > > MBR, and the rest of Grub occupied d400 bytes of /dev/sda1 (the > > 3MB BIOS boot partition on the single disk). > > > > > = > > > second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso > > > same machine and again Legacy install, GPT partition > > > however I did NOT install from the live session: > > > I chose to go directly to install rather than the Calamares installer > > > then manual partitioning > > > > > > Boot Loader: > > > all drives were detected, however the one with the bios_grub partition > > > was NOT highlighted, but I did select it. > > > GRUB was Not properly installed, my former grub menu was still active. > > How did you determine that it was the previous menu. Wouldn't it look > > just the same? > I enable GRUB_DISABLE_OS_PROBER so that the various other operating > systems are shown > if the new GRUB is properly installed I get the "new" one item only > GRUB display. > then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER and > update GRUB > > > > > *** I tried a second time, same as above being super careful, same result. > > > > > > I then booted with my default system, ran grub-install /dev/sde && > > > update-grub > > > then "new" system was on my boot menu. > > > then booted and it ran as expected. So you installed Grub on /dev/sde. > > Which method did you use to boot the "default" system (which I assume > > is bullseye, in a different partition on one or other of the disks), > > in view of the rather sparse menu from grub.cfg on the new system? > I boot with the "old" GRUB menu as explained above...it has Several > operating systems listed, my old default OS is still at the top of the > list. > > > > > back to the WiFi dongle, again the obscure firmware was properly installed > > > > > > Is this a Bug or a user/hardware issue? > > Presumably we are now back to talking about Grub. > > > > If you still have access to the bookworm system, you can check whether > > it claimed to have completed installing Grub successfully. You should > > see lines like: > > > >grub-installer: info: Installing grub on '/dev/sda' > >grub-installer: info: grub-install does not support --no-floppy > >grub-installer: info: Running chroot /target grub-install --force > > "/dev/sda" > >grub-installer: Installing for i386-pc platform. > >grub-installer: Installation finished. No error reported. > >grub-installer: info: grub-install ran successfully > > > > in /var/log/installer/syslog. > Thanks, I did not know where to look or what to look for. I've tidied these lines: > === > Apr 5 12:59:44 grub-installer: info: Identified partition label for > /dev/sdb12: gpt > Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb' > Apr 5 13:01:03 grub-installer: info: grub-install does not support > --no-floppy > Apr 5 13:01:03 grub-installer: info: Running chroot /target > grub-install --force "/dev/sdb" > Apr 5 13:01:03 grub-installer: Installing for i386-pc platform. > Apr 5 13:01:13 grub-installer: grub-install: warning: this GPT > partition label contains no BIOS Boot Partition; embedding won't be > possible. > Apr 5 13:01:13
Re: Email submission.
In-reply-to:
References: <9f8dd61d64d9c253af0fe23b546e6...@easthope.ca>
Subject: Re: Email submission.
From: David Wright
Date: Sat, 15 Apr 2023 22:20:55 -0500
And in turn, this reply doesn't contain any feedback to my suggestion
of installing the backported exim, which claims to support tls on
connect.
Yes, sorry. Too wary of venturing beyond stable.
Now installed backported exim. Unnecessary blanks removed for
legibility here.
$ dpkg -l | grep exim
ii exim4 4.96-14~bpo11+1 all metapackage to ease Exim MTA
(v4) installation
ii exim4-base 4.96-14~bpo11+1 amd64 support files for all Exim
MTA (v4) packages
ii exim4-config 4.96-14~bpo11+1 all configuration for the Exim
MTA (v4)
ii exim4-daemon-light 4.96-14~bpo11+1 amd64 lightweight Exim MTA (v4)
daemon
No new question in "dpkg-reconfigure exim4-config". Shouldn't it ask
to choose between STARTTLS and TLS-on-connect?
/etc/exim4/update-exim4.conf.conf is unchanged by adding the backport.
My only remaining advice is to try everything on every port.
Frequently, one particular method is advertised, but the software
may allow other protocols/methods too. For example, the SMTP
port and commands that mutt sends my posts with is quite different
from those used by my hand-crafted automated emails (same hosts).
Certainly trying many combinations. Technical support from the
smarthost
also might recogize a detail I'm overlooking.
I don't recall ever seeing a debug message with a heading.
Not a heading for the file or a comment explaining one line.
Headings for more abstract levels of progress.
Eg.
"Evaluating whether delivery is local."
"Submitting password for user to smarthost ."
Incidentally the debug text has formal syntax such as this.
08:29:51 3623 }{${if def:sender_ident {from
${quote_local_part:$sender_ident} }}${if def:sender_helo_name
{(helo=$sender_helo_name)
Does anyone recognize a language? Exim internal syntax?
I've never seen anything to be gained from comparing incoming and
outgoing email configurations.
Nothing to compare in configurations. Just an observation that POP3
via stunnel is painless. I might try bypassing exim and sending
directly from MUA to smarthost. Optionally through stunnel.
That seems to be moving on to newsreaders. ?
No, no. https://wiki.debian.org/Pan has the only mention about
starting stunnel I've found in Debian documents. Pertinent to receiving
mail here. Recklessly appended the topic rather than send another
message. =8~/
Thx,... P.
Re: Am I infected with a rootkit?
On Sun 16 Apr 2023 at 19:35:20 (+0200), Thomas Schmitt wrote: > > Jesper Dybdal, do you see the riddling lines in file ~/.bash_history > of the superuser ? > If so: Do you see other strange lines there ? (Do they give more clue ?) > > > A bit less on-topic: > > Greg Wooledge wrote: > > Bash doesn't read the contents of the history file into the in-memory > > history unless you run "history -r". If you had some kind of ksh-like > > setup where you combined "history -w" and "history -r" commands in your > > PROMPT_COMMAND or other variables, then we might be able to reconcile > > the statements we've been given. > > > > In the absence of that, there's just no way you could have commands in > > your shell history that were not typed in that same shell session. > > My Debians always behaved that way. I remember that in Debian 8 i got > several different readline histories in the first shell terminals which > i started. With Debian 11 it's only one history per user. It seems to be > a collection of the last commands of shell sessions when the recent > shutdowns happened. Me too: each shell starts with the contents of ~/.bash_history at that instant, and adds its freshly typed lines to the end of the disk file when it exits. And I spent a while searching unsuccessfully for some HISTFILE=~/.bash_history or history -r command squirrelled away in some startup file. I set export HISTCONTROL=ignoreboth and don't know whether that has side effects. $ echo "$SHELLOPTS" braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor:noclobber $ echo "$BASHOPTS" checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:globasciiranges:interactive_comments:progcomp:promptvars:sourcepath $ However, I can't confirm your Debian 8 behaviour. Cheers, David.
Re: Apt sources.list
On Sat, 15 Apr 2023, Greg Wooledge wrote: Now, personally I don't feel this is a threat model that I need to worry about. I just use plain old http sources at home, and if "They" learn that I've downloaded rxvt-unicode and mutt, well, good for Them. The thread model I'm most concerned about is local stuff *exporting* data elsewhere. I do understand that there are people in some parts of the world that want to do things that they ought to be allowed to do but their repressive governments are preventing. HTTPS is a useful tool to make that repression harder - but doesn't actually make people safe - if doing something is illegal then it's still illegal even if it's harder for the authorities to detect it. But it's pretty much impossible nowadays to have a "safe" environment at home. Phones, TVs, almost everything, now tries to establish outgoing connections. ESNI, and DNSoHTTPS are on the way to making it almost impossible to keep tabs on this and restrict what is allowed to egress. The only redeeming point is that corporates *need* to do egress filtering - so at the moment the browsers cannot totally block it - and if they did try, there would be the financing to provide a browser that corporates could use that, at least, allowed SNI sniffing and regular DNS.
Email clients and IMAP search support
Hi, Is there any desktop email client on Debian, that supports server side IMAP search, please ? I have an email server that support indexing attachment contents, and when I run a query from the command line using doveadm search or even TELNET, it is returning the correct email indexes. However, when I try the same search with a desktop client, nothing is returned. I tried Thunderbird, Balsa, Claws and Geary. None of them is satisfactory. Thanks for your help. Thanks, André
Re: Am I infected with a rootkit?
On 2023-04-16 17:57, Greg Wooledge wrote: On Sun, Apr 16, 2023 at 04:30:51PM +0200, Jesper Dybdal wrote: My .bashrc has: export HISTCONTROL=ignoreboth and that's all. And your description of the default behaviour matches what I experience with bash. There is simply no scenario where all of these things can be simultaneously true. Bash doesn't read the contents of the history file into the in-memory history unless you run "history -r". If you had some kind of ksh-like setup where you combined "history -w" and "history -r" commands in your PROMPT_COMMAND or other variables, then we might be able to reconcile the statements we've been given. In the absence of that, there's just no way you could have commands in your shell history that were not typed in that same shell session. Or somehow inserted into the PuTTY ssh client on the Windows machine to become part of the ssh session. You've just about convinced me that that must be the situation. I've just checked once more: the Windows machine does not have any remote control server (VNC or Remote Desktop) enabled. If it had, it could have been an intrusion into the WiFi LAN. So it's not that simple - unless there is some hidden remote control server functionality. The most stupidly paranoid, off-the-wall, tin-foil-hat scenario that I can come up with, which holds all these statements true, is that someone hacked into the Debian system as root, attached gdb (or some similar program) to a running bash, and used this opportunity to modify your shell's history. Not to do anything. Just to fuck with you. To make it LOOK like someone hacked you... and that the hacker was a halfwit. *Too* paranoid. And it would make sense only if I discovered it - if I hadn't happened to use the history, I would never have seen anything strange. The other scenario that comes to mind is that you actually typed the commands yourself, and forgot doing it. Yes. I certainly do not claim to always remember which commands I typed an hour earlier, so if those lines had been something that could remotely make sense to me, then I might well think I had done it myself. But those 4 lines? If I had somehow typed such a mess, I would remember it. Maybe you have dissociative identity disorder or something, who knows. Who knows? But if so, this is the first time it has shown symptoms. The last scenario... is that one or more of the statements you've given us are false. Well - I happen to know that they're not. Sometimes I almost think I must have dreamt it, but then I look at the 4 lines that I cut from the history file and saved. Thanks for your help - you've made it clear that the problem originated from the Windows machine. Though that doesn't quite rule out that damage could have been done to the Debian system at the same time, I think that in combination with the apparent clumsiness of those commands, I can almost trust that the Debian system is ok. The question then remains: what to do with the Windows system before I dare run a root ssh session from that machine again? Perhaps restore a backup, but from when? Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Am I infected with a rootkit?
Le 16 avril 2023 Jesper Dybdal a écrit : > The question then remains: what to do with the Windows system before I dare > run a root ssh session from that machine again? Perhaps restore a backup, but > from when? As you don't know *how* you can't guess *when* and should reinstall from scratch. If all your files are on debian it's not so hard.
Re: Am I infected with a rootkit?
Hi, to make this mail on-topic: Jesper Dybdal, do you see the riddling lines in file ~/.bash_history of the superuser ? If so: Do you see other strange lines there ? (Do they give more clue ?) A bit less on-topic: Greg Wooledge wrote: > Bash doesn't read the contents of the history file into the in-memory > history unless you run "history -r". If you had some kind of ksh-like > setup where you combined "history -w" and "history -r" commands in your > PROMPT_COMMAND or other variables, then we might be able to reconcile > the statements we've been given. > > In the absence of that, there's just no way you could have commands in > your shell history that were not typed in that same shell session. My Debians always behaved that way. I remember that in Debian 8 i got several different readline histories in the first shell terminals which i started. With Debian 11 it's only one history per user. It seems to be a collection of the last commands of shell sessions when the recent shutdowns happened. For example i create a new xterm and get to see (from new to old): su - firefox-esr & top ps -ef | grep pulseaudio umgebung view /u/x su - firefox-esr & xset r rate 250 30 In man bash i read: When the -o history option to the set builtin is enabled, the shell provides access to the command history, [...] On startup, the history is initialized from the file named by the vari‐ able HISTFILE (default ~/.bash_history). [...] set [--abefhkmnptuvxBCEHPT] [-o option-name] [arg ...] [...] -o option-name The option-name can be one of the following: [...] history Enable command history, as described above under HISTORY. This option is on by default in inter‐ active shells. At the end of ~/.bash_history of my desktop user i see indeed above history in old-to-new sequence: xset r rate 250 30 firefox-esr & su - view /u/x umgebung ps -ef | grep pulseaudio top firefox-esr & su - I did not execute them in this sequence in the recent sessions when i tried to find out what made pulseaudio permenantly busy. They surely stem from different xterms. It is not clear whether one per shutdown was memorized or whether more then one stem from a single shutdown. I become superuser by "su -" and get to see shutdown -h now shutdown -r now systemctl --global disable pulseaudio.service pulseaudio.socket shutdown -r now shutdown -h now shutdown -r now systemctl --global enable pulseaudio.service pulseaudio.socket shutdown -h now Since i only had one superuser xterm, i can quite surely state that the systemctl commands were not the last ones which were performed in their respective shells before shutdown. Have a nice day :) Thomas
Accesar a disco sin necesidad de root
Tengo debian en una laptop sony vaio, debido a que la unidad de DVD de descompuso, opte por ponerle un disco duro con un adaptador en la unidad de DVD, todo muy bien, pero ¿como le puedo hacer para que cuando acceso a dicho disco no me pida el password root?
Re: Accesar a disco sin necesidad de root
El 16/4/23 a las 21:51, CAMP escribió: > Tengo debian en una laptop sony vaio, debido a que la unidad de DVD > de descompuso, opte por ponerle un disco duro con un adaptador en la > unidad de DVD, todo muy bien, pero ¿como le puedo hacer para que > cuando acceso a dicho disco no me pida el password root? > A ver si te sirve esto: establece a tu usuario como propietario del punto de montaje: #chown -R usuario:usuario /media/usuario/nombre_punto_montaje
Re: Am I infected with a rootkit?
On 16/04/2023 09:19, Jesper Dybdal wrote: And there in the bash history were 4 lines that I had not written :-( I am certain that nobody had been in my apartment while I was gone. And even if they had, nobody with a key to my apartment would dream of writing things like the 4 lines that I found in the history file. The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users There is no file named "md5users" or directory named "/x" or command named "sp" on the Debian machine. Which shell do you use, and how is it configured? Note that bash by default does not share history between sessions, so even if someone logged in as root (via other ssh session) and typed them, they would not appear in your ssh session. See https://mywiki.wooledge.org/BashFAQ/088, or wait for Greg to chime in with details and corrections. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Apt sources.list
On Sat, 15 Apr 2023 20:30:11 -0400
Jeffrey Walton wrote:
> On Sat, Apr 15, 2023 at 11:09 AM wrote:
> > On Sat, 15 Apr 2023 14:01:27 +0100
> > Alain D D Williams wrote:
> > > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > > While we are talking about this, is there any reason why all the
> > > http: should not be https: ?
> > >
> > > I have done this on my own machine without ill effect.
> >
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate"
> > means we'll downgrade your search ranking if you don't use https.)
> > There is otherwise no earthly reason to have an encrypted
> > connection to a web server unless there is some exchange of private
> > information between you and the server.
> >
> > Reading through all of Google's explanations, I've never seen a
> > satisfactory explanation for this change. With that in mind, I
> > believe the Debian gods did the right thing in leaving their web
> > connections "insecure". Though, in truth, the integrity of Debian
> > server contents wouldn't be changed in the slightest whether the
> > connection was encrypted or not.
>
> The change came after Snowden released his cache of documents and the
> world learned how pervasive snooping is by the US government. There's
> nothing special about the US government, and we know other governments
> were doing it, too.
>
OMG! The U.S. government spying on people??!! They only have at least
one government agency which does only that-- the NSA. And everyone's
known about this forever.
What's even funnier is Google pushing this change, since there's no
nosier company on Earth than those guys. Their treasure trove of user
data probably rivals the NSA's.
Paul
--
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster
Re: Am I infected with a rootkit?
On Sun, Apr 16, 2023 at 03:11:07PM +0200, Michel Verdier wrote: > I don't remember changing default for that and my bash shares between > sessions. (NOTE: this is NOT the OP!) (Deletes a whole reply.) OK, not-the-OP... your statement that bash "shares between sessions" is extremely ambiguous. Do you mean that if you open two simultaneous bash sessions, and type a command into Session A, that it immediately appears in the history of Session B? (Or, immediately after hitting Enter in Session B, maybe.) If this is the case, you have MOST DEFINITELY altered the bash history configuration, in an EXTREMELY significant way. Whether you remember it or not. What we need to know, however, is whether the OP has made a similar change.
Re: Am I infected with a rootkit?
On 2023-04-16 14:40, Eduardo M KALINOWSKI wrote: On 16/04/2023 09:19, Jesper Dybdal wrote: And there in the bash history were 4 lines that I had not written :-( I am certain that nobody had been in my apartment while I was gone. And even if they had, nobody with a key to my apartment would dream of writing things like the 4 lines that I found in the history file. The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users There is no file named "md5users" or directory named "/x" or command named "sp" on the Debian machine. Which shell do you use, and how is it configured? Note that bash by default does not share history between sessions, so even if someone logged in as root (via other ssh session) and typed them, they would not appear in your ssh session. I use bash. More details in a reply to Greg in a moment. See https://mywiki.wooledge.org/BashFAQ/088, or wait for Greg to chime in with details and corrections. -- Jesper Dybdal https://www.dybdal.dk
Re: Am I infected with a rootkit?
On Sun 16 Apr 2023 at 14:19:34 (+0200), Jesper Dybdal wrote: > And there in the bash history were 4 lines that I had not written :-( > > I am certain that nobody had been in my apartment while I was gone. > And even if they had, nobody with a key to my apartment would dream of > writing things like the 4 lines that I found in the history file. > > The 4 lines were: > > md5users > > sp md5users > > sp /x/md5users > > ps /x/md5users > There is no file named "md5users" or directory named "/x" or command > named "sp" on the Debian machine. Just FTR and clarity's sake, are the "> " characters (which my MUA has unhelpfully doubled by quoting) part of what was typed in the putty session, or did you type them into the post to make them stand out? The reason I ask is that most people have their PS2 set to "> ", suggesting that these might have been some sort of continuation— of what, we don't know. Cheers, David.
Re: Debian Bookworm RC 1 installer- a Bug?
On 4/9/23 08:57, David Wright wrote: On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote: Debian Bookworm RC 1 installer Damned nice, the improvements are appreciated. I ran rc1 in my usual manner, and the only difference I noticed was the one extra question about non-free firmware, to which I replied yes. (There may well be improvements under the hood, so to speak.) Oh, and the initrd is somewhat larger, as per usual. using the new debian-bookworm-DI-rc1-amd64-netinst.iso Legacy install, GPT partition I assume Legacy means BIOS booting. Same here, but only one disk. correct. different term, same thing. Not UEFI graphic install, manual partitioning Mate Desktop (others were deselected) Non-graphical here, a suitable partition existed, and only standard and SSH server software was installed. WiFi firmware: Untested as this machine is a 2006-vintage mini-tower lacking wifi. [ snipped narrative of later network-switching ] Boot Loader: all disk drives were detected, however the one with the bios_grub partition was highlighted I can't recall seeing anything other than the first item highlighted, ie "Enter device manually", at least with the non-graphical installer in expert mode. I selected the (sole) hard drive, item 2. The only remaining item was the USB stick containing the installer ISO. As expected nowadays, when the machine rebooted, the Grub menu had only two lines, both pointing to the newly installed system. (I hadn't made any attempt to counteract GRUB_DISABLE_OS_PROBER during my installation.) So Grub was correctly installed in the MBR, and the rest of Grub occupied d400 bytes of /dev/sda1 (the 3MB BIOS boot partition on the single disk). = second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso same machine and again Legacy install, GPT partition however I did NOT install from the live session: I chose to go directly to install rather than the Calamares installer then manual partitioning Boot Loader: all drives were detected, however the one with the bios_grub partition was NOT highlighted, but I did select it. GRUB was Not properly installed, my former grub menu was still active. How did you determine that it was the previous menu. Wouldn't it look just the same? I enable GRUB_DISABLE_OS_PROBER so that the various other operating systems are shown if the new GRUB is properly installed I get the "new" one item only GRUB display. then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER and update GRUB *** I tried a second time, same as above being super careful, same result. I then booted with my default system, ran grub-install /dev/sde && update-grub then "new" system was on my boot menu. then booted and it ran as expected. Which method did you use to boot the "default" system (which I assume is bullseye, in a different partition on one or other of the disks), in view of the rather sparse menu from grub.cfg on the new system? I boot with the "old" GRUB menu as explained above...it has Several operating systems listed, my old default OS is still at the top of the list. back to the WiFi dongle, again the obscure firmware was properly installed Is this a Bug or a user/hardware issue? Presumably we are now back to talking about Grub. If you still have access to the bookworm system, you can check whether it claimed to have completed installing Grub successfully. You should see lines like: grub-installer: info: Installing grub on '/dev/sda' grub-installer: info: grub-install does not support --no-floppy grub-installer: info: Running chroot /target grub-install --force "/dev/sda" grub-installer: Installing for i386-pc platform. grub-installer: Installation finished. No error reported. grub-installer: info: grub-install ran successfully in /var/log/installer/syslog. Thanks, I did not know where to look or what to look for. === Apr 5 12:59:44 grub-installer: info: Identified partition label for /dev/sdb12: gpt Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb' Apr 5 13:01:03 grub-installer: info: grub-install does not support --no-floppy Apr 5 13:01:03 grub-installer: info: Running chroot /target grub-install --force "/dev/sdb" 5 12:59:44 grub-installer: info: Identified partition label for /dev/sdb12: gpt Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-legacy which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-bin which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-signed which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64 which isn't installed
Re: Apt sources.list
Op 16-04-2023 om 13:12 schreef Andrew M.A. Cater: Release day when someone pushes the magic switch and the symlinks move :) [snip] "Testing" == "Previous contents of Unstable" (== Trixie / Debian 13) Are you kidding? No way! Unstable is never pushed into testing just like that. There are packages that will never move to testing at all! "Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which will == Debian 14 eventually as Forky) And this doesn't make sense either. Regards, Frank
Re: Apt sources.list
On Sun 16 Apr 2023 at 07:14:31 (+0200), Frank wrote: > Op 15-04-2023 om 22:15 schreef Andrew M.A. Cater: > > On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote: > > > On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote: > > > > > > > I would suggest that you remain on bookworm until bookworm is released > > > > as > > > > stable. At that point (and only then) change bookworm to trixie and > > > > carry > > > > on. As soon as bookworm is released, there will be massive churn. > > > > > > OK. But how is testing one day before the release of bookworm > > > significantly > > > different from trixie a day afterwards? > > > > "Testing" one day before bookworm release -> bookworm. > > > > On release day, bookworm -> "stable", "unstable" -> testing == trixie > > Trixie is copied, essentially as the kickstarter for new "unstable". > > "Unstable" == Forky. > > > > The pent up changes that have been waiting while the freeze has been on > > all come out at once, potentially. > > > > It might not be very much, but it could be a bunch of stuff, size, effects > > unknown. Bookworm has been frozen-ish since January ... > > Yet if the OP intends to stay with testing, switching now would be > fine. Or do you seriously believe moving from bookworm (old testing) > to trixie (new testing) would have a different effect to staying with > testing while it moves from bookworm to trixie? The flood of packages > after the freeze ends would be the same either way. Yes, there's a difference: the changeover date is of your choosing. (Or, in my case, it would be six changeover dates.) Cheers, David.
Re: Am I infected with a rootkit?
On 2023-04-16 16:33, David Wright wrote: On Sun 16 Apr 2023 at 14:19:34 (+0200), Jesper Dybdal wrote: The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users Just FTR and clarity's sake, are the "> " characters (which my MUA has unhelpfully doubled by quoting) part of what was typed in the putty session, or did you type them into the post to make them stand out? They were not part of what was typed, and I did add them to make the lines stand out. Sorry for the unclear text. Here is a correct and clear, I hope, version: The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users End of the 4 lines -- Jesper Dybdal https://www.dybdal.dk
Re: Am I infected with a rootkit?
On Sun, Apr 16, 2023 at 10:08 AM Jesper Dybdal wrote: > ... > In the long term, now that I'm retired, I hope to drop Windows > completely - but not quite today :-). ++ My family went Windows-free about 2014. Grandparents, parents and me are all using Linux. I cut them over to Linux because of the malware and adware they kept installing. You won't miss Windows. Jeff
Re: Am I infected with a rootkit?
On Sun, Apr 16, 2023 at 04:39:13PM +0200, Jesper Dybdal wrote: > > On 2023-04-16 16:33, David Wright wrote: > > On Sun 16 Apr 2023 at 14:19:34 (+0200), Jesper Dybdal wrote: > > > The 4 lines were: > > > > md5users > > > > sp md5users > > > > sp /x/md5users > > > > ps /x/md5users > > > > > Just FTR and clarity's sake, are the "> " characters (which my MUA has > > unhelpfully doubled by quoting) part of what was typed in the putty > > session, or did you type them into the post to make them stand out? > They were not part of what was typed, and I did add them to make the lines > stand out. Sorry for the unclear text. > > Here is a correct and clear, I hope, version: > > The 4 lines were: > md5users > sp md5users > sp /x/md5users > ps /x/md5users > End of the 4 lines Sometimes, some tools rely on a shell at the "other side" to do their job. Emacs's Tramp is known for leaving traces in the shell history, quite possibly abominations like VSCode do their thing in a similar way. That said, the above commands look more like a human not quite knowing what (s)he's doing. If that were an intruder, I'd not worry too much ;-) Cheers -- t signature.asc Description: PGP signature
Re: Am I infected with a rootkit?
Le 16 avril 2023 Greg Wooledge a écrit : > Do you mean that if you open two simultaneous bash sessions, and type > a command into Session A, that it immediately appears in the history > of Session B? (Or, immediately after hitting Enter in Session B, maybe.) Ok I understand. I was meaning bash shares sessions but after closing session in history file. Of course not in memory history.
Re: Am I infected with a rootkit?
On Sun, Apr 16, 2023 at 04:30:51PM +0200, Jesper Dybdal wrote: > On 2023-04-16 15:08, Greg Wooledge wrote: > > (Have you altered root's bash history configuration on that Debian system? > > If so, how?) > My .bashrc has: > > export HISTCONTROL=ignoreboth > > and that's all. And your description of the default behaviour matches what > I experience with bash. There is simply no scenario where all of these things can be simultaneously true. Bash doesn't read the contents of the history file into the in-memory history unless you run "history -r". If you had some kind of ksh-like setup where you combined "history -w" and "history -r" commands in your PROMPT_COMMAND or other variables, then we might be able to reconcile the statements we've been given. In the absence of that, there's just no way you could have commands in your shell history that were not typed in that same shell session. The most stupidly paranoid, off-the-wall, tin-foil-hat scenario that I can come up with, which holds all these statements true, is that someone hacked into the Debian system as root, attached gdb (or some similar program) to a running bash, and used this opportunity to modify your shell's history. Not to do anything. Just to fuck with you. To make it LOOK like someone hacked you... and that the hacker was a halfwit. The other scenario that comes to mind is that you actually typed the commands yourself, and forgot doing it. Maybe you have dissociative identity disorder or something, who knows. The last scenario... is that one or more of the statements you've given us are false.
Re: Am I infected with a rootkit?
Le 16 avril 2023 Jesper Dybdal a écrit : > I have scanned the Windows machine with two antivirus tools (Windows defender > and Malwarebytes). Can you use clamav on windows ? >> modules.dep >> modules.devname >> modules.symbols.bin >> modules.symbols >> modules.builtin.bin >> modules.alias.bin >> modules.builtin.alias.bin >> modules.softdep >> modules.alias >> modules.dep.bin These are generated during kernel install. And you can safely remove /lib/modules/5.10.0-21-amd64 if these are the only files left. > * Is it probable that somebody can remote control one or both machines? Do > those 4 lines ring a bell? What are they all about? Perhaps a bot trying to execute some commands. As they do not apply to debian you debian machine should not be compromised. > * I would really like to know how this happened. I consider myself to be a > careful person who does not get hit by viruses and other malware. I've had a > Windows virus once - because I trusted an install program from > sourceforge. Malware can be installed via web sites > * Is there a significant risk that the problem came with the Bullseye upgrade? no > * I really don't want to reinstall from scratch. Not only because I don't > know whether there is a problem on one or both machines, but also because I > have no idea where any infection came from - it could easily be from something > that I would also reinstall. I think you don't have to. For debian. For windows a full deinstall without reinstall is the best :)
Re: Am I infected with a rootkit?
On Sun, Apr 16, 2023 at 02:19:34PM +0200, Jesper Dybdal wrote: > The windows machine had an ssh connection to the Debian machine (using > PuTTY), logged in as root on the Debian machine. > I then went for a walk with the dog, leaving the ssh session running. > When I came back, I wanted to re-issue some command to the ssh session, so I > pressed up-arrow a few times. > > And there in the bash history were 4 lines that I had not written :-( I would initially ask "who else lives with you" > I am certain that nobody had been in my apartment while I was gone. And even > if they had, nobody with a key to my apartment would dream of writing things > like the 4 lines that I found in the history file. > > The 4 lines were: > > md5users > > sp md5users > > sp /x/md5users > > ps /x/md5users > There is no file named "md5users" or directory named "/x" or command named > "sp" on the Debian machine. This certainly sounds like someone walking up to your machine and typing the commands. Did you see the commands within the PuTTY session, or were they *only* in the shell history? > * Is it probable that somebody can remote control one or both machines? Do > those 4 lines ring a bell? What are they all about? If someone did this with remote access, it would have to be access to the Windows machine. Nothing that could be done to the Debian machine would affect the in-memory shell history of a running instance of bash. Even writing to the /root/.bash_history file wouldn't cause the PuTTY session's bash to read those lines into its in-memory history. At least, not without a heavily altered bash history configuration. (Have you altered root's bash history configuration on that Debian system? If so, how?) Those commands look like nonsense to me. However, the fact that they're evolving from line to line looks like someone was trying to "get it right", and failing to do so. Again, it looks like something that was typed by an (ignorant) human. However, I can't even guess what the intent was. I tried googling "ps /x/md5users" and even "md5users" and got no useful results. So, it doesn't look like a known malware worm. Also, one would think that a malware worm would simply issue the desired command the first time, and not have to fumble around trying to type it correctly.
Re: Am I infected with a rootkit?
Le 16 avril 2023 Eduardo M. KALINOWSKI a écrit : > Which shell do you use, and how is it configured? Note that bash by default > does not share history between sessions, so even if someone logged in as root > (via other ssh session) and typed them, they would not appear in your ssh > session. I don't remember changing default for that and my bash shares between sessions. But it is not important, someone can easily remove commands from history. But if it was the case why not remove these remaining commands ?
AW: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
Good afternoon I do use USB 2.0. The printer EPSON ET M 1120 Debian is Debian 11 LXDE. This is the message. If You can read this, you are using the wrong driver Regards Thank You Sophie Von: Brian Gesendet: Freitag, 14. April 2023 22:10 An: debian-user@lists.debian.org Betreff: Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver On Fri 14 Apr 2023 at 14:40:33 +, Schwibinger Michael wrote: > Good afternoon. > The new printer is not working. > EPSON is saying > You cant use EPSON with Linux. > > Is this true? You could consider: * Stating the Debain OS being used. * Giving the printer make and model. * Specifying the connection method. USB. Network. * Giving the exact error message and where it came from. -- Brian.
Re: Am I infected with a rootkit?
On 2023-04-16 14:59, Michel Verdier wrote: Le 16 avril 2023 Jesper Dybdal a écrit : I have scanned the Windows machine with two antivirus tools (Windows defender and Malwarebytes). Can you use clamav on windows ? I hadn't thought of that. I'll check. modules.dep modules.devname modules.symbols.bin modules.symbols modules.builtin.bin modules.alias.bin modules.builtin.alias.bin modules.softdep modules.alias modules.dep.bin These are generated during kernel install. And you can safely remove /lib/modules/5.10.0-21-amd64 if these are the only files left. They are the only files on my harddisk that are not part of the .deb file for the kernel. There are lots of other files, but they match. * Is it probable that somebody can remote control one or both machines? Do those 4 lines ring a bell? What are they all about? Perhaps a bot trying to execute some commands. As they do not apply to debian you debian machine should not be compromised. Unless the malware on the windows machine is smart enough to use my secret key and decrypt it with a password retrieved from a key logger ... Malware can be installed via web sites I tend to stay away from doubtful websites - but you are of course right. * Is there a significant risk that the problem came with the Bullseye upgrade? no * I really don't want to reinstall from scratch. Not only because I don't know whether there is a problem on one or both machines, but also because I have no idea where any infection came from - it could easily be from something that I would also reinstall. I think you don't have to. For debian. For windows a full deinstall without reinstall is the best :) In the long term, now that I'm retired, I hope to drop Windows completely - but not quite today :-). Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Debian Bookworm RC 1 installer- a Bug?
On 4/9/23 08:57, David Wright wrote: On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote: Debian Bookworm RC 1 installer Damned nice, the improvements are appreciated. I ran rc1 in my usual manner, and the only difference I noticed was the one extra question about non-free firmware, to which I replied yes. (There may well be improvements under the hood, so to speak.) Oh, and the initrd is somewhat larger, as per usual. using the new debian-bookworm-DI-rc1-amd64-netinst.iso Legacy install, GPT partition I assume Legacy means BIOS booting. Same here, but only one disk. correct. different term, same thing. Not UEFI graphic install, manual partitioning Mate Desktop (others were deselected) Non-graphical here, a suitable partition existed, and only standard and SSH server software was installed. WiFi firmware: Untested as this machine is a 2006-vintage mini-tower lacking wifi. [ snipped narrative of later network-switching ] Boot Loader: all disk drives were detected, however the one with the bios_grub partition was highlighted I can't recall seeing anything other than the first item highlighted, ie "Enter device manually", at least with the non-graphical installer in expert mode. I selected the (sole) hard drive, item 2. The only remaining item was the USB stick containing the installer ISO. As expected nowadays, when the machine rebooted, the Grub menu had only two lines, both pointing to the newly installed system. (I hadn't made any attempt to counteract GRUB_DISABLE_OS_PROBER during my installation.) So Grub was correctly installed in the MBR, and the rest of Grub occupied d400 bytes of /dev/sda1 (the 3MB BIOS boot partition on the single disk). = second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso same machine and again Legacy install, GPT partition however I did NOT install from the live session: I chose to go directly to install rather than the Calamares installer then manual partitioning Boot Loader: all drives were detected, however the one with the bios_grub partition was NOT highlighted, but I did select it. GRUB was Not properly installed, my former grub menu was still active. How did you determine that it was the previous menu. Wouldn't it look just the same? I enable GRUB_DISABLE_OS_PROBER so that the various other operating systems are shown if the new GRUB is properly installed I get the "new" one item only GRUB display. then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER and update GRUB *** I tried a second time, same as above being super careful, same result. I then booted with my default system, ran grub-install /dev/sde && update-grub then "new" system was on my boot menu. then booted and it ran as expected. Which method did you use to boot the "default" system (which I assume is bullseye, in a different partition on one or other of the disks), in view of the rather sparse menu from grub.cfg on the new system? I boot with the "old" GRUB menu as explained above...it has Several operating systems listed, my old default OS is still at the top of the list. back to the WiFi dongle, again the obscure firmware was properly installed Is this a Bug or a user/hardware issue? Presumably we are now back to talking about Grub. If you still have access to the bookworm system, you can check whether it claimed to have completed installing Grub successfully. You should see lines like: grub-installer: info: Installing grub on '/dev/sda' grub-installer: info: grub-install does not support --no-floppy grub-installer: info: Running chroot /target grub-install --force "/dev/sda" grub-installer: Installing for i386-pc platform. grub-installer: Installation finished. No error reported. grub-installer: info: grub-install ran successfully in /var/log/installer/syslog. Thanks, I did not know where to look or what to look for. === Apr 5 12:59:44 grub-installer: info: Identified partition label for /dev/sdb12: gpt Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb' Apr 5 13:01:03 grub-installer: info: grub-install does not support --no-floppy Apr 5 13:01:03 grub-installer: info: Running chroot /target grub-install --force "/dev/sdb" 5 12:59:44 grub-installer: info: Identified partition label for /dev/sdb12: gpt Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-legacy which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-bin which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-signed which isn't installed Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64 which isn't installed
Re: Am I infected with a rootkit?
On 2023-04-16 15:08, Greg Wooledge wrote: On Sun, Apr 16, 2023 at 02:19:34PM +0200, Jesper Dybdal wrote: And there in the bash history were 4 lines that I had not written :-( I would initially ask "who else lives with you" So would I - if I didn't know that the few people with physical access to my apartment, including my wife, haven't the faintest idea that there is a thing called "md5". I am certain that nobody had been in my apartment while I was gone. And even if they had, nobody with a key to my apartment would dream of writing things like the 4 lines that I found in the history file. The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users There is no file named "md5users" or directory named "/x" or command named "sp" on the Debian machine. This certainly sounds like someone walking up to your machine and typing the commands. Did you see the commands within the PuTTY session, or were they *only* in the shell history? I saw them only in the shell history. And I am pretty sure that I cannot have overlooked them if they were visible on the screen. * Is it probable that somebody can remote control one or both machines? Do those 4 lines ring a bell? What are they all about? If someone did this with remote access, it would have to be access to the Windows machine. Nothing that could be done to the Debian machine would affect the in-memory shell history of a running instance of bash. Even writing to the /root/.bash_history file wouldn't cause the PuTTY session's bash to read those lines into its in-memory history. At least, not without a heavily altered bash history configuration. (Have you altered root's bash history configuration on that Debian system? If so, how?) My .bashrc has: export HISTCONTROL=ignoreboth and that's all. And your description of the default behaviour matches what I experience with bash. Those commands look like nonsense to me. However, the fact that they're evolving from line to line looks like someone was trying to "get it right", and failing to do so. Again, it looks like something that was typed by an (ignorant) human. However, I can't even guess what the intent was. I tried googling "ps /x/md5users" and even "md5users" and got no useful results. So, it doesn't look like a known malware worm. Also, one would think that a malware worm would simply issue the desired command the first time, and not have to fumble around trying to type it correctly. Exactly. I don't understand it. Of the two machines, the Debian has the most important data: mailboxes with mail archives for about 25 persons. And just about all my data files (docs, source code, photos, ...) live there. If the WIndows machine has a virus that can sniff my typed key decryption pass phrase and use it, then the Debian's root account may have been compromised. And I really need to be able to run ssh to root to administer that machine (which normally has neither keyboard nor monitor). And the Windows machine has access to the data files on the Debian machine. So even if root is not compromised, the Windows machine can make problems by destroying/modifying data files. I now back up the data files more frequently than I used to. Thanks a lot to those who have answered. And please keep the good ideas coming... Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Commands service and systemctl.
On Sun 16 Apr 2023 at 10:47:21 (+0200), Michel Verdier wrote: > Le 16 avril 2023 David Wright a écrit : > > > systemd-sysv-install. AFAICT from ls, the only /e/i.d/ script I use > > is anacron, and I don't think systemd will ever write a unit for that. > > anacron is launched from systemd > /lib/systemd/system/anacron.service > /lib/systemd/system/anacron.timer Yes, my fault for not looking more carefully. I may well have poked around anacron in the meantime. So I checked on another machine and realised I'd overlooked the two that are used: exim4 and hddtemp (run automagically, not by me). I hadn't heard of hddtemp, but inxi pulls it in. Cheers, David.
Re: Am I infected with a rootkit?
Le 16 avril 2023 Jesper Dybdal a écrit : >> Perhaps a bot trying to execute some commands. As they do not apply to >> debian you debian machine should not be compromised. > Unless the malware on the windows machine is smart enough to use my secret key > and decrypt it with a password retrieved from a key logger ... But you go out leaving ssh session on ? And if no one could physically go to your keyboard I can't imagine another possibility. Even if as Greg says it looks like a human typing.
Re: Commands service and systemctl.
Le 16 avril 2023 David Wright a écrit : > systemd-sysv-install. AFAICT from ls, the only /e/i.d/ script I use > is anacron, and I don't think systemd will ever write a unit for that. anacron is launched from systemd /lib/systemd/system/anacron.service /lib/systemd/system/anacron.timer
Re: On strange threads [was: EPSON ET M 1120 new printer...]
On Sun, 16 Apr 2023 to...@tuxteam.de wrote: On Sat, Apr 15, 2023 at 08:44:20PM +0100, Brian wrote: [...] Tongue. Boots. Lick. This was banter. And you trimmed away the truly funny bit. You must be a pretty unhappy person. Pity you. This was pain. Pity us all. Humor is the favorite child of pain and misery. None of us are as happy as we'd like, and even humor takes some practice. On both ends. -- Hackers are free people. They are like artists. If they are in a good mood, they get up in the morning and begin painting their pictures. -- Vladimir Putin
Re: "Bug" in Debian Installer?
d-i makes no distinction between nvme and usb. Maybe another problem is the chosen installation destination might not be passed to the code that does the grub install. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sat, 15 Apr 2023, David Wright wrote: > On Sat 15 Apr 2023 at 15:51:46 (-0700), David Christensen wrote: > > On 4/15/23 02:36, Andrew Wood wrote: > > > Ive just used the Debian 11 installer ISO running from a USB stick > > > to do an install (AMD64/UEFI) on another USB stick to use as a > > > 'portable PC'. > > > > > > When it got to the Grub install stage I was expecting it to ask me > > > which disk I wanted Grub installed on as it has in the past but > > > instead it did not. > > > > > > When I came to reboot the PC I found not only had it put Grub on > > > the USB it had also put on the PCs NVMe SSD overwriting the > > > Windows bootloader on there. > > > > > > Surely it should have prompted which disk I wanted it on? I > > > thought it was only Windows that trashed other peoples bootloaders > > > ;) > > > > I recently had a similarly confusing experience with a Dell Precision > > 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured > > as follows: > > > > "System Configuration" -> "SATA Operation" -> "AHCI" > > > > > > I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst > > CD, booted the CD, and installed Debian: > > > > "Debian GNU/Linux UEFI Installer menu" -> "Install" > > ... > > "Partitioning method" -> "Manual" -> <2.5" SATA SSD> > > ... > > What was the partitioning layout you used on this disk at that time? > > > In the past, d-i "Install" would prompt me regarding GRUB. This time, > > it did not. > > > > > > When d-i was complete, the computer could boot either Windows or > > Debian, with suitable BIOS Setup > > > > "General" -> "Boot Sequence" > > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and > > configured BIOS Setup: > > > > "Boot" -> "UEFI Boot" -> "Enable" > > > > The SSD would not boot. > > > > > > I zeroed the SSD and installed Debian again. The SSD now works in > > both computers. > > > > > > I later discovered that the first install created a directory and put > > files into the Dell's ESP (!). I did not select this, nor do I desire > > it. This is a defect with d-i: > > > > 2023-04-15 15:10:34 root@taz ~ > > # ls -ld /mnt/nvme0n1p1/EFI/debian > > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian > > > > 2023-04-15 15:10:36 root@taz ~ > > # ls -l /mnt/nvme0n1p1/EFI/debian > > total 5892 > > -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV > > -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi > > -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg > > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi > > -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi > > -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi > > > > > > So, I agree that d-i "Install" choice has bug(s) when installing > > Debian into a computer with multiple storage devices. > > Cheers, > David. > >
Re: "Bug" in Debian Installer?
On 16/04/2023 05:51, David Christensen wrote: I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, booted the CD, and installed Debian: "Debian GNU/Linux UEFI Installer menu" -> "Install" ... "Partitioning method" -> "Manual" -> <2.5" SATA SSD> Perhaps at this point installer detected EFI system partition that was used to install grub: In the past, d-i "Install" would prompt me regarding GRUB. This time, it did not. ... When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, by efibootmgr, etc. Some firmware allows to choose an .efi file (EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim script creates EFI boot entry. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? EFI system partition is designed to contain boot loaders from multiple vendors. A conflict may happen due to EFI/BOOT/bootx64.efi, but it is for removable media and for buggy firmware (as a workaround). # ls -l /mnt/nvme0n1p1/EFI/debian total 5892 -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi Fallback should create boot entries listed in BOOTX64.CSV if some problem with boot is detected. I am unsure concerning changing boot order. However this file is invoked by shimx64.efi or grubx64.efi (loaded by shim) and I do not expect that shim is booted with no user action when a disk is installed into another computer. -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi So, I agree that d-i "Install" choice has bug(s) when installing Debian into a computer with multiple storage devices. I do not think multiple storage devices is an issue. I suspect that you are not happy that by default Debian installer picked existing EFI system partition. Were you trying to prepare a disk for another computer? Did you created ESP on that disk and specified mount point? Anyway likely it is a reason to enable low priority configuration questions.
Re: Apt sources.list
On 15/04/2023 19:54, davidson wrote: On Sat, 15 Apr 2023 to...@tuxteam.de wrote: On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote: It's nice not to be telling everyone who can sniff a plaintext connection which packages you are installing, Without doubt, this is an advantage of a TLS connection. If you do care about that, here would be one reason. In case you wish to obscure what software you *install*, but need not conceal the software you *download*: Step one: Make a list of the packages you want, and then augment it with as many plausible alternatives and red herrings as you like. Step two: $ apt-get -d install This downloads the packages only, so you can download packages you will *not* install, along with ones you will. Then install the proper subset you want installed, without the '-d' option. This consumes more resources than using TLS, and increased resource usage was one the arguments made against the need for TLS everywhere. -- BOFH excuse #377: Someone hooked the twisted pair wires into the answering machine. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: "Bug" in Debian Installer? S.W.A.G.
On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote: > On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote: > > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote: > > > [1] I needed a websearch on S.W.A.G. Did find > > > - Sharing Warmth Around the Globe > > > - > > > - > > > > > } Stopped searching upon > > > Something We All Get (tired of hearing) > > > > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess". Yeah, I think it is. > In my experience (and usage) it was "Scientific Wild Ass Guess". Acknowledge on scientific usage and scientific experience. First appearance of S.W.A.G. in this thread was in a top post. That made it a Silly Wild Ass Guess. Follow up message ( debconf/priority was not changed ) made it a Stupid Wild Ass Guess. Back to "Sharing Warmth Around the Globe": Replying below previous text helps understanding each other. Regards Geert Stappers -- Silence is hard to parse
Re: Commands service and systemctl.
On Sun, 16 Apr 2023 10:47:21 +0200
Michel Verdier wrote:
Hello Michel,
>anacron is launched from systemd
>/lib/systemd/system/anacron.service
>/lib/systemd/system/anacron.timer
Unless;
anacron (2.3-36) unstable; urgency=medium
If you run Debian testing/unstable and ever installed anacron 2.3-33 on
a systemd based system, then anacron will no longer be enabled and the
daily/weekly/monthly cron jobs will not be run until it is.
I'm sure most people affected by the issue (I was one of them) have now
corrected it. However, just in case, here's how to find out if you are
affected and the solution;
To see if a system is affected you can use these commands:
zgrep -i anacron.*2.3-33 /var/log/apt/history.log*
systemctl status anacron.service anacron.timer
To re-enable anacron you can use these commands:
sudo systemctl enable anacron.service anacron.timer
sudo systemctl start anacron.service anacron.timer
Credit to: Lance Lin Wed, 11 Jan 2023 21:15:22 +0700
(who included the above as part of an anacron update)
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Don't worry about tomorrow
Live For Today - Lords of the New Church
pgpiX1GpGHQqt.pgp
Description: OpenPGP digital signature
Am I infected with a rootkit?
I have a Debian pc functioning as router, firewall, file server, name server, webserver, ... It has very recently been upgraded to Bullseye. On the internal network I have a Windows 10 pc. A few days after the Debian upgrade, I had the following strange experience: The windows machine had an ssh connection to the Debian machine (using PuTTY), logged in as root on the Debian machine. I then went for a walk with the dog, leaving the ssh session running. When I came back, I wanted to re-issue some command to the ssh session, so I pressed up-arrow a few times. And there in the bash history were 4 lines that I had not written :-( I am certain that nobody had been in my apartment while I was gone. And even if they had, nobody with a key to my apartment would dream of writing things like the 4 lines that I found in the history file. The 4 lines were: md5users sp md5users sp /x/md5users ps /x/md5users There is no file named "md5users" or directory named "/x" or command named "sp" on the Debian machine. I have scanned the Windows machine with two antivirus tools (Windows defender and Malwarebytes). I have run chkrootkit, rkhunter, and debsums on the Debian machine. That did not find anything. All of the above except chkrootkit were done on the running system, so they might be influenced by a rootkit. I have done a more manual check of the files belonging to the kernel package, in the hope that a rootkit will not find it easy to fool that. There were 10 files in /lib/modules/5.10.0-21-amd64 that do not belong in the current kernel package - I guess that they are leftovers from an earlier version. These 10 files do not seem dangerous to me; they are: modules.dep modules.devname modules.symbols.bin modules.symbols modules.builtin.bin modules.alias.bin modules.builtin.alias.bin modules.softdep modules.alias modules.dep.bin Since this happened a couple of weeks ago, there has been no visible sign of anything wrong. I am taking care to mount backup disks only when running from a booted rescue disk. And I have for the time being removed the ability of the Windows machine to log in as root on the Debian machine. I've tried logging all DNS requests from the Windows machine during a power-on sequence. I saw no clearly suspicious names among the surprisingly many names being looked up. What can I do? * Is it probable that somebody can remote control one or both machines? Do those 4 lines ring a bell? What are they all about? * I would really like to know how this happened. I consider myself to be a careful person who does not get hit by viruses and other malware. I've had a Windows virus once - because I trusted an install program from sourceforge. * Is there a significant risk that the problem came with the Bullseye upgrade? * I really don't want to reinstall from scratch. Not only because I don't know whether there is a problem on one or both machines, but also because I have no idea where any infection came from - it could easily be from something that I would also reinstall. * I could restore a backup of one or both of the machines. But I have no idea how long back I would have to go. I would not like to go back to before the Bullseye upgrade, since I would then have to repeat that upgrade - and it was not quite trouble-free. * Is there a place where I could download the correct checksums of all installed files? Some way to be able to run debsums from a booted rescue disk, but checking the system on the hard disk against freshly fetched checksums? Any suggestions will be much appreciated. Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Apt sources.list
On Sun, Apr 16, 2023 at 4:52 PM Jeffrey Walton wrote: > > On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall wrote: > > > > On Sat, 15 Apr 2023, Greg Wooledge wrote: > > > > > Now, personally I don't feel this is a threat model that I need to > > > worry about. I just use plain old http sources at home, and if "They" > > > learn that I've downloaded rxvt-unicode and mutt, well, good for Them. > > > > The thread model I'm most concerned about is local stuff *exporting* > > data elsewhere. > > > > I do understand that there are people in some parts of the world that > > want to do things that they ought to be allowed to do but their > > repressive governments are preventing. HTTPS is a useful tool to make > > that repression harder - but doesn't actually make people safe - if > > doing something is illegal then it's still illegal even if it's harder > > for the authorities to detect it. > > > > But it's pretty much impossible nowadays to have a "safe" environment at > > home. Phones, TVs, almost everything, now tries to establish outgoing > > connections. > > > > ESNI, and DNSoHTTPS are on the way to making it almost impossible to > > keep tabs on this and restrict what is allowed to egress. > > > > The only redeeming point is that corporates *need* to do egress > > filtering - so at the moment the browsers cannot totally block it - and > > if they did try, there would be the financing to provide a browser that > > corporates could use that, at least, allowed SNI sniffing and regular > > DNS. > > Corporations don't need browser cooperation for Data Loss Prevention > (DLP) (but they already have it). Corporations just run an > interception proxy, like NetSkope. The NetScope Root CA is loaded into > every browser trust store. The application will terminate all traffic, > inspect it, and forward the request if it looks innocuous. To be clear... The NetSkope Root CA is loaded into browsers for computers owned by the corporation. I.e., part of the corporation's standard image. The NetSkope Root CA is _not_part of Mozilla, Chrome, Edge, Opera, etc., trust store. (After re-reading, it sounded like I was stating the latter). Jeff > The W3C and Browsers have already decided "interception is a valid use > case." That boat has already sailed. The browsers claim authority > comes from Priority of Constituencies under the Web Design Principles. > I argued against it until I was blue in the face. Also see > https://www.w3.org/TR/html-design-principles/#priority-of-constituencies. > > The conspiracy runs even deeper. App developers cannot ask a WebSocket > for the certificate or public key used to setup the secure channel. If > an app/JavaScript could get the info, then it could determine the > connection was intercepted. The browsers don't want app authors > knowing that because "interception is a valid use case." So the W3C > and Browsers have baked interception into the model, and then > neutered/crippled the technologies to ensure the agenda is moved > forward. > > Jeff
Re: "Bug" in Debian Installer?
On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, booted the CD, and installed Debian: "Debian GNU/Linux UEFI Installer menu" -> "Install" ... "Partitioning method" -> "Manual" -> <2.5" SATA SSD> Perhaps at this point installer detected EFI system partition that was used to install grub: In the past, d-i "Install" would prompt me regarding GRUB. This time, it did not. ... When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, by efibootmgr, etc. Some firmware allows to choose an .efi file (EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim script creates EFI boot entry. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot recordYes Device /dev/sda That was the proper way to do it. David
Re: Am I infected with a rootkit?
On 2023-04-16 19:35, Thomas Schmitt wrote: Hi, to make this mail on-topic: Jesper Dybdal, do you see the riddling lines in file ~/.bash_history of the superuser ? Yes. If so: Do you see other strange lines there ? (Do they give more clue ?) No. I stupidly did not save the rest of .bash_history - only the 4 lines. I did, however, take a quick look in the file, and saw nothing conspicuous other than those 4 lines. Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Am I infected with a rootkit?
On 4/16/23 05:19, Jesper Dybdal wrote: I have a Debian pc functioning as router, firewall, file server, name server, webserver, ... It has very recently been upgraded to Bullseye. On the internal network I have a Windows 10 pc. And there in the bash history were 4 lines that I had not written :-( md5users sp md5users sp /x/md5users ps /x/md5users On 4/16/23 07:30, Jesper Dybdal wrote: > ... I really need to be able to run ssh [on Windows to] administer > [the Debian] machine (which normally has neither keyboard nor > monitor). What about installing a KVM switch and administering the Debian computer from the console? If the two computers are separated, you could use a KVM extender and put the KVM switch near the Windows computer. Or, you could get networked KVM equipment. That said, using one computer as router, firewall, file server, name server, web server, and more represents "all of your eggs in one basket". I suggest using dedicated hardware for networking, network segmentation (e.g. DMZ), and kernel or hypervisor compartmentalization of services. Qubes looks very appealing: https://www.qubes-os.org/ David
Re: Apt sources.list
On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall wrote: > > On Sat, 15 Apr 2023, Greg Wooledge wrote: > > > Now, personally I don't feel this is a threat model that I need to > > worry about. I just use plain old http sources at home, and if "They" > > learn that I've downloaded rxvt-unicode and mutt, well, good for Them. > > The thread model I'm most concerned about is local stuff *exporting* > data elsewhere. > > I do understand that there are people in some parts of the world that > want to do things that they ought to be allowed to do but their > repressive governments are preventing. HTTPS is a useful tool to make > that repression harder - but doesn't actually make people safe - if > doing something is illegal then it's still illegal even if it's harder > for the authorities to detect it. > > But it's pretty much impossible nowadays to have a "safe" environment at > home. Phones, TVs, almost everything, now tries to establish outgoing > connections. > > ESNI, and DNSoHTTPS are on the way to making it almost impossible to > keep tabs on this and restrict what is allowed to egress. > > The only redeeming point is that corporates *need* to do egress > filtering - so at the moment the browsers cannot totally block it - and > if they did try, there would be the financing to provide a browser that > corporates could use that, at least, allowed SNI sniffing and regular > DNS. Corporations don't need browser cooperation for Data Loss Prevention (DLP) (but they already have it). Corporations just run an interception proxy, like NetSkope. The NetScope Root CA is loaded into every browser trust store. The application will terminate all traffic, inspect it, and forward the request if it looks innocuous. The W3C and Browsers have already decided "interception is a valid use case." That boat has already sailed. The browsers claim authority comes from Priority of Constituencies under the Web Design Principles. I argued against it until I was blue in the face. Also see https://www.w3.org/TR/html-design-principles/#priority-of-constituencies. The conspiracy runs even deeper. App developers cannot ask a WebSocket for the certificate or public key used to setup the secure channel. If an app/JavaScript could get the info, then it could determine the connection was intercepted. The browsers don't want app authors knowing that because "interception is a valid use case." So the W3C and Browsers have baked interception into the model, and then neutered/crippled the technologies to ensure the agenda is moved forward. Jeff
Re: Accesar a disco sin necesidad de root
El dom, 16 abr 2023 a las 15:52, CAMP () escribió: > Tengo debian en una laptop sony vaio, debido a que la unidad de DVD > de descompuso, opte por ponerle un disco duro con un adaptador en la > unidad de DVD, todo muy bien, pero ¿como le puedo hacer para que > cuando acceso a dicho disco no me pida el password root? > > Lo tengo en el *fstab* lo que no recuerdo es si tuve que darle permisos o hice algo más no recuerdo, pero puedes probar, UUID=*uuid-del-disco* /media/*tuusuario*ext4 user,errors=remount-ro,auto,exec,rw 0 0 cambias el uuid del disco y tu usuario y debería de aparecer montada automáticamente (tengo kde). -- L.J.Marín Usando: Debian Testing
Re: Email clients and IMAP search support
Andre Rodier writes: > On Sun, 2023-04-16 at 17:01 +0100, Andre Rodier wrote: >> Hi, >> >> Is there any desktop email client on Debian, that supports server >> side IMAP search, please ? >> >> I have an email server that support indexing attachment contents, >> and when I run a query from the command line using >> doveadm search or even TELNET, it is returning the correct email indexes. >> >> However, when I try the same search with a desktop client, nothing >> is returned. I tried Thunderbird, Balsa, Claws and >> Geary. None of them is satisfactory. >> >> Thanks for your help. >> >> Thanks, >> André >> > > OK, I am answering to myself, Gnome Evolution works, it is sending the > search query to the server. > > Even in some advanced RTL languages like Arabic. > > Great! Hellow Andre, Searching for IMAP is good with Gmail web interface, i think. If you have web browser such as mozilla firefox, chromium browser. Try to gmail, just with web browser. It is not bad in my experience. And also i am Debian user (Debian 11 Bullseye under Chromebook). As you know, Gmail is good with UTF-8 support / Searching / Labeling. See here: https://gitlab.com/soyeomul/Gnus/-/commit/314e84446d1002726aec0ccf81a756d54568bfbb In real world, i use both Gmail and Emacs Gnus for email. Sincerely, Byung-Hee -- ^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Apt sources.list
On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote: [...] > > Corporations don't need browser cooperation for Data Loss Prevention > > (DLP) (but they already have it). Corporations just run an > > interception proxy, like NetSkope. The NetScope Root CA is loaded into > > every browser trust store. The application will terminate all traffic, > > inspect it, and forward the request if it looks innocuous. > > To be clear... The NetSkope Root CA is loaded into browsers for > computers owned by the corporation. I.e., part of the corporation's > standard image. Heh. You made me search for it in my browser's root CA store ;-) Anyway, your points are all valid. I do recommend to have a look at the browser's default root CA store before saying "you're safe with TLS". This is just marketing. TLS is but one tool. Don't get me wrong: I think widespread use of TLS is a Good Thing. But going about it as if it was Redemption is paternalistic to the point of being counterproductive. Security is a process, not a product, as Schneier says. Cheers -- t signature.asc Description: PGP signature
Re: "Bug" in Debian Installer?
On 17/04/2023 09:18, David Christensen wrote: On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, I have realized that you may be confused by difference of MBR vs. UEFI behavior. For MBR it is enough to choose a disk to boot in BIOS, for UEFI it is necessary to add boot entries through EFI variables in firmware. Boot entry consists of disk, partition (EFI System partition) and path of an .efi file on this partition. If so, you may suggest an additional subsection to https://wiki.debian.org/UEFI#Troubleshooting_common_issues I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. I agree if a computer is booted into MBR/BIOS/Compatibility mode or if expert install is selected. For regular UEFI install it is a trade-off since multiple OS loaders may coexist without conflicts. User should be asked if new OS should be booted by default (BootOrder), adding files to ESP is quite safe. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot record Yes Device /dev/sda That was the proper way to do it. Am I right that it was not UEFI install? Certainly overwriting of MBR must be acknowledged by the user.
