Bug#944839: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned: issues for application crash with this kernel
that solves it, thanks fwiw, I'm reading about this kernel option from lwn, https://lwn.net/Articles/673597/ and the opinions vary whether there's security improvement having it enabled/disabled... this may not be desirable for multi-user systems, here it's just a workstation so I suppose it is ok to use this mode as enabled. On 2019-11-16 3:13 a.m., Bastian Blank wrote: On Fri, Nov 15, 2019 at 11:23:09PM -0500, westlake wrote: When this kernel is used, the latest version of chrome crashes saying it can't launch because it is not able to create its own sandbox. (chrome "Version 78.0.3904.97 (Official Build) (64-bit)") Please try: | sysctl -w kernel.unprivileged_userns_clone=1 Bastian
Bug#944839: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned: issues for application crash with this kernel
Package: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned Version: 5.2.17-1~bpo10+1 Severity: important When this kernel is used, the latest version of chrome crashes saying it can't launch because it is not able to create its own sandbox. (chrome "Version 78.0.3904.97 (Official Build) (64-bit)") I like to have an rt kernel because I sometimes use jackdbus and ardour. I do not know if earlier versions of this application are an issue with this bpo kernel, but another application I have called "pulse-sms"(an .appimage application that is self contained) also shares the same error of not being able to create a "sandbox" and abruptly quits. I think there's something missing in this kernel, because I can boot into my custom "make deb-pkg" kernel with RT patches and both chrome and pulse-sms work again without issue. So it's more than chrome -- probably even affects debian-packaged applications. But the ubiquity of chrome tells me that filing this bug is important, so I marked it as such. If this helps: my kernel was compiled with gcc-8, and is kernel release 5.2.14 with official 5.2.14-rt7 RT-patches from kernel.org -- nothing else than kernel optons with "make menuconfig" and then performing "make deb-pkg"..
Bug#838607: linux-image-4.7.0-0.bpo.1-amd64-unsigned: new file date writing issue
Package: linux-image-4.7.0-0.bpo.1-amd64-unsigned Version: 4.7.2-1~bpo8+1 Severity: normal There's a bug with ext4 on the new 4.7 kernel -- rare but it happened here on an ext4 mountpoint (/home /dev/md1 ext4 rw,relatime,data=ordered) when a new file is created, the "create time" is not properly set.(2014 was written as the create year instead of 2016) it occured today after I updated to 4.7 so I can only assume it has something to do with it.. my system here has "mdadm" containers, and perhaps it's possible a set of conditions allowed this rarity to occur.
Bug#829532: linux-image-4.6.0-0.bpo.1-amd64: breaks qemu-nbd
Package: linux-image-4.6.0-0.bpo.1-amd64
Version: 4.6.1-1~bpo8+1
Severity: normal
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions
qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail
Bug#783958: linux-image-3.16.0-4-amd64: iptables fails to work with jessie's kernel
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt9-3~deb8u1 Severity: important A simple test with iptables against Jessie's default kernel fails to work, but using a custom kernel not from repositories and iptables works. A simple test is done allowing one match rule, and it can immediately be seen there is a problem with either iptables or Jessie's default kernel of 3.16.0-4-amd64. eg, iptables -I INPUT -p tcp --dport 22 -j ACCEPT iptables -P INPUT DROP traffic to port 22 later works if I apply iptables -P INPUT ACCEPT Using a non-stock kernel, the above example works exactly as expected. Since iptables can work with another kernel then I suppose there is something wrong with linux-image-3.16.0-4-amd64 preventing iptables from working. please have a look thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55439a94.6060...@videotron.ca
Bug#783958: linux-image-3.16.0-4-amd64: iptables fails to work with jessie's kernel
please close this bugreport (discovered this bug should be handled better by another source -- openvswitch) thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5543d6cb.6070...@videotron.ca
Bug#783437: linux-image-3.16.0-4-amd64: buggy debian patch to kernel upstream.
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt9-3~deb8u1 Severity: normal Not sure what is being changed in the kernel going for jessie, but from what I can tell for two upgrades I had to resort to a newer kernel from debian's experimental. I have got two systems here that get the same problem, and this relates to the video/Xorg driver issue. Though it may sound remotely unrelated, I think something that debian is doing with upstream is the reason why there is the same video driver issue. kernel linux-image-3.16.0-4-amd64 is problematic (as well as the others of amd64 3.14+ from backports or updates,.. no different result), for nvidia and intel gfx. The driver loads up shown in X log, and there is nothing extra more in detail to know really -- same symptom going all the way back from kernel 3.2 and up. So it's been happening before jessie but the user can manage to find a workaround with it.(though not easily, it's difficult unless one is familiar with it) 1- Video driver loads 2- Xorg attempts to start, no edid information is ever picked up. Graphic server fails to find any screens configured because for some reason it knows there is a video card(using the desired driver) but doesn't apply to using it at all and X immediately quits. (I don't bother to using fallback drivers as there's no point to using them when accelerated graphics is instead needed) If the same thing is broken (two machines, one nvidia, the other stocked intel) and I know it has something to do with debian's adjustments to the upstream because when I recompile outside debian's standard repository (backports or stable), the problem is then resolved. but maybe someone out there knows it better than I can-- something in 3.17 rc5 from experimental is enabling more support for video drivers to be working in general, at least for the two systems here being tested. What's common between these two machines. One uses the nvidia driver with the 3.17rc5 kernel, the other uses just this same kernel and uses the stocked intel video driver. Both systems then get their video detection resolved as E-did can be picked up by the X server.. I know there's a lot of blame on nvidia drivers, but this also happens with a kernel's stocked intel driver which should be working regardless the problems with nouveau and nvidia. Since there is a problem with even the stocked intel driver in a debian repackaging for Jessie(3.16.0-4), and using 3.17rc5 actually overcomes it, then perhaps this might offer a clue to something wrong with one of the patches going into 3.16. so please have a look thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553d9acc.7090...@videotron.ca
Bug#765690: packagename: type_problemheading_here
Package: linux-image-3.17-rc5-amd64 Version: 3.17~rc5-1~exp1 Severity: normal hi, can the following be a kernel problem? I'll explain a bit, it's got to do with the iptables command.. (fwiw, there's a bug with the lsb-functions, 40-systemd which is instead this can be used to test rules.v4 iptables-restore /etc/iptables/rules.v4 ) output, iptables-restore v1.4.21: iptables-restore: unable to initialize table 'nat' Error occurred at line: 2 Try `iptables-restore -h' or 'iptables-restore --help' for more information all basic nat modules I can come up with modprobe are loaded, but iptables continues to fail, I checked if NAT is compiled /boot/config-3.17-rc5-amd64 lsmod |grep nat act_nat12501 0 nft_chain_nat_ipv4 12552 0 nft_nat12507 0 nf_tables 54396 2 nft_chain_nat_ipv4,nft_nat nf_nat_ipv412912 1 nft_chain_nat_ipv4 nf_nat_ipv612920 0 nf_nat 18241 4 nft_chain_nat_ipv4,nft_nat,nf_nat_ipv4,nf_nat_ipv6 nf_conntrack 87476 5 nf_nat,nf_nat_ipv4,nf_nat_ipv6,nf_conntrack_ipv4,nf_conntrack_ipv6 so it looks like everything is compiled and loads, but iptables fails for v4. fwiw, the ip6tables loads properly for rules.v6.. If I recall the previous kernel in testing(vmlinuz-3.16-2-amd64) can have the iptables load ipv4 rules timely without issue -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5440f998.9080...@videotron.ca
Bug#765691: linux-image-3.17-rc5-amd64: nat failure with iptables
Package: linux-image-3.17-rc5-amd64 Version: 3.17~rc5-1~exp1 Severity: normal hi, can the following be a kernel problem? I'll explain a bit, it's got to do with the iptables command.. (fwiw, there's a bug with the lsb-functions, 40-systemd which is instead this can be used to test rules.v4 iptables-restore /etc/iptables/rules.v4 ) output, iptables-restore v1.4.21: iptables-restore: unable to initialize table 'nat' Error occurred at line: 2 Try `iptables-restore -h' or 'iptables-restore --help' for more information all basic nat modules I can come up with modprobe are loaded, but iptables continues to fail, I checked if NAT is compiled /boot/config-3.17-rc5-amd64 lsmod |grep nat act_nat12501 0 nft_chain_nat_ipv4 12552 0 nft_nat12507 0 nf_tables 54396 2 nft_chain_nat_ipv4,nft_nat nf_nat_ipv412912 1 nft_chain_nat_ipv4 nf_nat_ipv612920 0 nf_nat 18241 4 nft_chain_nat_ipv4,nft_nat,nf_nat_ipv4,nf_nat_ipv6 nf_conntrack 87476 5 nf_nat,nf_nat_ipv4,nf_nat_ipv6,nf_conntrack_ipv4,nf_conntrack_ipv6 so it looks like everything is compiled and loads, but iptables fails for v4. fwiw, the ip6tables loads properly for rules.v6.. If I recall the previous kernel in testing(vmlinuz-3.16-2-amd64) can have the iptables load ipv4 rules timely without issue -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5440f9f1.7010...@videotron.ca
Bug#765690: packagename: type_problemheading_here
There's a bug in multiple places. 1) netfilter-persistent/systemd fails https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764950 2) Emailed J.Wiltshire, he never responded. He's responsible for the netfilter package 3) There is a systemd bug related to the netfilter-persistent package, filed over here, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765683 linux (3.17-1~exp1) experimental; urgency=medium * New upstream release: http://kernelnewbies.org/Linux_3.17 * armel: Drop ixp4xx image. * topconfig: Reenable renamed IP_NF_NAT. (closes #762458) * udeb: refix renamed i2c-core. -- maximilian attems m...@debian.org Tue, 14 Oct 2014 23:01:39 +0200 linux (3.17~rc5-1~exp1) experimental; urgency=medium * New upstream release candidate [ Ben Hutchings ] * aufs: Update to aufs3.x-rcN-20140908 [ maximilian attems ] * udeb: fix renamed i2ccore. -- maximilian attems m...@debian.org Thu, 18 Sep 2014 23:50:00 +0200 http://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_3.17-1~exp1_changelog I think it's very clear there was indeed a change with nat in this kernel. This is not a configuration issue, otherwise iptables would be loading successfully without crashing with a NAT message. fwiw, iptables relies on the kernel for the NAT modules, so it appears quite clearly what the problem is, and that is this kernel has something new with NAT causing iptables to fail. Not rocket science. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544113ed.3000...@videotron.ca
Bug#765690: packagename: type_problemheading_here
this report is for package maintainers, not clueless idiots. thank you -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5441201a.2070...@videotron.ca
Bug#765582: linux-image-3.16-2-amd64: port 138 traffic generated
Package: linux-image-3.16-2-amd64 Version: 3.16.3-2 Severity: important There's port 138 traffic on a virtual 1:1 ethernet wire and I'm trying to find out where it's coming from, anyone want to tackle this? :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765502 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fb5bb.7010...@videotron.ca
Bug#765582: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#765582: linux-image-3.16-2-amd64: port 138 traffic generated)
thanks I found the culprit, and not because I didn't know what I was doing.. the output from the macvtaps that I'm using here as network interfaces was letting traffic from the hypervisor. But the problem didn't arise due to it not being setup properly but rather a technical limitation of the classical bridge which can't be moved into a separate namespace.. If the macvtap could be moved to another namespace then this problem could be prevented, but the particular underlying nic interface holding the macvtap is not designed to be moved out of the root namespace. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54403a5d.8040...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
apt-get install linux-image-3.14-2-amd64enter and fails. I suggest to close the bug because nobody is using a custom kernel. The scripts are looking for /lib/modules/kernel version where kernel version==My unpackaged kernel that has been copied to /boot. And this is the running kernel. I already explained what I did to work around it so that apt-get does not fail. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54270f36.3000...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
If someone tests it without any kernel modules paths (/lib/modules empty), and with a kernel(not needing an initrd in /boot as well), apt-get install kernel will fail I can understand why nobody wants to verify anything here because it takes time to compile a kernel without initrd nor any /lib/modules, and then boot up with it to see if this error occurs. I doubt anyone here is using this type of custom kernel with these conditions otherwise they'd notice the same. fwiw, the workaround output from message 5(first) message is actually completely a coincidence of wording from program output. the actual workaround I took can be found in message 12 and 17. The reason why I said is a bug or not, is testifying if this is a policy just as the name of the file edited for working around this is /etc/initramfs-tools/conf.d/driver-policy There's not much else to this report. If you want me to confirm anything you'll just have to apply the same condition tests. 1) no /lib/modules have this directory EMPTY 2) /boot/kernel one kernel nothing else (no initrd) 3) Boot this kernel, and try installing a kernel from the debian repos using initramfs 0.116 It'll fail, but that workaround works well to getting a kernel installed. Not rocket science once the same conditions are applied and should be immediately noticeable once you run a simple apt-get. The only thing non-debian on this system is that custom kernel which is booted from. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54274ea6.1020...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
the kernel version is quite irrelevant because it occurs with any custom kernel that does not have modules built outside the kernel. So it happens for 3.14, 3.15 and 3.16 kernels that don't have any /lib/modules/kernel version paths needed for them. The problem is dramatic because I would be using such a particular kernel build and not any other available kernel and the user is stuck if they ever wish to install a packaged kernel later. Simply the custom kernel booted only has it's kernel image being booted from and nothing else. For some reason the workaround of commenting out a line in a policy driver file seems to do the trick. The name of the kernel in the quotation is actually /boot/3.16.1--std-ipv6-64-vps and it doesn't have any modules external of it(this is by intention to minimize surface attacks on a server) The scripts are definitely failing when a module path doesn't exists for the current runinng kernel and I was hoping it is not something that is mandatory by debian policy, if it is then feel free to close this bug report. thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54258749.4020...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
(/boot/bzImage-3.16.1--std-ipv6-64 to be more complete, but it occurs with any kernel that doesn't have modules built externally) /boot/3.16.1--std-ipv6-64-vps and it doesn't have any modules external of it(this is by intention to minimize surface attacks on a thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54259771.40...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
WARNING: missing /lib/modules/3.16.1--std-ipv6-64-vps ^ Already implies the kernel since the first message. I thought the provided information was replicable enough. If someone wants to test this out, be my guest. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54261568.9060...@videotron.ca
Bug#760525: linux-image-3.14-2-amd64: routing fails
Package: linux-image-3.14-2-amd64 Version: 3.14.15-2 Severity: important Routing fails when there are macvtaps attached and SNAT/DNAT is used for routing with a tap device. (The routing being talked about concerns between eth0's public IP address and tap0 which is not a macvtap device on eth0.) The first test of routing is simple 'Forwarding' is set on eth0, and on a tap device(which was created with ip tuntap) echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding (or sysctl -w net.ipv4.conf.eth0.forwarding=1) echo 1 /proc/sys/net/ipv4/conf/tap0/forwarding On the far end of tap0 (a VM), a station's IP address is being SNAT/DNATted on this hypervisor's eth0 Here's the thing, I know it's a kernel issue because it never fails when I do echo 1 /proc/sys/net/ipv4/conf/all/forwarding echo 0 /proc/sys/net/ipv4/conf/all/forwarding echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding echo 1 /proc/sys/net/ipv4/conf/tap0/forwarding right away after on clean boot (and having started the VM) Don't be distracted by the VM and other things in the way. Here is the condition why this fails, - Macvtap devices on eth0(there's about 3 or 4). When there are no macvtap devices on eth0, routing doesn't need to be fixed using these four commands.. Routing from the tap0 device which later gets natted with eth0 always works but only after I issue these four commands. I believe this is more an upstream issue so I'll be cloning this bugreport. thanks -Scott -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54090009.9010...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
fwiw I commented-out line MODULES=dep (there's only one line in this file) /etc/initramfs-tools/initramfs.conf and installation(apt-get -f install) was able to complete while making an initrd image for kernel 3.14-2-amd64 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5405050c.5030...@videotron.ca
Bug#760127: initramfs-tools: creating initrd fails
Package: initramfs-tools Version: 0.116 Severity: important a booted custom kernel is being used and installing a new kernel package fails as the initramfs script in /etc/kernel/postinst.d/ fails apt-get install linux-image-3.14-2-amd64enter was issued , and mkinitramfs also fails ' mkinitramfs -k -o initrd.img-3.14-2-amd64 WARNING: missing /lib/modules/3.16.1--std-ipv6-64-vps Device driver support needs thus be built-in linux image! depmod: ERROR: could not open directory /lib/modules/3.16.1--std-ipv6-64-vps: No such file or directory depmod: FATAL: could not search modules: No such file or directory /dev/disk/by-uuid: Is a directory mkinitramfs: for root /dev/disk/by-uuid missing disk/by-uuid /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug ' The current kernel I'm using was compiled with modules built-in the kernel without any external module path. My understanding is if I'm installing a new kernel from a package it should not depend that a module path exists for the current kernel because it could be customized similar to the case I'm using (that is without using a module path) please look into, thanks -Scott -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5403e895.5040...@videotron.ca
Bug#760126: packagename: type_problemheading_here
Package: initramfs-tools Version: 0.116 Severity: important a booted custom kernel is being used and installing a new kernel package fails as the initramfs script in /etc/kernel/postinst.d/ fails apt-get install linux-image-3.14-2-amd64enter was issued , and mkinitramfs also fails ' mkinitramfs -k -o initrd.img-3.14-2-amd64 WARNING: missing /lib/modules/3.16.1--std-ipv6-64-vps Device driver support needs thus be built-in linux image! depmod: ERROR: could not open directory /lib/modules/3.16.1--std-ipv6-64-vps: No such file or directory depmod: FATAL: could not search modules: No such file or directory /dev/disk/by-uuid: Is a directory mkinitramfs: for root /dev/disk/by-uuid missing disk/by-uuid /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug ' The current kernel I'm using was compiled with modules built-in the kernel without any external module path. My understanding is if I'm installing a new kernel from a package it should not depend that a module path exists for the current kernel because it could be customized similar to the case I'm using (that is without using a module path) please look into, thanks -Scott -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5403e847.9060...@videotron.ca
checksum of a kernel needed
i'd like to verify something if this is not too much of an inconvenience... I'd just like to have an md5sum or shasum on this very specific kernel .deb or even if its the kernel image /var/cache/apt/archives/linux-image-3.14-0.bpo.1-686-pae_3.14.7-1~bpo70+1_i386.deb thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e3f137.1090...@videotron.ca
