You're right!
Thanks
2018-01-15 15:19 GMT+01:00 Sven Hartge :
> Elisabetta Falivene wrote:
>
> > In the end, changing in
> > /etc/initramfs-tools/conf.d/driver-policy
> > MODULES=dep to MODULES=most and
> > and then
> > update-initramfs -u -k 3.16.0.4-amd64 (in my case it was that the
> > proble
Elisabetta Falivene wrote:
> In the end, changing in
> /etc/initramfs-tools/conf.d/driver-policy
> MODULES=dep to MODULES=most and
> and then
> update-initramfs -u -k 3.16.0.4-amd64 (in my case it was that the
> problematic kernel)
> did the trick.
As I said: you are better of if you just remove
In the end, changing in
/etc/initramfs-tools/conf.d/driver-policy
MODULES=dep to MODULES=most and
and then
update-initramfs -u -k 3.16.0.4-amd64 (in my case it was that the
problematic kernel)
did the trick.
My debian is booting correctly again! Thank you very much to all of you!
Elisabetta
2018
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 arch
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
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 o
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
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.
> >
> >
>
>
> > 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
Elisabetta Falivene 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 i
>
>
> > 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 dange
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
> b
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- | cpio -id
>
> > do whatever you
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- | cpio -id
> do whatever you need to do
> find . ! -name *~ | cpio -H newc --create | gzip -9
>> /boo
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 probab
Elisabetta Falivene 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
>
>
> > 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!
Elisabetta Falivene 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
>
> 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 p
>
>
> > 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 mo
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-
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:
>
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*
23 matches
Mail list logo
