Re: Migrate Stretch to New UEFI Build?

[deloptes]

Patrick Bartek wrote:

> Actually, if I've understood what I've read over the past two weeks,
> that's not correct.  You need a dedicated partition formatted in FAT32,
> marked ef00 partition-type with the "boot" flag enabled on it. Mounting
> that partition on /boot/efi (or somewhere else, depends on the distro)
> is a LInux thing.

I did not say you have to mount ext4 on /boot and on top of it the EFI, did
I?
Obviously if you configure your BIOS to use UEFI, it will not use legacy
boot, so ...

regards

Re: Looking for advice on tools (or libraries) for unsupervised, bulk symmetric encryption/decryption of files

[Stefan Pietsch]

On 11.01.19 22:45, Jonathan Dowland wrote:

> EncFS should not be used for any new file encryption project, IMHO.
> There was the following report in 2014:
> https://defuse.ca/audits/encfs.htm
> This is referenced in the NEWS file in the EncFS package
> https://salsa.debian.org/debian/encfs/blob/debian/sid/debian/NEWS
> 
> Both the report and the NEWS file are 5 years sold so I am not sure of
> its current status but I'd want to seek positive assurance.

See GitHub issue #314 that lists the open security issues in EncFS:
https://github.com/vgough/encfs/issues/314

Re: Slow boot

[Richard Hector]

On 12/01/19 4:47 PM, Richard Hector wrote:
> On 12/01/19 1:28 AM, David wrote:
>> Hi, I have no expertise in this, except to suggest that if I was
>> seeing your symptoms then I would investigate if the discussion
>> here might be relevant:
>> https://lists.debian.org/debian-devel/2018/12/msg00184.html
> 
> Interesting, thanks - I'm going to try 4.19 from backports, so that I
> can try the random.trust_cpu option mentioned in that thread.

Well - not as informative as I'd hoped - the new kernel doesn't have
that delay (well, there seems to be a 20s delay in a similar place), so
trying the random.trust_cpu option wasn't so useful. I did anyway, and
the 20s delay remained - but it's not really apparent during the boot,
so maybe I was wrong and user-mode processes have started by then.

I guess I'll just keep using the 4.19 kernel anyway ...

Richard



signature.asc
Description: OpenPGP digital signature

Re: Slow boot

[Richard Hector]

On 12/01/19 1:28 AM, David wrote:
> Hi, I have no expertise in this, except to suggest that if I was
> seeing your symptoms then I would investigate if the discussion
> here might be relevant:
> https://lists.debian.org/debian-devel/2018/12/msg00184.html

Interesting, thanks - I'm going to try 4.19 from backports, so that I
can try the random.trust_cpu option mentioned in that thread.

Richard



signature.asc
Description: OpenPGP digital signature

Re: Slow boot

[Richard Hector]

