Re: su does not work anymore

[Rainer Dorsch]

Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
> On Vi, 01 mai 20, 22:32:58, Rainer Dorsch wrote:
> > Hello,
> > 
> > I had an accidential / in a
> > 
> > # chown -R install-user /xyz/dfak /
> > 
> > command. Changing the ownership / recursively is certainly not a good
> > idea.
> 
> Ugh. For such situations one should either have good backups or a
> reasonably fast and automated method of reinstalling the system.
> 
> See also http://taobackup.com
> 

Thanks for sharing the nice link, Andrei. Unfortunately, I took the novice 
approach on step 1 for the system files. I do not see any issues on the system 
anymore tough. To be on the saver side, I also did an "apt-get reinstall" of 
the relevant packages. I hope the next "apt-get dist-upgrade" will eliminate 
any so far hidden issues.

Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: su does not work anymore

[Sven Joachim]

On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:

> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
>> On Vi, 01 mai 20, 22:32:58, Rainer Dorsch wrote:
>> > Hello,
>> >
>> > I had an accidential / in a
>> >
>> > # chown -R install-user /xyz/dfak /
>> >
>> > command. Changing the ownership / recursively is certainly not a good
>> > idea.
>>
>> Ugh. For such situations one should either have good backups or a
>> reasonably fast and automated method of reinstalling the system.
>>
>> See also http://taobackup.com
>>
>
> Thanks for sharing the nice link, Andrei. Unfortunately, I took the novice
> approach on step 1 for the system files. I do not see any issues on the system
> anymore tough. To be on the saver side, I also did an "apt-get reinstall" of
> the relevant packages. I hope the next "apt-get dist-upgrade" will eliminate
> any so far hidden issues.

There will likely be a few problems left.  Reinstalling packages fixes
the owner and permissions of most ordinary files, but directories are
left alone, and some programs (especially daemons) might find themselves
unable to write where they are supposed to.

Cheers,
   Sven

Re: su does not work anymore

[The Wanderer]

On 2020-05-02 at 06:57, Sven Joachim wrote:

> On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:
> 
>> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:

>>> Ugh. For such situations one should either have good backups or
>>> a reasonably fast and automated method of reinstalling the
>>> system.
>>> 
>>> See also http://taobackup.com
>> 
>> Thanks for sharing the nice link, Andrei. Unfortunately, I took the
>> novice approach on step 1 for the system files. I do not see any
>> issues on the system anymore tough. To be on the saver side, I also
>> did an "apt-get reinstall" of the relevant packages. I hope the
>> next "apt-get dist-upgrade" will eliminate any so far hidden
>> issues.
> 
> There will likely be a few problems left.  Reinstalling packages
> fixes the owner and permissions of most ordinary files, but
> directories are left alone, and some programs (especially daemons)
> might find themselves unable to write where they are supposed to.

