general protection fault on vif50.1-q1-guest (Debian 8/Xen)

[John Naggets]

Hello,

I had recently a general protection fault on a Debian 8 server with
Xen (debian pacakge: 4.4.4lts4-0+deb8u1) on the vif50.1-q1-guest
kernel proces. I have copied the kernel log below in this mail for
reference. After this GPF the system was still responding but one domU
lost network connectivity and all the others where still working
properly. I decided to power-off and power-on the system as a soft GPF
renders the system in an unstable state.

Now I am trying to find out what is most likely the cause of this
general protection fault in order to avoid that again in the future
and would like your opinion on that:

- is this maybe a bug in the Debian kernel I am using?
- a bug in the Xen package used by Debian 8?
- a hardware issue?
- if it is a hardware issue, what is most likely? RAM? CPU?
- anything else I am missing?

Note that the hardware is enterprise grade hardware and that the BIOS
has been updated to the latest available version.The CPUs (dual CPU)
are Intel Xeon E5-2640 v3 @ 2.60GHz.

Thank you for your input.

Best regards,
John

[Wed May  6 14:48:02 2020] general protection fault:  [#1] SMP
[Wed May  6 14:48:02 2020] Modules linked in: xt_physdev
iptable_filter ip_tables x_tables xen_netback xen_blkback hmac
binfmt_misc xen_gntdev xen_evtchn xenfs xen_privcmd nfsd auth_rpcgss
oid_registry nfs_acl nfs lockd fscache sunrpc bridge bonding iTCO_wdt
iTCO_vendor_support mxm_wmi zfs(PO) zunicode(PO) x86_pkg_temp_thermal
intel_powerclamp zcommon(PO) intel_rapl znvpair(PO) spl(O) coretemp
crc32_pclmul zavl(PO) aesni_intel pcspkr aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd ast ttm drm_kms_helper evdev joydev drm
lpc_ich mfd_core i2c_algo_bit mei_me mei shpchp tpm_tis tpm ipmi_si
ipmi_msghandler wmi acpi_power_meter processor thermal_sys button
8021q garp stp mrp llc drbd lru_cache libcrc32c crc32c_generic autofs4
ext4 crc16 mbcache jbd2 dm_mod raid1 md_mod mlx4_en vxlan xen_blkfront
ptp pps_core
[Wed May  6 14:48:02 2020]  hid_generic usbhid hid sg sd_mod
crc_t10dif crct10dif_generic ahci libahci crct10dif_pclmul
crct10dif_common crc32c_intel ehci_pci ehci_hcd mlx4_core libata
i2c_i801 i2c_core usbcore usb_common scsi_mod nvme
[Wed May  6 14:48:02 2020] CPU: 0 PID: 8305 Comm: vif50.1-q1-gues
Tainted: P   O  3.16.0-10-amd64 #1 Debian 3.16.72-1
[Wed May  6 14:48:02 2020] Hardware name: Quanta Computer Inc
QuantaPlex T41S-2U/S2S-MB, BIOS S2S_3B12 05/30/2019
[Wed May  6 14:48:02 2020] task: 88003c9f95d0 ti: 88004a3ac000
task.ti: 88004a3ac000
[Wed May  6 14:48:02 2020] RIP: e030:[]
[] xenvif_gop_frag_copy+0x22/0x3b0 [xen_netback]
[Wed May  6 14:48:02 2020] RSP: e02b:88004a3afd98  EFLAGS: 00010282
[Wed May  6 14:48:02 2020] RAX: 1000 RBX: 8802e0841800
RCX: 7aec7d18f3f45689
[Wed May  6 14:48:02 2020] RDX: 88004a3afe80 RSI: 8802e0841800
RDI: 000111f703b7
[Wed May  6 14:48:02 2020] RBP: c9002332c258 R08: 5ff8d9a9
R09: b1fe2a0e
[Wed May  6 14:48:02 2020] R10: 8800 R11: 0002
R12: 7aec7d18f3f45689
[Wed May  6 14:48:02 2020] R13: c9002332c258 R14: 88004a3afe54
R15: 0001
[Wed May  6 14:48:02 2020] FS:  ()
GS:88048400() knlGS:88048400
[Wed May  6 14:48:02 2020] CS:  e033 DS:  ES:  CR0: 80050033
[Wed May  6 14:48:02 2020] CR2: 7f49c8679000 CR3: 74855000
CR4: 00042660
[Wed May  6 14:48:02 2020] Stack:
[Wed May  6 14:48:02 2020]  58f6d400 c90023336c08
02c0 8802e0841800
[Wed May  6 14:48:02 2020]  88004a3afe80 0080
8802e0841800 c9002332c258
[Wed May  6 14:48:02 2020]  79eb3472cad61644 0028
88004a3afe54 0001
[Wed May  6 14:48:02 2020] Call Trace:
[Wed May  6 14:48:02 2020]  [] ?
xenvif_kthread_guest_rx+0x549/0xce0 [xen_netback]
[Wed May  6 14:48:02 2020]  [] ?
xenvif_map_frontend_rings+0xd0/0xd0 [xen_netback]
[Wed May  6 14:48:02 2020]  [] ? kthread+0xd1/0xf0
[Wed May  6 14:48:02 2020]  [] ? __schedule+0x22f/0x750
[Wed May  6 14:48:02 2020]  [] ?
kthread_create_on_node+0x1b0/0x1b0
[Wed May  6 14:48:02 2020]  [] ? ret_from_fork+0x6e/0xa0
[Wed May  6 14:48:02 2020]  [] ?
kthread_create_on_node+0x1b0/0x1b0
[Wed May  6 14:48:02 2020] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44
00 00 41 57 41 56 b8 00 10 00 00 41 55 41 54 49 89 cc 55 53 49 89 fd
4b 8d 3c 08 48 83 ec 30 <48> 8b 09 4c 8b 74 24 68 4c 8b 7c 24 70 80 e5
40 74 08 49 8b 4c
[Wed May  6 14:48:02 2020] RIP  []
xenvif_gop_frag_copy+0x22/0x3b0 [xen_netback]
[Wed May  6 14:48:02 2020]  RSP 
[Wed May  6 14:48:33 2020] ---[ end trace 4fb039a0de2de66f ]---

Spectre variants 3a and 4 on Debian 8

[John Naggets]

Hello,

I would like to protect my SuperMicro SYS-5018R-MR server from the
newest Spectre variants 3a and 4 and hence did the following:

- updated SuperMicro BIOS to v3.1 from 06/06/2018 which explicitly
addresses these 2 new variants based on their release notes
- updated to the latest Debian 8.11 with the kernel 3.16.57-2 (2018-07-14)
- added non-free/contrib repos and installed intel-microcode package
- rebooted server

Still after all that the spectre-meltdown-checker.sh script from
meltdown.ovh still reports that my server is vulnearble to variants 3a
and 4 and even to variant 3.

Is it possible that this is related to me using Debian 8 with a Kernel 3.16?

Another particularity from this server is that I am using Xen dom0
hypervisor (official Xen 4.4 packages from Debian 8 repo). So maybe
this is because of Xen?

Best regards,
John

Re: ThinkSystem RAID 930-8i driver/module for Debian 9

[John Naggets]

Thanks Dan for suggesting some alternatives. Unfortunately most of
them are not really convenient or simple. What about a 5th alternative
which would be simply to "Install Debian 10 (buster/testing)" ? In
theory as it has a more modern kernel version the module/driver for
this new RAID card should be supported. What do you think except for
the fact that this is a testing release...

On Tue, Jan 30, 2018 at 9:15 PM, Dan Ritter <d...@randomstring.org> wrote:
> On Tue, Jan 30, 2018 at 06:49:34PM +0100, John Naggets wrote:
>> Hi,
>>
>> I just got a new Lenovo ThinkSystem SR630 server and I am trying to
>> install Debian 9.3 onto it. Unfortunately at the disk partitioning
>> step it does not find any disks. It looks like Debian 9 does not have
>> the kernel driver/module for its RAID card.
>>
>> The RAID card is a Lenovo ThinkSystem RAID 930-8i which basically is a
>> re-branded LSI card. lspci shows the following output:
>>
>> LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3508 (rev 01)
>>
>> Any ideas how I could get Debian 9 running on this server with this RAID 
>> card?
>>
>
> Older versions of that card have good support in the kernel under the
> name megaraid_sas, so I would expect that you need a new kernel.
>
> Options:
>
> 1. debian-backports
> 2. unstable
> 3. install on to another disk, then compile a new kernel
> 4. build your own installer with a new kernel
>
> It's not clear to me that it is in the kernel before the very
> latest, 4.15.
>
> -dsr-

ThinkSystem RAID 930-8i driver/module for Debian 9

[John Naggets]

Hi,

I just got a new Lenovo ThinkSystem SR630 server and I am trying to
install Debian 9.3 onto it. Unfortunately at the disk partitioning
step it does not find any disks. It looks like Debian 9 does not have
the kernel driver/module for its RAID card.

The RAID card is a Lenovo ThinkSystem RAID 930-8i which basically is a
re-branded LSI card. lspci shows the following output:

LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3508 (rev 01)

Any ideas how I could get Debian 9 running on this server with this RAID card?

Best regards,
John

Re: IPv6 SLAAC and RFC 7217

[John Naggets]

Thanks Andy for the tip about the stable_secret sysctl, I will try
this out soon and see how it behaves.

On Mon, Jan 22, 2018 at 2:06 AM, Andy Smith <a...@strugglers.net> wrote:
> Hi John,
>
> On Sun, Jan 21, 2018 at 07:29:23PM +0100, John Naggets wrote:
>> I was wondering if there is a "standard" way in Debian 9 through the
>> /etc/network/interfaces file to enable/force using a stable private
>> IPv6 address using SLAAC as specified in RFC 7217?
>
> I have never tried it but <https://unix.stackexchange.com/a/255955>
> seems to suggest that you would set the stable_secret sysctl and
> then it would work automatically after that.
>
> You could set the sysctl from /etc/network/interfaces or from
> /etc/sysctl.d/ or just by some other script.
>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>

IPv6 SLAAC and RFC 7217

[John Naggets]

Hi,

I was wondering if there is a "standard" way in Debian 9 through the
/etc/network/interfaces file to enable/force using a stable private
IPv6 address using SLAAC as specified in RFC 7217?

Any one already managed to do that on a Debian 9 client? or know how to do that?

Cheers,
John

Re: Upgrading to stretch (jessie-backports question)

[John Naggets]

On Thu, Dec 7, 2017 at 8:29 PM, Greg Wooledge  wrote:

>> Actually moving on the Debian stretch I would not need anymore the
>> backports because the ZFS packages are included in stretch. So could I
>> just get rid of my backports APT source by deleting my list file
>> beforehand and then simply do a dist-upgrade?
>
> My personal recommendation would be to comment out (or delete) the
> old backports line(s).  If in the future you find yourself wanting
> stretch-backports (from buster) then add the new backports line at
> that time.

I think I will go for that variant as it makes the most sense to me.

What about third-party APT repositories sources such as for MongoDB,
Nextcloud, etc, would one simply replace "jessie" with "stretch" in
the sources files at the same time as for the official Debian APT
repositories before running a dist-upgrade?

Re: Upgrading to stretch (jessie-backports question)

[John Naggets]

On Thu, Dec 7, 2017 at 6:39 PM, Greg Wooledge  wrote:

> No.  Backports have to be specifically requested.

Aha I get it. So by changing my APT sources.list for backports from
jessie-backports to stretch-backports all my ZFS packages will simply
get upgraded to the official/main Debian (non backports) stretch ZFS
packages?

Actually moving on the Debian stretch I would not need anymore the
backports because the ZFS packages are included in stretch. So could I
just get rid of my backports APT source by deleting my list file
beforehand and then simply do a dist-upgrade?

Re: Upgrading to stretch (jessie-backports question)

[John Naggets]

On Thu, Dec 7, 2017 at 6:11 PM, Tom Furie  wrote:

> Is there a reason not to switch to your backports source to stretch at
> the same time as the others?

If I understand correctly doing that I will end up with the ZFS
packages for unstable (Debian 10) after running a dist-upgrade? Is my
understanding correct?

Currently I have the following packages from jessie-backports:

ii  dh-python2.20170125~bpo8+1
all  Debian helper tools for packaging Python libraries and
applications
ii  dkms 2.3-2~bpo8+1
all  Dynamic Kernel Module Support Framework
ii  libnvpair1linux  0.6.5.9-2~bpo8+1
amd64Solaris name-value library for Linux
ii  libuutil1linux   0.6.5.9-2~bpo8+1
amd64Solaris userland utility library for Linux
ii  libzfs2linux 0.6.5.9-2~bpo8+1
amd64OpenZFS filesystem library for Linux
ii  libzpool2linux   0.6.5.9-2~bpo8+1
amd64OpenZFS pool library for Linux
ii  spl  0.6.5.9-1~bpo8+1
amd64Solaris Porting Layer user-space utilities for Linux
ii  spl-dkms 0.6.5.9-1~bpo8+1
all  Solaris Porting Layer kernel modules for Linux
ii  zfs-dkms 0.6.5.9-2~bpo8+1
all  OpenZFS filesystem kernel modules for Linux
ii  zfs-zed  0.6.5.9-2~bpo8+1
amd64OpenZFS Event Daemon
ii  zfsutils-linux   0.6.5.9-2~bpo8+1
amd64command-line tools to manage OpenZFS filesystems

Upgrading to stretch (jessie-backports question)

[John Naggets]

Hi,

I am currently using Debian 8 and have enabled the jessie-backports
repository with the following line in
/etc/apt/sources.d/backports.list:

deb http://ftp.debian.org/debian jessie-backports main contrib

The only reason for this is that I am using ZFS on jessie for some
data disks/partitions. Now I would like to do a dist-upgrade from
jessie to stretch and was wondering how to handle the
jessie-backports.

Should I for example before doing the dist-upgrade to stretch delete
the APT jessie-backports source? or should I simply leave it and do a
dist-upgrade as usual?

Best regards,
John

PXE netboot to load OS from /dev/sda1

[John Naggets]

Hi,

I have installed Debian 9 onto an old laptop with an SSD disk.
Unfortunately the BIOS does not support booting from that SSD disk so
I would like to "abuse" of PXE in order to boot my installed Linux
from /dev/sda1.

For that purpose I setup a PXE server on another machine on the same
LAN using the netboot.tar.gz file from Debian 9 and slightly adapted
the pxelinux.cfg/default file to add the following entry:

LABEL netboot
KERNEL debian-installer/amd64/linux
APPEND initrd=debian-installer/amd64/initrd.gz root=/dev/sda1

Unfortunately it still boots the Debian installer and somehow does not
boot from /dev/sda1. I thought having "root=/dev/sda1" should make it
boot from /dev/sda1 and hence skip the installer part. At least I
think it used to work in the past.

Does anyone see what I am missing here?

Best,
John

Re: OpenJDK 8 from jessie backports

[John Naggets]

Thanks Georgi you made my day! That worked like a charm.

On Thu, Sep 14, 2017 at 3:10 PM, Georgi Naplatanov <go...@oles.biz> wrote:
> On 09/14/2017 03:45 PM, John Naggets wrote:
>> Hi,
>>
>> I did the mistake of running an "apt-get dist-upgrade" on my Debian 8
>> machine which uses Debian backports in oder to have the OpenJDK 8
>> package. Now I am stuck by with the OpenJDK 7 from the Debian repo and
>> if I try to install OpenJDK 8 again I get the following error:
>>
>> $ sudo apt-get install openjdk-8-jre-headless
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  openjdk-8-jre-headless : Breaks: ca-certificates-java (< 20160321~)
>> but 20140324 is to be installed
>> E: Unable to correct problems, you have held broken packages.
>>
>> Does anyone have an idea how I can get OpenJDK 8 from backports back?
>
> Hi John,
>
> I had the same problem with Jessie and OpenJdk-8.
>
> You have to install ca-certificates-java from backports too.
>
> HTH
>
> Kind regards
> Georgi
>

OpenJDK 8 from jessie backports

[John Naggets]

Hi,

I did the mistake of running an "apt-get dist-upgrade" on my Debian 8
machine which uses Debian backports in oder to have the OpenJDK 8
package. Now I am stuck by with the OpenJDK 7 from the Debian repo and
if I try to install OpenJDK 8 again I get the following error:

$ sudo apt-get install openjdk-8-jre-headless
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 openjdk-8-jre-headless : Breaks: ca-certificates-java (< 20160321~)
but 20140324 is to be installed
E: Unable to correct problems, you have held broken packages.

Does anyone have an idea how I can get OpenJDK 8 from backports back?

Best,
John

Re: not possible to install apt-transport-https package on jessie

[John Naggets]

Thanks Pascal for your hints. Indeed I had to comment out the gluster
repository which is forwarding HTTP to HTTPS, then re-run apt-cache
update, install apt-transport-https and finally modify the gluster
repository source to directly use HTTPS. That was an interesting case
;)