On 12/01/19 3:41 AM, Michael Stone wrote:
> On Fri, Jan 11, 2019 at 02:03:44PM +1300, Richard Hector wrote:
>> According to dmesg, this is where it appears to hang:
>>
>> [    2.717311] device-mapper: uevent: version 1.0.3
>> [    2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
>> initialised: dm-d
>> e...@redhat.com
>> [    2.978281] clocksource: Switched to clocksource tsc
>> [  121.459392] md: linear personality registered for level -1
>> [  121.460391] md: multipath personality registered for level -4
>> [  121.461444] md: raid0 personality registered for level 0
> 
> dmesg is the wrong tool for this, as it only shows kernel messages and
> the delay is probably not in the kernel. try "journalctl -b", which will
> show both kernel messages and other logs for the current boot.
> 

I think it is in the kernel, actually. Compare:

dmesg:

[2.655799] random: crng init done
[2.655828] random: 7 urandom warning(s) missed due to ratelimiting
[2.666315] md8: detected capacity change from 0 to 499965231104
[2.839576] device-mapper: uevent: version 1.0.3
[2.839664] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
initialised: dm-de...@redhat.com
[2.979835] clocksource: Switched to clocksource tsc
[  131.281666] PM: Starting manual resume from disk
[  131.281699] PM: Hibernation image partition 253:8 present
[  131.281699] PM: Looking for hibernation image.
[  131.281783] PM: Image not found (code -22)
[  131.281784] PM: Hibernation image not present or could not be loaded.
[  141.617008] EXT4-fs (md0): mounted filesystem with ordered data mode.
Opts: (null)
[  172.514409] ip_tables: (C) 2000-2006 Netfilter Core Team
[  172.556027] systemd[1]: systemd 232 running in system mode. (+PAM
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[  172.556181] systemd[1]: Detected architecture x86-64.

journalctl -b:

Jan 12 16:12:37 rh-khost1 kernel: random: crng init done
Jan 12 16:12:37 rh-khost1 kernel: random: 7 urandom warning(s) missed
due to ratelimiting
Jan 12 16:12:37 rh-khost1 kernel: md8: detected capacity change from 0
to 499965231104
Jan 12 16:12:37 rh-khost1 kernel: device-mapper: uevent: version 1.0.3
Jan 12 16:12:37 rh-khost1 kernel: device-mapper: ioctl: 4.35.0-ioctl
(2016-06-23) initialised: dm-de...@redhat.com
Jan 12 16:12:37 rh-khost1 kernel: clocksource: Switched to clocksource tsc
Jan 12 16:12:37 rh-khost1 kernel: PM: Starting manual resume from disk
Jan 12 16:12:37 rh-khost1 kernel: PM: Hibernation image partition 253:8
present
Jan 12 16:12:37 rh-khost1 kernel: PM: Looking for hibernation image.
Jan 12 16:12:37 rh-khost1 kernel: PM: Image not found (code -22)
Jan 12 16:12:37 rh-khost1 kernel: PM: Hibernation image not present or
could not be loaded.
Jan 12 16:12:37 rh-khost1 kernel: EXT4-fs (md0): mounted filesystem with
ordered data mode. Opts: (null)
Jan 12 16:12:37 rh-khost1 kernel: ip_tables: (C) 2000-2006 Netfilter
Core Team
Jan 12 16:12:37 rh-khost1 systemd[1]: systemd 232 running in system
mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS
Jan 12 16:12:37 rh-khost1 systemd[1]: Detected architecture x86-64.

So dmesg _does_ show systemd messages, systemd starts a couple of lines
later, and it then reads all the kernel messages and writes them out
with the same timestamp.

I did try systemd-analyze (blame and critical-path) earlier, but they
also showed that the delay wasn't on systemd's watch.

Thanks,

Richard



signature.asc
Description: OpenPGP digital signature

Re: Migrate Stretch to New UEFI Build?

[Michael Stone]

On Fri, Jan 11, 2019 at 04:56:07PM -0800, Patrick Bartek wrote:

On Fri, 11 Jan 2019 07:13:30 -0500 Michael Stone  wrote:

On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:
>Plus, I
>want to have a common-shared  /boot partition for possible future
>upgrades or expansions.

This is a really bad idea, and will cause far more trouble than it can
possibly save in the future. You do need one EFI partition per system,
and you can have different directories there for different OSs.



You misunderstood as I was too general in my post about partitioning.

I WILL have a dedicated EFI System Partition (ESP) formatted FAT32
marked with the "boot" flag AS WELL AS a dedicated partition with a
mount point of /boot  /boot/efi will be the mount point for the ESP. As
far as I've read UEFI booting firmware, etc. does not require this.
It's a Linux recommendation.  But I could be wrong: UEFI/GPT is new to
me.


I'm not really sure what you're trying to say here. Yes, the UEFI spec 
doesn't talk about where to put the efi partition in a linux system, 
because it isn't a linux spec. In theory you can put it anywhere or 
nowhere (it's not used in day-to-day operation at all). But, if you 
intend to put grub on it using the normal install process, it needs to 
be in /boot/efi or the install won't work. (By default it will be in 
/boot/efi/EFI/debian.) It is possible to manually put it somewhere else, 
or to use a directory other than debian. I'm not sure why you would 
decide to mount it elsewhere, as I can't see any benefit to doing so. 
Putting grub in a directory other than "EFI/debian" does allow for 
multiple OSs to have their own boot loaders which can be started from 
the UEFI boot menu. (E.g., you could have EFI/stretch, EFI/centos7, 
EFI/sid, etc.) In this case I would still keep the efi partition mounted 
on /boot/efi to reduce long-term confusion. I'd also add new directories 
instead of trying to keep multiple versions of debian from overwriting 
the debian directory.


In addition to the efi partition, where the boot loader goes, you also 
need a /boot partition where the kernel and the grub menu configuration 
go. (Actually, in most cases this does not need to be a separate 
partition, but you do need a /boot directory.) You talk about sharing 
the /boot partition and this is what I said was a really bad idea: have 
a separate /boot per install or you'll have multiple installs stomping 
on each other's boot configs.


Just about everything above can in theory be worked around or done 
differently, but you'll be way outside of what you can expect support 
for at that point.

Re: Migrate Stretch to New UEFI Build?

[Patrick Bartek]

On Fri, 11 Jan 2019 08:38:52 +0100
deloptes  wrote:

> Patrick Bartek wrote:
> 
> > 
> > Building a new UEFI system to supplant my "showing its age" 12 year old
> > non-UEFI, MBR-only system, and don't want to do a clean install of
> > Stretch.  Cloning drive and converting to GPT is out. I want only to
> > migrate the Stretch install out of the others there. Any links
> > or suggestions as to the best way to do this will be greatly
> > appreciated.
> > 
> > 
> > I have done this before, but only with a MBR system & drives. Plus, I
> > want to have a common-shared  /boot partition for possible future
> > upgrades or expansions.
> > 
> > Here's a general procedure gleaned from numerous sources, none which
> > individually covered exactly my circumstances. All the steps will take
> > place on the new UEFI system as root.
> > 
> > 
> > 1. Boot New System with 64-bit hybrid LiveCD since I already have I
> > one  . . . somewhere ;-) Check it booted into UEFI mode.
> > 
> > 2. Partition new drive appropriately in GPT and format
> > 
> > 3. Mount appropriate partitions of both drives
> > 
> > 4. Use rsync to copy contents of corresponsing partitions -- Old to New
> > 
> > 6. Edit fstab on migrated system: new UUIDs; add mount line for /boot
> > partition, etc. Copy contents of /boot directory to /boot partition.
> > Add efi directory to new /boot partition.
> > 
> > 7. chroot to system on new drive
> > 
> > 8. Install all necessary efi files, efi-grub especially, etc. (They are
> > not installed on old system.  MBR only, remember . . .)
> > 
> > 9. Create new system map, initrd image, etc., for each kernel. Install
> > grub
> > 
> > 10.  Shutdown, remove old drive.
> > 
> > 11. Boot. Hope it works. ;-)
> > 
> > 
> > Any caveats?  Glaring errors?  Suggestions?
> > 
> > Thanks
> > 
> > B  
> 
> there was a post yesterday that /boot/efi is dedicated partition formated in
> FAT32 while /boot may be ext4.