I had to fix my primary system from a more severe version of a similar
problem, a year or so ago; long story short, when I built the system I
put /var on a separate RAID array from the rest of the general install
(because, like /home, it's documented as needing potentially lots of
space so it didn't seem suited for the smaller-capacity SSD array), and
when that array died and the data-recovery service gave me my files back
they had passed the whole thing through a tool that assumes and applies
a generic Windows-filesystem permission set and mangles the filenames
into a form that uses only NTFS-legal characters.

It took me three-to-six months of painful, detailed effort, with
painstaking back-and-forth comparisons against a known-good system and
lots of manual scripting to redownload the /var/cache/apt/archives/
contents for verification, to be sure I had everything back together to
a sufficient degree. Even then, I'm still not sure things are 100%; just
yesterday, I found a trio of rarely-accessed files (under /home, and not
config files, fortunately) whose names still had underscores in place of
colons.

Manual recovery like this *can* be done, but I do not recommend
embarking upon it without very strong reason. (In my case, I needed to
fix the filenames and permissions of my entire /home partition anyway,
and that includes irreplaceable data measuring in terabytes and dating
in some cases as far back as the '90s. Proper external backup is now
very much on my radar.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: su does not work anymore

[Carl Fink]

On 5/2/20 7:19 AM, The Wanderer wrote:

Manual recovery like this *can* be done, but I do not recommend
embarking upon it without very strong reason. (In my case, I needed to
fix the filenames and permissions of my entire /home partition anyway,
and that includes irreplaceable data measuring in terabytes and dating
in some cases as far back as the '90s. Proper external backup is now
very much on my radar.)


Why not just reinstall the OS and copy the /home/username files into the
new /home partition? Reinstalling Debian is extremely easy.

--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: su does not work anymore

[The Wanderer]

On 2020-05-02 at 08:32, Carl Fink wrote:

> On 5/2/20 7:19 AM, The Wanderer wrote:
> 
>> Manual recovery like this *can* be done, but I do not recommend 
>> embarking upon it without very strong reason. (In my case, I needed
>> to fix the filenames and permissions of my entire /home partition
>> anyway, and that includes irreplaceable data measuring in terabytes
>> and dating in some cases as far back as the '90s. Proper external
>> backup is now very much on my radar.)
> 
> Why not just reinstall the OS and copy the /home/username files into
> the new /home partition? Reinstalling Debian is extremely easy.

For one thing, I have a fair few packages not necessarily installed
along with the OS, as well as some programs manually compiled and
installed et cetera; digging them all up and getting them back in place
would be a pain in its own right.

For another, I don't have the experience with reinstalling and not
losing data that way in order to trust the result. I've historically
always installed to new drives, and copied the data across from the old
ones. In this case, I didn't have a system to put either the old or the
new drives in with enough ports to hook all the drives up at once, and I
didn't want to risk installing over top and losing the undamaged
remnants of my system.

For a third, I'd have had to fix the /home permissions and filenames
regardless, because /home was on the same array as /var and had gone
through the same ownership-and-permissions metadata-lossy
filename-mangling recovery process.

What I ended up doing might be argued not to have been the most
objectively optimal option in hindsight, but it was what occurred to me
as making sense at the time, and it did end up working - and thereby
proving that (as I said) this type of recovery *can* be done, however
much I don't recommend embarking upon it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: su does not work anymore

[Gene Heskett]

On Saturday 02 May 2020 07:19:13 The Wanderer wrote:

> On 2020-05-02 at 06:57, Sven Joachim wrote:
> > On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:
> >> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
> >>> Ugh. For such situations one should either have good backups or
> >>> a reasonably fast and automated method of reinstalling the
> >>> system.
> >>>
> >>> See also http://taobackup.com
> >>
> >> Thanks for sharing the nice link, Andrei. Unfortunately, I took the
> >> novice approach on step 1 for the system files. I do not see any
> >> issues on the system anymore tough. To be on the saver side, I also
> >> did an "apt-get reinstall" of the relevant packages. I hope the
> >> next "apt-get dist-upgrade" will eliminate any so far hidden
> >> issues.
> >
> > There will likely be a few problems left.  Reinstalling packages
> > fixes the owner and permissions of most ordinary files, but
> > directories are left alone, and some programs (especially daemons)
> > might find themselves unable to write where they are supposed to.
>
> I had to fix my primary system from a more severe version of a similar
> problem, a year or so ago; long story short, when I built the system I
> put /var on a separate RAID array from the rest of the general install
> (because, like /home, it's documented as needing potentially lots of
> space so it didn't seem suited for the smaller-capacity SSD array),
> and when that array died and the data-recovery service gave me my
> files back they had passed the whole thing through a tool that assumes
> and applies a generic Windows-filesystem permission set and mangles
> the filenames into a form that uses only NTFS-legal characters.
>
> It took me three-to-six months of painful, detailed effort, with
> painstaking back-and-forth comparisons against a known-good system and
> lots of manual scripting to redownload the /var/cache/apt/archives/
> contents for verification, to be sure I had everything back together
> to a sufficient degree. Even then, I'm still not sure things are 100%;
> just yesterday, I found a trio of rarely-accessed files (under /home,
> and not config files, fortunately) whose names still had underscores
> in place of colons.
>
> Manual recovery like this *can* be done, but I do not recommend
> embarking upon it without very strong reason. (In my case, I needed to
> fix the filenames and permissions of my entire /home partition anyway,
> and that includes irreplaceable data measuring in terabytes and dating
> in some cases as far back as the '90s. Proper external backup is now
> very much on my radar.)

That leaves amanda, standing alone away from the crowd.  I've used it 
here for over 20 years now as a shorter term solution to getting 
anything back, provided I discover its missing in under 56 or so days.  
I don't use tapes but virtual tapes on a big HD, as real tapes aren't 
near as dependable.  60 of them on a 2T drive ATM.

Drives that aren't shut down don't fail, I have some with nearly 200,000 
spinning hours on them and as good as the day they were first spun up 
decades ago. The Amanda backup scheduler also does not do fulls on 
Friday, but juggles incrementles in an attempt to use about the same 
amount of media for each run. You setup the days of a runcycle and 
amanda juggles the backup levels around while absolutely doing a full on 
every entry in the disklist at least once per runcycle days. It keeps a 
database so it knows what is has and what vtape its in. But with vtapes, 
its not the time consuming sequential tape read to find what it needs as 
the vtape access is random & hundreds of times faster.

I could lose this main drive yet this morning, get in the pickup and run 
up to Staples and get a new drive, bring it back and install linuxcnc 
from the dvd, get that database from last nights backup with tar, 
install amanda, and by 5pm, have this machine back in the exact state it 
was in at this mornings 2AM backup.  Whats not to like?  Have cron run 
it in the wee hours every night and sleep well, knowing you have 
disaster recovery at hand right from your own keyboard.  I'm doing 5 
machines with it. The New York State Dept of Health is doing at least 40 
machines with it.  Cern uses it.  The list goes on.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

new installation unable to use

[The7up]

Hi Guys!

I need your help! I have just installed Debian 10.3 on my computer but is
unusable. In the beginning, everything is OK but when I hover over the
mouse on my name in the login screen it stopped for a second.
When I logged in, everything is OK again, until opening any application.
After that, the system became unusable, when a terminal opened, it is
difficult to write (slow and repeating letters). But, when I could start
*top*, the first item on the list is gnome-shell with 300+%.

I tried to google it, but no success.

Any suggestions?

Thanks in advance,
The7up



Mentes
a vírusoktól. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: /etc/default/keyboard not loaded at startup

[gwinship]

Thank both of you for your support. However, the dpkg-reconfigure method doesn 
not fix the issue. I will still have to run the
udevadm trigger --subsystem-match=input --action=change
command each time I enter a new session.
I am aware that in the config it says that the /etc/default/keyboard settings 
are applied. Nevertheless, each start-up I will have the US layout used on all 
applications and terminal emulators. I also checked whether the localectl might 
interfere, but running localectl status outputs

   System Locale: LANG=en_US.UTF-8
  LANGUAGE=en_US:en
   VC Keymap: uk
  X11 Layout: gb,de
   X11 Model: pc105
 X11 Options: grp:win_space_toggle
before executing the udev command.
I'd be very glad if there are any other suggestions on how to apply the 
configuration at startup without restarting the kernel input system each time.
Cheers,
Felix


-‐‐ Original Message ‐‐‐
On Tuesday, April 28, 2020 5:20 PM, David Wright  
wrote:

> On Sun 26 Apr 2020 at 10:00:37 (+0300), Andrei POPESCU wrote:
>
> > On Sb, 25 apr 20, 16:39:24, gwinship wrote:
> >
> > > I added following configuration to my /etc/default/keyboard
> >
> > Hint: you can use 'dpkg-reconfigure keyboard-configuration' to get a
> > text-mode wizard.
>
> I've found that odd things can happen if X is running when you use
> this command. I can only suppose it's to do with how the system
> switches between graphics and text modes. That's why I suggested
> booting into a text-only system.
>
> > > XKBMODEL="pc105"
> > > XKBLAYOUT="gb,de"
> > > XKBVARIANT=""
> > > XKBOPTIONS="grp:win_space_toggle"
> > > BACKSPACE="guess"
> > > however. This does not load at boot.
> >
> > What is "this" that doesn't load at boot? How do you check?
> > As per your Xorg.log below the configuration is applied.
> > [...]
> >
> > > The /var/log/Xorg.log is
> > > [ 268.781] () Option "xkb_model" "pc105"
> > > [ 268.781] () Option "xkb_layout" "gb,de"[ 268.781] (WW) Option 
> > > "xkb_variant" requires a string value
> > > [ 268.781] (**) Option "xkb_options" "grp:win_shift_toggle"
>
> All my /etc/default/keyboard files contain the line
> XKBVARIANT=""
> but I've never seen that warning. In fact, I have never seen the
> Option "xkb_variant" line reflected in the Xorg log, presumably
> because, on my systems, it's always empty. That goes for squeeze,
> wheezy, jessie, stretch and buster.
>
> What I expect to see from:
>
> XKBMODEL="pc105"
> XKBLAYOUT="us"
> XKBVARIANT=""
> XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
>
> BACKSPACE="guess"
>
> is, for two keyboards:
>
> (II) config/udev: Adding input device DELL DELL USB Keyboard 
> (/dev/input/event0)
> () DELL DELL USB Keyboard: Applying InputClass "libinput keyboard catchall"
> (II) Using input driver 'libinput' for 'DELL DELL USB Keyboard'
> (II) systemd-logind: got fd for /dev/input/event0 13:64 fd 31 paused 0
> () DELL DELL USB Keyboard: always reports core events() Option "Device" 
> "/dev/input/event0"
> () Option "_source" "server/udev"(II) event0 - DELL DELL USB Keyboard: is 
> tagged by udev as: Keyboard
> (II) event0 - DELL DELL USB Keyboard: device is a keyboard
> (II) event0 - DELL DELL USB Keyboard: device removed
> () Option "config_info" 
> "udev:/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:413C:2005.0001/input/input3/event0"
> (II) XINPUT: Adding extended input device "DELL DELL USB Keyboard" (type: 
> KEYBOARD, id 11)
> () Option "xkb_model" "pc105"() Option "xkb_layout" "us"
> () Option "xkb_options" "lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
>
> and:
>
> () Logitech K520: Applying InputClass "libinput keyboard catchall"
> (II) Using input driver 'libinput' for 'Logitech K520'
> (II) systemd-logind: returning pre-existing fd for /dev/input/event12 13:76
> () Logitech K520: always reports core events() Option "Device" 
> "/dev/input/event12"
> () Option "_source" "_driver/libinput"(II) libinput: Logitech K520: is a 
> virtual subdevice
> () Option "config_info" 
> "udev:/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.2/0003:046D:C52B.0005/0003:046D:2011.0007/input/input25/event12"
> (II) XINPUT: Adding extended input device "Logitech K520" (type: KEYBOARD, id 
> 17)
> () Option "xkb_model" "pc105"() Option "xkb_layout" "us"
> () Option "xkb_options" "lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
>
> Cheers,
> David.