Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190858 > unrolled thread

System won't boot anymore after upgrade to jessie

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-09 22:20 +0100
    Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-09 23:00 +0100
      Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-10 11:40 +0100
        Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-10 19:50 +0100
          Re: System won't boot anymore after upgrade to jessie Felix Miata <mrmazda@earthlink.net> - 2018-01-10 22:00 +0100
            Re: System won't boot anymore after upgrade to jessie Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-10 22:20 +0100
              Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-11 01:10 +0100
                Re: System won't boot anymore after upgrade to jessie Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-11 14:50 +0100
                  Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-11 20:30 +0100
                    Re: System won't boot anymore after upgrade to jessie David Wright <deblis@lionunicorn.co.uk> - 2018-01-12 23:20 +0100
                      Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-12 23:30 +0100
                      Re: System won't boot anymore after upgrade to jessie deloptes <deloptes@gmail.com> - 2018-01-13 01:50 +0100
    Re: System won't boot anymore after upgrade to jessie Don Armstrong <don@debian.org> - 2018-01-09 23:00 +0100
      Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-10 11:30 +0100
        Re: System won't boot anymore after upgrade to jessie Sven Hartge <sven@svenhartge.de> - 2018-01-10 12:40 +0100
          Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-10 14:00 +0100
            Re: System won't boot anymore after upgrade to jessie Sven Hartge <sven@svenhartge.de> - 2018-01-10 17:50 +0100
              Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-11 11:50 +0100
                Re: System won't boot anymore after upgrade to jessie Sven Hartge <sven@svenhartge.de> - 2018-01-11 13:10 +0100
                  Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-11 14:00 +0100
              Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-15 13:00 +0100
                Re: System won't boot anymore after upgrade to jessie Sven Hartge <sven@svenhartge.de> - 2018-01-15 15:30 +0100
                  Re: System won't boot anymore after upgrade to jessie Elisabetta Falivene <e.falivene@ilabroma.com> - 2018-01-15 15:30 +0100

Page 1 of 2  [1] 2  Next page →

#190858 — System won't boot anymore after upgrade to jessie

[Multipart message — attachments visible in raw view] — view raw

Hi,
I did an upgrade from debian 7 wheezy to debian 8 jessie on the master of a
cluster (1 master + 8 nodes). It seemed all went well. Then I rebooted the
machine and the problems began. I can't boot the master anymore returning
an error:

*Running scripts/local-block*

*Unable to find LVM volume*


*Running scripts/local-block*

*Unable to find LVM volume*


*... (lot of times)*








*gave up waiting for root device. Common problems:- Boot args (cat
/proc/cmdline)- check rootdelay= (did the sistem wait long enouth?)- check
root= (did the sistem wait for the right device?)- missing modules (cat
/proc/modules; ls /dev)ALERT! /dev/mapper/system-root does not exist.
Dropping to a shell!"*
*modprobe: module ehci-pci not found in modules.dep*

*modprobe: module ehci-orion not found in modules.dep*

*modprobe: module ehci-hcd not found in modules.dep*

*modprobe: module ohci-hcd not found in modules.dep*

*Busybox v1.22.1 (Debian 1:1.22.0-9+deb8u1) built-in shell (ash)*
*Enter help for a list of built-in commands*


* /bin/sh can't access tty job control turned off  *
*(initramfs)*

Anyway, in grub there are two available kernel to boot

*kernel 3.2.0-4-amd64*

*kernel 3.16.0-4-amd64 (that is **3.16.43-2 kernel**)*


Truly, it boots correctly with the old kernel 3.2, but not with 3.16.

In the kernel 3.16 case, moreover, when the initramfs prompt is shown, it
seems not to load the usb keyboard so i'm truly able to do anything. I
tried to boot in 3.16 recovery mode and I get the same error. lvm2 module
is installed and up to date. The system has 6 hard disk in raid as far as i
know.


What is happening?

Thank you very much

Elisabetta

[toc] | [next] | [standalone]

#190859

Elisabetta Falivene wrote:

> I did an upgrade from debian 7 wheezy to debian 8 jessie on the master of
> a cluster (1 master + 8 nodes). It seemed all went well. Then I rebooted
> the machine and the problems began. I can't boot the master anymore
> returning an error:
> 
> *Running scripts/local-block*
> 
> *Unable to find LVM volume*
> 
> 
> *Running scripts/local-block*
> 
> *Unable to find LVM volume*

looks like initrd and/or udev

There were similar issues with upgrade from wheezy to jessie in my upgrades
as well.

I usually boot with usb stick and fix the initrd - you might need to
configure or reconfigure few things. the easiest to try is to recreate
initrd.

But as you did not provide any information how system is setup regarding
lvm, its just guessing

regards