On Fri, Dec 30, 2016 at 4:43 PM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> Le 30/12/2016 à 16:25, John Naggets a écrit :
>>
>> I have now additional source in /etc/apt/sources.list.d/gluster.list
>> which is the following:
>>
>> deb
>> http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.16/Debian/jessie/apt
>> jessie main
>
>
> Although the URL is http, I checked that the site redirects http to https.
> IMO you should directly use "https" to make it clear that this repository
> requires the https transport.
>
>> And here would be the output of apt-cache policy:
>>
>> Package files:
>>  100 /var/lib/dpkg/status
>>  release a=now
>>  500
>> http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.16/Debian/jessie/apt/
>> jessie/main amd64 Packages
>>  origin download.gluster.org
>>  500 http://ftp.ch.debian.org/debian/ jessie-updates/main Translation-en
>>  500 http://ftp.ch.debian.org/debian/ jessie-updates/main amd64 Packages
>>  release o=Debian,a=stable-updates,n=jessie-updates,l=Debian,c=main
>>  origin ftp.ch.debian.org
>>  500 http://security.debian.org/ jessie/updates/main Translation-en
>>  500 http://security.debian.org/ jessie/updates/main amd64 Packages
>>  release v=8,o=Debian,a=stable,n=jessie,l=Debian-Security,c=main
>>  origin security.debian.org
>> Pinned packages:
>
>
> As I suspected, the jessie/main section on ftp.ch.debian.org is missing,
> although the line is present is sources.list :
>
>>>> deb http://ftp.ch.debian.org/debian jessie main
>
>
> Maybe try to add another mirror and run apt-get update ?
> Or comment out the glusterfs repository and run apt-get update.
>