Actually, if I've understood what I've read over the past two weeks,
that's not correct.  You need a dedicated partition formatted in FAT32,
marked ef00 partition-type with the "boot" flag enabled on it. Mounting
that partition on /boot/efi (or somewhere else, depends on the distro)
is a LInux thing.

> I also plan to migrate to UEFI boot in Feb. :)

Best of luck.  I got the last two components of my new system today.
It's my Christmas present to me! No one gives me toys anymore.  So, I
buy them myself. ;-)

B

Re: Migrate Stretch to New UEFI Build?

[Patrick Bartek]

On Fri, 11 Jan 2019 07:13:30 -0500
Michael Stone  wrote:

> On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:
> >Plus, I
> >want to have a common-shared  /boot partition for possible future
> >upgrades or expansions.  
> 
> This is a really bad idea, and will cause far more trouble than it can 
> possibly save in the future. You do need one EFI partition per system, 
> and you can have different directories there for different OSs.
> 

You misunderstood as I was too general in my post about partitioning.

I WILL have a dedicated EFI System Partition (ESP) formatted FAT32
marked with the "boot" flag AS WELL AS a dedicated partition with a
mount point of /boot  /boot/efi will be the mount point for the ESP. As
far as I've read UEFI booting firmware, etc. does not require this.
It's a Linux recommendation.  But I could be wrong: UEFI/GPT is new to
me.

Thanks for the response.

B

Re: dumb question about SSL

[Roberto C . Sánchez]

On Fri, Jan 11, 2019 at 10:17:05PM +, mick crane wrote:
> I'm having a bit of bother with my home server thingy.
> does apache, roundcube, dovecot, cups.
> is buster.
> Is problem with roundcube communicating with dovecot or something. sending
> mail times out and the settings webpage isn't working whereas it was fine  a
> week ago.
> 
> It occurs to me I don't really understand how SSL works and if problem I
> have might be to do with that not understanding.
> You can make a self signed certificate, a public, private pair
> Apache says you can make one and Dovecot says you can make one.
> So are these SSL pairs separate things or one thing in one place that
> identifies the machine.
> What happens if connect to running apache  over encryption then connect to
> running dovecot over webmail with encryption, does it expect different keys
> ?
> I'm a bit confused about it.
> are the keys particular to the machine ? the domain ? the software ?
> 
> I dunno what I've done. I think I made some keys for apache the other day to
> see if I could get ssl working ( is just local so I don't really need it,
> but anyway ) but perhaps I made keys from dovecot documentation a year or so
> ago.
> 
> Perhaps there might be an issue that I changed my local domain from "local"
> to "home" in that time. Could that have anything to do with it ?
> 
There are so many variables involved here that it is difficult to guess
at what is going wrong.

Please post specific error messages that you are seeing, either in your
client applications or in the server logs.

> Should I delete all the ssl directories I can find to see if that helps ?
> 
That sounds rather extreme and seems likely to result in causing a
different set of problems.

I taught a class a little over two years ago specifically on SSL
certificate authority and server/client certificate creation and
deployment.  If you contact me off-list, I can email you the
documentation (I never got around to posting it online).  You might find
some useful things in there.

