Bug#917632: bugs.debian.org: During kernel boot the nvme module is not loaded, make the kernel not finding the rootfs

[Patrick Boettcher]

Thank you. 

I fixed my problem with manually running 

sudo update-initramfs -u

I don't why the initial initramfs did not contain the necessary
"things" to load the nvme-module automatically. Maybe it was the
constellation of update-packages.

--
Patrick.



On Sat, 29 Dec 2018 15:12:52 -0800
Don Armstrong  wrote:

> Control: reassign -1 linux-signed-amd64
> Control: found -1 4.17.0-3
> 
> Just a note, bugs.debian.org is the package for reporting issues with
> the bug tracking system itself, not general issues in packages (or the
> kernel.)
> 
> I've reassigned this bug for you.
> 
> On Sat, 29 Dec 2018, Patrick Boettcher wrote:
> > I did an apt upgrade this morning, I'm running testing/unstable.
> > This updated my kernels to 4.17.0-3-amd64 and 4.19.0-1-amd64. I
> > think the first since a few months (6 or more, but less then one
> > year).  
> 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > sudo apt update; sudo apt dist-upgrade
> > 
> >* What was the outcome of this action?
> > 
> > After rebooting to the new kernel booting stuck with some messages
> > about mdadm looking for a RAID I don't have.
> > 
> > Ultimately the initramfs-shell came up and I found out that there
> > are no block- devices loaded. /dev/sda* and /dev/nvme* did not
> > exists.
> > 
> > I manually modprobe'd nvme. Followed by CTRL-D and the boot
> > continued.
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (602, 'unstable'), (601, 'testing'), (600, 'stable'),
> > (598, 'experimental') Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 4.17.0-3-amd64 (SMP w/12 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot
> > set LC_ALL to default locale: No such file or directory UTF-8),
> > LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default
> > locale: No such file or directory UTF-8) Shell: /bin/sh linked
> > to /usr/bin/dash Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >   

Bug#917632: bugs.debian.org: During kernel boot the nvme module is not loaded, make the kernel not finding the rootfs

[Patrick Boettcher]

Package: bugs.debian.org
Severity: important
Tags: upstream

Dear Maintainer(s),

   * What led up to the situation?

I did an apt upgrade this morning, I'm running testing/unstable. This updated
my kernels to 4.17.0-3-amd64 and 4.19.0-1-amd64. I think the first since a few
months (6 or more, but less then one year).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

sudo apt update; sudo apt dist-upgrade

   * What was the outcome of this action?

After rebooting to the new kernel booting stuck with some messages about mdadm
looking for a RAID I don't have.

Ultimately the initramfs-shell came up and I found out that there are no block-
devices loaded. /dev/sda* and /dev/nvme* did not exists.

I manually modprobe'd nvme. Followed by CTRL-D and the boot continued.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (602, 'unstable'), (601, 'testing'), (600, 'stable'), (598, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default locale: 
No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#639161: linux-image-3.0.0-1-686-pae: Upgrade 2.6.39 -> 3.0.0 breaks playback on DiBcom 7000PC

[Patrick Boettcher]

Hi,

Afaik, this is fixed with those commits:

[media] dib0700: correct error message for_v3.0
[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access

from

http://git.linuxtv.org/pb/media_tree.git/shortlog/refs/heads/for_v3.0

A pull request has been sent to the media-maintainer, but it seems he is
busy.

--
Patrick.

On Thursday 25 August 2011 00:50:37 Ben Hutchings wrote:

Patrick,

Please could you take a look at the following bug report on Linux 3.0 as
packaged in Debian.

Ben.

On Wed, 2011-08-24 at 18:59 +0200, Soeren D. Schulze wrote:
> Package: linux-2.6
> Version: 3.0.0-1
> Severity: normal
>
> I usually use tzap/mplayer for TV playback.
>
> After the upgrade to Linux 3.0.0, tzap command line output still looks
> fine, but mplayer does not seem to receive any data (its cache does not
> fill up).
>
> syslog/dmesg output looks the same as in 2.6.39.  On the first try to
> tune, dmesg receives:
>
> dib0700: tx buffer length is larger than 4. Not supported.
> (for which I find various non-Debian bug reports)
>
> But that does not seem to be the issue, because the same message appears
> in 2.6.39, where everything is fine.
> So I do not really have an idea what the problem is, but I certainly
> know that it's a regression, because simply booting Linux 2.6.39 rather
> than 3.0.0 on the same system avoids the problem.
>
> -- Package-specific info:
> ** Version:
> Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk)
> (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011
>
> ** Command line:
> BOOT_IMAGE=/vmlinuz-3.0.0-1-686-pae
> root=UUID=3aa0a731-df46-486e-9c1e-258723e14f8f ro
>
> ** Not tainted
>
> ** Kernel log:
> [   11.031446] saa7134:   card=172 -> RoverMedia TV Link Pro FM
>19d1:0138
> [   11.031580] saa7134:   card=173 -> Zolid Hybrid TV Tuner PCI
>1131:2004
> [   11.031713] saa7134:   card=174 -> Asus Europa Hybrid OEM
>1043:4847
> [   11.031847] saa7134:   card=175 -> Leadtek Winfast DTV1000S
>107d:6655
> [   11.031982] saa7134:   card=176 -> Beholder BeholdTV 505 RDS
>:5051
> [   11.032126] saa7134:   card=177 -> Hawell HW-404M7
>
> [   11.032217] saa7134:   card=178 -> Beholder BeholdTV H7
>5ace:7190
> [   11.032351] saa7134:   card=179 -> Beholder BeholdTV A7
>5ace:7090
> [   11.032485] saa7134:   card=180 -> Avermedia PCI M733A
>1461:4155 1461:4255
> [   11.032656] saa7134:   card=181 -> TechoTrend TT-budget T-3000
>13c2:2804
> [   11.032789] saa7134:   card=182 -> Kworld PCI SBTVD/ISDB-T Full-Seg
> Hybrid  17de:b136
> [   11.032923] saa7134:   card=183 -> Compro VideoMate Vista M1F
>185b:c900
> [   11.033057] saa7134:   card=184 -> Encore ENLTV-FM 3
>1a7f:2108
> [   11.033192] saa7134:   card=185 -> MagicPro ProHDTV Pro2
> DMB-TH/Hybrid  17de:d136
> [   11.033326] saa7134:   card=186 -> Beholder BeholdTV 501
>5ace:5010
> [   11.033460] saa7134:   card=187 -> Beholder BeholdTV 503 FM
>5ace:5030
> [   11.033596] saa7134[0]: subsystem: 1131:, board: UNKNOWN/GENERIC
> [card=0,autodetected]
> [   11.075242] IR NEC protocol handler initialized
> [   11.265597] saa7134[0]: board init: gpio is 10020
> [   11.368582] saa7134[0]: Huh, no eeprom present (err=-5)?
> [   11.381924] saa7134[0]: registered device video0 [v4l2]
> [   11.382055] saa7134[0]: registered device vbi0
> [   11.417515] IR RC5(x) protocol handler initialized
> [   11.607051] cfg80211: Calling CRDA to update world regulatory domain
> [   11.995773] IR RC6 protocol handler initialized
> [   12.191500] IR JVC protocol handler initialized
> [   12.263839] dib0700: loaded with support for 20 different device-types
> [   12.264209] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
> [   12.265499] dvb-usb: will pass the complete MPEG2 transport stream to
> the software demuxer.
> [   12.266158] DVB: registering new adapter (Hauppauge Nova-T Stick)
> [   12.517093] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
> [   12.609760] IR Sony protocol handler initialized
> [   12.790869] DiB0070: successfully identified
> [   12.907896] ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
> [   12.907988] VIA 82xx Audio :00:11.5: PCI INT C -> Link[ALKC] ->
> GSI 22 (level, low) -> IRQ 22
> [   12.908316] VIA 82xx Audio :00:11.5: setting latency timer to 64
> [   12.932675] saa7134 ALSA driver for DMA sound loaded
> [   12.932807] saa7134[0]/alsa: saa7134[0] at 0xfdffc000 irq 16
> registered as card -1
> [   12.948789] lirc_dev: IR Remote Control driver registered, major 249
> [   12.952109] IR LIRC bridge handler initialized
> [   13.380033] Registered IR keymap rc-dib0700-rc5
> [   13.380514] input: IR-receiver inside an USB DVB receiver as
> /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0/input6
> [   13.380749] rc0: IR-receiver inside an USB DVB receiver as
> /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0
> [   

Bug#578551: libauthen-sasl-cyrus-perl: FTBFS with Perl 5.12: strange version number

[Patrick Boettcher]

Hi all,

On Sun, 2 May 2010, Dominic Hargreaves wrote:

This is an awkward one. The -server suffix is intended to distinguish
a fork of the code against the main CPAN line. Both versions (
http://www.cpan.org/authors/id/P/PB/PBOETTCH/ and
http://search.cpan.org/~adamson/Authen-SASL-Cyrus-0.12/Cyrus.pod)

look fairly quiet, and there have been no new release of mainline since
the fork was made. Perhaps it would be appropriate to see whether
the -server variant could take over the main line. and a 0.14 be
released?


The -server supports everything the non '-server' has. At the time of 
writing it I tried to merge it with Mark's release, but I never reached 
him.


I remember a short mail exchange between Russ and Graham Barr and me 
beginning of this year, where Graham said he wanted to merge the two to 
produce a completely new release with a new name. Don't know what happened 
since then.


best regards,

Patrick.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#567643: openoffice.org: Segfault when starting soffice.bin - testing of 2010-01-30

[Patrick Boettcher]

On Saturday 30 January 2010 15:01:27 Rene Engelhard wrote:
> severity 567643 grave
> tag 567643 + pending
> thanks
> 
> On Sat, Jan 30, 2010 at 01:37:19PM +0100, Patrick Boettcher wrote:
> > OpenOffice unusuable after updating today on testing. Tried to run with
> > clean ~/.openoffice.org, doesn't help.
> 
> Aha. And why do did you update testing to 3.1.1-14 today? I mean,
> that version already is in testing some day

Quite frankly I did not update to testing intentionally to test OpenOffice 
rather I updated "everything" to testing - since 6 years this is the second 
time that I have problems with testing... 

So not a big deal - just wanted you to be aware.


> Read the bugs already reported:
> 
> Pending Upload bugs -- Grave functionality bugs (2 bugs)
> 
>   #566189 [G|P|☺↝] [openoffice.org] openoffice.org: Openoffice crashes
>  on startup with DeploymentException #566832 [G|MP|☺↝] [openoffice.org]
>  openoffice.org: Any OpenOffice application crashes on startup
> 
> Pending Upload bugs -- Serious (policy violations or makes package unfit
>  for release) (1 bug)
> 
>   #566829 [S|MPR|☺↝] [openoffice.org] crashes on startup:
>  pand:$OOO_BASE_DIR/program/cairocanvas.uno.so: No such file or directory.
> 
> Pending Upload bugs -- Important bugs (2 bugs)
> 
>   #565667 [i|MPR|☺♔↝] [openoffice.org-emailmerge] Setting up /
>  dpkg-reconfigure openoffice.org-emailmerge segfaults in unopkg.bin #566062
>  [i|MPR|☺↝] [openoffice.org] openoffice.org: component manager is not
>  available; openoffice won't start
> 
> This is pending, I just got the request to wait for a upload for one week,
> otherwise the build priority of the package would be decreased...

I have read the bug list, but was too blind to see anything related to me - 
sorry.

> 
> > (gdb)  thread apply all bt full
> > Thread 1 (Thread 0x77fb87b0 (LWP 21560)):
> > #0  0x7fffe3c1143b in store::OStorePageBIOS::acquirePage () from
> > /usr/lib/ure/lib/libstore.so.3 No locals.
> > #1  0x7fffe3c19da9 in store::OStoreLockBytes::create () from
> > /usr/lib/ure/lib/libstore.so.3 No locals.
> > #2  0x7fffe3c1f9c2 in store_openStream () from
> > /usr/lib/ure/lib/libstore.so.3
> 
> qed. Same bug as the others. Reinstall your packages (for
> /var/lib/openoffice/program/services.rdb) and/or remove
> the rdbs in your /var/spool/openoffice/uno_packages/cache/.

That worked. Thanks a lot.

Gruesse,
-- 
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#567643: openoffice.org: Segfault when starting soffice.bin - testing of 2010-01-30

[Patrick Boettcher]

Package: openoffice.org
Version: 1:3.1.1-14
Severity: normal

OpenOffice unusuable after updating today on testing. Tried to run with clean 
~/.openoffice.org, doesn't help.

Might be something completely unrelated, but I don't know how to find out.

Backtrace:

$  gdb /usr/lib/openoffice/program/soffice.bin
GNU gdb (GDB) 7.0-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/openoffice/program/soffice.bin...Reading symbols 
from /usr/lib/debug/usr/lib/openoffice/program/soffice.bin...done.
(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/lib/openoffice/program/soffice.bin
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x7fffe3c1143b in store::OStorePageBIOS::acquirePage () from 
/usr/lib/ure/lib/libstore.so.3
Current language:  auto
The current source language is "auto; currently c++".

(gdb)  thread apply all bt full
Thread 1 (Thread 0x77fb87b0 (LWP 21560)):
#0  0x7fffe3c1143b in store::OStorePageBIOS::acquirePage () from 
/usr/lib/ure/lib/libstore.so.3
No locals.
#1  0x7fffe3c19da9 in store::OStoreLockBytes::create () from 
/usr/lib/ure/lib/libstore.so.3
No locals.
#2  0x7fffe3c1f9c2 in store_openStream () from 
/usr/lib/ure/lib/libstore.so.3
No locals.
#3  0x7fffe3e36340 in ORegKey::getValueInfo () from 
/usr/lib/ure/lib/libreg.so.3
No locals.
#4  0x7fffe3e335a5 in getValueInfo () from /usr/lib/ure/lib/libreg.so.3
No locals.
#5  0x7fffe408ef7a in stoc_simreg::RegistryKeyImpl::getAsciiListValue ()
from /usr/lib/ure/lib/bootstrap.uno.so
No locals.
#6  0x7fffe407d14d in retrieveAsciiValueList () from 
/usr/lib/ure/lib/bootstrap.uno.so
No locals.
#7  0x7fffe407cf07 in retrieveAsciiValueList () from 
/usr/lib/ure/lib/bootstrap.uno.so
No locals.
#8  0x7fffe407d461 in 
stoc_smgr::ORegistryServiceManager::getFromServiceName ()
from /usr/lib/ure/lib/bootstrap.uno.so
No locals.
#9  0x7fffe40837a9 in 
stoc_smgr::ORegistryServiceManager::loadWithServiceName ()
from /usr/lib/ure/lib/bootstrap.uno.so
No locals.
#10 0x7fffe4083962 in 
stoc_smgr::ORegistryServiceManager::queryServiceFactories ()
from /usr/lib/ure/lib/bootstrap.uno.so
No locals.
#11 0x7fffe407e23a in stoc_smgr::OServiceManager::createInstanceWithContext 
()
from /usr/lib/ure/lib/bootstrap.uno.so
No locals.
#12 0x7fffe407b3c4 in stoc_smgr::OServiceManager::createInstance () from 
/usr/lib/ure/lib/bootstrap.uno.so
No locals.
#13 0x7fffe2d9500b in BasicLocalFileLayer ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#14 0x7fffe2d95236 in SimpleLocalFileLayer ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#15 0x7fffe2d962f5 in configmgr::localbe::createReadonlyLocalFileLayer ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#16 0x7fffe2da2573 in 
configmgr::localbe::LocalStratumBase::createReadonlyFileLayer ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#17 0x7fffe2da31c6 in configmgr::localbe::LocalStratumBase::getLayer ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#18 0x7fffe2da3d69 in configmgr::localbe::LocalSingleStratumBase::getLayer 
()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#19 0x7fffe2d86b17 in 
configmgr::backend::MultiStratumBackend::searchSupportingStrata ()
---Type  to continue, or q  to quit---
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#20 0x7fffe2d88a7e in configmgr::backend::MultiStratumBackend::listLayers ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#21 0x7fffe2d87f02 in 
configmgr::backend::MultiStratumBackend::listOwnLayers ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#22 0x7fffe2d6c2a4 in configmgr::backend::BackendAccess::getLayers ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#23 0x7fffe2d716b7 in configmgr::backend::BackendAccess::getNodeData ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#24 0x7fffe2d36d67 in configmgr::backend::CacheController::loadDirectly ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals.
#25 0x7fffe2d38935 in configmgr::backend::CacheController::loadComponent ()
from /usr/lib/openoffice/program/../basis-link/program/configmgr2.uno.so
No locals

Bug#501704: Linking with llvm 2.3 fails with undefined reference to llvm::verifyFunction

[Patrick Boettcher]

Hi Giridhar,

On Fri, 29 May 2009, Y Giridhar Appaji Nag wrote:


Hi Patrick,

On 08/10/09 19:40 +0200, Patrick Boettcher said ...

Linking my binary which is using LLVM as follows:

g++ `llvm-config --ldflags` `llvm-config --libs` -o compile $^

fails like that:

undefined reference to `llvm::verifyFunction(llvm::Function const&,
llvm::VerifierFailureAction)'


Unfortunately, you raised this bug on 2.3-1~exp0 which is no longer in the
archive.  I noticed that 2.5 does have llvm::verifyFunction.  Would you be
able to re-test this and report back?


Actually it would quite an effort, because we are no longer using any 
packaged llvm. :(


This is because (at least for the time being) on the frontend-part can be 
used as a library. If you writing a backend and if you're adding 
intrinsics you need to handle llvm yourself to keep binary compatibility 
on the IR level and this is what we're doing now...


Sorry,
Patrick.

--
  Mail: patrick.boettc...@desy.de
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#501704: Linking with llvm 2.3 fails with undefined reference to llvm::verifyFunction

[Patrick Boettcher]

Package: llvm
Version: 2.3-1~exp0
Severity: important

Linking my binary which is using LLVM as follows:

g++ `llvm-config --ldflags` `llvm-config --libs` -o compile $^

fails like that:

undefined reference to `llvm::verifyFunction(llvm::Function const&,
llvm::VerifierFailureAction)'

greping for verifyFunction in /usr/lib/llvm find nothing in the .a or .o
files.

When building an AST I think it is common to use verifyFunction (though
not 100% sure) that's why I marked this one as important.

Patrick.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages llvm depends on:
ii  binfmt-support1.2.11 Support for extra binary formats
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.2-1  GCC support library
ii  libstdc++64.3.2-1The GNU Standard C++ Library v3

Versions of packages llvm recommends:
ii  llvm-dev  2.3-1~exp0 common libraries and headers for L

Versions of packages llvm suggests:
pn  llvm-doc   (no description available)

-- no debconf information




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]