Re: not possible to install apt-transport-https package on jessie

[John Naggets]

I have now additional source in /etc/apt/sources.list.d/gluster.list
which is the following:

deb 
http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.16/Debian/jessie/apt
jessie main

And here would be the output of apt-cache policy:

Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 
http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.16/Debian/jessie/apt/
jessie/main amd64 Packages
 origin download.gluster.org
 500 http://ftp.ch.debian.org/debian/ jessie-updates/main Translation-en
 500 http://ftp.ch.debian.org/debian/ jessie-updates/main amd64 Packages
 release o=Debian,a=stable-updates,n=jessie-updates,l=Debian,c=main
 origin ftp.ch.debian.org
 500 http://security.debian.org/ jessie/updates/main Translation-en
 500 http://security.debian.org/ jessie/updates/main amd64 Packages
 release v=8,o=Debian,a=stable,n=jessie,l=Debian-Security,c=main
 origin security.debian.org
Pinned packages:

On Fri, Dec 30, 2016 at 2:45 PM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> Le 30/12/2016 à 14:19, John Naggets a écrit :
>>
>> Do you have an idea which line could be missing? Here is the content
>> of my /etc/apt/sources.list file:
>>
>> deb http://ftp.ch.debian.org/debian jessie main
>> deb-src http://ftp.ch.debian.org/debian/ jessie main
>>
>> deb http://security.debian.org/ jessie/updates main
>> deb-src http://security.debian.org/ jessie/updates main
>>
>> # jessie-updates, previously known as 'volatile'
>> deb http://ftp.ch.debian.org/debian jessie-updates main
>> deb-src http://ftp.ch.debian.org/debian/ jessie-updates main
>
>
> It looks fine, but is that all ? There is no https repository, so apt-get
> should have no reason to complain about missing https transport, except one
> of the mirrors is broken and redirects to https URLs. "apt-cache policy" may
> provide extra information.
>
> BTW, ca-certificate is only a "recommends", so you could try to install with
> --no-install-recommends.
>