Regards,

-Roberto

-- 
Roberto C. Sánchez

dumb question about SSL

[mick crane]

I'm having a bit of bother with my home server thingy.
does apache, roundcube, dovecot, cups.
is buster.
Is problem with roundcube communicating with dovecot or something. 
sending mail times out and the settings webpage isn't working whereas it 
was fine  a week ago.


It occurs to me I don't really understand how SSL works and if problem I 
have might be to do with that not understanding.

You can make a self signed certificate, a public, private pair
Apache says you can make one and Dovecot says you can make one.
So are these SSL pairs separate things or one thing in one place that 
identifies the machine.
What happens if connect to running apache  over encryption then connect 
to running dovecot over webmail with encryption, does it expect 
different keys ?

I'm a bit confused about it.
are the keys particular to the machine ? the domain ? the software ?

I dunno what I've done. I think I made some keys for apache the other 
day to see if I could get ssl working ( is just local so I don't really 
need it, but anyway ) but perhaps I made keys from dovecot documentation 
a year or so ago.


Perhaps there might be an issue that I changed my local domain from 
"local" to "home" in that time. Could that have anything to do with it ?


Should I delete all the ssl directories I can find to see if that helps 
?


mick




--
Key ID4BFEBB31

Re: Setting a USB for multi usages

[Thomas Schmitt]

Hi,

MENGUAL Jean-Philippe wrote:
> My purpose is having a USB stick splitted in 2 parts:
> 1. MBR + partitions: a Debian installer from an ISO
> 2. A blank partition to install data or whatver
>
> While I know to "burn" an iso on a key via dd, how can I do to have a clean
> installer but using key for other usages?

Put the ISO onto the stick, completely deface its pseudo-GPT,
and use program fdisk to add one or more partitions.

The partition situation in a Debian ISO for x86 is not as nice
as it should/could be:

  $ /sbin/fdisk -lu debian-9.3.0-amd64-netinst.iso
  ...
  Device  Boot StartEnd Sectors  Size Id Type
  debian-9.3.0-amd64-netinst.iso1 *0 593919  593920  290M  0 Empty
  debian-9.3.0-amd64-netinst.iso2   3760   4591 832  416K ef EFI 
(FAT-12/1

Note the EFI partition 2 of type 0xef sitting inside partition 1 which
is of type 0x00.
Nevertheless fdisk will add partition 3 and 4 if you ask it to do so.


There are the data of a GPT, but it is not properly announced by a
protective MBR partition of type 0xee. The GPT shows the same overlapping
partitions, which are explicitely forbidden by the GPT specs.
Thus my advise to remove the GPT header block:

  dd if=/dev/zero bs=512 seek=1 count=1 conv=notrunc of=/dev/sdX

where /dev/sdX is the device file of your USB stick.
(Option conv=notrunc is just for the case your of= target is an .iso file
 and not a disk device file.)


On a USB stick, the GPT backup header will probably not be recognized
because it will be misplaced. But an overly smart partition editor might
still find it and propose to replace your MBR partition table by that
GPT.

To kill the backup GPT header, you need to compute the last 512-byte
block number n of the ISO (in case of the 9.3.0 ISO n is 593919):

  n=$(expr $(ls -l debian-9.3.0-amd64-netinst.iso | awk '{print $5}') / 512 - 1)

and zeroize that block:

  dd if=/dev/zero bs=512 seek=$n count=1 conv=notrunc of=/dev/sdX

After this, programs like gdisk will not try to overwrite the MBR
partition table by the GPT.


Have a nice day :)

Thomas

Re: Setting a USB for multi usages

[Joel Wirāmu Pauling]

If using Uefi installs you only need to have a vfat formated first
partition with a folder called efi and the appropriate efi
binary/substructure. You can use the rest of the disk as you like.

BIOS installers on the same can be achieved with syslinux in addition to
uefi. However I find that just having uefi seems to go better these days
(at least if installing onto recent hardware). Due to varying levels of
vendor write as around CSM (compatibility BIOS/system mode) breaking dual
BIOS/eufi media installers.

-Joel

On Sat., 12 Jan. 2019, 09:48 MENGUAL Jean-Philippe  Hi,
>
> My purpose is having a USB stick splitted in 2 parts:
> 1. MBR + partitions: a Debian installer from an ISO
> 2. A blank partition to install data or whatver
>
> While I know to "burn" an iso on a key via dd, how can I do to have a
> clean installer but using key for other usages?
>
> Thanks very much
>
> regards
>
> --
> [image: Logo Hypra] JEAN-PHILIPPE MENGUAL
> DIRECTEUR TECHNIQUE ET QUALITÉ
> 102, rue des poissonniers, 75018, Paris
> Tel : +331 84 73 06 61 <+33184730661> Mob : +336 76 34 93 37
> <+33676349337>
> jpmeng...@hypra.fr
> www.hypra.fr
> [image: Facebook Hypra]  [image:
> Twitter Hypra]  [image: Linkedin
> Jean-Philippe]
> 
>
>