[toc] | [prev] | [next] | [standalone]

#190879

[Multipart message — attachments visible in raw view] — view raw

>
> looks like initrd and/or udev
> There were similar issues with upgrade from wheezy to jessie in my upgrades
> as well.
> I usually boot with usb stick and fix the initrd - you might need to
> configure or reconfigure few things. the easiest to try is to recreate
> initrd.


Yes, all the hints point to that, but I'm not sure I can do this alone
without making a mess and with a machine containing several Terabytes of
data I'm not allowed to :_)


> But as you did not provide any information how system is setup regarding
> lvm, its just guessing
>

It wasn't me to configure the machine in the first place so is a bit
tricky. I can give more information if you can point me out what you could
need. thank you a lot

[toc] | [prev] | [next] | [standalone]

#190904

Elisabetta Falivene wrote:

> It wasn't me to configure the machine in the first place so is a bit
> tricky. I can give more information if you can point me out what you could
> need. thank you a lot

well it is interesting to know if you have raid or so, if your boot and root
are on LVM, or probably only root is on lvm.

Perhaps it will be sufficient to pass root parameter to the kernel

the process to fix initrd is not that complicated

1. boot from rescue media usb like ubuntu
2. become root (sudo bash)
3. vgscan
4. vgchange -ay <volume group>
5. mount root and boot somewhere ex. /mnt/root and /mnt/root/boot (if boot
is separate partition)

6. prepare to chroot
mount --bind /dev  /mnt/root/dev
mount --bind /dev/pts  /mnt/root/dev/pts
mount --bind /proc  /mnt/root/proc
mount --bind /sys  /mnt/root/sys

7. chroot  /mnt/root

now you can fix initrd

example

update-initramfs -u -k `uname -r`

8. update-grub (not really needed, but to be on the safe side)

9. reboot

In addition

7.1 if you need to examine initrd

        cd /tmp/
        mkdir test
        cd test/
        zcat /boot/initrd.img-<version> | cpio -id

        do whatever you need to do

        find . ! -name *~ | cpio -H newc --create | gzip -9
> /boot/initrd.img-<version>


perhaps test this process in VM to get familiar with it before doing this on
production system

IMO it will be solved if you recreate initrd from the chroot environment, if
not see what you have in the initrd ... but perhaps someone else will do
this


regards

[toc] | [prev] | [next] | [standalone]

#190909

deloptes composed on 2018-01-10 19:48 (UTC+0100):

> 7.1 if you need to examine initrd

>         cd /tmp/
>         mkdir test
>         cd test/
>         zcat /boot/initrd.img-<version> | cpio -id

>         do whatever you need to do

>         find . ! -name *~ | cpio -H newc --create | gzip -9
>> /boot/initrd.img-<version>

If you're only interested in initrd examination, and based upon a simplistic
perusal of its changelog, lsinitramfs has been included in initramfs-tools
probably at least 7 years. openSUSE copied it from Mandriva going on 10 years
ago. https://bugzilla.opensuse.org/show_bug.cgi?id=439103#c7
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#190910

On Wed, Jan 10, 2018 at 03:56:17PM -0500, Felix Miata wrote:
> deloptes composed on 2018-01-10 19:48 (UTC+0100):
> 
> > 7.1 if you need to examine initrd
> 
> >         cd /tmp/
> >         mkdir test
> >         cd test/
> >         zcat /boot/initrd.img-<version> | cpio -id
> 
> >         do whatever you need to do
> 
> >         find . ! -name *~ | cpio -H newc --create | gzip -9
> >> /boot/initrd.img-<version>
> 
> If you're only interested in initrd examination, and based upon a simplistic
> perusal of its changelog, lsinitramfs has been included in initramfs-tools
> probably at least 7 years. openSUSE copied it from Mandriva going on 10 years
> ago. https://bugzilla.opensuse.org/show_bug.cgi?id=439103#c7

Moreover, the simple zcat|cpio -i no longer works with stretch's initrd
images.  They're in a different format, and you *have* to use
lsinitramfs or unmkinitramfs to see or extract their contents.

On a jessie system, the zcat|cpio -i may still work (not sure about
backported kernels though).

[toc] | [prev] | [next] | [standalone]

#190915

Greg Wooledge wrote:

> Moreover, the simple zcat|cpio -i no longer works with stretch's initrd
> images.  They're in a different format, and you have to use
> lsinitramfs or unmkinitramfs to see or extract their contents.
> 
> On a jessie system, the zcat|cpio -i may still work (not sure about
> backported kernels though).

I just tested it on stretch

file /boot/initrd.img-4.14.12eko4
/boot/initrd.img-4.14.12eko4: gzip compressed data, last modified: Tue Jan 
9 22:45:46 2018, from Unix