Re: not possible to install apt-transport-https package on jessie

[John Naggets]

Do you have an idea which line could be missing? Here is the content
of my /etc/apt/sources.list file:

deb http://ftp.ch.debian.org/debian jessie main
deb-src http://ftp.ch.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

# jessie-updates, previously known as 'volatile'
deb http://ftp.ch.debian.org/debian jessie-updates main
deb-src http://ftp.ch.debian.org/debian/ jessie-updates main

On Fri, Dec 30, 2016 at 12:26 AM, Pascal Hambourg
<pas...@plouf.fr.eu.org> wrote:
> Le 29/12/2016 à 23:14, John Naggets a écrit :
>>
>>
>> $ sudo apt-get update
>> Hit http://security.debian.org jessie/updates InRelease
>> Ign http://ftp.ch.debian.org jessie InRelease
>> Get:1 http://ftp.ch.debian.org jessie-updates InRelease [145 kB]
>> Hit http://ftp.ch.debian.org jessie Release.gpg
>> Hit http://ftp.ch.debian.org jessie Release
>> Get:2 http://security.debian.org jessie/updates/main Translation-en [178
>> kB]
>> Get:3 http://security.debian.org jessie/updates/main Sources [174 kB]
>> Get:4 http://ftp.ch.debian.org jessie-updates/main Sources [15.4 kB]
>> Get:5 http://security.debian.org jessie/updates/main amd64 Packages
>> [336 kB]
>> Get:6 http://ftp.ch.debian.org jessie-updates/main amd64
>> Packages/DiffIndex [6,916 B]
>> Get:7 http://ftp.ch.debian.org jessie-updates/main
>> Translation-en/DiffIndex [2,704 B]
>> Get:8 http://ftp.ch.debian.org jessie/main Sources [7,059 kB]
>> E: The method driver /usr/lib/apt/methods/https could not be found.
>> N: Is the package apt-transport-https installed?
>>
>>
>> $ sudo apt-get install apt-transport-https
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  apt-transport-https : Depends: libcurl3-gnutls (>= 7.16.2) but it is
>> not going to be installed
>> E: Unable to correct problems, you have held broken packages.
>>
>>
>> $ sudo apt-get install libcurl3-gnutls
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  libcurl3-gnutls : Depends: librtmp1 (>= 2.4+20131018.git79459a2-3~)
>> but it is not installable
>>Recommends: ca-certificates but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>>
>>
>> $ sudo apt-get install ca-certificates
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Package ca-certificates is not available, but is referred to by another
>> package.
>> This may mean that the package is missing, has been obsoleted, or
>> is only available from another source
>>
>> E: Package 'ca-certificates' has no installation candidate
>
>
> I guess a line for the jessie repository is missing in
> /etc/apt/sources.list.
>

