I have (finally) decided to give Debian 8 a try, after some mucking around I installed. THe install medium was an Debian 8.3 i386 DVD, and was upgraded from the net. The install of the kernel produces the following error..... -----------------cut here------------------------ Processing triggers for initramfs-tools (0.120+deb8u3) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-686-pae mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /etc/initramfs-tools/ Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /boot/initrd.img-3.16.0-4-686-pae with 1. dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for libc-bin (2.19-18+deb8u10) ... Errors were encountered while processing: linux-image-3.16.0-4-686-pae initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) -----------------cut here---------------------- Now it actually works OK, the ramdisk image was installed correctly. What it has done though it prevents the kernel from being upgraded. I have sort of got around this by compiling my own kernel (I do this as a matter of course anyway), this of course required me to dump systemd as it WILL NOT work with a standard kernel from kernel.org. Lindsay
On Monday, 17 July 2017 12:56:19 PM AEST Ray via luv-main wrote:
I have (finally) decided to give Debian 8 a try, after some mucking around I installed. THe install medium was an Debian 8.3 i386 DVD, and was upgraded from the net. The install of the kernel produces the following error.....
Why did you install Debian 8 after Debian 9 has been released?
Processing triggers for initramfs-tools (0.120+deb8u3) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-686-pae mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /etc/initramfs-tools/
Did you try the "MODULES=most" option? If so did it work?
Now it actually works OK, the ramdisk image was installed correctly. What it has done though it prevents the kernel from being upgraded. I have sort of got around this by compiling my own kernel (I do this as a matter of course anyway), this of course required me to dump systemd as it WILL NOT work with a standard kernel from kernel.org.
https://wiki.gentoo.org/wiki/Systemd Why won't it work? Gentoo documents the kernel compilation settings that are needed. https://github.com/systemd/systemd/blob/master/README The systemd git repository has better documentation including settings that should be disabled (which surprised me) and many settings that are needed for optional systemd features. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting zlinew9@virginbroadband.com.au (zlinew9@virginbroadband.com.au):
Now it actually works OK, the ramdisk image was installed correctly. What it has done though it prevents the kernel from being upgraded. I have sort of got around this by compiling my own kernel (I do this as a matter of course anyway), this of course required me to dump systemd as it WILL NOT work with a standard kernel from kernel.org.
If you wish to retain the freedom to compile a kernel _your_ way without special bespoke requirements being imposed on you by systemd, you can do so on Debian systems -- through the simple expedient of apt-get installing one of the other packaged init systems. In Debian 9 'Stretch', those are: openrc, runit, upstart, sysvinit. I installed Debian 8 'Jessie' and documented easy conversion to use the 'Jessie' openrc package, here: http://linuxmafia.com/faq/Debian/openrc-conversion.html Please note carefully the caveats about certain DEs (the kitchen-sink metapackages for GNOME, MATE, Cinnamon, KDE, and Razor-qt) and a couple of other packages with overly large dependency trees (e.g., hplip) and what to do about that. I strongly recommend testing using a VM before taking any such steps on a real system. That is what I did to write the referenced Web page. FYI, I switched that Debian 8 'Jessie' test system to track debian-unstable ('sid'), and it continues to work beautifully, so I expect you would have very good results on Debian 9 'Stretch', the current debian-stable branch. When I have time, I'll probably repeat the VM experiment using a fresh ISO image of Official Debian 9 'stretch', to reconfirm the data on that page. P.S.: If you're compiling your own kernel anyway, and would consider putting systemd in the dustbin, then you can further simplify by compiling monolithically into the kernel binary all drivers essential to early boot and root FS mounting on your hardware. That having been done, you can dispense with the initrd (initial RAMdisk), further simplifying your system. -- Cheers, "The crows seemed to be calling his name, thought Caw." Rick Moen -- Deep Thoughts by Jack Handey rick@linuxmafia.com McQ! (4x80)
On 17.07.2017 17:28, Rick Moen via luv-main wrote:
Quoting zlinew9@virginbroadband.com.au (zlinew9@virginbroadband.com.au):
Now it actually works OK, the ramdisk image was installed correctly. What it has done though it prevents the kernel from being upgraded. I have sort of got around this by compiling my own kernel (I do this as a matter of course anyway), this of course required me to dump systemd as it WILL NOT work with a standard kernel from kernel.org.
If you wish to retain the freedom to compile a kernel _your_ way without special bespoke requirements being imposed on you by systemd, you can do so on Debian systems -- through the simple expedient of apt-get installing one of the other packaged init systems. In Debian 9 'Stretch', those are: openrc, runit, upstart, sysvinit.
I installed Debian 8 'Jessie' and documented easy conversion to use the 'Jessie' openrc package, here: http://linuxmafia.com/faq/Debian/openrc-conversion.html
Please note carefully the caveats about certain DEs (the kitchen-sink metapackages for GNOME, MATE, Cinnamon, KDE, and Razor-qt) and a couple of other packages with overly large dependency trees (e.g., hplip) and what to do about that.
I strongly recommend testing using a VM before taking any such steps on a real system. That is what I did to write the referenced Web page. FYI, I switched that Debian 8 'Jessie' test system to track debian-unstable ('sid'), and it continues to work beautifully, so I expect you would have very good results on Debian 9 'Stretch', the current debian-stable branch.
When I have time, I'll probably repeat the VM experiment using a fresh ISO image of Official Debian 9 'stretch', to reconfirm the data on that page.
P.S.: If you're compiling your own kernel anyway, and would consider putting systemd in the dustbin, then you can further simplify by compiling monolithically into the kernel binary all drivers essential to early boot and root FS mounting on your hardware. That having been done, you can dispense with the initrd (initial RAMdisk), further simplifying your system.
Thank you for the reply, you have actually described almost axactly what I have done. Anything in the nature of experimental configuration or install is done on a spare system. A major reason for compiling my own kernel is to get rid of the ram disk, so all drivers and files systems required for booting are compiled in to the kernel. I like a simple system (I use Lilo for that reason) and I avoid like the plague such "kitchen sink" packages like gnome (for a window manager I run fvwm, one that is very much under rated these days) I have another spare system I will give Debian 9 a go on it following your sugestions. Note: I spent 30 years as a complex systems technician, the experience from that has left two concepts ingrained in my very soul. 1: NEVER TOUCH A SYSTEM THAT IS NOT HAVING ANY PROBLEMS, or when ever something fails, the first port of call is what ever was worked on last. 2: THE MORE COMPLEX ANY SYSTEM BECOMES THE MORE UNRELIABLE IT BECOMES, FULL STOP!!!! Lindsay
participants (3)
-
Rick Moen -
Russell Coker -
zlinew9＠virginbroadband.com.au