$ zcat /boot/initrd.img-4.14.12eko4 | cpio -id
76825 blocks

so if it is gzip format it works perfectly - what format do you mean?

If you look into /usr/bin/unmkinitramfs it is a shell script

but anyway - good hint

regards

[toc] | [prev] | [next] | [standalone]

#190934

On Thu, Jan 11, 2018 at 01:05:01AM +0100, deloptes wrote:
> Greg Wooledge wrote:
> 
> > Moreover, the simple zcat|cpio -i no longer works with stretch's initrd
> > images.  They're in a different format, and you have to use
> > lsinitramfs or unmkinitramfs to see or extract their contents.
> > 
> > On a jessie system, the zcat|cpio -i may still work (not sure about
> > backported kernels though).
> 
> I just tested it on stretch
> 
> file /boot/initrd.img-4.14.12eko4
> /boot/initrd.img-4.14.12eko4: gzip compressed data, last modified: Tue Jan 
> 9 22:45:46 2018, from Unix
> 
> $ zcat /boot/initrd.img-4.14.12eko4 | cpio -id
> 76825 blocks
> 
> so if it is gzip format it works perfectly - what format do you mean?

Whatever "4.14.12eko4" is, it's not a stretch kernel image.

wooledg:~$ ls /boot
config-3.16.0-4-amd64      initrd.img-4.9.0-4-amd64   System.map-4.9.0-5-amd64
config-4.9.0-4-amd64       initrd.img-4.9.0-5-amd64   vmlinuz-3.16.0-4-amd64
config-4.9.0-5-amd64       lost+found                 vmlinuz-4.9.0-4-amd64
grub                       System.map-3.16.0-4-amd64  vmlinuz-4.9.0-5-amd64
initrd.img-3.16.0-4-amd64  System.map-4.9.0-4-amd64

wooledg:~$ zcat /boot/initrd.img-3.16.0-4-amd64 | cpio -itv | head -3
drwxr-xr-x  10 root     root            0 Apr 10  2017 .
drwxr-xr-x   5 root     root            0 Apr 10  2017 scripts
-rw-r--r--   1 root     root         9187 Apr 17  2016 scripts/functions

wooledg:~$ zcat /boot/initrd.img-4.9.0-5-amd64 | cpio -itv | head -3

gzip: /boot/initrd.img-4.9.0-5-amd64: not in gzip format
cpio: premature end of archive

wooledg:~$ lsinitramfs /boot/initrd.img-4.9.0-5-amd64 | head -3
kernel
kernel/x86
kernel/x86/microcode

wooledg:~$ file /boot/initrd.img-3.16.0-4-amd64 
/boot/initrd.img-3.16.0-4-amd64: gzip compressed data, last modified: Mon Apr 10 14:03:50 2017, from Unix

wooledg:~$ file /boot/initrd.img-4.9.0-5-amd64
/boot/initrd.img-4.9.0-5-amd64: ASCII cpio archive (SVR4 with no CRC)

In fact, I believe the stretch initrd images are sequences of concatenated
cpio archives, some gzipped, some not, possibly with a NUL byte or
something between them.

wooledg:~$ cpio -itv < /boot/initrd.img-4.9.0-5-amd64
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86/microcode
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r--   1 root     root        98304 Apr  9  2017 kernel/x86/microcode/GenuineIntel.bin
194 blocks

Whereas, if you use lsinitramfs, you'll see far more content, from
the subsequent cpio archives in the image.  Or, if you manually
string together multiple cpio commands:

wooledg:~$ { cpio -itv; echo XXXXXXX; zcat | cpio -itv | head -3; } < /boot/initrd.img-4.9.0-5-amd64
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86/microcode
drwxr-xr-x   2 root     root            0 Apr  9  2017 kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r--   1 root     root        98304 Apr  9  2017 kernel/x86/microcode/GenuineIntel.bin
194 blocks
XXXXXXX
drwxr-xr-x  10 root     root            0 Jan  5 08:00 .
drwxr-xr-x   5 root     root            0 Jan  5 08:00 scripts
-rw-r--r--   1 root     root         9394 Mar  6  2017 scripts/functions

I don't actually know how many cpio archives are concatenated together
in that image.  At least two, obviously, with the first uncompressed
and the second gzipped.

[toc] | [prev] | [next] | [standalone]

#190956

Greg Wooledge wrote:

> I don't actually know how many cpio archives are concatenated together
> in that image.  At least two, obviously, with the first uncompressed
> and the second gzipped.

This kernel is custom, produced on one stretch system. On other stretch
system another custom image is as you describe it. Something must be
responsible for producing those images on stretch in different format. Who
knows what is that exactly - would save me some time - is it automatically
done by size or an option somewhere?