not possible to install apt-transport-https package on jessie

[John Naggets]

Hi,

I am trying to install the apt-transport-https package in order to
avoid the "E: The method driver /usr/lib/apt/methods/https could not
be found." error message which recently appeared when I want to
apt-get update/upgrade. Unfortunately something is wrong here but I
have no idea what... Have a look below at my commands and output.

Regards,
John


$ sudo apt-get update
Hit http://security.debian.org jessie/updates InRelease
Ign http://ftp.ch.debian.org jessie InRelease
Get:1 http://ftp.ch.debian.org jessie-updates InRelease [145 kB]
Hit http://ftp.ch.debian.org jessie Release.gpg
Hit http://ftp.ch.debian.org jessie Release
Get:2 http://security.debian.org jessie/updates/main Translation-en [178 kB]
Get:3 http://security.debian.org jessie/updates/main Sources [174 kB]
Get:4 http://ftp.ch.debian.org jessie-updates/main Sources [15.4 kB]
Get:5 http://security.debian.org jessie/updates/main amd64 Packages
[336 kB]
Get:6 http://ftp.ch.debian.org jessie-updates/main amd64
Packages/DiffIndex [6,916 B]
Get:7 http://ftp.ch.debian.org jessie-updates/main
Translation-en/DiffIndex [2,704 B]
Get:8 http://ftp.ch.debian.org jessie/main Sources [7,059 kB]
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?


