Re: Installing a python package with pipx
If it where an issue with pip or pipx, yes. But as you pointed out yourself, it's also happening on OpenSuse, so the issue can't be pip or pipx, but rather either what you are trying to install or your understanding of it. Am So., 2. Juni 2024 um 14:20 Uhr schrieb Richmond : > I am not complaining, I am trying to find out how to get it working. And > as pip (and pipx) are debian packages I think it is reasonable to > discuss it on the debian user list. > >
Re: Installing a python package with pipx
python3 -m venv venv source venv/bin/activate pip install musicpy That's how its done. Also, complaining here about something that doesn't even work on other distros and thus can't be a Debian problem doesn't make that much sense. Am So., 2. Juni 2024 um 13:50 Uhr schrieb Richmond : > OK Back on Debian, I removed the one package installed with pipx, which > was musicpy, then tried to install it with pip, but got this message > which actually tells me to use pipx. (There is no package python-musicpy). > > pip install musicpy > error: externally-managed-environment > > × This environment is externally managed > ╰─> To install Python packages system-wide, try apt install > python3-xyz, where xyz is the package you are trying to > install. > > If you wish to install a non-Debian-packaged Python package, > create a virtual environment using python3 -m venv path/to/venv. > Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make > sure you have python3-full installed. > > If you wish to install a non-Debian packaged Python application, > it may be easiest to use pipx install xyz, which will manage a > virtual environment for you. Make sure you have pipx installed. > > See /usr/share/doc/python3.11/README.venv for more information. > >
Re: Installing a python package with pipx
On Sat, Jun 1, 2024, 23:50 Richmond wrote: > Richard writes: > > > A packages documentation is always your best friend: https://pypi.org > > /project/idle/ > > > > Yes it makes it look easy there, but: > > import idle > Traceback (most recent call last): > File "", line 1, in > File ".local/pipx/shared/lib/python3.11/site-packages/idle.py", line 4, > in > from layout import * > ModuleNotFoundError: No module named 'layout' > That's what I'm talking about. You wildly mix commands together that don't go together. And whatever is off with your paths. Things of pipx installed packages should be in .local/bin and .local/shared/pipx. At least on Debian that's the default. No idea what you did. > > > Also, python script isn't a necessarily a standalone executable. And > > also, you shouldn't just wildly mix pipx commands with pip commands > > if you don't know what you are doing. Either create a venv with > > python3 -m venv or use pipx, not both. Once created, stick to these > > separate paths. And read the documentation of pipx while you're at > > it. Sure, venvs are easy to handle, as you can just delete them and > > start from scratch, but mixing commands without knowing what one is > > doing is just a recipe for desaster. > > > > I don't know what I am doing for sure. But I did not wildly mix, I just > kept trying things until I found something which worked. Most things > didn't, and still don't. > You are, your last comment is more than proof enough. You should just remove everything you installed with pipx, create a separate venv - without using pipx! - and solely work inside it. And don't touch pipx for anything that's not meant as a standalone CLI program, like yt-dlp, speedtest and the sorts. Maybe that way you can't do that much wrong. At this point this is hardly a Debian related topic. You should first learn more about Python venvs and their package managers. >
Re: Installing a python package with pipx
A packages documentation is always your best friend: https://pypi.org/project/idle/ Also, python script isn't a necessarily a standalone executable. And also, you shouldn't just wildly mix pipx commands with pip commands if you don't know what you are doing. Either create a venv with python3 -m venv or use pipx, not both. Once created, stick to these separate paths. And read the documentation of pipx while you're at it. Sure, venvs are easy to handle, as you can just delete them and start from scratch, but mixing commands without knowing what one is doing is just a recipe for desaster. On Sat, Jun 1, 2024, 23:00 Richmond wrote: > Richard writes: > > > Pretty much just what pipx does. > > > > Well I don't know how. > > Now I need to run idle in my new environment. I have installed it > > .local/pipx/shared/bin/pip install idle > > and it is here: > > .local/pipx/shared/lib/python3.11/site-packages/idle.py > > but I don't know how to run it. I just get errors. > >
Re: Installing a python package with pipx
Pretty much just what pipx does. On Sat, Jun 1, 2024, 22:00 Richmond wrote: > > I got it working by doing: > > python3 -m venv .local/pipx/venvs/musicpy/ > > .local/pipx/venvs/musicpy/bin/python3.11 > > Then I was able to import musicpy from the python shell. > > How bewildering! > > Thanks. > >
Re: Installing a python package with pipx
That's the point of venv's. pipx runpip should do the trick. Or the classic way: source path/to/venv/bin/activate. That way you activate the position virtual environment (venv) created in that directory with all packages installed in that venv. Richard On Sat, Jun 1, 2024, 19:10 Richmond wrote: > I guess I have to tell python where to look? > >
Re: Installing a python package with pipx
Looking at the package, no wonder it fails. musicpy doesn't contain anything that can be executed. So pipx run can't work for obvious reasons. You'll have to install it with pipx install and use it in a python script. https://pypi.org/project/musicpy/ Richard On Sat, Jun 1, 2024, 18:40 Richmond wrote: > Richard writes: > > > If you haven't closed the terminal window/logged out, you need to run > > source .bashrc. Running pipx ensurepath should have said something > > like that. > > Yes, I did this: > > > > (logged out and in to get updated PATH) > >
Re: Installing a python package with pipx
If you haven't closed the terminal window/logged out, you need to run source .bashrc. Running pipx ensurepath should have said something like that. Richard On Sat, Jun 1, 2024, 18:10 Richmond wrote: > I have been trying to install this: > > https://pypi.org/project/musicpy/#description > > with not much success. > > I have done these: > > sudo aptitude install pip > sudo aptitude install pipx > pipx ensurepath > pipx install --include-deps musicpy > > (logged out and in to get updated PATH) > > pipx run musicpy > 'musicpy' executable script not found in package 'musicpy'. > Available executable scripts: > > I think it is installed, but how do I run it? > >
Re: Question About Free File Transfering Apps
A client that by your own words barely works, while fully functional alternatives have been available for many years already. So what's your point? Am Do., 30. Mai 2024 um 14:23 Uhr schrieb Anssi Saari < anssi.sa...@debian-user.mail.kapsi.fi>: > > Wow. I already mentioned an open source client? What's your point? > >
Re: Question About Free File Transfering Apps
There have already been many answers. And since it's highly unlikely any third party will include support for such a closed down system, you might want to look at them. At least I don't think Google will suddenly open source Nearby Share for everyone to write clients for it. Am Do., 30. Mai 2024 um 11:00 Uhr schrieb Anssi Saari < anssi.sa...@debian-user.mail.kapsi.fi>: > I'd like to know too, assuming you're asking for transferring files > between Android and Linux. > > I'd like Quick Share support in Linux as it's built into Android and > available for Windows. Someone has an early version at > https://github.com/Martichou/rquickshare but I only got it working one > way, Linux PC to phone and even that needed disabling the firewall on > the PC. But maybe that'll improve. > >
Re: Question About Free File Transfering Apps
KDE connect? That has clients for many systems. But the question is, what's the issue with the existing solutions? It's quite a useless task to recommend file transfer apps when they all have the same issue you try to avoid. Richard
Re: Dovecot correct ownership for logs
Then where does the combination rwx come in here? With read the app knows the file is there, with write it writes to the file. Question is, where the necessity would be to know the owner of the file or even the kind. The logger is supposed to just append text to a file. If it were trying to append text to something it doesn't have the ownership for, it should just get an error, as that would ultimately be the case when it tries to write to the file knowing it doesn't have ownership because the user said so. No need for further knowledge. Am So., 19. Mai 2024 um 17:04 Uhr schrieb Greg Wooledge : > On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote: > > Dovecot expects execution permissions on the directory it writes the logs > > to. Because "Standard POSIX permissions for a non-root process to enter a > > directory." How on earth is that even a thing? > > That's how Unix permissions have always worked. In order to access > a file, you need +x permissions on *all* of the directories leading > up to that file, and then appropriate permissions on the file itself. > > If you have read permission on a directory but *not* execute permissions, > then the only thing you can do is read the contents of that directory -- > the filenames and their inode numbers. You cannot stat() the files, > so you can't see who owns them or even what kind of files they are. > Just their names. > > If you have execute permission but *not* read permission on a directory, > then you can access the files within the directory, but only if you > already know their names. You can't read the directory to get their > names. > > Likewise, write permission on a directory allows you to rename or unlink > files contained within that directory (because the names are not a > property of the files -- they are part of the *directory*). You don't > need write permission on a file to unlink it. Only on the directory. > >
Re: Dovecot correct ownership for logs
So, I've just written to the Dovecot mailing list, the reality why Dovecot is complaining is so much worse than anything I could have imagined. While everything indicates Dovecot is able to write to the log files, it seems Dovecot expects execution permissions on the directory it writes the logs to. Because "Standard POSIX permissions for a non-root process to enter a directory." How on earth is that even a thing? Beyond binaries there shouldn't really be any excuse for that many things to have execution permissions on anything.
Re: Dovecot correct ownership for logs
> > Don't call me a liar, you are just too dumb to understand. It's sad to see that you need to make it this blatantly obvious that even I clearly understand more than you do. And you're the one trying to scold me about sticking to the mailing list rules when you so obviously don't care for them yourself. No the point is, you are not setting a file path, you are configure dovecot > to directly write to these files. I'm configuring dovecot the way it wants to be configured if you want to deviate from default settings. What doesn't want to get to your brain is that dovecot isn't the issue. Without postfix interfering everything would be fine. It's postfix causing issues, not dovecot. Very simple logic would have told you that, but you are way too focused on hatred and on knowing everything better without actually doing so. I'm sorry but if you don't have any clue of what you are talking about, just don't reply. Also you may want to refrain from further replies - or attacks in your case - before you write something you can't take back.
Re: selinux on bookworm
As you found out yourself, by default it's installed and running. And it's quite likely they would interfere. Still, the question remains. Why do you need SELinux? Do you have an actual need for it? If not, go with what's already there. This will be much easier to set up and handle. Richard Am Fr., 17. Mai 2024 um 14:23 Uhr schrieb George at Clug < c...@goproject.info>: > Is AppArmor already installed and running? It is on my system, maybe this > would conflict with SeLinux? > > # aa-status > https://wiki.debian.org/AppArmor/HowToUse > Disable AppArmor AppArmor is a security mechanism and disabling it is not > recommended. If you really need to disable AppArmor on your system: > > > https://reintech.io/blog/securing-debian-12-with-selinux > By default, Debian comes with AppArmor, another security module, so you > may need to switch to SELinux manually. Here's how you can enable SELinux > on your Debian 12 system: > > sudo apt-get update > sudo apt-get install selinux-basics selinux-policy-default auditd > > George. > >
Re: selinux on bookworm
Is there a specific reason why you want to use SELinux? AppArmor is already there and much easier to configure. SELinux usually causes more issues than AppArmor too as it's not as granular, especially on distros not made specifically for it, at least in my experience. And on Debian, some apps already have AppArmor configs in their packages. Question only is if they are in notify or enforcing mode. Best, Richard Am Fr., 17. Mai 2024 um 11:05 Uhr schrieb Antonio Russo : > Hello, > > I'm trying to get selinux working on a fresh, gui-free installation of > bookworm. I'm not trying to run any servers, nor use standard desktop > utilities (yet). I was hoping this setup would be simple enough that > selinux would be simple to get going. > > I'm following [1], which is very straightforward. The problem I'm > getting is that it seems woefully incomplete. > > [...] > > Best, > Antonio > > [1] https://wiki.debian.org/SELinux/Setup
Re: Dovecot correct ownership for logs
So now that you don't know any further, you just start lying? Now that's rich. > I told you where to look, which is more than you deserve after how you behave. You didn't though. > Configure the literal industry standard syslog or journald to use a facility to your liking and the problem should resolve itself. The point is, Dovecot has an option to write certain types of logs to different files. While it's doing that great, postfix is upset about that capability. It shouldn't even try to access these files. So the issue is not being able to log to files, that's already solved, but postfix running crazy when using a very simple setting. Am Do., 16. Mai 2024 um 18:55 Uhr schrieb Henning Follmann < hfollm...@itcfollmann.com>: > On Thu, May 16, 2024 at 01:00:19PM +0200, Richard wrote: > > But why is postfix even holding a lock on it? And how do I prevent that? > I > > never asked it to. > > At least, I don't think there should be a different process holding a > lock > > on it. > > > > I told you where to look, which is more than you deserve after how you > behave. > Configure the literal industry standard syslog or journald to use a > facility to your liking and the problem should resolve itself. > > -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
Re: Dovecot correct ownership for logs
But why is postfix even holding a lock on it? And how do I prevent that? I never asked it to. At least, I don't think there should be a different process holding a lock on it. Am Mi., 15. Mai 2024 um 18:45 Uhr schrieb Henning Follmann < hfollm...@itcfollmann.com>: > On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote: > > > [...] > > > But that's still not that helpful for the main issue. Why on earth is > > postfix throwing issues about the log files, even when they are > > world-readable and -writable? It's not that dovecot doesn't log to them, > > but it's also not the case that it's an error message that can just be > > ignored, as it brings mail delivery to a halt. > > > > Maybe because you write directly to the logfile. One process trying to > write > t it while a different already holds a lock to it. > > -H > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
Re: Dovecot correct ownership for logs
mailbox_transport isn't defined anywhere. Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > > On 15/5/24 18:23, Richard wrote: > > Interesting. That's not even configured in our main.cfg. We have these > > concerning dovecot: > > smtpd_sasl_type = dovecot > > mailbox_command = /usr/lib/dovecot/deliver -d $USER > > The sasl line is not relevant > > The mailbox_command is unusual. It means whatever process actually > execute the mailbox_command runs as (some) postfix user to run the > deliver application. This may well cause permission issues. > > The usual case is dovecot listens for commands on a unix socket or maybe > an IP socket. In any case it has an entirely separate user ID from postfix. > > You may want to look at using the mailbox_transport option instead of > the mailbox_command option > > mailbox_transport = lmtp:unix:private/dovecot-lmtp > >
Re: Dovecot correct ownership for logs
Interesting. That's not even configured in our main.cfg. We have these concerning dovecot: smtpd_sasl_type = dovecot mailbox_command = /usr/lib/dovecot/deliver -d $USER But that's still not that helpful for the main issue. Why on earth is postfix throwing issues about the log files, even when they are world-readable and -writable? It's not that dovecot doesn't log to them, but it's also not the case that it's an error message that can just be ignored, as it brings mail delivery to a halt. Am Mi., 15. Mai 2024 um 05:00 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > This can be configured in postfix main.conf as > > virtual_transport = lmtp:unix:private/dovecot-lmtp or mailbox_transport > = lmtp:unix:private/dovecot-lmtp > > From the postfix howto guide > > mailbox_transport_maps (default: empty) > > Optional lookup tables with per-recipient message delivery transports > to use for local(8) mailbox delivery, whether or not the recipients are > found in the UNIX passwd database. > > The precedence of local(8) delivery features from high to low is: > aliases, .forward files, mailbox_transport_maps, mailbox_transport, > mailbox_command_maps, > mailbox_command, home_mailbox, mail_spool_directory, > fallback_transport_maps, fallback_transport and luser_relay. > > https://www.postfix.org/local.8.html > > https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/ > >
Re: Dovecot correct ownership for logs
Says the one refusing to stay on topic. What a sad hypocrite. On Tue, May 14, 2024, 20:10 Henning Follmann wrote: > On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote: > > "Top posting" (writing the answer above the text that's being replied to) > > is literally industry standard behavior. > > > Whatever. > It is not standard behavior in mailing lists. > > https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guidelines.2C_and_Tips > > But I just asked you to not to. You can ignore that, as you do. > > Good luck with your issues. > > > Also, I don't think you've really cleared out any confusion. Now, how > > exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing > > errors? Because it clearly is for 2 out of 3 files as visible from the > file > > sizes in my original post. Only the debug file is empty, but maybe > nothing > > relevant enough has been found yet. There are entries from master, > > imap, imap-login, managesieve-login, anvil and various other processes in > > info and error. But the error messages from postfix still appear, also > > seemingly at least vastly slowing down emails being delivered to the > users, > > if not bringing that to a complete halt. Only after commenting out these > > locations in 10-logging.conf the mails show up for the users. > > > > > -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
Re: Dovecot correct ownership for logs
How exactly do I do that? Am Di., 14. Mai 2024 um 18:40 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > > From what I can find out, the postfix local delivery agent is not > chroot and it communicates with the main postfix processes via shared > directories and pipes. > > To debug the problem I suggest checking the chroot and non chroot > processes and eliminate those that are not relevant to the seen error > messages > >
Re: OT: Top Posting
You really must think of yourself as being the epitome of human creation. I don't see any use in continuing this nonsense. If you don't have anything relevant to say, this case is closed for me. Am Di., 14. Mai 2024 um 16:55 Uhr schrieb gene heskett : > On 5/14/24 10:09, Richard wrote: > > Just because something isn't an official ISO standard doesn't mean it's > > not standard behavior. And how it relates to this mailing list? It's > > called a setting. > > > No its not, its your refusal to use the down arrow in your reply editor > to put your reply after the question. It really is that simple. If your > choice of email agents cannot do that, its time to switch to an agent > that can. There are dozens of them. > > > Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett > > mailto:loris.benn...@fu-berlin.de>>: > > > > Hi Richard, > > > > Richard mailto:rrosn...@gmail.com>> writes: > > > > > "Top posting" (writing the answer above the text that's being > replied > > > to) is literally industry standard behavior. > > > > Can you provide a link to the standard you are referring to? > > > > Assuming such a standard exists, how would it apply to this > newsgroup? > > > > [snip (51 lines)] > > > > Cheers, > > > > Loris > > > > -- > > This signature is currently under constuction. > > > > Cheers, Gene Heskett, CET. > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author, 1940) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > >
Re: OT: Top Posting (was: Dovecot correct ownership for logs)
Just because something isn't an official ISO standard doesn't mean it's not standard behavior. And how it relates to this mailing list? It's called a setting. Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett < loris.benn...@fu-berlin.de>: > Hi Richard, > > Richard writes: > > > "Top posting" (writing the answer above the text that's being replied > > to) is literally industry standard behavior. > > Can you provide a link to the standard you are referring to? > > Assuming such a standard exists, how would it apply to this newsgroup? > > [snip (51 lines)] > > Cheers, > > Loris > > -- > This signature is currently under constuction. > >
Re: Dovecot correct ownership for logs
And you think you're important enough to change that setting for a whole
mailing account? You're funny.
Am Di., 14. Mai 2024 um 15:16 Uhr schrieb Brad Rogers :
> On Tue, 14 May 2024 15:11:16 +0200
> Richard wrote:
>
> Hello Richard,
>
> >"Top posting" (writing the answer above the text that's being replied
> >to) is literally industry standard behavior.
>
> This 'literally' isn't industry.
>
> --
> 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?"
> Is she really going out with him?
> New Rose - The Damned
>
Re: Dovecot correct ownership for logs
"Top posting" (writing the answer above the text that's being replied to) is literally industry standard behavior. Also, I don't think you've really cleared out any confusion. Now, how exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing errors? Because it clearly is for 2 out of 3 files as visible from the file sizes in my original post. Only the debug file is empty, but maybe nothing relevant enough has been found yet. There are entries from master, imap, imap-login, managesieve-login, anvil and various other processes in info and error. But the error messages from postfix still appear, also seemingly at least vastly slowing down emails being delivered to the users, if not bringing that to a complete halt. Only after commenting out these locations in 10-logging.conf the mails show up for the users. Am Di., 14. Mai 2024 um 14:54 Uhr schrieb Henning Follmann < hfollm...@itcfollmann.com>: > On Tue, May 14, 2024 at 01:58:07PM +0200, Richard wrote: > > > > Please don't top post! It is a pain to follow a thread if you do. > > > > Am Di., 14. Mai 2024 um 13:45 Uhr schrieb Greg Wooledge < > g...@wooledge.org>: > > > > > On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote: > > > > Postfix is chrooted (usuallly) to /var/spool/postfix > > > > > > If this is true, then how would a local delivery agent work? It needs > > > write access to all users' inboxes, which are either in /var/mail or in > > > users' home directories. > > Usually the local delivery is done by a local agent (procmail, dovecot's > lmtp daemon). These do not run chrooted. > > > > > > > I could imagine the Postfix SMTP sending/receiving and queue processing > > > programs being chrooted, but the LDA probably isn't. Or at least not > > > chrooted to /var/spool/postfix. > > > > > > > [fixed top posting] > > For us the situation is even a bit stranger. The inboxes are located in > > neither location, but in /maildirs/username/ (no idea why it was set up > > that way, but it's a dedicated mail server where the user's don't have > > their own home directory). /var/mail is empty. > > This is a common dovecot setup. > lmtp provides a unix socket into postfix chroot environment. This process > usually runs as postfix user so the socket is owned by postfix. But it uses > the dovecot logging configuration. > Having the maildirs in a dedicated directory makes it easy to have a > dedicated drive just for the mailboxes. This makes adapting to growth much > simpler. > > -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
Re: Dovecot correct ownership for logs
>
> ps -eo pid,user,group,comm | grep postfix
> 2886706 postfix postfix pickup
> 2886707 postfix postfix qmgr
> 2886764 postfix postfix tlsmgr
Also as far as I know, postfix logs to syslog too. At least there is no
dedicated file or folder for it in /var/log.
Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem, which just opens a whole other bunch of questions. So in
case that for some odd reason AppArmor logs aren't logged to syslog (and
also it doesn't have a dedicated file), these are the rules for dovecot and
postfix I could find:
postfix has an apparmor (in abstractions) file that doesn't say anything
about /var/log. It only has these rules for things in /var:
/var/spool/postfix/etc/*r,
/var/spool/postfix/lib/lib*.so* mr,
/var/spool/postfix/lib/@{multiarch}/lib*.so* mr,
Dovecot has two files. In tunables you can find this:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories
# where dovecot is allowed to store and read mails
#
# The default value is quite broad to avoid breaking existing setups.
# Please change @{DOVECOT_MAILSTORE} to (only) contain the directory
# you use, and remove everything else.
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/
/var/vmail/ /var/mail/ /var/spool/mail
Which doesn't seem to be relevant for this. No idea how dovecot can put the
mail into /maildirs/username, but since that's working I'm not complaining.
The file in abstractions only contains this:
# used with dovecot/*
abi ,
capability setgid,
deny capability block_suspend,
# dovecot's master can send us signals
signal receive peer=dovecot,
owner @{run}/dovecot/config rw,
# Include additions to the abstraction
include if exists
Am Di., 14. Mai 2024 um 13:45 Uhr schrieb :
> On Tue, May 14, 2024 at 01:29:17PM +0200, Richard wrote:
> > My guess is that postfix runs as postfix.
>
> That would be my guess too (or perhaps as some special "Debian-+postfix".
>
> > At least processes like local,
> > smtpd, bounce etc run as that user. But beyond that I have no idea how to
> > find that out. At least there's nothing in the postfix.service or
> > postfix@.service
> > about that. So I've changed the files to dovecot:postfix 664, but same
> > error.
>
> You might try
>
> ps -eo pid,user,group,comm | grep postfix
>
> or similar. Or have a look at Posrfix's log file ownerships.
>
> You might try making the log files in question world writable just
> to see whether the problem disappears or this approach is a blind
> alley (don't forget to revert that: leaving them world-writable
> seems like asking for trouble).
>
> Cheers
> --
> t
>
Re: Dovecot correct ownership for logs
For us the situation is even a bit stranger. The inboxes are located in neither location, but in /maildirs/username/ (no idea why it was set up that way, but it's a dedicated mail server where the user's don't have their own home directory). /var/mail is empty. Am Di., 14. Mai 2024 um 13:45 Uhr schrieb Greg Wooledge : > On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote: > > Postfix is chrooted (usuallly) to /var/spool/postfix > > If this is true, then how would a local delivery agent work? It needs > write access to all users' inboxes, which are either in /var/mail or in > users' home directories. > > I could imagine the Postfix SMTP sending/receiving and queue processing > programs being chrooted, but the LDA probably isn't. Or at least not > chrooted to /var/spool/postfix. > >
Re: Dovecot correct ownership for logs
My guess is that postfix runs as postfix. At least processes like local, smtpd, bounce etc run as that user. But beyond that I have no idea how to find that out. At least there's nothing in the postfix.service or postfix@.service about that. So I've changed the files to dovecot:postfix 664, but same error. Am Di., 14. Mai 2024 um 06:34 Uhr schrieb : > On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote: > > Maybe someone here knows how the ownership of these files for Dovecot > needs > > to be in order to work, as various distributions of Dovecot packages seem > > to use different users: > > I'd like Dovecot not to log into syslog, but to dedicated files. > Therefore > > I've created the directory /var/log/dovecot and told dovecot in > > 10-logging.conf to log info, debug and error messages to separate files. > > But I get error messages from postfix (weird): > > I think this Dovecot's LDA (the local delivery agent) [1], which is > invoked by the MTA (Postfix) and is, therefore, most probably running > as postfix. > > [...] > > > > (temporary failure. Command output: lda(user): Error: > > > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied > Can't > > > open log file /var/log/dovecot/error.log: Permission denied ) > > This message actually is an indicator against the chroot theory posed > elsewhere in this thread (in a chroot, you would get "no such file or > directory", I guess). > > > > This is the content of /var/log/dovecot: > > -rw-r--r-- 1 dovecot dovecot0 13. Mai 20:50 debug.log > > -rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log > > -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log > > Try to set the log file's group to mail (or whatever group Postfix is > running as) and make them group writable. > > Cheers > -- > t >
Re: Dovecot correct ownership for logs
AppArmor complaints would be shown in journalctl too. But dmseg doesn't show anything either. Just switched dovecot back to these log files, waited for the error message, yet dmesg doesn't have anything new since yesterday. Systemd was also my guess as it was originally set to ProtectSystem=full for dovecot.service, but reducing that to yes didn't change anything. These are the in the Service block of the service, maybe you see anything that could be a reason too: [Service] Type=notify ExecStart=/usr/sbin/dovecot -F ExecReload=/usr/bin/doveadm reload ExecStop=/usr/bin/doveadm stop PrivateTmp=true NonBlocking=yes ProtectSystem=yes ProtectHome=no PrivateDevices=true Restart=on-failure Best Richard Am Mo., 13. Mai 2024 um 22:28 Uhr schrieb Greg Wooledge : > On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote: > > May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=< > u...@domain.de>, > > > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, > status=deferred > > > (temporary failure. Command output: lda(user): Error: > > > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied > Can't > > > open log file /var/log/dovecot/error.log: Permission denied ) > > > > This is the content of /var/log/dovecot: > > -rw-r--r-- 1 dovecot dovecot0 13. Mai 20:50 debug.log > > -rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log > > -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log > > The first two things that come to mind are AppArmor, and systemd unit > files. > > Check to see whether there's an AppArmor profile for this program, or > any lines from AppArmor in dmesg. > > If that's not it, look at the systemd unit file(s) that start the > dovecot service(s), if there are any, and see if they're using any of > the directives that restrict the locations the program can access. > >
Re: Dovecot correct ownership for logs
But why should it cause issues? I set the logging in dovecot's conf.d, so I'd expect dovecot to write these logs, not postfix as it has its own settings. Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > > On 14/5/24 04:16, Richard wrote: > > Maybe someone here knows how the ownership of these files for Dovecot > > needs to be in order to work, as various distributions of Dovecot > > packages seem to use different users: > > I'd like Dovecot not to log into syslog, but to dedicated files. > > Therefore I've created the directory /var/log/dovecot and told dovecot > > in 10-logging.conf to log info, debug and error messages to separate > > files. But I get error messages from postfix (weird): > > > A possible cause of problems between postfix and dovecot is that postfix > usuallly runs chroot so the file tree it sees is not the same as the one > the rest of the system sees. > >
Dovecot correct ownership for logs
Maybe someone here knows how the ownership of these files for Dovecot needs to be in order to work, as various distributions of Dovecot packages seem to use different users: I'd like Dovecot not to log into syslog, but to dedicated files. Therefore I've created the directory /var/log/dovecot and told dovecot in 10-logging.conf to log info, debug and error messages to separate files. But I get error messages from postfix (weird): May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=, > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred > (temporary failure. Command output: lda(user): Error: > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't > open log file /var/log/dovecot/error.log: Permission denied ) This is the content of /var/log/dovecot: -rw-r--r-- 1 dovecot dovecot0 13. Mai 20:50 debug.log -rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log So why is Dovecot complaining? I only see processes owned by root, dovecot, dovenull and user processes of dovecot. And dovenull seems to be not relevant for this. Best Richard
Re: How to run automatically a script as soon root login
>> If yes, second dumb question: Coiuld it be ANY script or command? >> (also running as non-rootuser, like adding "runuser -u myuser >> command_whatever"). >Root can do this, yes. Or to be more precise, .bashrc (and any file that's read from it like .bash_aliases) can run anything the bash CLI can run with the same privileges. Of course, anything requiring user input like entering passwords won't work. The same is true for .profile, but with the twist that depending on which shell is reading it, other syntaxes may be possible/required, while .bashrc and similarly named files are pretty much bash-exclusive. So as long as it's something that should run upon login, like setting user-wide environment variables. > Sorry, dumb question: Depending of the shell, the user is using (let's say, he will use bash), can the script not be added into ~/.bashrc? .profile is simply more universal. E.g. I'm mounting cloud storage drives through rclone. Since I put the command into .profile, it won't just be run when I log in to the bash shell, but also when I log in to Gnome. I don't think that would be possible with .bashrc. Best Richard Am Mo., 13. Mai 2024 um 18:34 Uhr schrieb : > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > > .profile > > > > Sorry, dumb question: Depending of the shell, the user is using (let's > say, he > > will use bash), can the script not be added into ~/.bashrc? > > Yes. Consult your shell's manual. And it will also depend on whether > it is considered to be a "login shell". And on a couple of other > factors. > > > If yes, second dumb question: Coiuld it be ANY script or command? > > (also running as non-rootuser, like adding "runuser -u myuser > > command_whatever"). > > Root can do this, yes. > > Cheers > -- > t >
Re: How to run automatically a script as soon root login
Should be as easy as executing the script from the .profile of root - that means if "log in as root" actually means root, not just sudo'ing. .profile will always be read as soon as the user logs in, no matter how. Through a terminal, a GUI, doesn't matter. No idea if doing this through systemd is even possible. Best Richard On Mon, May 13, 2024, 04:10 Mario Marietto wrote: > Hello to everyone. > > I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that > I will use to forward the cloudflare connection to FreeBD. > What I want to do is to run the script below as soon as root has logged > in. > > I've configured the automatic login of root adding to this service file : > > nano /etc/systemd/system/getty.target.wants/getty@tty1.service > > this line : > > ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I > $TERM > > Now,what I want to do is that the script below is ran as soon root is able > to logged in automatically : > > /usr/bin/warp > > warp-cli disconnect > echo 1 > /proc/sys/net/ipv4/ip_forward > iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE > OLD_IP="$(curl -s api.ipify.org)" > warp-cli connect > NEW_IP="$(curl -s api.ipify.org)" > echo Connected to Cloudflare Warp... > echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP > > [Forgot to say that I switched boot target to text with this command : > > sudo systemctl set-default multi-user.target] > > What I tried right now has been to create a respawn service with systemd. > I created a file in /etc/systemd/system/ i.e. warp.service > > [Unit] > Desription=warp with systemd, respawn > After=pre-network.target > > [Service] > ExecStart=/usr/bin/warp > Restart=always > > [Install] > WantedBy=multi-user.target > > > and I've activated it : > > systemctl enable warp.service > > > rebooted and started it manually : > > systemctl daemon-reload > systemctl start warp.service > > It does not work and anyway it does not seem to be what I want... > > [image: Istantanea_2024-05-12_23-46-37.png] > > I want that the warp script is run everytime root is logged in,not > more,not less. > I suspect that the solution is easier than what I'm trying to do... > > -- > Mario. >
Re: Ter info: FileZilla
On Sat, 11 May 2024 11:49:12 +0200 Sjoerd wrote: > Wat je nu ziet gebeuren, is dat FileZilla eerst contact probeert te > maken via het IPv6-adres. Na ruim 2 minuten geeft-ie het op, en dan > wordt overgegaan naar het IPv4-adres, waarna de verbinding vlot tot > stand komt. Maar als je dan iets wilt uploaden, wordt opnieuw eerst > het IPv6-adres geprobeerd, en herhaalt deze toestand zich. Zet voor de betreffende host alleen het ipv4 adres in de hosts file (die bestaat onder windows ook, dan forceer je de boel naar ipv4. HTH, R. -- richard lucassen http://contact.xaq.nl/
Re: debian bookworm japanese kana input disabled
/var/log/apt/history will tell you what apt also has been showing you during that process. Never just mindlessly agree to what apt tells you it's about to do, especially pay attention to the app list for "remove" and "auto-remove". Things can always go wrong. So if apt told you it will remove some package for whatever reason that's needed for kana, it will have done so. So check the history and have a look at any packages from that timestamp that where set to be removed. Best Richard Am Do., 9. Mai 2024 um 03:45 Uhr schrieb 冨澤守治 : > Hellow! > > Thanks you for your supprting everyday. > > Last night (JST) I did some apt update && apt upgade. > But all of sudden I can't input kana and even print any editer or calc > cell. > (Roman alphabet has no problem on printing.) > > yours sincerely > > -- > Moriharu Tomizawa > >
Re: Viewing an an OpenStreetMap tile offline.
>From the Github page [1]: > for RUNNING gosm you'll need: > libglib2.0-0 2.20.1-1 libgtk2.0-0 2.14.7-5 libcairo2 1.8.6-2+b1 libcurl3 > 7.18.2-8.1 libpng12-0 1.2.27-2 libwebkit-1.0-1 1.0.1-4+b1 libbz2-1.0 1.0.5 > java >=1.5 for PDF-Export With such ancient dependencies, I wouldn't even try to run it as it seems quite unlikely that the versions available in a current Debian repo will still be able to run it. Or at least try to compile all those dependencies from source. Doing that in a VM of a much older Debian version may be easier as depending on how many dependencies you'd need to compile to even get these, you may have at least some already available. And "Last Update: 2013-04-26" is an overstatement. Something may have changes back then, but the files on Sourceforge haven't been touched since 2009. Under these circumstances, I wouldn't even bother trying to get such ancient software up and running. Not with so many alternatives listed in the OpenStreetMap Wiki [2]. Best Richard [1]: https://github.com/sebkur/gosm [2]: https://wiki.openstreetmap.org/wiki/Software/Desktop Am So., 5. Mai 2024 um 22:00 Uhr schrieb : > Hi, is anyone using Gosm or something similar to view OpenStreetMap > tiles offline? > https://wiki.openstreetmap.org/wiki/Gosm > > The instructions under "Downloading and running" yield > bash: ./gosm: No such file or directory > > "Last Update: 2013-04-26" suggests an ia32 application? > > Is there an alternative application? > > Multiarch is needed in this 64 bit system? > > Other ideas? > > Thanks, ... P. > > > -- > VoIP: +1 604 670 0140 > work: https://en.wikibooks.org/wiki/User:PeterEasthope > >
grub requirements for fonts
I'd like to increase the font size in Grub (v2.12, at least I think that's the better alternative to just lowering the resolution) and opted to just use a custom font as there seems to be an OTF version of "GNU Unifont", though it seems to be jagged by design, but I'm running into issues. I thought about just using Noto Mono Regular for it, as Noto is supposed to always work and a monospaced font is recommended for easier setting of letters, as Grub uses bitmap fonts. Now my issue is that on one hand, the conversion to a bitmap font seems to be quite bad, the letters look really jagged. On the other hand, it seems that despite Noto supposed to being about no tofu, I actually get a lot of tofu. Both the up and down arrows in the description text at the bottom of grubs boot selector and the border around everything is just made up of tofu. And I tried converting the font with both grub-mkfont and Grub Customizer, same result. So what exactly are the requirements for fonts to be used in Grub so that they are converted to PFF2 fonts in a higher quality and don't show tofu? Best Richard
Gnome problem occured, system can't recover on testing
Hi, after a reboot I'm now greeted by a white screen saying Oh no! Something has gone wrong A problem has occurred and the system can't recover. Please contact a system administrator. I can still switch to a different tty, but I can't really tell what the issue is. The output of journalctl -b --priority 3 is: kernel: cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected bluetoothd[894]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed. bluetoothd[894]: sap-server: Operation not permitted (1) bluetoothd[894]: Failed to load LTKs for hci0: Invalid Parameters (0x0d) systemd[1]: Failed to start firewalld.service - firewalld - dynamic firewall daemon. csc_vpnagent[961]: Function: startParser File: ../../vpn/Common/Xml/CVCSaxParser.cpp Line: 171 Invoked Function: xmlCreateFileParserCtxt Return Code: -33554427 (0xFE05) Description: GLOBAL_ERROR_NULL_POINTER csc_vpnagent[961]: Function: LoadSettingsFromXmlFile File: ../../vpn/PhoneHome/PhoneHomeAgent.cpp Line: 626 Invoked Function: XmlParser::parseFile Return Code: -33554423 (0xFE09) Description: GLOBAL_ERROR_UNEXPECTED gnome-session-binary[1447]: Unrecoverable failure in required component org.gnome.Shell.desktop kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5) gnome-session-binary[1618]: Unrecoverable failure in required component org.gnome.Shell.desktop gnome-session-binary[1618]: Unrecoverable failure in required component org.gnome.SettingsDaemon.UsbProtection.desktop kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110) login[2018]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory PAM adding faulty module: pam_lastlog.so Now, the first line can just be ignored, that's typical. The things that concern me the most are the last two lines. It already has been reported as a bug and seems to be in the works, but I haven't seen any inidcation that this should cause a complete failure. The other reasons I've found for the Gnome related error message was either trouble with Nvidia - but I don't have any installed - or outdated firmware. So I've just made double shure to really have the latest firmware by copying over the 04/2024 archive from kernel.org with rsync -rc, yet no change (I'm running on a Ryzen 7040, so the AMD firmware available in the Debian repos is way too old, no matter which branch). So what's going on? Best Richard
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
Hi Michel, upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a rather trivial case shouldn't be resulting in such fatal errors. Best Richard On Wed, Apr 24, 2024, 14:23 Michel Verdier wrote: > On 2024-04-23, Richard wrote: > > > luks-775ea946-6797-4c4d-a042-72924309f3d2 > > UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > luks-78362aa3-760c-41de-b911-6531b684e3f7 > > UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > initramfs extract line from /etc/crypttab to create its own crypttab > as you have seen in main/cryptroot/crypttab, and only for rootfs, not for > swap > > > Now, is this a bug in the package or am I missing something? And how do I > > create a working initramfs now? > > swap is usually mounted after rootfs is mounted, thus using > /etc/crypttab. If you want to resume from swap you have to follow > paragraph 2.2.1 on > https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption > > If you don't need to resume you can follow the much easier chapter 1 on > the same url, using /dev/urandom as a keyfile. > > >
Re: Trouble/bug with initramfs-tools adding encrypted swap partition
Hello Hans, this is exactly what I did. To be precise, I followed this guide [1], with the difference that instead of "crypt" I used the actual name, luks- (Disks thanksfully shows everything relevant). It's not the first time I'm doing this. Yet I experience the errors mentioned. Sure, I'm not using the -u flag with update-initramfs as I see no point in updating what's already broken, I just use -ck all. But that shouldn't make a difference. Best Richard [1]: https://wiki.debian.org/GrubEFIReinstall Am Mi., 24. Apr. 2024 um 08:35 Uhr schrieb Hans : > Am Dienstag, 23. April 2024, 22:26:17 CEST schrieb Richard: > > Hi Richard, > > this is, what I am doing when this happens: > > 1. booting into a live system (any new is working, I prefer kali-linux) > > 2. If you are using encrypted filesystems, open it. But you have to name > it like it is named in /etc/crypttab of the defective system > > 3. Now mount the device with root-filesystem to /mnt > > 4. If you have /boot as a separated partition, mount it to /mnt/boot > > 5. Now mount needed system directories to /mnt > > mount --bind /sys /mnt/sys > > mount --bind /proc /mnt/proc > > mount --bind /dev /mnt/dev > > 6. If everything is mounted correct, you can chroot into the mounted system > > chroot /mnt > > 7. Now you can create a new initrd > > update-initramfs -u > > > > 8. exit the chroot and reboot. > > > -- > > > Note: > > 1. if you have encrypted filesystems, check in the chroot the files > > /etc/crypttab > > /etc/cryptsetup-initramfs/conf-hook > > In conf-hook check the last line, the parm "ASKPASS=Y" should be commented > out. > > 2. You can check the UUID of every partition with the command > > blkid /dev/sda1 > > and compare it with the entries in /etc/fstab, /etc/crypttab and > everywhere else it is used. > > 3. In chroot, you can of course also create a new initrd, using > > update-initramfs -c -k all > > 4. Please remember, when you have encrypted partitions, then the UUID of > the device is other, than the partitions, you later mount. Example: > > blkid /dev/sda3 > > UUID=1234556-dfre-3456. > > Now > > cryptsetup luksOpen /dev/sda3 crypt_sda3 > > blkid /dev/mapper/crypt_sda3 > > UUID=9876g54-765g-87hg > > Watch this, when changing any UUIDs in /etc/fstab or anywhere else. > > Last but not least: Hope this helps, good luck! > > Best > > Hans > > > >
Trouble/bug with initramfs-tools adding encrypted swap partition
Hi, I've just set up a new computer with Debian Testing. I initially set it up without a swap partition, but I want to add it now. The partition has already been created as a LUKS2 partition, but I can't get update-initramfs to add it so it will automatically be decrypted at boot (both have same passphrase, but opposed to using the bootup passphrase or ask for a separate one, I'm only asked much later by grub. Running update-initramfs -ck all gives me this error: update-initramfs: Generating /boot/initrd.img-6.6.15-amd64 cryptsetup: WARNING: target 'luks-78362aa3-760c-41de-b911-6531b684e3f7' not found in /etc/crypttab but /etc/crypttab has these two lines, just like I did on my old device: luks-775ea946-6797-4c4d-a042-72924309f3d2 UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin luks,keyscript=/bin/cat luks-78362aa3-760c-41de-b911-6531b684e3f7 UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin luks,keyscript=/bin/cat So it clearly doesn't miss from the crypttab. Though I can'ft check if the second partition has a crypto_keyfile.bin, as it is a swap partition and I have no idea how to look inside. For completeness, that's the fstab: UUID=F5D8-8C91/boot/efi vfat defaults,noatime 0 2 /dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 / btrfs subvol=/@,defaults,noatime,space_cache=v2,autodefrag,discard,compress=zstd:4 0 0 /dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 /home btrfs subvol=/@home,defaults,noatime,space_cache=v2,autodefrag,discard,compress=zstd:4 0 0 /dev/mapper/luks-78362aa3-760c-41de-b911-6531b684e3f7 swap swap defaults,noatime,discard 0 0 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 and this is the command line in /etc/default/grub (of course I did run update-grub afterward): GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=775ea946-6797-4c4d-a042-72924309f3d2:luks-775ea946-6797-4c4d-a042-72924309f3d2 root=/dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 splash resume=/dev/mapper/luks-78362aa3-760c-41de-b911-6531b684e3f7" I even created the file /etc/initramfs-tools/conf.d/resume containing the line "RESUME=UUID=luks-78362aa3-760c-41de-b911-6531b684e3f7", also no change. In the meantime, I also tried adding the initramfs option in crypttab, yet no change. Upon inspecting the created initramfs by unpacking it with unmkinitramfs, I can see the initramfs does contain crypttab twice. The one in main/etc/crypttab is identical to the one in my system, but the one in main/cryptroot/crypttab is missing the second entry of the swap partition. Also, since then I've done a reboot and now when gdm would load I'm only greeted by a strange white screen telling my something happened the system can't recover from and that I should talk to my admin (or something like that). I was still able to switch tty. So while I'm not sure if that's even related, I tried to remove the swap partition from fstab, crypttab, grub and the resume file. But the same error kept happening over and over again. So I booted to a live USB (of 12.5), chrooted into the system without mounting the swap partition to try to run "update-initramfs -ck all" from there. But now it even refuses to find the root partition in crypttab. Now, is this a bug in the package or am I missing something? And how do I create a working initramfs now? Best Richard
Re: Ethernet werkt niet
On Tue, 19 Mar 2024 15:37:56 +0100 Paul van der Vlis wrote: > Zoiets was dat bij mij ook. Ik vroeg me af of er ook een soort PING > was op MAC niveau. arping -I eth0 a.b.c.d Dat zendt arp who-has naar a.b.c.d: # arping -I wlan0 -c 1 192.168.66.1 ARPING 192.168.66.1 from 192.168.66.252 wlan0 Unicast reply from 192.168.66.1 [00:0D:B9:3F:F6:CE] 4.217ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) # tcpdump -ni wlan0 arp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 23:44:22.257279 ARP, Request who-has 192.168.66.1 (ff:ff:ff:ff:ff:ff) tell 192.168.66.252, length 28 23:44:22.261106 ARP, Reply 192.168.66.1 is-at 00:0d:b9:3f:f6:ce, length 46 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel -- richard lucassen http://contact.xaq.nl/
Re: Ethernet werkt niet
On Mon, 18 Mar 2024 14:13:11 +0100 Paul van der Vlis wrote: > Naast networkmanager heb ik ook een verbinding via > /etc/network/interfaces geprobeerd, maar daar ook geen succes. Wat ik > zie is een boel DHCPDISCOVER maar geen lease. Het lijkt alsof hij > geen antwoord krijg via DHCP. En als je Network-Destroyer stopt en gewoon aan de cli kijkt wat er gebeurt? ip link set eth0 up Daarna: dhclient eth0 Of ip a a a.b.c.d/nm dev eth0 ip r a default via a.b.c.1 En /etc/resolv.conf even editten Ik heb trouwens een laptop (staat nu 1000km verderop) en die heeft een issue met de hardware of driver (ik weet zo niet uit m'n hoofd welke kaart dat is). Die geeft qua receive niet thuis soms en dan zie je wel dhcp requests maar geen antwoord. R. -- richard lucassen http://contact.xaq.nl/
Re: sshd Match regel
On Wed, 21 Feb 2024 16:21:35 +0100 Roland Clobus wrote: > On 21/02/2024 16:08, Paul van der Vlis wrote: > >>>>> Wie heeft een tip > > Ik heb nog een (zeer) oude Linksys WRT staan, die kan ik benaderen > met: > > ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 > -oHostKeyAlgorithms=+ssh-rsa username@mylocalip > > Ik heb met ssh -v username@mylocalip de waarde voor -oKexAlgorithms > gevonden. Even ter info: onder Debian heb je een package dat openssh-client-ssh1 heet. Enige nadeel is dat-ie de /etc/ssh/ssh_config uitleest en niet bijvoorbeeld een /etc/ssh/ssh1_config. Even scripten dus met een eigen config file. Er is ook een scp1 in dat package. -- richard lucassen http://contact.xaq.nl/
Re: Booten vanaf USB steeds trager
On Wed, 21 Feb 2024 15:42:36 +0100 Paul van der Vlis wrote: > > Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de > > root device niet kan vinden en dat duurt dan een tijdje. IIRC helpt > > een > > > > update-initramfs -u > > Dit had ik al geprobeerd, maar hielp niet. Ik bedacht me later dat dat met md devices is. Als de mdadm.conf niet overeenkomt met wat er in de initramdisk zit dan gaat-ie md127, md126 etc aanmaken en dan krijg je dat. Nooit uitgezocht waarom. En dan helpt de update-initramfs -u wel uiteraard. > > console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02 > > rootfstype=ext4 fsck.repair=yes rootwait > > Dit is geen Pi, dus ook geen cmdline.txt Het gaat niet zozeer om de RPi, maar om de kernel opties die de kernel meekrijgt als-ie vanaf USB boot R. -- richard lucassen http://contact.xaq.nl/
Re: Booten vanaf USB steeds trager
On Tue, 20 Feb 2024 09:31:02 +0100
Paul van der Vlis wrote:
> Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op
> dat dit steeds trager wordt, op dezelfde machine:
>
> Debian10: 18 seconden
> Debian11: 60 seconden
> Debian12: ruim 120 seconden
Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de root
device niet kan vinden en dat duurt dan een tijdje. IIRC helpt een
update-initramfs -u
dan, maar zeker weet ik dat niet ('t is alweer een tijdje terug). Met
een monitor erop kun je die meldingen zien. Ik sloop trouwens altijd de
"quiet" optie uit /etc/default/grub (en daarna update-grub). Heb je wel
"rootwait" als kerneloptie meegegeven? Volgens mij moet dat ook. Dit
staat in de cmdline.txt file op mijn Raspberry Pi:
console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02
rootfstype=ext4 fsck.repair=yes rootwait
Ben geen guru op dat gebied trouwens.
--
richard lucassen
http://contact.xaq.nl/
Re: Problemen met rechten LetsEncrypt
On Sat, 27 Jan 2024 14:16:52 +0100 Paul van der Vlis wrote: > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > Misschien is dat het? > > Alles in /etc/letsencrypt was root:root. > Dan helpt het niet als een user lid is van een groep. > > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat > het weer fout gaat bij een nieuw certificaat of bij het verlengen van > een certificaat. [addendum] Ik heb, zoals Geert al opperde, de hele boel wel eens opnieuw opgezet. En sinds de laatste keer gaat het eigenlijk best wel goed. -- richard lucassen http://contact.xaq.nl/
Re: Problemen met rechten LetsEncrypt
On Sat, 27 Jan 2024 14:16:52 +0100 Paul van der Vlis wrote: > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > Misschien is dat het? > > Alles in /etc/letsencrypt was root:root. > Dan helpt het niet als een user lid is van een groep. > > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat > het weer fout gaat bij een nieuw certificaat of bij het verlengen van > een certificaat. Ik gebruik ook certbot en ik heb gemerkt dat het af en toe misgaat en dan maakt-ie directories aan met domain.tld-0001 of dirs van gelijke strekking (iets met een nummer als 0001, 0002 etc). Ik heb destijds een quick and dirty script in elkaar gejast: ### #!/bin/dash certbot \ --manual \ --preferred-challenges dns \ certonly \ -d domain.tld \ -d www.domain.tld \ --config-dir ~/share/letsencrypt/etc/ \ --work-dir ~/share/letsencrypt/certs/ \ --logs-dir ~/share/letsencrypt/log/ cd ~/share/letsencrypt/etc/live/domain.tld cat fullchain.pem privkey.pem > domain.tld-bundle.pem scp domain.tld-bundle.pem \ root@:/etc/ssl/domain.tld/ ssh root@ service lighttpd restart ### Op de server zet ik die bundel op chmod 400. De server start toch als root op, leest de spullen uit en gaat dan verder met een unprivileged user. HTH, R. -- richard lucassen http://contact.xaq.nl/
Re: Problemen met rechten LetsEncrypt
On Wed, 24 Jan 2024 15:15:37 +0100 Paul van der Vlis wrote: > Op een vers geinstalleerde Debian12 heb ik een raar probleem met > LetsEncrypt certificaten. (Ik gebruik certbot, weet niet of dat van > belang is.) > > Eerder was het zo dat gebruikers die lid waren van de groep ssl-cert > bij de certicaten en keys mochten, maar nu niet meer. Alleen root mag > erbij. > > Weet iemand hier meer van? Ik zag geen bug. Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst uitloggen en weer inloggen voordat de user echt tot de groep hoort. Misschien is dat het? R. -- richard lucassen http://contact.xaq.nl/
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 14/01/24 03:59, Greg Wooledge wrote: I have dealt with terminals with passthrough printers before, but it was three decades ago, and I've certainly never heard of a printer communicating *back* to the host over this channel I've also set up passthrough printers on terminals - which were hanging off muxes ... it's a serial connection, so bidirectional commumination should be fine, and more recent printers would make use of that. And in fact, when we ran out of mux ports, we even hung an extra terminal off the passthrough port, so bidirectional worked :-) These were physical serial terminals, of course - I don't remember having to get a terminal emulator to do this. It also wasn't on Linux - some were on SCO, and the others might have been on some kind of mainframe - a government department. We weren't involved in that side of it. Richard
Re: find question
On 30/12/23 01:27, Greg Wooledge wrote: On Fri, Dec 29, 2023 at 10:56:52PM +1300, Richard Hector wrote: find $dir -mtime +7 -delete "$dir" should be quoted. Got it, thanks. Will that fail to delete higher directories, because the deletion of files updated the mtime? Or does it get all the mtimes first, and use those? It doesn't delete directories recursively. unicorn:~$ mkdir -p /tmp/foo/bar unicorn:~$ touch /tmp/foo/bar/file unicorn:~$ find /tmp/foo -name bar -delete find: cannot delete ‘/tmp/foo/bar’: Directory not empty Understood. But I suppose you're asking "What if it deletes both the file and the directory, because they both qualify?" In that case, you should use the -depth option, so that it deletes the deepest items first. unicorn:~$ find /tmp/foo -depth -delete unicorn:~$ ls /tmp/foo ls: cannot access '/tmp/foo': No such file or directory Without -depth, it would try to delete the directory first, and that would fail because the directory's not empty. -depth must appear AFTER the pathnames, but BEFORE any other arguments such as -mtime or -name. Except that from the man page, -delete implies -depth. Maybe that's a GNUism; I don't know. And how precise are those times? If I'm running a cron job that deletes 7-day-old directories then creates a new one less than a second later, will that reliably get the stuff that's just turned 7 days old? The POSIX documentation describes it pretty well: -mtime n The primary shall evaluate as true if the file modification time subtracted from the initialization time, divided by 86400 (with any remainder discarded), is n. To qualify for -mtime +7, a file's age as calculated above must be at least 8 days. (+7 means more than 7. It does not mean 7 or more.) So 7 days and one second doesn't count as "more than 7 days"? It truncates the value to integer days before comparing? Ah, yes, I see that now under -atime. Confusing. Thanks for pushing me to investigate :-) It's not uncommon for the POSIX documentation of a command to be superior to the GNU documentation of that same command, especially a GNU man page. GNU info pages are often better, but GNU man pages tend to be lacking. Understood, thanks. Though it might be less correct where GNUisms exist. That leaves the question: When using -delete (and -depth), does the deletion of files within a directory update the mtime of that directory, thereby rendering the directory inelegible for deletion when it would have been before? Or is the mtime of that directory recorded before the contents are processed? I just did a quick test (using -mmin -1 instead), and it did delete the whole lot. So I'm still unclear why sometimes the top-level directory (or a directory within it) gets left behind. I've just noticed that one of the directories (not the one in $dir) contains a '@' symbol; I don't know if that affects it? I'm tempted to avoid the problem by only using find for the top-level directory, and exec'ing "rm -r(f)" on it. I'm sure you'll tell me there are problems with that, too :-) Apologies for the slow response - sometimes the depression kicks in and I don't get back to a problem for a while :-( Cheers, Richard
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
On 07.01.24 20:33, songbird wrote: i see you've solved your issue, but i just wanted to point out that it works and is ok for people who want to try it out. Says who?
Re: systemd-boot not asking password, not resuming from hibernate
On 07.01.24 18:07, David Wright wrote: On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials? I'm assuming that when you boot, you do get /one/ prompt for your passphrase, and not zero. If it doesn't ask /again/ after that, then I'd guess that it's storing something somewhere. Nope, there's absolutely none. It just boots straight into the system, just as I said. Hence, I literally named this topic "systemd-boot *not asking* password". If it wouldn't ask again, that would just be the as expected behavior you'll also get from Grub. It makes no sense to ask for every encrypted partition when the passphrase is the same. In the little I've read about this, I've come across a scheme where Grub writes an initrd file in memory and appends it to your main initrd(s) so that the kernel can read it later. I kinda doubt that, like a lot. Maybe update-initramfs does pull in information from the Grub config, but otherwise there's no indication to that. It does pass parameters you put into the /etc/default/grub to the Kernel though. For the installation, I just installed systemd-boot. Afterward I had to uncomment the timeout option in /boot/efi/loader/loader.conf so I would get the selection screen, but I didn't make any other modifications. So what exactly is missing? Adding to that, resume from hibernate doesn't seem to work. Resume is included in the options line in the /boot/efi/loader/entries files, it's also enabled in initramfs-tools, yet after powering on after hibernating, I'm not greeted with where I left off. I don't use hibernation. I close down desktops because I can remotely boot them, and I leave laptops running as they consume trivial power. Good for you, not my use case. PS: by any chance does anybody know if systemd-boot supports Argon2 KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's difficult to find the specific documentation on systemd-boot. You probably need to follow appropriate lists if you want to stay up to date. That's just how not to do things. Software should be well documented, otherwise it should be replaced by something that is. Systemd replaced SysV Init as a service starter because it was much easier to handle and not just a pile of historical garbage nobody understands anymore. The same should be kept for other systemd services.
Re: Possibly broken Grub or initrd after updates on Testing
On 04.01.24 19:49, Richard Rosner wrote:
On 04.01.24 19:02, David Wright wrote:
Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?
Cheers,
David.
Let's hope the mailing list let's this go through.
It did, but since it seems to have been malformed yet again, let's try
again.
Keep in mind, this is based on the assumption that your whole /
partition is LUKS encrypted (in my case now LUKS2). "root partition
UUID1" is the UUID that's shown in Disks or on the Grub screen for the
decryption password prompt. Now, I can't say for sure what
"root-partition-UUID2" is, but that's what seems to be symlinked to
/dev/dm-0 and with blkid, one of the entries will look like this:
/dev/mapper/luks-: UUID=""
BLOCK_SIZE="4096" TYPE="ext4"
So maybe it's just some kind of virtual UUID for the decrypted root
partition.
Adding to that, "root partition UUID1.1" is basically the same as
UUID1.1, just without dashes. So it's the same format as Grub shows for
the ususal bootup password prompt. Let's hope this time this is the
right one.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
insmod png
if background_image
/usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-UUID2>' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64 root=UUID=UUID2> ro quiet root=/dev/mapper/luks- splash
resume=/dev/mapper/luks-
echo 'Loading initial ramdisk ...'
Re: Possibly broken Grub or initrd after updates on Testing
On 07.01.24 18:07, David Wright wrote: I compared your new grub.cfg with mine (suitably decimated and edited) and the significant differences are very few; extra modules are loaded: cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256. Myset root='hd0,gpt5' is replaced by set root='cryptouuid/' and my --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5 is replaced by hint='cryptouuid/' Unlike the first version of grub.cfg that you pasted earlier: cryptomount -u set root='cryptouuid/ there's no cryptomount in your new one. I'm guessing that means that the LUKS2 partition has been decrypted by Grub before grub.cfg is commanded. Do you now get just the one prompt for the passphrase when you boot? (I'm not very familiar with how far encrypted /boot has progressed.) There was always only one prompt for the passphrase when boot was working on its own. Only if you had to manually decrypt all partitions, you'd need to enter it for every encrypted partition there is — probably because you don't necessarily need to have the same password for everything. There might be an option to have it reuse the key, but I have yet to find that. Also, that the cryptomount lines are missing must be why Grub was still a bit unreliable. I'll write my current grub.cfg in a separate message, as they are back now after some experiments with rEFInd, systemd-boot and trying to get resume from hibernation to work reliably. The other difference in the earlier, pasted grub.cfg is that its linux line was extremely long, and looked as though a large amount of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub? I commented previously on the multiple root= parameters, and have also noticed that the recovery mode lines had "single" duplicated. I presume all that configuration stuff has gone away now. Well, that bunch of text is necessary, since grub has to communicate the location of the root and the swap partitions to the kernel, so of course they are automatically included in the default/grub. The last one there is just a little fix for better handling very old Synaptic touchpads in Wayland. In my current grub.cfg the multiple root= entries in one line seem to be gone, but there are still multiple single in the recovery parts. I somehow doubt whether all this will be any help, as you're working well beyond my experience, and somewhere near the cutting edge of Grub. Just shows how hopelessly outdated Grub is and that it sorely needs a replacement — and a better experience in replacing it. Grub 2.12 was just released in December. On the other hand, LUKS was originally released in 2004, LUKS2 followed in 2018 and became the default with cryptsetup 2.1.0 in early 2019 — though Debian seems to ignore that, since the installer still by default creates LUKS1 volumes. Also, by default, LUKS2 uses Argon2 key derivation function — unsupported even by Grub 2.12. All this in a time when smartphones have been encrypted for years by default, so have MacBooks and even Windows is slowing making it a default. Not to mention the fact that Linux distributions are offering encryption in their installers for many years now, with a few even making it a default, like Pop.
systemd-boot not asking password, not resuming from hibernate
I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials? For the installation, I just installed systemd-boot. Afterward I had to uncomment the timeout option in /boot/efi/loader/loader.conf so I would get the selection screen, but I didn't make any other modifications. So what exactly is missing? Adding to that, resume from hibernate doesn't seem to work. Resume is included in the options line in the /boot/efi/loader/entries files, it's also enabled in initramfs-tools, yet after powering on after hibernating, I'm not greeted with where I left off. PS: by any chance does anybody know if systemd-boot supports Argon2 KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's difficult to find the specific documentation on systemd-boot.
Re: Possibly broken Grub or initrd after updates on Testing
On 04.01.24 19:02, David Wright wrote:
Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?
Cheers,
David.
Let's hope the mailing list let's this go through.
Keep in mind, this is based on the assumption that your whole /
partition is LUKS encrypted (in my case now LUKS2).
"root-partition-UUID" is the UUID that's shown in Disks or on the Grub
screen for the decryption password prompt. Now, I can't say for sure
what "root-partition-UUID2" is, but that's what seems to be symlinked to
/dev/dm-0 and with blkid, one of the entries will look like this:
/dev/mapper/luks-: UUID=""
BLOCK_SIZE="4096" TYPE="ext4"
So maybe it's just some kind of virtual UUID for the decrypted root
partition.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if loadfont unicode ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
insmod png
if background_image /boot/grub/.background_cache.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option
'gnulinux-simple-' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64
root=UUID= ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-' {
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-6.5.0-5-amd64-advanced-' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64
root=UUID= ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.5.0-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64 (recovery
mode)' --class debian --class gnu-linux
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Well, that was a bust. I accidentally didn't just format the EFI
partition, but deleted it. So I re-created it with the help of disks and
gparted (to leave the first 3 MB empty, I remeber that being a fix added
kinda recently to combat bad BIOS/EFI implementations, since Windows is
doing the same and nobody could come up with anything better.
Anyways, after installing rEFInd with no grub present, it would boot
into rEFInd, but that's it. No boot options, nothing under F2. Also, I
couldn't find anything helpful on the Arch Wiki page for this. In
theory, it should be as simple as refind-install. So the only reason I
could guess to be the reason would be that rEFInd might not be capable
of handling LUKS, which would be quite disappointing. Maybe I'll take a
look at systemd-boot in the next days, as I don't need any customization
anyways, and maybe it can handle encryption (or better decryption)
better than Grub — especially with LUKS2 grub seems a bit unreasonably slow.
On 04.01.24 11:56, Richard Rosner wrote:
Good to know that it should be possible. But as mentioned, these
symbols only offer me to boot from grub or fwupd. F2 also doesn't show
that much more, it merely gives me the option to boot into the BIOS
settings. Maybe I'll have to completely purge all Grub packages, wipe
the existing EFI partition and then try to install rEFInd. I'll have
to check.
On Thu, Jan 4, 2024, 09:29 Joel Roth wrote:
On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond
repair, I today
> tried to just replace it with rEFInd. Installation succeeded
without any
> trouble. But when I start my system, rEFInd just asks me if I
want to boot
> with fwupd or with the still very broken Grub. Am I missing
something? Is
> rEFInd really just something to select between different OSs
(and not just
> different distributions like Grub can very well do) and then
gives the rest
> over to their bootloaders or am I missing something so rEFInd
will take over
> all of Grubs jobs?
I boot my debian-based system with rEFInd. Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present.
rEFInd installs into EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.
> On 01.01.24 21:45, Richard Rosner wrote:
> >
> >
> > On 01.01.24 21:20, Richard Rosner wrote:
> > >
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived
anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how
to even do
> > > > > this, it might as well be a documentation for users
having such
> > > > > troubles in the future.
> > > > >
> > > > > Also, besides the way that I have no clue how it would
have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply
don't see
> > > > > anything wrong with it anyways. So I can't even look at
the grub
> > > > > settings files grub.cfg is being generated from to check
where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually
with into
> > > > /etc/grub.d/40_custom, observing the comments there, and
also into
> > > > grub.cfg itself at the appropriate place (near the
bottom). The
> > > > former is so that Grub includes it in any new grub.cfg
that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the
UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should
Grub have,
> > besides the fact that I can't even be entirely sure Grub is to
blame and
> > not something else.
--
Joel Roth
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
You should really re-read the FAQ that was sent in just two days ago... On January 4, 2024 11:58:28 AM GMT+01:00, Jeffrey Walton wrote: >On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner wrote: >> >> Wow, what a bunch of unhelpful comments. >> >> First, if it wasn't for Eddie recommending boot-repair, "broken beyond >> repair" in fact was the very fitting term. > >Here was Eddie's comment" I have had very good results using >"Boot-Repair" software to recover Grub difficulties." > >"Broken beyond repair" seems to be context dependent. And it seems to >depend on the user. > >> Second, have you maybe considered that I've already read the home page of >> rEFInd and came to the same conclusion? Besides the fact that the page is >> virtually unreadable - both from a visual and a content point of view - I >> have yet to find anything indicating what it is actually capable of and what >> not. Because as far as I can tell, it should be able to do what I want it to >> do. > >No. You did not state it. And you did not cite something you did not >understand. I think you are full of shit. > >> So please, if you don't have anything to add other than snarky remarks, just >> don't answer. > >You mean like: "So, since for whatever reason Grub seems to be broken >beyond repair"? > >Jeff >
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Good to know that it should be possible. But as mentioned, these symbols only offer me to boot from grub or fwupd. F2 also doesn't show that much more, it merely gives me the option to boot into the BIOS settings. Maybe I'll have to completely purge all Grub packages, wipe the existing EFI partition and then try to install rEFInd. I'll have to check. On Thu, Jan 4, 2024, 09:29 Joel Roth wrote: > On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote: > > So, since for whatever reason Grub seems to be broken beyond repair, I > today > > tried to just replace it with rEFInd. Installation succeeded without any > > trouble. But when I start my system, rEFInd just asks me if I want to > boot > > with fwupd or with the still very broken Grub. Am I missing something? Is > > rEFInd really just something to select between different OSs (and not > just > > different distributions like Grub can very well do) and then gives the > rest > > over to their bootloaders or am I missing something so rEFInd will take > over > > all of Grubs jobs? > > I boot my debian-based system with rEFInd. Grub is not > present. A couple big icons show on the boot screen. The > small print at the bottom mentions hit F2 for more options. > On my system, F2 offers a selection among all kernels > present. > > rEFInd installs into EFI/refind/ in the EFI partition. > I originally encountered it looking for something to > boot debian on a Intel Mac. It's been trouble-free. > > > > > > On 01.01.24 21:45, Richard Rosner wrote: > > > > > > > > > On 01.01.24 21:20, Richard Rosner wrote: > > > > > > > > On 01.01.24 20:30, David Wright wrote: > > > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: > > > > > > On 01.01.24 18:13, David Wright wrote: > > > > > > I can boot by hand, but since this is all archived anyways and > it's > > > > > > uneccessarily difficult to find some sort of guide how to even do > > > > > > this, it might as well be a documentation for users having such > > > > > > troubles in the future. > > > > > > > > > > > > Also, besides the way that I have no clue how it would have to > look > > > > > > like to set up a paragraph in the grub.cfg, I simply don't see > > > > > > anything wrong with it anyways. So I can't even look at the grub > > > > > > settings files grub.cfg is being generated from to check where > the > > > > > > error lies. > > > > > You append the commands that you used to boot manually with into > > > > > /etc/grub.d/40_custom, observing the comments there, and also into > > > > > grub.cfg itself at the appropriate place (near the bottom). The > > > > > former is so that Grub includes it in any new grub.cfg that you > > > > > create. > > > > Good to know. > > > Edit:, never mind. Tried that, it still booted straight to the UEFI > BIOS > > > menu after entering my password. At this point, I'm seriously > > > considering slapping rEFInd on it and pray that it picks up on > > > everything automatically and fix the situation. But so should Grub > have, > > > besides the fact that I can't even be entirely sure Grub is to blame > and > > > not something else. > > -- > Joel Roth > >
Re: Possibly broken Grub or initrd after updates on Testing
I have kept the referral to the old problem in the topic for a reason. Been there, done that. I'm not entirely sure how, but boot-repair was the only thing that was able to fix Grub. Before that I've reinstalled it countless times, thanks. But since this is very much not an answer to the question at hand, but to the original question - and as such an entirely different topic - I'm rewriting this to the old topic too. On Thu, Jan 4, 2024, 02:12 Jeffrey Walton wrote: > On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner > wrote: > > > > So, since for whatever reason Grub seems to be broken beyond repair, > > I seriously doubt this is the case. I'm guessing the problem lies > elsewhere. > > > I today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if I > want to boot with fwupd or with the still very broken Grub. Am I missing > something? Is rEFInd really just something to select between different OSs > (and not just different distributions like Grub can very well do) and then > gives the rest over to their bootloaders or am I missing something so > rEFInd will take over all of Grubs jobs? > > The rEFInd website is at <https://www.rodsbooks.com/refind/>. I'm > guessing you have not taken time to read about it based on your > questions. > > Jeff > >
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Wow, what a bunch of unhelpful comments. First, if it wasn't for Eddie recommending boot-repair, "broken beyond repair" in fact was the very fitting term. Second, have you maybe considered that I've already read the home page of rEFInd and came to the same conclusion? Besides the fact that the page is virtually unreadable - both from a visual and a content point of view - I have yet to find anything indicating what it is actually capable of and what not. Because as far as I can tell, it should be able to do what I want it to do. So please, if you don't have anything to add other than snarky remarks, just don't answer. On Thu, Jan 4, 2024, 02:12 Jeffrey Walton wrote: > On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner > wrote: > > > > So, since for whatever reason Grub seems to be broken beyond repair, > > I seriously doubt this is the case. I'm guessing the problem lies > elsewhere. > > > I today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if I > want to boot with fwupd or with the still very broken Grub. Am I missing > something? Is rEFInd really just something to select between different OSs > (and not just different distributions like Grub can very well do) and then > gives the rest over to their bootloaders or am I missing something so > rEFInd will take over all of Grubs jobs? > > The rEFInd website is at <https://www.rodsbooks.com/refind/>. I'm > guessing you have not taken time to read about it based on your > questions. > > Jeff > >
Re: Possibly broken Grub or initrd after updates on Testing
Thanks, this actually did the job. I don't know what it was, but my guess is it was the step "purge Grub before reinstalling it". PS: rewrote to the old subject, as this is clearly an answer to the original problem, as it doesn't have anything to do with replacing Grub all together. On 03.01.24 21:04, Eddie wrote: I have had very good results using "Boot-Repair" software to recover Grub difficulties. Eddie On 1/3/24 14:23, Richard Rosner wrote: So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. But when I start my system, rEFInd just asks me if I want to boot with fwupd or with the still very broken Grub. Am I missing something? Is rEFInd really just something to select between different OSs (and not just different distributions like Grub can very well do) and then gives the rest over to their bootloaders or am I missing something so rEFInd will take over all of Grubs jobs?
Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. But when I start my system, rEFInd just asks me if I want to boot with fwupd or with the still very broken Grub. Am I missing something? Is rEFInd really just something to select between different OSs (and not just different distributions like Grub can very well do) and then gives the rest over to their bootloaders or am I missing something so rEFInd will take over all of Grubs jobs? On 01.01.24 21:45, Richard Rosner wrote: On 01.01.24 21:20, Richard Rosner wrote: On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS menu after entering my password. At this point, I'm seriously considering slapping rEFInd on it and pray that it picks up on everything automatically and fix the situation. But so should Grub have, besides the fact that I can't even be entirely sure Grub is to blame and not something else.
Re: Possibly broken Grub or initrd after updates on Testing
On 01.01.24 21:20, Richard Rosner wrote: On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS menu after entering my password. At this point, I'm seriously considering slapping rEFInd on it and pray that it picks up on everything automatically and fix the situation. But so should Grub have, besides the fact that I can't even be entirely sure Grub is to blame and not something else.
Re: Possibly broken Grub or initrd after updates on Testing
On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4 The UUID of the first partition containing the EFI stuff is 3647-0C47, the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with ext4 as it seems - why does Debian still not default to creating LUKS2 by default anyways after 5 years?) and the swap partition has b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1). Because it could lock people out of their preexisting LUKS partitions. I meant when you use the automated installer and wipe the whole disk anyways. There wouldn't be any preexisting LUKS partitions left that could be broken. Or can there not be LUKS1 and LUKS2 at the same time in the event that e.g. the device with the system on is LUKS2 and another device just containing data was LUKS1? For me it looks like the grub.cfg has everything it needs to work. Why do your linux lines have two root= strings? No idea. I never really touched anything related to grub, besides the earlier mentioned tries to get some logs. Also, since it looks like there is no grub rescue mode installed (at least it's not being entered when it should) I did remove the comment in front of GRUB_DISABLE_RECOVER and set it to "false", just in case that for some reason it would default to true, thus not installing grub rescue. There's only one root in the /etc/default/grub.
Re: Possibly broken Grub or initrd after updates on Testing
I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4 The UUID of the first partition containing the EFI stuff is 3647-0C47, the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with ext4 as it seems - why does Debian still not default to creating LUKS2 by default anyways after 5 years?) and the swap partition has b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1). For me it looks like the grub.cfg has everything it needs to work. On 01.01.24 18:13, David Wright wrote: On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote: On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: Like this? └─sda6 8:60 406.2G 0 part └─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G 0 crypt /home That's groups of 8 4 4 4 12. Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid aren't available there? I thought you could boot by hand. Then all the UUIDs are available to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe them into a 40_custom paragraph in grub.cfg so you can boot easily. Then I would work on getting Grub to write its grub.cfg correctly. In the meantime, 40_custom would stay put. Cheers, David.
Re: Possibly broken Grub or initrd after updates on Testing
Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid aren't available there? On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: >Like this? > > └─sda6 8:60 406.2G 0 part >└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G 0 crypt > /home > >That's groups of 8 4 4 4 12. > >Cheers, >David. >
Re: Possibly broken Grub or initrd after updates on Testing
So, I found a way to manually mount luks partition in Grub and boot from it. What I did to get there: set root=(hd0,gpt2) cryptomount -a This gave me the unencrypted version of the root partition as (crypto1) set root=(crypto1) linux /vmlinuz root=/dev/mapper/luks-UUID initrd /initrd.img boot The problem only is to get the UUID format right. When you're asked to enter the decryption key in a normal boot, it's shown, but without any dashes. But the format must be the same eg Disks shows it. But sure if a Grub tool can show that, but worst case you'll be booted into a initrd BusyBox terminal where you can just look inside /dev/mapper and see the true path that needs to be entered. Question is, how do I repair the boot process so I don't have to boot by hand every time? On January 1, 2024 12:52:40 PM GMT+01:00, Richard Rosner wrote: >I do not see an answer to my questions.
Re: Possibly broken Grub or initrd after updates on Testing
I do not see an answer to my questions. > On Jan 1, 2024, at 11:52, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner): >> I'm not sure what you meant with "rescue mode", but I've reinstalled >> grub anyways. The log of it doesn't look good though. Quite a bunch >> of errors. The result also is the same. > > Please review the posts in the thread starting on Dec 21 2023 14:25:26 > UTC, > https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com > > -- > Michael Kjörling https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” >
Re: Possibly broken Grub or initrd after updates on Testing
I'm not sure what you meant with "rescue mode", but I've reinstalled grub anyways. The log of it doesn't look good though. Quite a bunch of errors. The result also is the same. https://pastes.io/nvmlsxghlm > On Jan 1, 2024, at 11:03, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1 Jan 2024 09:16 +0100, from rich...@rosner-online.de (Richard Rosner): >> could you please check if you received either of my two tries to get >> this answer through the mailing list? > > I did not. Maybe they are held for moderation due to size? > > Next time, you can check for yourself at either > https://lists.debian.org/debian-user/recent or at > https://lists.debian.org/debian-user/ under the "archives" heading. > There's also a search there. If a message is not in the archive after > one or two archive refreshes, it probably didn't make it through the > list for whatever reason there may be. > > -- > Michael Kjörling https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” >
Re: wegvallen / uitvallen van IPv6
On Fri, 29 Dec 2023 22:54:38 +0100 Geert Stappers wrote: > Verder is mijn inschatting dat het `ip6tables`, i.p.v. `iptables`, > moet zijn. Inderdaad, uit de losse pols neergeschreven, niet getest, maar zoals je zegt: ip6tables :-) -- richard lucassen http://contact.xaq.nl/
Re: Possibly broken Grub or initrd after updates on Testing
As far as I can tell, /boot and /boot/grub are the same filesystem. After all, I didn't really do anything custom. Just your default LUKS installation with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted swap on 3. I did make a video. Nothing that's not showing up always. For a fraction of a second it shows something about slot 0 open, that's it. > On Dec 29, 2023, at 20:37, Richard Rosner wrote: > > As far as I can tell, /boot and /boot/grub are the same filesystem. After > all, I didn't really do anything custom. Just your default LUKS installation > with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted > swap on 3. > > I did make a video. Nothing that's not showing up always. For a fraction of a > second it shows something about slot 0 open, that's it. > >> On Dec 29, 2023, at 20:13, Michael Kjörling <2695bd53d...@ewoof.net> wrote: >> >> On 29 Dec 2023 18:56 +0100, from rich...@rosner-online.de (Richard Rosner): >>> Hey, I have quite the strange issue. After updating a bunch of >>> packages today [1], mostly related to systemd, gstreamer and udev, >>> and restarting my device, it no longer boots. I have an encrypted >>> system. So I do get asked for my decryption password as usual, but a >>> few seconds later, instead of continuing to the Grub boot menu, my >>> device simply reboots to the BIOS menu. >> >> Sounds to me very much like GRUB is having trouble finding or reading >> critical files under /boot/grub, and gives up for that reason. But it >> _should_ stop, not reboot, if that's the case. >> >>> From what you describe, it sounds like you use a LUKS-encrypted /boot. >> Is that correct? Also, please confirm that the contents of /boot/grub >> are located on the same file system as the contents of /boot (that is, >> that /boot/grub is not on its own file system). >> >> You probably already know this, but the GRUB LUKS passphrase prompt is >> very early stage. >> >> Have you tried making a video recording of the screen from when you >> press Enter at the passphrase prompt, to when it reboots, and then go >> through that carefully (frame by frame)? Maybe GRUB _does_ print >> something indicating what the actual problem is, but it reboots so >> quickly after that that you don't have time to see it. A video might >> capture that fraction-of-a-second display (even if only partially) and >> help point you in the right direction. >> >> -- >> Michael Kjörling https://michael.kjorling.se >> “Remember when, on the Internet, nobody cared that you were a dog?” >>
Re: wegvallen / uitvallen van IPv6
On Fri, 29 Dec 2023 10:57:54 +0100 Geert Stappers wrote: > > Misschien dat je router advertisements op 546/udp niet accepteert? > > > > iptables -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT > > > > Ik roep maar wat hoor. > > Die aanvulling zou aanleiding moeten zijn > om het bericht (met kletskoek) niet te versturen. Lees het eens anders: dat je router advertisements op 546/udp niet accepteert? "je" is het onderwerp, "je router" is dat niet. 't Is wat onduidelijk inderdaad. Wellicht was diet beter geweest: dat je router-advertisements op 546/udp niet accepteert? Als je Linuxdoos achter een router die SLAAC doet die pakketten weggooit krijg je dit soort problemen. > } dat je router advertisements op 546/udp niet accepteert? > > Routers versturen router advertisements > en als routers router advertisements accepteren > dan is dat van andere routers. > > Momenteel weten we niet hoeveel devices router advertisements > doen op het netwerk waar IPv6 soms wegvalt. > > } iptables -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT > > [1] > [1] Wat een dwaalspoor, lijkt wel sabotage Nou nou Geert, gewoon niet handig opgeschreven mijnerzijds. -- richard lucassen http://contact.xaq.nl/
Possibly broken Grub or initrd after updates on Testing
Hey, I have quite the strange issue. After updating a bunch of packages today [1], mostly related to systemd, gstreamer and udev, and restarting my device, it no longer boots. I have an encrypted system. So I do get asked for my decryption password as usual, but a few seconds later, instead of continuing to the Grub boot menu, my device simply reboots to the BIOS menu. It's not the first time I ran into such an issue. I did once after manually updating initrd because Grub wouldn't offer to boot the 6.5.0-4 kernel because of malformed grub.cfg. The solution was kinda simple. Boot into a life system, mount the encrypted system according to [2], find out the guide was either outdated or not suitable for updating initrd, find a fix, recreate initrd again and done. Sadly, this time that solution won't help. Also I can't find any way to get a log of which troubles Grub runs into that it can't continue the boot process. I tried getting Grub to write logs to the system by modifying GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub by removing quite and splash and adding loglevel=7 (and update-grub), but nothing is written, probably because for some reason Grub can't really decrypt the system. So, how do I even find out what's wrong? I'm not familiar with the Grub cmd, I have no idea how to get it to tell me what's wrong to even start finding a solution. Anybody knows more? [1]: Start-Date: 2023-12-28 19:40:04 Upgrade: udev:amd64 (254.5-1, 255.2-2), acl:amd64 (2.3.1-3+b1, 2.3.1-4), wpasupplicant:amd64 (2:2.10-20, 2:2.10-21), libacl1:amd64 (2.1.1-3-61, 2.3.1-4), libarmadillo12:amd64 (1:12.6.4+dfsg-1, 1:12.6.7±dfsg-1), libpam-systemd:amd64 (254.5-1, 255.2-2), libp11-kit0:amd64 (0.25.3-2, 0.25.3-4), libp11-kit0:i386 (0.25.3-2.6.25.3-4), libsonic0:amd64 (0.2.0-12, 0.2.0-13), libinput10:amd64 (1.23.0-2, 1.23.0-2.1), libsystemd0:amd64 (254.5-1, 255.2-2), libsystend0:i386 (254.5-1. 255.2-2), pandoc-data:amd64 (3.0.1-3, 3.0.1-4), libudev-dev:amd64 (254.5-1, 255.2-2), systemd:amd64 (254.5-1, 255.2-2), libudev1:amd64 (254.5-1, 255.2-2), libudev1:i386 (254.5-1, 255-2-2), p11-kit-modules:amd64 (0.25.3-2, 0.25.3-4), python3-wxgtk4.0:amd64 (4.2.1+dfsg-2, 4.2.1-dfsg-3), gstreamer1.0-gtk3:amd64 (1.22.7-1, 1.22.8-3), gstreamer1.0-plugins-good:amd64 (1.22,7-1, 1-22-83-3), gstreamer1.0-plugins-good:i386 (1.22.7-1, 1.22.8-3), libcap-ng0:amd64 (0.8.3-3, 0.8.4-1), mdamd:amd64 (4.2+20231026-1, 4.2+20231121-1), libinput-tools:amd64 (1.23.0-2, 1.23.0-2.1), libsystemd-shared:amd64 (254.5-1, 255.2-2), libattr1:amd64 (1:2.5.1-4+b1, 1:2.5.1-5), cpio:amd64 (2.13+dfsg-7.1, 2.14+dfsg-1), gstreamer1.0-pulseaudio:amd64 (1:22.7-1, 1.22.8-3), libsystemd-dev:amd64 (254.5-1, 255.2-2), p11-kit:amd64 (0.25.3-2, 0.25.3-4), libinput-bin:amd64 (1.23.0-2, 1.23.0-2.1) End-Date: 2023-12-28 19:45:40 [2]: https://wiki.debian.org/GrubEFIReinstall
find question
Hi all, When using: find $dir -mtime +7 -delete Will that fail to delete higher directories, because the deletion of files updated the mtime? Or does it get all the mtimes first, and use those? And how precise are those times? If I'm running a cron job that deletes 7-day-old directories then creates a new one less than a second later, will that reliably get the stuff that's just turned 7 days old? Or will there be a race condition depending on how quickly cron starts the script, which could be different each time? Is there a better way to do this? Cheers, Richard
Re: is dit goed ? nameserver met netwerk device eraanvast?
On Fri, 29 Dec 2023 09:09:04 +0100 Gijs Hillenius wrote: > Ik zal avahi uitzetten, en zien wat dat doet. > > Echter, ik vermoed dat ik (hier) op een dood spoor rijd. Wat ik > eigenlijk wil oplossen is het geregeld wegvallen / uitvallen van IPv6. > Het eerste wat ik zag in logs is die avahi melding.. Misschien dat je router advertisements op 546/udp niet accepteert? iptables -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT Ik roep maar wat hoor. R. -- richard lucassen http://contact.xaq.nl/
Re: lists
On 21/12/23 11:55, Pocket wrote: On 12/20/23 17:37, gene heskett wrote: On 12/20/23 12:05, Pocket wrote: On 12/20/23 11:51, gene heskett wrote: On 12/20/23 08:30, Pocket wrote: If I get one bounce email I am banned, I will never get to even 10% as 2% and I am gone. That may be a side effect that your provider should address, or as suggested by others, change providers. Actually I can not change as the ISP has exclusive rights to the high speed internet in the area I reside in. No other providers are allowed. You could use an email provider that is not your ISP. Richard
Re: sid
On 28/11/23 04:52, Michael Thompson wrote: [lots of stuff] Quick question - are you subscribed to the list? I notice you've replied a couple of times to your own emails, but not to any of the people who've offered suggestions. It's probably a good idea to subscribe, or at least check the archives: https://lists.debian.org/debian-user/recent Secondly, you say: "I sent a big email a couple of days ago, which covered how you might work around that, but so far, it has not been fixed. By my reckoning, it's been 6 days now." Filing a bug may well be useful, but it should be done through the proper channels, not via a post on debian-user. https://www.debian.org/Bugs/Reporting Cheers, Richard
Re: Re: RTL8852 driver for Debian 11
I'm currently wrestling with Debian 12 for my Lenovo IdeaPad 7 laptop - after having the NIC function swimmingly with Ubuntu, Kali, LMDE, and Tails. Not only is wireless not seen - but it seems that the functionality of the DVD version leaves a LOT to be desired. The only place I found that had the driver required me to install more content from online (which I can't access, due to the laptop not having an Ethernet port, as well as no wireless). When one couples the above with the Debian site being horrible organized (seriously: it gives me the impression that people don't want you to use Debian), I cant help but think: for all of this talk about Debian being awesome, I am spending WAY too much time installing this - with very little to show for it! signature.asc Description: OpenPGP digital signature
Re: RTL8852 driver for Debian 11
Testing access to the message. I find the issue with Debian weird, as I was able to use this same computer (Lenovo IdeaPad I7, with a Realtek b52 controller) with Ubuntu, Kali, and Tails, without an issue! I hear that Debian is awesome when it comes to stability - but after spending over 8 hours trying to install it to my laptop, I'm beginning to question what constitutes as "awesome" in some people's eyes... I'm trying to learn about how to compile a driver (if I can find one for Debian 12) - if anyone can assist, that would be great! signature.asc Description: OpenPGP digital signature
Re: Default DNS lookup command?
On 31/10/23 16:27, Max Nikulin wrote: On 30/10/2023 14:03, Richard Hector wrote: On 24/10/23 06:01, Max Nikulin wrote: getent -s dns hosts zircon Ah, thanks. But I don't feel too bad about not finding that ... 'service' is not defined in that file, 'dns' doesn't occur, and searching for 'hosts' doesn't give anything useful either. I guess reading nsswitch.conf(5) is required. Do you mean that "hosts" entry in your /etc/nsswitch.conf lacks "dns"? Even systemd nss plugins recommend to keep it as a fallback. If you get no results then your resolver or DNS server may not be configured to resolve single-label names. Try some full name getent -s dns ahosts debian.org Sorry for the confusion (and delay) - I think I was referring to the getent man page, rather than the config file. Richard
Re: systemd service oddness with openvpn
On 12/11/23 04:47, Kamil Jońca wrote: Richard Hector writes: Hi all, I have a machine that runs as an openvpn server. It works fine; the VPN stays up. Are you sure? Have you client conneted and so on? Yes. I can ssh to the machines at the other end. However, after running for a while, I get these repeatedly in syslog: Nov 07 12:17:24 ovpn2 openvpn[213741]: Options error: In [CMD-LINE]:1: Error opening configuration file: opvn2.conf Here you have something like typo (opvn2c.conf - I would expect ovpn2.conf) Bingo - I was confused by the extra c, but that's not what you were referring to. The logrotate postrotate line has systemctl restart openvpn-server@opvn2 which is the source of the misspelling. So it's trying to restart the wrong service. To be honest, I haven't been very happy with the way the services get made up on the fly like that, only to fail ... it's bitten me in other ways before. Thank you very much :-) Richard
Re: systemd service oddness with openvpn
On 7/11/23 12:41, Richard Hector wrote: Hi all, I have a machine that runs as an openvpn server. It works fine; the VPN stays up. However, after running for a while, I get these repeatedly in syslog: I don't know if anyone's watching, but ... It appears that this happens when logrotate restarts openvpn. I just have "systemctl restart openvpn-server@ovpn2" in my postrotate section in the logrotate config. I've seen other people recommend using 'copytrucate' instead of restarting openvpn, and others suggesting that openvpn should be configured to log via syslog, or that it should just log to stdout, and init (systemd) can then capture it. I'm not sure what's the best option here - and I still don't know why restarting it causes this failure. Richard
Re: Request to Establish a Debian Mirror Server for Bangladeshi Users
On 8/11/23 17:10, Md Shehab wrote: Dear Debian Community, I hope this email finds you well. I am writing to propose the establishment of a Debian mirror server in Bangladesh I am confident that a Debian mirror server in Bangladesh would be a valuable resource for the local tech community I would like to request your support for this proposal. I am open to any suggestions or feedback you may have. I suggest starting by reading here: https://www.debian.org/mirror/ftpmirror Cheers, Richard
Re: systemd service oddness with openvpn
On 7/11/23 12:41, Richard Hector wrote: Hi all, I have a machine that runs as an openvpn server. It works fine; the VPN stays up. However, after running for a while, I get these repeatedly in syslog: I should also have mentioned - this is debian bookworm (12.2) Richard
systemd service oddness with openvpn
Hi all, I have a machine that runs as an openvpn server. It works fine; the VPN stays up. However, after running for a while, I get these repeatedly in syslog: Nov 07 12:17:24 ovpn2 openvpn[213741]: Options error: In [CMD-LINE]:1: Error opening configuration file: opvn2.conf Nov 07 12:17:24 ovpn2 openvpn[213741]: Use --help for more information. Nov 07 12:17:24 ovpn2 systemd[1]: openvpn-server@opvn2.service: Main process exited, code=exited, status=1/FAILURE Nov 07 12:17:24 ovpn2 systemd[1]: openvpn-server@opvn2.service: Failed with result 'exit-code'. Nov 07 12:17:24 ovpn2 systemd[1]: Failed to start openvpn-server@opvn2.service - OpenVPN service for opvn2. Nov 07 12:17:29 ovpn2 openvpn[213770]: Options error: In [CMD-LINE]:1: Error opening configuration file: opvn2.conf Nov 07 12:17:29 ovpn2 openvpn[213770]: Use --help for more information. Nov 07 12:17:29 ovpn2 systemd[1]: openvpn-server@opvn2.service: Main process exited, code=exited, status=1/FAILURE Nov 07 12:17:29 ovpn2 systemd[1]: openvpn-server@opvn2.service: Failed with result 'exit-code'. Nov 07 12:17:29 ovpn2 systemd[1]: Failed to start openvpn-server@opvn2.service - OpenVPN service for opvn2. This is the openvpn-server@.service: [Unit] Description=OpenVPN service for %I After=network-online.target Wants=network-online.target Documentation=man:openvpn(8) Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO [Service] Type=notify PrivateTmp=true WorkingDirectory=/etc/openvpn/server ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw ProtectSystem=true ProtectHome=true KillMode=process RestartSec=5s Restart=on-failure [Install] WantedBy=multi-user.target And this is my override.conf: [Service] ExecStart= ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --config %i.conf (because I want timestamps) As I say, the VPN is functioning, and systemctl status shows it's running. Why would it firstly think it needs starting, and secondly fail to do so? The config file /etc/openvpn/server/ovpn2.conf file which it "fails to open" hasn't gone away ... Any tips? Note the machine is quite low powered; it's an old HP thin client. But this is all it does, and it seems to perform adequately. Thanks, Richard
Re: Default DNS lookup command?
On 24/10/23 06:01, Max Nikulin wrote: On 22/10/2023 18:39, Richard Hector wrote: But not strictly a DNS lookup tool: richard@zircon:~$ getent hosts zircon 127.0.1.1 zircon.lan.walnut.gen.nz zircon That's from my /etc/hosts file, and overrides DNS. I didn't see an option in the manpage to ignore /etc/hosts. getent -s dns hosts zircon However /etc/resolv.conf may point to local systemd-resolved server or to dnsmasq started by NetworkManager and they read /etc/hosts by default. Ah, thanks. But I don't feel too bad about not finding that ... 'service' is not defined in that file, 'dns' doesn't occur, and searching for 'hosts' doesn't give anything useful either. I guess reading nsswitch.conf(5) is required. Thanks, Richard
Re: Default DNS lookup command?
On 22/10/23 04:56, Greg Wooledge wrote: On Sat, Oct 21, 2023 at 05:35:21PM +0200, Reiner Buehl wrote: is there a DNS lookup command that is installed by default on any Debian getent hosts NAME getent ahostsv4 NAME That said, you get much finer control from dedicated tools. That is a useful tool I should remember. But not strictly a DNS lookup tool: richard@zircon:~$ getent hosts zircon 127.0.1.1 zircon.lan.walnut.gen.nz zircon That's from my /etc/hosts file, and overrides DNS. I didn't see an option in the manpage to ignore /etc/hosts. I haven't found a way to get just DNS results, without pulling in extra software. Richard
Re: xinetd verwijderen
On Fri, 13 Oct 2023 16:55:18 +0200 Cecil Westerhof wrote: > > Ja, dat lijkt me wel. Debian 12 heeft standaard geen xinetd > > geïnstalleerd. > > Ben begonnen met 8, of 9 denk ik. Toen zat het er waarschijnlijk wel > in. Volgens mij zat het al in Debian Hamm ;-) -- richard lucassen http://contact.xaq.nl/
Re: Fresh install, Bookworm, XFCE keeps recreating directories
On 16/09/23 12:19, Curt Howland wrote: Good evening. Did a fresh install of Bookworm, installing desktop with XFCE. I'm not interested in having directories like "Public" and "Videos", but every time I delete them something recreates those directories. I can't find where these are set to be created, and re-re-re created. Is there a way to turn this off? Have a look at the output of "apt show xdg-user-dirs" - looks like you need to edit .config/user-dirs.dirs Cheers, Richard
Re: Fout tijdens apt upgrade
On Sat, 02 Sep 2023 17:53:51 +0200 Cecil Westerhof wrote: > > En wat is 'dit probleem' ook al weer? > > Je zou natuurlijk even naar mijn oorspronkelijke bericht kunnen > kijken, of mijn reactie op je andere reactie kunnen lezen. > Maar dit is mijn probleem: > Tijdens een apt upgrade krijg ik: > libdvd-pkg: Checking orig.tar integrity... > /usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK > libdvd-pkg: `apt-get check` failed, you may have broken > packages. Aborting... En wat zegt "apt -f install" nou? -- richard lucassen http://contact.xaq.nl/
Re: Fout tijdens apt upgrade
On Sat, 02 Sep 2023 15:17:23 +0200 Cecil Westerhof wrote: > Firefox is on hold. Die wil ik standaard niet upgraden, daar als je > die upgrade terwijl firefox nog draait firefox crasht. > Al tientallen keren 'apt upgrade' gedraaid met firefox on hold zonder > dit probleem te hebben. Ik weet niet beter dat als je een package "on hold" zet dat-ie dan bij een aanwezige update zegt dat-ie "kept back" is Niets aan de hand dus in dit geval. R. -- richard lucassen http://contact.xaq.nl/
Re: Fout tijdens apt upgrade
On Fri, 01 Sep 2023 22:17:34 +0200 Cecil Westerhof wrote: > > Wellicht een nieuwe dependency dat-ie wil installeren? Wat doet > > > > apt full-upgrade > > apt full-upgrade > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Calculating upgrade... Done > The following packages have been kept back: > firefox-esr > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. En een: apt install -f Of wat volgens mij ook wel werkt is: apt install firefox-esr Maar ik ben geen apt guru, anderen hebben wellicht een fraaiere oplossing -- richard lucassen http://contact.xaq.nl/
Re: Fout tijdens apt upgrade
On Fri, 01 Sep 2023 21:07:39 +0200 Cecil Westerhof wrote: > Tijdens een apt upgrade krijg ik: > libdvd-pkg: Checking orig.tar integrity... > /usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK > libdvd-pkg: `apt-get check` failed, you may have broken packages. > Aborting... > > Als ik dan doe: > apt-get check > > Dan krijg ik: > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > > En als ik doe: > apt upgrade > > Dan krijg ik: > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Calculating upgrade... Done > The following packages have been kept back: > firefox-esr > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > > Wat kan hier aan de hand zijn? > Is het iets om me zorgen over te maken? Wellicht een nieuwe dependency dat-ie wil installeren? Wat doet apt full-upgrade R. -- richard lucassen http://contact.xaq.nl/
Re: Waarom aparte boot-partitie ?
On Wed, 5 Jul 2023 15:08:24 +0200 Paul van der Vlis wrote: > Ik snap best dat een aparte /boot soms zinvol kan zijn, bijvoorbeeld > omdat je systeem verder encrypted is. Of omdat bepaalde hardware het > misschien vraagt. > > Maar wat is de verdere meerwaarde eigenlijk? Ik heb nog lilo systemen en met een aparte /boot en dan zag ik altijd dezelfde lilo.conf (/etc/lilo.conf is een symlink naar /boot/lilo.conf). Wel zo handig dat de ene versie niet de ander overschrijft als je eens een andere versie wilt draaien. Er zullen vast nog wel meer redenen zijn. Voor grub geldt denk ik wel hetzelfde, al ben ik geen grub guru -- richard lucassen http://contact.xaq.nl/
Re: debian-user-digest Digest V2023 #447
Is the list software blind to language _and_ spam? On 14/5/23 11:59, debian-user-digest-requ...@lists.debian.org wrote:
Re: how to change default nameserver?
On 11/04/23 15:17, gene heskett wrote: On 4/10/23 18:04, zithro wrote: So, I got curious about his claim : "that change to resolv.conf adding the search line [search hosts, nameserver] has been required since red hat 5.0 in 1998". (The bracket addition is mine) I'm not using RHEl-based systems a lot so I may be wrong, and there's not a lot of material left from the 1998 web, but the resolv.conf file *looks* identical in RHEL-based systems, at least nowadays. I quickly browsed a few RH help pages about resolv.conf, but couldn't find his claim. I then searched for "search hosts, nameserver" on search engines (-with- the quotes, to only get full-match results). Either I get no results or ... wait for it ... it *ONLY* gives me results where Gene posted ! So Gene, can you tell us where you read this ? In a man page from a good 20 years ago. I still have a copy of that original redhat 5.0 on a shelf above me, but not a floppy drive to read those disks with. Well, it's not in resolver(5) (which is for resolv.conf) on Red Hat 5.0.5. Richard
Re: how to change default nameserver?
On 11/04/23 15:17, gene heskett wrote: In a man page from a good 20 years ago. I still have a copy of that original redhat 5.0 on a shelf above me, but not a floppy drive to read those disks with. Downloading an iso ... :-) Richard
