On Wed, Mar 26, 2025 at 07:48:16AM -0500, Richard Owlett wrote:
> On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > [SNIP]
> >
> > I normally use "sudo -s", which is the closest sudo approximation to
> > the traditional behvior of "su" (before it was broken in buster).
> >
>
> I don't understand the
Greg (HE12025-03-27):
> I'm certain sudo has its use cases, but all I do personally is su to
> root and update and upgrade my stable Bookworm using apt, so I feel no
> need to complexify the issue with sudo.
The fallacy in here being assuming, without stating it and without
justifying it that sudo
>
> "sudo -i" is meant to approximate the behavior of "su -". Before buster,
> nobody would have used that on a Debian system. It's horrible. The
> fact that people are now embracing it as a norm is even worse.
>
Why horrible?
David Wright writes:
> host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$
> /bin/su --login
> Password:
> bullseye on /dev/sda5 toto05
> host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/program-1.2.3
> host 09:58:08 /somewhere/that/is/obnoxiously/long/progra
On Wed, Mar 26, 2025 at 02:55:11PM -, Greg wrote:
> On 2025-03-26, Richard Owlett wrote:
>
> >> If he hasn't noticed yet, I doubt it.
> >
> > I agree.
> > If I understand what people want to accomplish by using command-line
> > options, I would likely have gone to System->Log Out ... and the
On 21/03/2025 20:38, J wrote:
But i must mention that *this passage from Debian Wiki seems incorrect*
Bind mount various virtual filesystems:
# for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run;
do mount -B $i /mnt/$i; done
https://wiki.debian.org/GrubEFIReinstall#
On 20/03/2025 03:22, J wrote:
But before this oopsie deletion I have saved as a back-up at least
something from /boot folder, or maybe even everything.
Copy files from backup to /boot and to the EFI system partition
EFI/debian/BOOTX64.CSV
EFI/debian/fbx64.efi
EFI/debian/grub.cfg
EFI/debian
On 30/03/2025 12:32, George Kirkham wrote:
Now with Journalctl, is it still possible to connect the failed-to-boot
disk drive to another computer and read logs? How?
[...]
https://man.archlinux.org/man/journalctl.1.en
-D DIR, --directory=DIR
There is <https://manpages.debian.org/journal
On Sun, 30 Mar 2025 16:32:55 +1100
George Kirkham wrote:
> PS I am currently using Thunderbird to try out email threading. Are
> the any other good email clients that support email threading and are
> packaged in Debian?
If, as in this email, you have two separate queries, you might do
better (
Hi,
On Sun, Mar 30, 2025 at 04:32:55PM +1100, George Kirkham wrote:
> Now with Journalctl, is it still possible to connect the failed-to-boot disk
> drive to another computer and read logs? How?
You got an answer regarding reading systemd journal in another
directory, but…
For there to
On Sun, 30 Mar 2025 at 05:33, George Kirkham wrote:
> 'Back in the good old days' when logging was to text files. When a disk
> drive failed to boot, I could attach that disk drive to another computer
> as a secondary drive, and then mount and read the logs to see why it
>
On 30/3/25 20:50, David wrote:
On Sun, 30 Mar 2025 at 05:33, George Kirkham wrote:
'Back in the good old days' when logging was to text files. When a disk
drive failed to boot, I could attach that disk drive to another computer
as a secondary drive, and then mount and read the l
George Kirkham wrote:
[snip disk drive question]
> PS I am currently using Thunderbird to try out email threading. Are the
> any other good email clients that support email threading and are
> packaged in Debian?
I use mutt, command line MUA, excellent.
--
Chris Green
·
Hi,
'Back in the good old days' when logging was to text files. When a disk
drive failed to boot, I could attach that disk drive to another computer
as a secondary drive, and then mount and read the logs to see why it
could no longer boot. As well as to inspect other things.
Greg Wooledge wrote:
...
> Maybe. If you haven't created an /etc/default/su file, then something
> like this:
>
> $ su
> # adduser richard
>
> may fail. You could work around it in various ways (e.g. explicitly
> typing out /usr/sbin/adduser richard).
>
> My recommendation is to create a
Max Nikulin (HE12025-03-28):
> Approximately a decade ago I
> noticed that new entries were not added to some history file, I do not
> remember if it was .bash_history or for some other tool, but the owner of
> the file was root. It was the reason why I
o clarify why I suggested namely "sudo -i". It is
completely unrelated to e.g. PATH issues.
The context is live image boot. To recover installed system the user
needs root privileges to execute several commands. ~/.bashrc vs.
~/.profile difference is not significant.
sudo does not as
Thank you for the answer.
The problem was I accidentally removed the */boot *folder, WHILE trying to
back it up. So there were only *OS folders *and something was missing.
I figured out later that *kernels are also stored in /boot *and tried to
reinstall the kernel manually, but ran into a
On 2025-03-28, David Wright wrote:
>
> As end-users are the people that computers are built and run
> for, I don't know why you'd find people's use of the term
> "slightly pejorative". (I assume you aren't calling out me
> in particular.)
I was calling myself out, not you. You have always been he
On Wed, Mar 26, 2025 at 15:46:15 +0100, Nicolas George wrote:
> $ su
> # make install
>
> Whoopsie! The Makefile just pwned you.
That's a COMPLETELY separate discussion. Obviously I was referring to
software from reputable sources.
> $ make DESTDIR=/tmp/i install
> $ sud
On Thu 27 Mar 2025 at 22:14:03 (-0400), Michael Stone wrote:
> On Thu, Mar 27, 2025 at 08:29:50PM -0500, David Wright wrote:
> > Excellent, that solves the problem for those on old terminals or
> > lacking copy/paste. As for me, I'll continue to use /bin/su --login,
> > as I have for nigh on three
On Thu, Mar 27, 2025 at 08:29:50PM -0500, David Wright wrote:
Excellent, that solves the problem for those on old terminals or
lacking copy/paste. As for me, I'll continue to use /bin/su --login,
as I have for nigh on three decades, so that I land in my preferred,
consistent cwd, /root.
su -
do
On Thu 27 Mar 2025 at 17:05:56 (-), Greg wrote:
> On 2025-03-26, David Wright wrote:
> >
> > As posted earlier today, a file in sudoers.d/ makes trivial admin
> > tasks like monitoring and logging easier, particularly where the
> > programs concerned can cause damage if the wrong options are us
On Thu 27 Mar 2025 at 13:58:10 (-0400), Greg Wooledge wrote:
> On Thu, Mar 27, 2025 at 12:48:35 -0500, David Wright wrote:
> > It could be argued that it would be simple enough to communicate
> > the user's cwd to root, as a workaround, so that it didn't have to
> > be retyped.
>
> You know what d
On 2025-03-26, David Wright wrote:
>
> As posted earlier today, a file in sudoers.d/ makes trivial admin
> tasks like monitoring and logging easier, particularly where the
> programs concerned can cause damage if the wrong options are used.
I'm certain sudo has its use cases, but all I do persona
On Thu, Mar 27, 2025 at 12:48:35 -0500, David Wright wrote:
> It could be argued that it would be simple enough to communicate
> the user's cwd to root, as a workaround, so that it didn't have to
> be retyped.
You know what does that for you? sudo -s. Or su if you've configured
it with a one-lin
t 07:26:35 (-0400), Dan Ritter wrote:
>
> The Linux console has no cut/paste. The text or framebuffer
> console you get when you boot without having a GUI available? No
> cut/paste there. You can add one with another daemon.
Yes, I can't imagine anyone doing serious work at the console
without a tool like gpm, available ever since buzz (1.1).
Cheers,
David.
ication, server people like to do extremely weird stuff
> for remote management.
The Linux console has no cut/paste. The text or framebuffer
console you get when you boot without having a GUI available? No
cut/paste there. You can add one with another daemon.
Don't call things "crude" when they still work properly.
-dsr-
On 3/26/25 6:55 AM, Greg Wooledge wrote:
[SNIP]
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
I don't understand the reference to some "brokenness" of "su".
I've not closely followed this thread so I may
On Wed 26 Mar 2025 at 16:37:41 (-), Greg wrote:
> On 2025-03-26, Richard Owlett wrote:
> >
> > I assumed it was effectively the same as power down and then logging in
> > as root on power-up.
>
> It is. But it's unnecessary and dangerous to run your entire DE as root.
> Or maybe you log in t
Greg Wooledge (HE12025-03-26):
> This caused ALL KINDS of problems. People would do things like:
>
> $ su
> # apt update
> # apt install somepkg
>
> And the postinstall script for somepkg would fail because it couldn't
> find commands that are in /sbin or /usr/sbin, because those dir
So, in most cases* sudo -s* is better? Any downsides?
ср, 26 мар. 2025 г. в 16:10, Greg Wooledge :
> On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> > On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > > I normally use "sudo -s", which is the closest sudo approximation to
> > > the trad
On Wed, Mar 26, 2025 at 07:55:33AM -0400, Greg Wooledge wrote:
[...]
> I normally use "sudo -s", which is the closest sudo approximation to
> the traditional behvior of "su" (before it was broken in buster).
>
> "sudo -i" is meant to approximate the behavior of "su -". Before buster,
> nobody w
On 2025-03-26, Richard Owlett wrote:
>
> I assumed it was effectively the same as power down and then logging in
> as root on power-up.
It is. But it's unnecessary and dangerous to run your entire DE as root.
Or maybe you log in to the console and use startx to run Mate?
At any rate, I do follo
On 2025-03-26, Greg Wooledge wrote:
>>
>> Does this "brokenness" of "su" have any potential effect on my usage?
>
> Maybe. If you haven't created an /etc/default/su file, then something
> like this:
If he hasn't noticed yet, I doubt it.
I noticed when I finally erased Stretch and installed Boo
On 2025-03-26, Richard Owlett wrote:
>> If he hasn't noticed yet, I doubt it.
>
> I agree.
> If I understand what people want to accomplish by using command-line
> options, I would likely have gone to System->Log Out ... and then logged
> in as root.
Not recommended.
On Wed 26 Mar 2025 at 10:03:59 (-0500), Richard Owlett wrote:
> On 3/26/25 9:55 AM, Greg wrote:
> > On 2025-03-26, Richard Owlett wrote:
> >
> > > > If he hasn't noticed yet, I doubt it.
> > >
> > > I agree.
> > > If I understand what people want to accomplish by using command-line
> > > options
On Wed 26 Mar 2025 at 16:24:21 (+0300), J wrote:
> ср, 26 мар. 2025 г. в 16:10, Greg Wooledge :
> > On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> > > On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > > > I normally use "sudo -s", which is the closest sudo approximation to
> > > > the t
On 3/26/25 9:55 AM, Greg wrote:
On 2025-03-26, Richard Owlett wrote:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what people want to accomplish by using command-line
options, I would likely have gone to System->Log Out ... and then logged
in as root.
Not recommended.
On 3/26/25 9:04 AM, Greg wrote:
On 2025-03-26, Greg Wooledge wrote:
Does this "brokenness" of "su" have any potential effect on my usage?
Maybe. If you haven't created an /etc/default/su file, then something
like this:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what
On Wed, Mar 26, 2025 at 04:19:37PM +0300, J wrote:
> >
> > > work with* root?* I will try to test.
> >
> > I fully expect it to, yes.
> >
>
> Oh, yes, it works. I just had to use *sudo su* and not not
I think you never need "sudo su". "sudo -i" and "sudo -s" will do your
bidding, depending on you
>
> > work with* root?* I will try to test.
>
> I fully expect it to, yes.
>
Oh, yes, it works. I just had to use *sudo su* and not not
*su - *
Also it's bad that Wiki doesn't clarify* how to* 'boot the rescue system
including the kernel option "efi=runti
On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote:
> On 3/26/25 6:55 AM, Greg Wooledge wrote:
> > I normally use "sudo -s", which is the closest sudo approximation to
> > the traditional behvior of "su" (before it was broken in buster).
>
> I don't understand the reference to some "brok
On Wed, Mar 26, 2025 at 12:23:38 +0100, to...@tuxteam.de wrote:
> On Wed, Mar 26, 2025 at 02:15:03PM +0300, J wrote:
> > And i thought *sudo -i*, you speaking about, is something like
> > *--interactive*, which is not, how i see now...
>
> The long form is "--login", not interactive. But the "-i"
On Wed, Mar 26, 2025 at 02:15:03PM +0300, J wrote:
> > In my opinion, "sudo -i" might be added to the wiki articles. I would
> > prefer to see a warning concerning compound shell commands in *sudo* docs.
> >
> > J, my impressions is that you read some docs strongly suggesting to
> > prefix every co
> In my opinion, "sudo -i" might be added to the wiki articles. I would
> prefer to see a warning concerning compound shell commands in *sudo* docs.
>
> J, my impressions is that you read some docs strongly suggesting to
> prefix every command instead of just becoming root.
Actually it is easier
There were also some minor problems which I solved with *apt update/upgrade*
> while being in *chroot*.
>
In particular, there was for some reason no internet connection after I
booted to the restored system. Something wrong was with firmware and/or
initramfs i guess.
On 25/03/2025 19:47, J wrote:
Notice that the page suggests "# for i in /dev /dev/pts /proc "
so it is assumed that users should run
$ sudo -i
sudo *SH -c '...' -* as mentioned above. But it is not written in WIki.
In my opinion, "sudo -i" might be added to the wiki articles. I wo
On Wed, Mar 26, 2025 at 09:25:01AM +0700, Max Nikulin wrote:
> On 25/03/2025 19:47, J wrote:
> > Notice that the page suggests "# for i in /dev /dev/pts /proc "
> > so it is assumed that users should run
> >
> > $ sudo -i
> >
> > sudo *SH -c '...' -* as mentioned above. But it is not
OK, probably the bash script will run fine.
>
> > https://wiki.debian.org/GrubEFIReinstall#Using_the_rEFInd_rescue_media
>
> In the context of bind-mounts the link is confusing.
>
It's EFI Reinstall, not */boot *reinstall, my only problem is that
"# for i in /dev /dev/pts /pro
debian.org/GrubEFIReinstall#Using_the_rEFInd_rescue_media
In the context of bind-mounts the link is confusing. In some cases
rEFInd should be able to boot *installed* Linux in the case of troubles
system firmware, e.g. missed boot entry. No chroot is required for grub
reinstall. However you wrot
> sudo sh -c '...'
>
Didn't know such a thing. Wasn't mention in the wiki.
Have you considered doing something crazy like creating the mount points?
>
Can't say so. I have fixed my problem a few days ago (see above about
mounting), now i am discussing with Max if Wiki is correct.
https://wiki.d
I have rechecked.
It doesn't work with sudo also.
Not in a one line, not when i tried to make line breaks with \, not in a
bash script.
user@debian:~$ sudo for i in /dev /dev/pts /proc /sys
/sys/firmware/efi/efivars /run; do mount -B $i /mnt/$i; done
bash: syntax error near unexpected token `do'
I had to reinstall Windows 10 for one particular reason and Windows Boot
Loader wasn’t working quite right, so I have tried to fix it under Linux.
And accidently deleted the whole /boot folder …oops. As Linux /boot folder
was placed also in ESP folder, originally created by and for the Windows
it might be
> interesting. If not, sorry for the noise.
>
> Best
>
> Hans
>
> Am Mittwoch, 19. März 2025, 10:31:26 CET schrieb Dan Purgert:
> > On Mar 19, 2025, Hans wrote:
> > > Hi Geert,
> > >
> > > the desired goal is, that my origi
the noise.
Best
Hans
Am Mittwoch, 19. März 2025, 10:31:26 CET schrieb Dan Purgert:
> On Mar 19, 2025, Hans wrote:
> > Hi Geert,
> >
> > the desired goal is, that my original MAC will never appear after
> > boot. As dpkg-reconfigure macchanger claims this to do, in
Hi,
On Wed, Mar 19, 2025 at 04:34:48PM +0100, Hans wrote:
> Am Mittwoch, 19. März 2025, 16:24:15 CET schrieb Stefan Monnier:
> > >> Seems we've been through this before in 2022 (sorry that it's
> > >> Google Groups which I thought was defunct but anyway):
> > >> https://groups.google.com/g/linux.d
Am Mittwoch, 19. März 2025, 16:24:15 CET schrieb Stefan Monnier:
> >> > the desired goal is, that my original MAC will never appear after boot.
> >> > As
> >> > dpkg-reconfigure macchanger claims this to do, in real it does not.
> >>
> >> Se
>> > the desired goal is, that my original MAC will never appear after boot. As
>> > dpkg-reconfigure macchanger claims this to do, in real it does not.
>> Seems we've been through this before in 2022 (sorry that it's Google Groups
>> which I t
Am Mittwoch, 19. März 2025, 14:38:08 CET schrieb Greg:
> On 2025-03-19, Hans wrote:
> > Hi Geert,
> >
> > the desired goal is, that my original MAC will never appear after boot. As
> > dpkg-reconfigure macchanger claims this to do, in real it does not.
>
> See
On 2025-03-19, Hans wrote:
> Hi Geert,
>
> the desired goal is, that my original MAC will never appear after boot. As
> dpkg-reconfigure macchanger claims this to do, in real it does not.
>
Seems we've been through this before in 2022 (sorry that it's Google Groups
wh
On Mar 19, 2025, Hans wrote:
> Hi Geert,
>
> the desired goal is, that my original MAC will never appear after
> boot. As dpkg-reconfigure macchanger claims this to do, in real it
> does not.
Is this PC physically leaving your LAN? If not, changing the MAC isn't
going
Hi Geert,
the desired goal is, that my original MAC will never appear after boot. As
dpkg-reconfigure macchanger claims this to do, in real it does not.
My background thouhgts are: When using maachanger in TAILS, then it will never
protect the victim.
Of course, one can always write a script
On 2025-03-18, Geert Stappers wrote:
>> What did I miss, if any?
>
> Probably https://xyproblem.info
I believe the problem is that the mac address change that he implements
manually with macchanger doesn't survive a reboot of the system.
It seems you would have to configure /etc/default/maccha
On Tue, Mar 18, 2025 at 04:28:31PM +0100, Hans wrote:
> Hi folks,
>
> maybe I missed something,
> but during install I can chose, if macchanger will
> change the macaddress, whenever a network interface comes up.
>
> As this happens during boot, too, I wondered, why I
Hi folks,
maybe I missed something, but during install I can chose, if macchanger will
change the macaddress, whenever a network interface comes up.
As this happens during boot, too, I wondered, why I instead get still the
original macaddress.
Is this just a bug, or do I have to add extra
(on an ordinary
> > AMD64 desktop running xfce and lightDM).After the upgrade it no longer
> > boots into the GUI. I have to login and then run startx. Why? What's the
> > recommended way make it boot into the GUI?
>
> Perhaps check systemctl status display-manage
e
it boot into the GUI?
Another annoyance is that after booting and starting the X session, num lock is
on. It never used to be. How can this be fixed?
Check https://forum.xfce.org/viewtopic.php?id=17485
If that fixes it once but not every time, xfce has a list of commands to
run on startup.
longer boots
> into the GUI. I have to login and then run startx. Why? What's the
> recommended way make it boot into the GUI?
Perhaps check systemctl status display-manager.service
I ran : sudo systemctl status display-manager.service >out.txtbefore typing
startx.The cont
hat's the
> recommended way make it boot into the GUI?
Perhaps checksystemctl status display-manager.service
> Another annoyance is that after booting and starting the X session, num lock
> is on. It never used to be. How can this be fixed?
My desktops have always had this set i
"halbtaxabo-...@yahoo.com" writes:
> I upgraded from bookworm to trixie a couple of weeks ago (on an
> ordinary AMD64 desktop running xfce and lightDM).
> After the upgrade it no longer boots into the GUI. I have to login
> and then run startx. Why? What's the recommen
hat's the
> recommended way make it boot into the GUI? Another annoyance is that after
> booting and starting the X session, num lock is on. It never used to be.
> How can this be fixed?
Looks like X is not starting. What graphics hardware do you have? If it is a
NVidia card: Was t
I upgraded from bookworm to trixie a couple of weeks ago (on an ordinary AMD64
desktop running xfce and lightDM).After the upgrade it no longer boots into the
GUI. I have to login and then run startx. Why? What's the recommended way make
it boot into the GUI?
Another annoyance is that
Thank Wright! debian installer is netinst 12.8
since "ran successfully" can't be found in syslog, grub installation
must fail
but i didn't see any error msg during installation, it's rather dishonest
perhaps they hesitate whether to remove freebsd bootloader
i don't have time to debug for th
On Wed 12 Feb 2025 at 13:59:11 (+0800), hlyg wrote:
> i can't find "ran successfully" in entire syslog with editor's search
> function
That's because Grub wasn't installed in the MBR, hence explaining
why the FreeBSD loader wasn't touched.
> 2nd disk has 4 partitions, 2 for stretch and deb12, ins
Thank Wright!
i can't find "ran successfully" in entire syslog with editor's search
function
2nd disk has 4 partitions, 2 for stretch and deb12, installer seems to
parse their grub.cfg, making log very long
Feb 11 08:54:28 in-target: Creating config file /etc/default/grub with
new version^
On Wed 12 Feb 2025 at 08:33:57 (+0800), hlyg wrote:
> Thank Curley again! manually editing grub.cfg is amateur as it is
> auto-generated. but my stanza is simple, it's easy to add it if
> removed.
>
> if it were Windows, it would be much easier
>
> i examine syslog, among many lines probing each
Thank Curley again! manually editing grub.cfg is amateur as it is
auto-generated. but my stanza is simple, it's easy to add it if removed.
if it were Windows, it would be much easier
i examine syslog, among many lines probing each partition for OS, i
can't find how i specify installation targe
On Tue, 11 Feb 2025 21:44:58 +0800
hlyg wrote:
> Thank Curley, but i have solved on my own
Excellent.
>
> isn't installer syslog supposed to record my choice during
> installation?
Yes, and a couple other files in /var/log/installation.
>
> i let bios boot 2nd dis
Thank Curley, but i have solved on my own
isn't installer syslog supposed to record my choice during installation?
i let bios boot 2nd disk, which also has deb12, run update-grub
now it can boot newly-installed deb12 on 1st disk,
then follow stanza at
https://www.gnu.org/software/grub/m
rub-installer: Installing for x86_64-efi platform.
syslog:Dec 3 17:45:46 grub-installer: Installation finished. No error reported.
syslog:Dec 3 17:45:46 grub-installer: info: grub-install ran successfully
What you want to know is where exactly grub was installed. For grub to
boot both operating
up iucode-tool (2.3.1-3) ...^M
Feb 11 08:55:09 in-target: Setting up intel-microcode
(3.20240910.1~deb12u1) ...^M
Feb 11 08:55:09 in-target: intel-microcode: microcode will be updated at
next boot^M
Feb 11 08:55:09 in-target: Processing triggers for initramfs-tools
(0.142+deb12u1) ...^M
Feb 11 0
On 2/3/25 23:39, Automætic wrote:
Hi,
I'm configuring a new Debian installation on my workstation, with both the
/boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM conta
/tmp/initramfs/ to review main/cryptroot/crypttab, but it only contains
> an entry for lvm_crypt, boot_crypt is missing.
It seems the right way as initrd is loaded from /boot which is already
unencrypted. And this is why update-initramfs filters your /etc/crypttab
and puts only root fs in in
n on my workstation, with both
> > > the /boot partition and the root filesystem encrypted:
> > > - /dev/nvme0n1p1 -> /EFI
> > > - /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
> > > - /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes
&
On Tue, Feb 04, 2025 at 12:18:10AM -0800, Loren M. Lang wrote:
> On Mon, Feb 03, 2025 at 10:39:25PM +, Automætic wrote:
> > Hi,
> >
> > I'm configuring a new Debian installation on my workstation, with both the
> > /boot partition and the root filesystem
On Mon, Feb 03, 2025 at 10:39:25PM +, Automætic wrote:
> Hi,
>
> I'm configuring a new Debian installation on my workstation, with both the
> /boot partition and the root filesystem encrypted:
> - /dev/nvme0n1p1 -> /EFI
> - /dev/nvme0n1p2 -> LUKS2 (pbkdf2
Hello,
From what I understand, a year ago, grub2 upstream LUKS2 support was
still only initial and thus not complete:
https://savannah.gnu.org/bugs/?55093
So it still probably better to stick with LUKS1 for /boot for now
Hi,
I'm configuring a new Debian installation on my workstation, with both the
/boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes
T
On 2025-02-01 12:39, Andrew M.A. Cater wrote:
On Sat, Feb 01, 2025 at 10:07:49AM -0700, g...@extremeground.com wrote:
On 2025-02-01 09:29, g...@extremeground.com wrote:
BTW: the same happens with the previous kernel. Also, this is a
Debian/Buster server running on AMD64 hardware. I've fsck'd th
On Sat, Feb 01, 2025 at 10:07:49AM -0700, g...@extremeground.com wrote:
> On 2025-02-01 09:29, g...@extremeground.com wrote:
>
> BTW: the same happens with the previous kernel. Also, this is a
> Debian/Buster server running on AMD64 hardware. I've fsck'd the partition
> and it's fine.
>
> I reboo
On 2025-02-01 11:29, g...@extremeground.com wrote:
I get the message right after the boot sequence declares the / drive
clean. The subject message repeats 3 times then the system boot stops.
It still responds to the keyboard but there is no system to log into.
When I go into the system in a
On 2025-02-01 09:29, g...@extremeground.com wrote:
I get the message right after the boot sequence declares the / drive
clean. The subject message repeats 3 times then the system boot stops.
It still responds to the keyboard but there is no system to log into.
When I go into the system in a
I get the message right after the boot sequence declares the / drive
clean. The subject message repeats 3 times then the system boot stops.
It still responds to the keyboard but there is no system to log into.
When I go into the system in a chroot after booting with systemrescue, I
find that
On Sun 05 Jan 2025 at 17:17:32 (+0100), Nicolas George wrote:
> Anil F Duggirala (12025-01-05):
> > sudo mv /usr/lib/udev/rules.d/61-gdm.rules /usr/lib/udev/rules.d/61-
> > gdm.rules.bak
>
> Unrelated to the actual issue: IIRC you can achieve the same result of
> disabling a system udev rule by cr
Anil F Duggirala (12025-01-05):
> sudo mv /usr/lib/udev/rules.d/61-gdm.rules /usr/lib/udev/rules.d/61-
> gdm.rules.bak
Unrelated to the actual issue: IIRC you can achieve the same result of
disabling a system udev rule by creating an empty rule file in /etc with
the exact same name. It has the ben
x27; >
/etc/modprobe.d/nvidia-power-management.conf
5. apt remove xserver-xorg-video-intel. (gave me an error on one boot
(wifi?) but the error didn't come up in subsequent boots).
And finally I did:
6. sudo mv /usr/lib/udev/rules.d/61-gdm.rules /usr/lib/udev/rules.d/61-
gdm.rules.bak
I
On Sun, Jan 05, 2025 at 09:07:09AM -0500, Anil F Duggirala wrote:
> Thank you both for your instructions. I have followed the exact
> instructions as proposed by Oli and have managed to successfully
> install and load the nvidia driver.
>
> However, apparently I am now stuck in an X session instea
Thank you both for your instructions. I have followed the exact
instructions as proposed by Oli and have managed to successfully
install and load the nvidia driver.
However, apparently I am now stuck in an X session instead of the
Wayland session I had before.
I have followed the additional instr
Are you using Gnome or KDE? (or something else). I ask this as my KDE with the
packaged Nvidia 535 drivers is unable to run Wayland. So for now I use X11 with
KDE.
It is my understanding that KDE will work with Wayland when using the Nvidia
stable version 560.35.03 however this version has y
1 - 100 of 5739 matches
Mail list logo