$ sudo apt-get install apt-transport-https
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apt-transport-https : Depends: libcurl3-gnutls (>= 7.16.2) but it is
not going to be installed
E: Unable to correct problems, you have held broken packages.


$ sudo apt-get install libcurl3-gnutls
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libcurl3-gnutls : Depends: librtmp1 (>= 2.4+20131018.git79459a2-3~)
but it is not installable
   Recommends: ca-certificates but it is not installable
E: Unable to correct problems, you have held broken packages.


$ sudo apt-get install ca-certificates
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package ca-certificates is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'ca-certificates' has no installation candidate

Re: probable broken tomcat6 package on wheezy

[John Naggets]

Hi Alex,

By installing the previous package version from the apt cache archive
as you mention I managed to find out that it is the libtomcat6-java
package which is broken. You just need to downgrade that package back
to deb7u3 and Tomcat will start again.

Thanks for the hint and hopefully this package will be quickly fixed.

Best,
H.N.

On Sat, Dec 17, 2016 at 9:53 AM, Alex Mestiashvili
<a...@biotec.tu-dresden.de> wrote:
> On 12/17/2016 07:40 AM, John Naggets wrote:
>> Hi,
>>
>> Since today the tomcat6 package on Debian 7.11 seems to be broken as
>> the tomcat6 service does not start anymore. Here is the relevant
>> output of catalina.out:
>>
>> Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
>> validateFile
>> WARNING: Problem with directory [/usr/share/tomcat6/server/classes],
>> exists: [false], isDirectory: [false], canRead: [false]
>> Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
>> validateFile
>> WARNING: Problem with directory [/usr/share/tomcat6/server], exists:
>> [false], isDirectory: [false], canRead: [false]
>> Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
>> validateFile
>> WARNING: Problem with directory [/usr/share/tomcat6/shared/classes],
>> exists: [false], isDirectory: [false], canRead: [false]
>> Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
>> validateFile
>> WARNING: Problem with directory [/usr/share/tomcat6/shared], exists:
>> [false], isDirectory: [false], canRead: [false]
>> Dec 17, 2016 6:35:16 AM org.apache.coyote.http11.Http11Protocol init
>> INFO: Initializing Coyote HTTP/1.1 on http-8080
>> Dec 17, 2016 6:35:16 AM org.apache.catalina.startup.Catalina load
>> INFO: Initialization processed in 438 ms
>> java.lang.reflect.InvocationTargetException
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
>> Caused by: java.lang.ExceptionInInitializerError
>> at 
>> org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:262)
>> at 
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
>> at org.apache.catalina.core.StandardServer.start(StandardServer.java:752)
>> at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
>> ... 6 more
>> Caused by: java.util.MissingResourceException: Can't find bundle for
>> base name org.apache.naming.factory.LocalStrings, locale en_US
>> at 
>> java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1499)
>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1322)
>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:721)
>> at org.apache.naming.StringManager.(StringManager.java:68)
>> at org.apache.naming.StringManager.getManager(StringManager.java:213)
>> at 
>> org.apache.naming.factory.ResourceLinkFactory.(ResourceLinkFactory.java:44)
>> ... 10 more
>>
>> Using the following tomcat:
>>
>> $ dpkg -l|grep tomcat
>> ii  libtomcat6-java6.0.45+dfsg-1~deb7u4
>> all  Servlet and JSP engine -- core libraries
>> ii  tomcat66.0.45+dfsg-1~deb7u4
>> all  Servlet and JSP engine
>> ii  tomcat6-common 6.0.45+dfsg-1~deb7u4
>> all  Servlet and JSP engine -- common files
>>
>> and JRE:
>>
>> dpkg -l|grep jre
>> ii  default-jre-headless   1:1.7-47+deb7u2
>> amd64Standard Java or Java compatible Runtime (headless)
>> ii  openjdk-7-jre-headless:amd64   7u111-2.6.7-2~deb7u1
>> amd64OpenJDK Java runtime, using Hotspot JIT (headless)
>>
>> The following package updates have been performed this early morning
>> and I suspect one of these following packages to be broken:
>>
>> libicu-dev libicu48 libservlet2.5-java libtomcat6-java  tomcat6
>> tomcat6-admin tomcat6-common
>>
>> Any ideas? I can't find anything yet on any debian mailing lists...
>>
>> Best regards
>> H.N.
>>
>
> Hi,
> As a temporary workaround disable the unattended-upgrades, and
> try to install the previous version from /var/cache/apt/archives.
> It solved the problem for me. ( of course if you don't clean the apt
> archives )
>
> Best,
> Alex
>
>
>