Re: Slow boot

[Cindy-Sue Causey]

On 1/11/19, Dan Ritter  wrote:
> Cindy-Sue Causey wrote:
>> On 1/11/19, Dan Ritter  wrote:
>> >
>> > As an experiment -- try this:
>> >
>> > echo udev_log=\"err\" >> /etc/udev/udev.conf
>> >
>> > (Or, alternatively, edit /etc/udef/udev.conf and insert/change
>> > that as necessary.)
>>
>>
>> Manually editing sounds like a good route because mine says this when
>> you get there:
>>
>> # udevd is started in the initramfs, so when this file is modified the
>> # initramfs should be rebuilt.
>>
>> "[S]hould"... Sounds like some of that should/shall/will and must
>> (??) coming into play.
>
> Yes, it needs to be followed by running:
>
> # update-initramfs -k all -u
>
> or similar. Thanks for the catch!


You're welcome. It was a nice side bonus from lurking along from the
sidelines. Having read that, it occurred to me that it would be
interesting to:

1) Enter that change but don't update then monitor appropriate files
for short period of time.

2) Next update initramfs then monitor those files again.

3) DELETE that change but do NOT update initramfs then monitor same files again.

4) Lastly update initramfs over that deletion then monitor one last
time to see what, if anything, changes.

I'm a-suming it would possibly/likely turn out similar to how we
*must* run update-grub after making changes to /etc/grub.d... if we
would like to see our manual changes do anything useful, that is. :)

PS This is one of those cases that falls under a different thread...
that one (or more) about personalized tweaks under locations other
than /home/user. I'm imagining this kind of tweak possibly getting
zapped on the next upgrade that includes /etc/udef/udev.conf.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Looking for advice on tools (or libraries) for unsupervised, bulk symmetric encryption/decryption of files

[Jonathan Dowland]

On Wed, Jan 09, 2019 at 10:18:47PM -0500, Celejar wrote:

The standard encryption technology for linux is LUKS. It works on the
block device level, not the file level.


LUKS would be no good if the user wants to move/copy/share the encrypted
files, encrypted, elsewhere: they didn't say so explicitly but that's
the impression I got reading their message.


I believe that the most commonly used software for file level
encryption is EncFS. I haven't really used it much, and can't speak to
its long term stablity.


EncFS should not be used for any new file encryption project, IMHO.
There was the following report in 2014:
https://defuse.ca/audits/encfs.htm
This is referenced in the NEWS file in the EncFS package
https://salsa.debian.org/debian/encfs/blob/debian/sid/debian/NEWS

Both the report and the NEWS file are 5 years sold so I am not sure of
its current status but I'd want to seek positive assurance.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Setting a USB for multi usages

[MENGUAL Jean-Philippe]

Hi,

My purpose is having a USB stick splitted in 2 parts:
1. MBR + partitions: a Debian installer from an ISO
2. A blank partition to install data or whatver

While I know to "burn" an iso on a key via dd, how can I do to have a 
clean installer but using key for other usages?


Thanks very much

regards

--
signature_jp_2
Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra 
 Linkedin Jean-Philippe 

Re: Monitor process who is eat my entropy

[Andy Smith]

Hello,

On Fri, Jan 11, 2019 at 10:33:39PM +0300, Reco wrote:
> On Fri, Jan 11, 2019 at 08:28:18PM +0100, basti wrote:
> > is there a way to monitor processes that access /dev/urandom
> 
> auditctl -w /dev/urandom -r
> 
> remove it with
> 
> auditctl -D

Note also that one should not really be concerned with reads from
urandom because this does not deplete the entropy pool, i.e. urandom
is inexhaustible.

/dev/random is the one which blocks, but I should think that reading
directly from either device is now deprecated in favour of system
calls, which are not going to open and read a device file. So
tracing that will not provide what is ultimately wanted, though it
does satisfy the letter of the request.

I think getrandom is supposed to be used these days:

https://manpages.debian.org/stretch/manpages-dev/getrandom.2.en.html

So indeed as you suggest, a different kind of tracing like BPF will
be more appropriate. That's beyond me at that point, though.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Monitor process who is eat my entropy

[Reco]

On Fri, Jan 11, 2019 at 08:28:18PM +0100, basti wrote:
> Hello,
> 
> is there a way to monitor processes that access /dev/urandom

auditctl -w /dev/urandom -r

remove it with

auditctl -D

> and show how may entropy the get?

You'll probably need some advanced kernel-level tracing facility (such
as BPF) for that.