regards

[toc] | [prev] | [next] | [standalone]

#191013

On Thu 11 Jan 2018 at 20:26:24 (+0100), deloptes wrote:
> Greg Wooledge wrote:
> 
> > I don't actually know how many cpio archives are concatenated together
> > in that image.  At least two, obviously, with the first uncompressed
> > and the second gzipped.
> 
> This kernel is custom, produced on one stretch system. On other stretch
> system another custom image is as you describe it. Something must be
> responsible for producing those images on stretch in different format. Who
> knows what is that exactly - would save me some time - is it automatically
> done by size or an option somewhere?

It seems likely that it's because you can add blobs to a preexisting
initramfs without polluting it/having to unpack and repack it. Greg's
example seems to contain an Intel blob. Not compressing it could be
down to futility, or even licence restrictions (not "hiding" it).

https://unix.stackexchange.com/questions/243657/appending-files-to-initramfs-image-reliable

BTW the necessity of directories to be unpacked before their contents
still pertains, ie ignore the trick in "cpio -o"'s manpage about using
find … -depth   to create archives in case you are tempted.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#191015

David Wright wrote:

> It seems likely that it's because you can add blobs to a preexisting
> initramfs without polluting it/having to unpack and repack it. Greg's
> example seems to contain an Intel blob. Not compressing it could be
> down to futility, or even licence restrictions (not "hiding" it).

thanks, so is it automatically done by selecting specific options, or is
setup somewhere in config file (/etc/initram... or alike)?

that is indeed very interesting

regards

[toc] | [prev] | [next] | [standalone]

#191016

David Wright wrote:


> 
>
https://unix.stackexchange.com/questions/243657/appending-files-to-initramfs-image-reliable
> 
> BTW the necessity of directories to be unpacked before their contents
> still pertains, ie ignore the trick in "cpio -o"'s manpage about using
> find … -depth   to create archives in case you are tempted.
> 
> Cheers,
> David.

I think it is automatically done when microcode is installed

[toc] | [prev] | [next] | [standalone]

#190860

On Tue, 09 Jan 2018, Elisabetta Falivene wrote:

> Hi,
> I did an upgrade from debian 7 wheezy to debian 8 jessie on the master of a
> cluster (1 master + 8 nodes). It seemed all went well. Then I rebooted the
> machine and the problems began. I can't boot the master anymore returning
> an error:
> 
> *Running scripts/local-block*
> 
> *Unable to find LVM volume*

[...]
> *modprobe: module ehci-pci not found in modules.dep*

[...]

> Truly, it boots correctly with the old kernel 3.2, but not with 3.16.
> 
> In the kernel 3.16 case, moreover, when the initramfs prompt is shown, it
> seems not to load the usb keyboard so i'm truly able to do anything.

This sounds like the initramfs doesn't have the appropriate modules
built into it.

I suspect that your /etc/initramfs-tools/initramfs.conf has MODULES=dep.
You should try changing that to MODULES=most; and then rebuild the
initramfs using something like:

update-initramfs -vu;

This should provide information on the modules that are being added to
the initramfs, which should include the lvm modules and the ehci
modules. [The missing ehci/ohci modules are likely what is causing your
USB keyboard to not work.]

-- 
Don Armstrong                      https://www.donarmstrong.com

The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot
possibly go wrong goes wrong it usually turns out to be impossible to
get at or repair.
 -- Douglas Adams  _Mostly Harmless_

[toc] | [prev] | [next] | [standalone]

#190876

[Multipart message — attachments visible in raw view] — view raw

>
>
> > Truly, it boots correctly with the old kernel 3.2, but not with 3.16.
> >
> > In the kernel 3.16 case, moreover, when the initramfs prompt is shown, it
> > seems not to load the usb keyboard so i'm truly able to do anything.
>
> This sounds like the initramfs doesn't have the appropriate modules
> built into it.
> I suspect that your /etc/initramfs-tools/initramfs.conf has MODULES=dep.
> You should try changing that to MODULES=most; and then rebuild the
> initramfs using something like:
> update-initramfs -vu;
>

Unfortunately is already 'most'. There is a way to check which modules are
included in the actual initramfs?
I'm not sure how initramfs works when you have different kernels available.
There is an initramfs image for each kernel? I mean, if I do an
update-initramfs and I booted with kernel 3.2, the command will affect the
3.2 initramfs or the 3.26 initramfs?
If I screw up the old kernel boot I couldn't boot for good.



> This should provide information on the modules that are being added to
> the initramfs, which should include the lvm modules and the ehci
> modules. [The missing ehci/ohci modules are likely what is causing your
> USB keyboard to not work.]


Yes, there's a specific module to manage raid? Maybe the problem it's that.