probable broken tomcat6 package on wheezy

[John Naggets]

Hi,

Since today the tomcat6 package on Debian 7.11 seems to be broken as
the tomcat6 service does not start anymore. Here is the relevant
output of catalina.out:

Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
validateFile
WARNING: Problem with directory [/usr/share/tomcat6/server/classes],
exists: [false], isDirectory: [false], canRead: [false]
Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
validateFile
WARNING: Problem with directory [/usr/share/tomcat6/server], exists:
[false], isDirectory: [false], canRead: [false]
Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
validateFile
WARNING: Problem with directory [/usr/share/tomcat6/shared/classes],
exists: [false], isDirectory: [false], canRead: [false]
Dec 17, 2016 6:35:15 AM org.apache.catalina.startup.ClassLoaderFactory
validateFile
WARNING: Problem with directory [/usr/share/tomcat6/shared], exists:
[false], isDirectory: [false], canRead: [false]
Dec 17, 2016 6:35:16 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Dec 17, 2016 6:35:16 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 438 ms
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.lang.ExceptionInInitializerError
at 
org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:262)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:752)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
... 6 more
Caused by: java.util.MissingResourceException: Can't find bundle for
base name org.apache.naming.factory.LocalStrings, locale en_US
at 
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1499)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1322)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:721)
at org.apache.naming.StringManager.(StringManager.java:68)
at org.apache.naming.StringManager.getManager(StringManager.java:213)
at 
org.apache.naming.factory.ResourceLinkFactory.(ResourceLinkFactory.java:44)
... 10 more