Reco

Monitor process who is eat my entropy

[basti]

Hello,

is there a way to monitor processes that access /dev/urandom and show
how may entropy the get?

I have try lsof /dev/urandom without luck.

Best regards,

Can't disable touchpad while typing (Wayland)

[Hank Barta]

Hi all, I'm inclined to file a bug for this but before I do the
reportbug GUI suggests I contact the list. I'm running Debian Buster
on a Dell XPS 13 9370 and using Gnome on Wayland.
I've checked 'Disable While Typing' in Tweaks -> Keyboard & Mouse ->
Touchpad and also confirmed with
hbarta@rocinante:~$ gsettings get
org.gnome.desktop.peripherals.touchpad disable-while-typing true
hbarta@rocinante:~$
I've also verified the setting using the dconf editor.
I'm not sure if this is a bug in libinput, gnome-settings, gnome-shell
or some other part of the desktop.
How should I proceed in order to have the best chance to get this resolved.
I've searched for an existing bug but did not find one (and I don't
think I'm very good at that.)
Thanks!

-- 
'03 BMW F650CS - hers
'98 Dakar K12RS - "BABY K" grew up.
'93 R100R w/ Velorex 700 (MBD starts...)
'95 Miata - "OUR LC"
polish visor: apply squashed bugs, rinse, repeat
Beautiful Sunny Winfield, Illinois

Re: Slow boot

[deloptes]

David wrote:

> Hi, I have no expertise in this, except to suggest that if I was
> seeing your symptoms then I would investigate if the discussion
> here might be relevant:
> https://lists.debian.org/debian-devel/2018/12/msg00184.html

Good story - thanks and no comments!

Re: Why choose Debian on server

[francis picabia]

Both Debian and CentOS are good choices for a server OS.
We use both in my workplace.  We don't install a desktop.
It is not required and it is a waste of resources.

Debian is a good fit for developers, as there
is a great breadth of packages, and often more recent.

CentOS is easier to manage as an Apache server - the way
Debian does it with dozens of little files to enable is harder for
someone with Redhat background to master.

The bonus with CentOS/Redhat is long support lifecycle.  You can
install it and keep it running for up to 10 years, with updates.
Debian does not do that, however it provides for good upgrade
support in situ, and this is generally safe to do with relatively
little downtime.

The downside of CentOS/Redhat is the packages like open source DB
or PHP will be older than what many applications want, and you'll need
to work with 3rd party repositories such as Webtatic to get the versions
you want.  That's fine, except it introduces a new variable.  We've run
into a situation where we want to install a new server identical to
the production version and the repository no longer carries the version
of PHP it once did.  It's free, so there are no guarantees they want
to continue patching older versions for security issues, backports, etc.
On the other hand, Redhat has people who are paid to do the backports,
so even with older PHP it is being maintained, and that gets passed on to
CentOS packages.

To get into a specific, CentOS 7.5 provides php 5.4 currently, which is
fairly old,
while the current release of Debian 9.6 provides php 7.0.

We generally gravitate to CentOS when the application is relatively boring
like a CMS that is widely used.  When the application requires exotic
packages
that are not available in CentOS, like a bunch of perl modules (e.g.
netdisco)
then we tend to go with Debian.  The reasoning is we want the whole thing
updated for security without after thoughts, and stuff installed by cpan
under CentOS will be installed once and forgotten.

In my mind it is all about best fit for the job.  You try not to carry
a bias into the selection just so you can slap more stickers onto
servers.


On Wed, Jan 2, 2019 at 6:51 AM Alessandro Baggi 
wrote:

> Hi list,
> I'm new to this list and I'm choosing the right distribution for server
> needs. I hope that I'm not OT and don't want start a flame. I'm
> evaluating the possibility to switch on debian so I hope you will give
> your experiences about this topic.
>
> At the moment I'm using CentOS 7 on server and workstation but very old
> software, add third repos for get some software, use unmaintained
> software where patchs are released by dev distro team, big changes
> between a current release and next release, big corporation piloted
> distro, waiting that rh release a security patches and then recompiled
> on centos, problem on new hardware, unable to install new software from
> source due to old libs get me bored, and frustated in the last year. I
> like flexibility and I noticed that centos chains my knowledge.
>
> Today seems that RH Family is the standard and rh is more supported by
> software vendors. Considering 10 years of support, Selinux working out
> of the box, stability, enteprise class and free distro..user choose
> Centos with the perception that things work better because all is
> "followed" by a corporation. With this assumption users feel more secure
> and unfailing.
>
> This is not necessarely true. I think that is the sysadmin that make
> things safer, secure and unfailing. Sure that a stable and reliable OS
> take his part but when big blue take this game I'm not so sure about
> centos future. What if someone will choose to drop centos project? Maybe
> this is premature but from this "Why not choose a stable and community
> piloted distro where user needs are first purpose?"
>
> I used Debian in the past on several server for a big company without
> any problems but now are several years that I use centos on server and
> workstation and today I lost my debian knowledge about stability on
> server usage.
>
> Why you choose debian on server? Where for you it is better than centos
> and other server distro?
>
> Thanks in advance.
> Alessandro.
>
>