2018-01-09 22:56 GMT+01:00 Don Armstrong <don@debian.org>:

> On Tue, 09 Jan 2018, Elisabetta Falivene wrote:
>
> > Hi,
> > I did an upgrade from debian 7 wheezy to debian 8 jessie on the master
> of a
> > cluster (1 master + 8 nodes). It seemed all went well. Then I rebooted
> the
> > machine and the problems began. I can't boot the master anymore returning
> > an error:
> >
> > *Running scripts/local-block*
> >
> > *Unable to find LVM volume*
>
> [...]
> > *modprobe: module ehci-pci not found in modules.dep*
>
> [...]
>
> > Truly, it boots correctly with the old kernel 3.2, but not with 3.16.
> >
> > In the kernel 3.16 case, moreover, when the initramfs prompt is shown, it
> > seems not to load the usb keyboard so i'm truly able to do anything.
>
> This sounds like the initramfs doesn't have the appropriate modules
> built into it.
>
> I suspect that your /etc/initramfs-tools/initramfs.conf has MODULES=dep.
> You should try changing that to MODULES=most; and then rebuild the
> initramfs using something like:
>
> update-initramfs -vu;
>
> This should provide information on the modules that are being added to
> the initramfs, which should include the lvm modules and the ehci
> modules. [The missing ehci/ohci modules are likely what is causing your
> USB keyboard to not work.]
>
> --
> Don Armstrong                      https://www.donarmstrong.com
>
> The major difference between a thing that might go wrong and a thing
> that cannot possibly go wrong is that when a thing that cannot
> possibly go wrong goes wrong it usually turns out to be impossible to
> get at or repair.
>  -- Douglas Adams  _Mostly Harmless_
>
>

[toc] | [prev] | [next] | [standalone]

#190886

Elisabetta Falivene <e.falivene@ilabroma.com> wrote:

> Unfortunately is already 'most'. 

Please check if you have a file /etc/initramfs-tools/conf.d/driver-policy
or any other file containing a different configuration. Anything in
/etc/initramfs-tools/conf.d/ takes precedence over the main config file.

> There is a way to check which modules are included in the actual
> initramfs?

There is "lsinitramfs" from initramfs-tools.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190891

[Multipart message — attachments visible in raw view] — view raw

>
>
> > Unfortunately is already 'most'.
>
> Please check if you have a file /etc/initramfs-tools/conf.d/driver-policy
> or any other file containing a different configuration. Anything in
> /etc/initramfs-tools/conf.d/ takes precedence over the main config file.
>

Thank you, it was "dep" indeed!


>
> > There is a way to check which modules are included in the actual
> > initramfs?
>
> There is "lsinitramfs" from initramfs-tools.
>

Precious! Lvm seems to be there. From the error my system throw, I have to
include at least ehci-pci, ehci-orion, ehci-hcd and ohci-hcd and have back
the control of the usb keyboard.