Using the following tomcat:

$ dpkg -l|grep tomcat
ii  libtomcat6-java6.0.45+dfsg-1~deb7u4
all  Servlet and JSP engine -- core libraries
ii  tomcat66.0.45+dfsg-1~deb7u4
all  Servlet and JSP engine
ii  tomcat6-common 6.0.45+dfsg-1~deb7u4
all  Servlet and JSP engine -- common files

and JRE:

dpkg -l|grep jre
ii  default-jre-headless   1:1.7-47+deb7u2
amd64Standard Java or Java compatible Runtime (headless)
ii  openjdk-7-jre-headless:amd64   7u111-2.6.7-2~deb7u1
amd64OpenJDK Java runtime, using Hotspot JIT (headless)

The following package updates have been performed this early morning
and I suspect one of these following packages to be broken:

libicu-dev libicu48 libservlet2.5-java libtomcat6-java  tomcat6
tomcat6-admin tomcat6-common

Any ideas? I can't find anything yet on any debian mailing lists...

Best regards
H.N.

unmount mount point when exiting gnome3 desktop

[John Naggets]

Hello,

I would like to automatically unmount a DavFS mount point
/media/webdav) when a users logs off the gnome3 desktop on jessie.

For that purpose I have added the following command to
/etc/gdm3/PostSession/Default:

/bin/umount /media/webdav

But it looks like this script never gets executed when a user logs off
as the partition is always mounted. Do I need to do anything else?

Cheers
John

aufofs starting before networking at system boot

[John Naggets]

Hello,

I noticed that on my Debian jessie installation by looking in
/etc/rc5.d that autofs gets started before the networking script.
Somehow I think this does not make sense and autofs should get started
after the networking script.

For example in my case autofs has to query my internal LDAP server to
get its autofs maps but the network is not available at that stage.
The result is that when the desktop is ready for a user to login, I do
not have any NFS /home directory mounted via autofs... The only
solution at this stage for me is to do a sudo service autofs
restart.

Any suggestions?

Regards
ML


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/captze3tmd4cwnsevzqbx-ada0ky0no8_-jqzk-ndoyxqv+e...@mail.gmail.com