Re: kernel "unsigned" in sid

[Michael Stone]

On Fri, Jan 11, 2019 at 09:55:45AM +0100, dot...@gmail.com wrote:

I recently came across an inconsistency in sid that it seems difficult (to me)
to overcome.

A kernel package named linux-image-4.19.0-1-amd64-unsigned provides the running
kernel but, since few days ago, it creates conflicts with the metapackage
linux-image-amd64 (bercause it depends on linux-image-4.19.0-1-amd which, in
turn, conflicts with the installed kernel).

I can't trivially replace the "unsigned" (BTW, what does "unsigned" stand for,
anyway?) version with linux-image-4.19.0-1-amd because of the same version
number.

I'm not really worried because this will probably be solved when moving to the
next kernel release but the situation is a bit annoying.

Is there any solution?


How did you get the unsigned kernel installed in the first place? It's 
not typically installed, and I don't see any dependencies that would pull 
it in. If it weren't installed there'd be no problem. :) If you have 
another kernel already installed, boot into that, then replace the 
unsigned kernel with the corresponding kernel that lacks the -unsigned 
suffix. If you don't have another kernel installed, try installing an 
older one or (as you suggested) wait for the next one. In theory you 
should be able to just remove the -unsigned and replace it without 
having another kernel available, but it's better to have an alternative 
in case something goes wrong.


-unsigned means that the kernel doesn't come with a signature that can 
be used for secure boot. It's part of the build process for the signed 
kernels, is a reproducible build, and may have other special-purpose 
applications, but it is not generally needed.

Re: Slow boot

[Michael Stone]

On Fri, Jan 11, 2019 at 02:03:44PM +1300, Richard Hector wrote:

According to dmesg, this is where it appears to hang:

[2.717311] device-mapper: uevent: version 1.0.3
[2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
initialised: dm-d
e...@redhat.com
[2.978281] clocksource: Switched to clocksource tsc
[  121.459392] md: linear personality registered for level -1
[  121.460391] md: multipath personality registered for level -4
[  121.461444] md: raid0 personality registered for level 0


dmesg is the wrong tool for this, as it only shows kernel messages and 
the delay is probably not in the kernel. try "journalctl -b", which will 
show both kernel messages and other logs for the current boot.

Re: Failure to boot - LVM problems?

[Michael Stone]

On Fri, Jan 11, 2019 at 03:16:37PM +1300, Richard Hector wrote:

It turns out the later failures to boot probably weren't; it's just that
I had 'quiet' enabled in the kernel commandline. Disabling that enabled
me to see where it was hanging 


Yeah, I hate that "quiet" is the default--in the best case it's 
pointless, in the worst case it gets in the way.

Re: Slow boot

[Dan Ritter]

Cindy-Sue Causey wrote: 
> On 1/11/19, Dan Ritter  wrote:
> > Richard Hector wrote:
> >> Hi all,
> >>
> >> This machine is taking ages to boot.
> >>
> >> It's a fresh install.
> >>
> >> According to dmesg, this is where it appears to hang:
> >>
> >> [2.717311] device-mapper: uevent: version 1.0.3
> >> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
> >> initialised: dm-d
> >> e...@redhat.com
> >> [2.978281] clocksource: Switched to clocksource tsc
> >> [  121.459392] md: linear personality registered for level -1
> >> [  121.460391] md: multipath personality registered for level -4
> >> [  121.461444] md: raid0 personality registered for level 0
> >>
> >> I have started wondering recently about the hardware - could I have a
> >> clock problem?
> >>
> >> None of the other 'clocksource' entries have a similar lag, and there's
> >> no similar lag at that point on my desktop.
> >>
> >> Do I need to provide more context, or do more diagnostics?
> >>
> >
> > As an experiment -- try this:
> >
> > echo udev_log=\"err\" >> /etc/udev/udev.conf
> >
> > (Or, alternatively, edit /etc/udef/udev.conf and insert/change
> > that as necessary.)
> 
> 
> Manually editing sounds like a good route because mine says this when
> you get there:
> 
> # udevd is started in the initramfs, so when this file is modified the
> # initramfs should be rebuilt.
> 
> "[S]hould"... Sounds like some of that should/shall/will and must
> (??) coming into play.

Yes, it needs to be followed by running:

# update-initramfs -k all -u

or similar. Thanks for the catch!

-dsr-

Re: Slow boot

[David]

On Fri, 11 Jan 2019 at 12:04, Richard Hector  wrote:
>
> This machine is taking ages to boot.

You could also try the 'systemd-analyze blame' tool.

Re: Slow boot

[David]

On Fri, 11 Jan 2019 at 12:04, Richard Hector  wrote:
>
> Hi all,
>
> This machine is taking ages to boot.
>
> It's a fresh install.
>
> According to dmesg, this is where it appears to hang:
>
> [2.717311] device-mapper: uevent: version 1.0.3
> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
> initialised: dm-d
> e...@redhat.com
> [2.978281] clocksource: Switched to clocksource tsc
> [  121.459392] md: linear personality registered for level -1
> [  121.460391] md: multipath personality registered for level -4
> [  121.461444] md: raid0 personality registered for level 0

Hi, I have no expertise in this, except to suggest that if I was
seeing your symptoms then I would investigate if the discussion
here might be relevant:
https://lists.debian.org/debian-devel/2018/12/msg00184.html

Re: Migrate Stretch to New UEFI Build?

[Michael Stone]

On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:

Plus, I
want to have a common-shared  /boot partition for possible future
upgrades or expansions.


This is a really bad idea, and will cause far more trouble than it can 
possibly save in the future. You do need one EFI partition per system, 
and you can have different directories there for different OSs.

Re: Slow boot

[Cindy-Sue Causey]

On 1/11/19, Dan Ritter  wrote:
> Richard Hector wrote:
>> Hi all,
>>
>> This machine is taking ages to boot.
>>
>> It's a fresh install.
>>
>> According to dmesg, this is where it appears to hang:
>>
>> [2.717311] device-mapper: uevent: version 1.0.3
>> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
>> initialised: dm-d
>> e...@redhat.com
>> [2.978281] clocksource: Switched to clocksource tsc
>> [  121.459392] md: linear personality registered for level -1
>> [  121.460391] md: multipath personality registered for level -4
>> [  121.461444] md: raid0 personality registered for level 0
>>
>> I have started wondering recently about the hardware - could I have a
>> clock problem?
>>
>> None of the other 'clocksource' entries have a similar lag, and there's
>> no similar lag at that point on my desktop.
>>
>> Do I need to provide more context, or do more diagnostics?
>>
>
> As an experiment -- try this:
>
> echo udev_log=\"err\" >> /etc/udev/udev.conf
>
> (Or, alternatively, edit /etc/udef/udev.conf and insert/change
> that as necessary.)


Manually editing sounds like a good route because mine says this when
you get there:

# udevd is started in the initramfs, so when this file is modified the
# initramfs should be rebuilt.

"[S]hould"... Sounds like some of that should/shall/will and must
(??) coming into play.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Slow boot

[Dan Ritter]

Richard Hector wrote: 
> Hi all,
> 
> This machine is taking ages to boot.
> 
> It's a fresh install.
> 
> According to dmesg, this is where it appears to hang:
> 
> [2.717311] device-mapper: uevent: version 1.0.3
> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23)
> initialised: dm-d
> e...@redhat.com
> [2.978281] clocksource: Switched to clocksource tsc
> [  121.459392] md: linear personality registered for level -1
> [  121.460391] md: multipath personality registered for level -4
> [  121.461444] md: raid0 personality registered for level 0
> 
> I have started wondering recently about the hardware - could I have a
> clock problem?
> 
> None of the other 'clocksource' entries have a similar lag, and there's
> no similar lag at that point on my desktop.
> 
> Do I need to provide more context, or do more diagnostics?
> 

As an experiment -- try this:

echo udev_log=\"err\" >> /etc/udev/udev.conf

(Or, alternatively, edit /etc/udef/udev.conf and insert/change
that as necessary.)

-dsr-

kernel "unsigned" in sid

[dotdeb]

I recently came across an inconsistency in sid that it seems difficult (to
me) to overcome.

A kernel package named linux-image-4.19.0-1-amd64-unsigned provides the
running kernel but, since few days ago, it creates conflicts with the
metapackage linux-image-amd64 (bercause it depends on
linux-image-4.19.0-1-amd which, in turn, conflicts with the installed
kernel).

I can't trivially replace the "unsigned" (BTW, what does "unsigned" stand
for, anyway?) version with linux-image-4.19.0-1-amd because of the same
version number.

I'm not really worried because this will probably be solved when moving to
the next kernel release but the situation is a bit annoying.

Is there any solution?

a.

Re: Slow boot

[Curt]

On 2019-01-11, Richard Hector  wrote:
>
> Hints on where to look for the boot sequence in the kernel source, perhap=
> s?
>

If you're using systemd the output of

 systemd-analyze blame
 systemd-analyze critical-chain

might be informative.