Reading here, though I think they were talking about ubuntu, (
https://ubuntuforums.org/showthread.php?t=1365365) there is a module to
manage raid called dmraid. Maybe including that could solve the problem?

Here is my lsinitramfs output for the not booting kernel

/boot/initrd.img-3.16.0-4-amd64
.
sbin
sbin/mdmon
sbin/lvm
sbin/sulogin
sbin/dmsetup
sbin/rmmod
sbin/blkid
sbin/udevadm
sbin/e2fsck
sbin/fsck.ext4
sbin/modprobe
sbin/mdadm
sbin/vgchange
sbin/fsck
sbin/logsave
run
lib
lib/modprobe.d
lib/modprobe.d/aliases.conf
lib/modules
lib/modules/3.16.0-4-amd64
lib/modules/3.16.0-4-amd64/modules.dep.bin
lib/modules/3.16.0-4-amd64/modules.alias
lib/modules/3.16.0-4-amd64/modules.builtin.bin
lib/modules/3.16.0-4-amd64/modules.symbols
lib/modules/3.16.0-4-amd64/modules.dep
lib/modules/3.16.0-4-amd64/modules.devname
lib/modules/3.16.0-4-amd64/kernel
lib/modules/3.16.0-4-amd64/kernel/drivers
lib/modules/3.16.0-4-amd64/kernel/drivers/ata
lib/modules/3.16.0-4-amd64/kernel/drivers/ata/libahci.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/ata/ahci.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/ata/libata.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/acpi
lib/modules/3.16.0-4-amd64/kernel/drivers/acpi/thermal.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/acpi/fan.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/input
lib/modules/3.16.0-4-amd64/kernel/drivers/input/evdev.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/thermal
lib/modules/3.16.0-4-amd64/kernel/drivers/thermal/thermal_sys.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/usb
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/core
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/core/usbcore.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/common
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/common/usb-common.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/host
lib/modules/3.16.0-4-amd64/kernel/drivers/usb/host/uhci-hcd.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/hid
lib/modules/3.16.0-4-amd64/kernel/drivers/hid/hid.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/hid/usbhid
lib/modules/3.16.0-4-amd64/kernel/drivers/hid/usbhid/usbhid.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/scsi
lib/modules/3.16.0-4-amd64/kernel/drivers/scsi/scsi_mod.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/scsi/sd_mod.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md
lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid456.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-snapshot.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid1.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-region-hash.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-log.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid0.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/linear.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-mirror.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-raid.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-mod.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid10.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/multipath.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/md-mod.ko
lib/modules/3.16.0-4-amd64/kernel/drivers/md/dm-bufio.ko
lib/modules/3.16.0-4-amd64/kernel/lib
lib/modules/3.16.0-4-amd64/kernel/lib/raid6
lib/modules/3.16.0-4-amd64/kernel/lib/raid6/raid6_pq.ko
lib/modules/3.16.0-4-amd64/kernel/lib/crc16.ko
lib/modules/3.16.0-4-amd64/kernel/lib/crc-t10dif.ko
lib/modules/3.16.0-4-amd64/kernel/arch
lib/modules/3.16.0-4-amd64/kernel/arch/x86
lib/modules/3.16.0-4-amd64/kernel/arch/x86/crypto
lib/modules/3.16.0-4-amd64/kernel/arch/x86/crypto/crct10dif-pclmul.ko
lib/modules/3.16.0-4-amd64/kernel/fs
lib/modules/3.16.0-4-amd64/kernel/fs/mbcache.ko
lib/modules/3.16.0-4-amd64/kernel/fs/ext4
lib/modules/3.16.0-4-amd64/kernel/fs/ext4/ext4.ko
lib/modules/3.16.0-4-amd64/kernel/fs/jbd2
lib/modules/3.16.0-4-amd64/kernel/fs/jbd2/jbd2.ko
lib/modules/3.16.0-4-amd64/kernel/crypto
lib/modules/3.16.0-4-amd64/kernel/crypto/crct10dif_generic.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/crct10dif_common.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/xor.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx/async_tx.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx/async_xor.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx/async_memcpy.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx/async_raid6_recov.ko
lib/modules/3.16.0-4-amd64/kernel/crypto/async_tx/async_pq.ko
lib/modules/3.16.0-4-amd64/modules.order
lib/modules/3.16.0-4-amd64/modules.symbols.bin
lib/modules/3.16.0-4-amd64/modules.softdep
lib/modules/3.16.0-4-amd64/modules.builtin
lib/modules/3.16.0-4-amd64/modules.alias.bin
lib/systemd
lib/systemd/systemd-udevd
lib/udev
lib/udev/scsi_id
lib/udev/ata_id
lib/udev/rules.d
lib/udev/rules.d/80-drivers.rules
lib/udev/rules.d/55-dm.rules
lib/udev/rules.d/50-firmware.rules
lib/udev/rules.d/60-persistent-storage-dm.rules
lib/udev/rules.d/63-md-raid-arrays.rules
lib/udev/rules.d/50-udev-default.rules
lib/udev/rules.d/56-lvm.rules
lib/udev/rules.d/60-persistent-storage.rules
lib/udev/rules.d/64-md-raid-assembly.rules
lib/udev/hotplug.functions
lib/klibc-IpHGKKbZiB_yZ7GPagmQz2GwVAQ.so
lib/x86_64-linux-gnu
lib/x86_64-linux-gnu/libc.so.6
lib/x86_64-linux-gnu/libudev.so.1
lib/x86_64-linux-gnu/libdl.so.2
lib/x86_64-linux-gnu/libcom_err.so.2
lib/x86_64-linux-gnu/libcrypt.so.1
lib/x86_64-linux-gnu/libblkid.so.1
lib/x86_64-linux-gnu/libdevmapper-event.so.1.02.1
lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
lib/x86_64-linux-gnu/libselinux.so.1
lib/x86_64-linux-gnu/libpcre.so.3
lib/x86_64-linux-gnu/libuuid.so.1
lib/x86_64-linux-gnu/libe2p.so.2
lib/x86_64-linux-gnu/librt.so.1
lib/x86_64-linux-gnu/libkmod.so.2
lib/x86_64-linux-gnu/libtinfo.so.5
lib/x86_64-linux-gnu/libreadline.so.5
lib/x86_64-linux-gnu/libacl.so.1
lib/x86_64-linux-gnu/libpthread.so.0
lib/x86_64-linux-gnu/libext2fs.so.2
lib/x86_64-linux-gnu/libmount.so.1
lib/x86_64-linux-gnu/libattr.so.1
init
conf
conf/arch.conf
conf/initramfs.conf
conf/mdadm
conf/conf.d
conf/conf.d/driver-policy
conf/conf.d/resume
scripts
scripts/local-premount
scripts/local-premount/resume
scripts/local-premount/ORDER
scripts/local-block
scripts/local-block/lvm2
scripts/local-block/ORDER
scripts/functions
scripts/init-top
scripts/init-top/all_generic_ide
scripts/init-top/keymap
scripts/init-top/udev
scripts/init-top/blacklist
scripts/init-top/ORDER
scripts/local-top
scripts/local-top/lvm2
scripts/local-top/mdadm
scripts/local-top/ORDER
scripts/local
scripts/nfs
scripts/init-bottom
scripts/init-bottom/udev
scripts/init-bottom/ORDER
etc
etc/ld.so.conf
etc/lvm
etc/lvm/lvm.conf
etc/modprobe.d
etc/modprobe.d/mdadm.conf
etc/modprobe.d/fbdev-blacklist.conf
etc/mtab
etc/udev
etc/udev/udev.conf
etc/e2fsck.conf
etc/mdadm
etc/mdadm/mdadm.conf
etc/fstab
etc/ld.so.cache
etc/ld.so.conf.d
etc/ld.so.conf.d/x86_64-linux-gnu.conf
etc/ld.so.conf.d/libc.conf
etc/ld.so.conf.d/zz_i386-biarch-compat.conf
bin
bin/dmesg
bin/dd
bin/losetup
bin/mknod
bin/umount
bin/sleep
bin/nfsmount
bin/ls
bin/insmod
bin/chroot
bin/resume
bin/reboot
bin/false
bin/mkfifo
bin/kmod
bin/poweroff
bin/halt
bin/cpio
bin/gzip
bin/mkdir
bin/udevadm
bin/run-init
bin/readlink
bin/mv
bin/nuke
bin/pivot_root
bin/sync
bin/ipconfig
bin/true
bin/kill
bin/mount
bin/cat
bin/uname
bin/minips
bin/fstype
bin/gunzip
bin/ln
bin/reset
bin/fgrep
bin/last
bin/sha256sum
bin/realpath
bin/dumpkmap
bin/stat
bin/login
bin/renice
bin/sed
bin/ping6
bin/unxz
bin/who
bin/dumpleases
bin/ar
bin/wget
bin/cttyhack
bin/tar
bin/expr
bin/whoami
bin/echo
bin/od
bin/run-parts
bin/tail
bin/sha1sum
bin/rpm2cpio
bin/ash
bin/hexdump
bin/patch
bin/strings
bin/df
bin/chown
bin/hostid
bin/tee
bin/bzip2
bin/uncompress
bin/ping
bin/lzma
bin/logname
bin/nslookup
bin/stty
bin/more
bin/tftp
bin/rev
bin/basename
bin/wc
bin/telnet
bin/unzip
bin/ipcalc
bin/unlzma
bin/expand
bin/less
bin/sh
bin/vi
bin/dnsdomainname
bin/openvt
bin/uudecode
bin/chmod
bin/traceroute6
bin/uniq
bin/xzcat
bin/du
bin/cp
bin/microcom
bin/pwd
bin/logger
bin/id
bin/printf
bin/nc
bin/unix2dos
bin/uptime
bin/tty
bin/chgrp
bin/lzopcat
bin/deallocvt
bin/top
bin/free
bin/which
bin/seq
bin/unexpand
bin/ftpget
bin/[[
bin/cal
bin/grep
bin/yes
bin/unlzop
bin/traceroute
bin/rm
bin/[
bin/awk
bin/find
bin/xargs
bin/uuencode
bin/ps
bin/taskset
bin/chvt
bin/sort
bin/bunzip2
bin/fold
bin/getopt
bin/busybox
bin/rpm
bin/xz
bin/sha512sum
bin/ftpput
bin/pidof
bin/setkeycodes
bin/watch
bin/hostname
bin/dirname
bin/date
bin/clear
bin/tac
bin/cmp
bin/rmdir
bin/groups
bin/lzcat
bin/head
bin/usleep
bin/env
bin/touch
bin/test
bin/egrep
bin/dc
bin/lzop
bin/killall
bin/bzcat
bin/diff
bin/tr
bin/md5sum
bin/zcat
bin/timeout
bin/mt
bin/cut
bin/ionice
bin/dos2unix
bin/setsid
bin/netstat
bin/time
sbin/modinfo
sbin/mkswap
sbin/loadkmap
sbin/httpd
sbin/udhcpd
sbin/syslogd
sbin/rdate
sbin/watchdog
sbin/route
sbin/pivot_root
sbin/acpid
sbin/adjtimex
sbin/switch_root
sbin/mdev
sbin/getty
sbin/udhcpc
sbin/depmod
sbin/blockdev
sbin/fstrim
sbin/init
sbin/hwclock
sbin/arping
sbin/logread
sbin/halt
sbin/ifconfig
sbin/poweroff
sbin/freeramdisk
sbin/lsmod
sbin/nameif
sbin/swapoff
sbin/reboot
sbin/sysctl
sbin/devmem
sbin/loadfont
sbin/chroot
sbin/insmod
sbin/start-stop-daemon
sbin/vconfig
sbin/arp
sbin/losetup
sbin/klogd
sbin/brctl
sbin/ip
sbin/swapon
bin/mktemp
lib64
lib64/ld-linux-x86-64.so.2

[toc] | [prev] | [next] | [standalone]

#190903

Elisabetta Falivene <e.falivene@ilabroma.com> wrote:

>>> Unfortunately is already 'most'.

>> Please check if you have a file /etc/initramfs-tools/conf.d/driver-policy
>> or any other file containing a different configuration. Anything in
>> /etc/initramfs-tools/conf.d/ takes precedence over the main config file.

> Thank you, it was "dep" indeed!

Then remove those additional files, check that MODULES=most is set in
/etc/initramfs-tools/initramfs.conf, do a "update-initramfs -u -kall",
and you should be good to go.

> Reading here, though I think they were talking about ubuntu, (
> https://ubuntuforums.org/showthread.php?t=1365365) there is a module to
> manage raid called dmraid. Maybe including that could solve the problem?

No, dmraid is for Controller-based SoftRAID, often used with Windows.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190927

[Multipart message — attachments visible in raw view] — view raw

>
>
> > Thank you, it was "dep" indeed!
>
> Then remove those additional files, check that MODULES=most is set in
> /etc/initramfs-tools/initramfs.conf, do a "update-initramfs -u -kall",
> and you should be good to go.
>

The driver policy file? It is safe to just remove it?

Btw, isn't a bit dangerous to use -kall? The documentation says the kall
will make the change affect all the initramfs on the machine. If the one
actually working gets modified and starts to have problems I could not be
able to boot for good, couldn't?

Just to explore the safest way, if i make a copy of the initramfs actually
present in /boot (/boot/initrd.img-3.16.0-4-amd64 (bad one, not booting)
and /boot/initrd.img-3.2.0-4-amd64 (good one, booting) ), then I do
update-initramfs and it doesn't work, to restore the previous situation,
rewriting the modified initramfs file with the old one is enough? Or
alternatively I can create a new initramfs from scratch and boot that one?


>
> > Reading here, though I think they were talking about ubuntu, (
> > https://ubuntuforums.org/showthread.php?t=1365365) there is a module to
> > manage raid called dmraid. Maybe including that could solve the problem?
>
> No, dmraid is for Controller-based SoftRAID, often used with Windows


Great, thanks!
betta

[toc] | [prev] | [next] | [standalone]

#190928

Elisabetta Falivene <e.falivene@ilabroma.com> wrote:
>>> Thank you, it was "dep" indeed!

>> Then remove those additional files, check that MODULES=most is set in
>> /etc/initramfs-tools/initramfs.conf, do a "update-initramfs -u -kall",
>> and you should be good to go.

> The driver policy file? It is safe to just remove it?

Yes. It is a left-over from something. It is old and it is certainly not
needed, it is just annoying.

I had it on my Wheezy systems and removed it during the upgrade to
Jessie, because it was causing the same problems you had.

> Btw, isn't a bit dangerous to use -kall? The documentation says the kall
> will make the change affect all the initramfs on the machine. If the one
> actually working gets modified and starts to have problems I could not be
> able to boot for good, couldn't?

In theory. But this change just makes your initramfs more universal and
thus more likely to boot on different hardware than breaking anything.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190931

[Multipart message — attachments visible in raw view] — view raw

>
>
> > The driver policy file? It is safe to just remove it?
>
> Yes. It is a left-over from something. It is old and it is certainly not
> needed, it is just annoying.
>

Ok


>
> I had it on my Wheezy systems and removed it during the upgrade to
> Jessie, because it was causing the same problems you had.
>
> > Btw, isn't a bit dangerous to use -kall? The documentation says the kall
> > will make the change affect all the initramfs on the machine. If the one
> > actually working gets modified and starts to have problems I could not be
> > able to boot for good, couldn't?
>
> In theory. But this change just makes your initramfs more universal and
> thus more likely to boot on different hardware than breaking anything.
>

Got it! Thank you very much!
b

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web