SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
A lilo entry that uses an initrd shouldn't contain a 'root=' line as the rootfs is specified by the -r option of the mkinitrd. I have a vague recollection of this causing some issues for people running current around the time that the lilo version was bumped, but I can't remember exactly what it was. IMO best to remove it from the example so as to avoid any chance of confusion.
The 'root=' option in lilo (or the kernel parameters) takes precedence over the parameter specified when creating the initrd. As long as the two options are the same (both the real root file-system) then there is no problem. From the standpoint of flexibility it makes sense to use the lilo parameter, since changing that will always affect which device is mounted, while the parameter to mkinitrd is used only when no kernel parameter is specified. The "init" script for the initrd parses the provided kernel parameters.
In my humble opinion it would be less confusing to remove the parameter from the "mkinitrd" command.
When KDE fires up it reports a "bad battery" with only 38% capacity. Given that I never got more than 2-3 hrs on this heap I find that curious as WinXP (is a corporate laptop I am forced to use) doesn't see this. Maybe related to this syslog entry?
Code:
Oct 19 14:19:36 sauron kernel: [ 6.446244] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Oct 19 14:19:36 sauron kernel: [ 6.856142] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Oct 19 14:19:36 sauron kernel: [ 6.856175] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Haven't played with much else (terminals, Firefox, KDE config), but so far so good. Yay, team!!
The 'root=' option in lilo (or the kernel parameters) takes precedence over the parameter specified when creating the initrd. As long as the two options are the same (both the real root file-system) then there is no problem. From the standpoint of flexibility it makes sense to use the lilo parameter, since changing that will always affect which device is mounted, while the parameter to mkinitrd is used only when no kernel parameter is specified. The "init" script for the initrd parses the provided kernel parameters.
In my humble opinion it would be less confusing to remove the parameter from the "mkinitrd" command.
I've used both (-r /dev/sdax and root = /dev/sdax) together for as long as I can remember for my multiboot boxes, as that makes it easier to see what lilo[.conf] and intrd are loading, and has had no ill effects. Doing it now as a matter of fact. Helps me keep track when switching between OSes and HUGE v. GENERIC.
325.15 has been working well for me. ffmpeg x11grab works just fine.
Yes I have narrowed it down to this . in 14.0 with the new nvidia kernel 319 from the 310 it broke my ability to capture in kdenlive. rolled back was fine.
In 14.1 rc the restrictive build is broken for me I reply For me it does compile and it does limited functions then will Segmentation fault on some codecs.
the same one compiled in the 14.0 environment used in the 14.1 rc does fine . So I will start a new thread in the future on the kdenlive because the newest one coming out the kdenlive 1.0 is going to be very different from what we been seeing. This is the ffmpeg 1.2 that I been compiling with my builds and also with Alien Bob build 14.0.
The Alien Bob 14.0 build works fine in 14.1 rc but that is built in the 14.0 environment.
thanks for all the feed back you slackers are the best.
Tested with this NVIDIA-Linux-x86_64-331.13-beta in 14.1 rc with 14.0 restrictive build, built in 14.0 ffmpeg 1.2.
Last edited by Drakeo; 10-20-2013 at 03:21 PM.
Reason: explain limited functions
On reflection (and a bit of searching of LQ to find my previous posts on this subject) what I was almost but not entirely remembering above is that you end up having problems if you use an encrypted rootfs and pass the luks mapping name with the old style "mkinitrd -r cryptroot", or even root=/dev/mapper/cryptroot from lilo.conf
In lilo.conf you can't put root=cryptroot (it will throw out an error), but if you specify root=/dev/mapper/cryptroot in lilo.conf (as suggested in README_CRYPT.TXT) then that would override the -r cryptroot passed to the initrd and when you get to the following section of code in the initrd's init file you end up with an incorrect assignment.
Code:
if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
CRYPTDEV="luks$(basename $LUKSDEV)"
elif [ "x$ROOTDEV" = "x$(basename $ROOTDEV)" ]; then
CRYPTDEV="$ROOTDEV"
else
CRYPTDEV="luks$(basename $LUKSDEV)"
fi
Instead of setting CRYPTDEV to ROOTDEV (i.e. the 'cryptroot' on the -r) it will fail the condition, fall through to the 'else' and set CRYPTDEV to 'luksnnnn'. As a result, ROOTDEV will still be set to /dev/mapper/cryptroot, but cryptsetup will create a mapping on /dev/mapper/luksnnnn and you get a "Kernel Panic - failed to mount rootfs!"
I'm not certain but I've gotten the idea in my head that before the version bump of lilo it didn't used to pass root= to the kernel if an initrd was used, and this is why this latent problem hasn't hit us until now.
In short, If you're using an encrypted rootfs and if your bootloader passes the root= to the initrd via the kernel args then you better be using the luksnnnn names (e.g. root=/dev/mapper/lukssda1) or you're going to hit a problem.
If you're using the old style 'cryptroot' name, then don't pass the root= argument from your bootloader.
Anyway, that's what I was trying to remember when I posted above.
P.S.
On first thought, there's a temptation to do a quick and dirty fix like this:
... but you have to remember that luks mappings aren't the only thing that lives in /dev/mapper. (LVM for one, and possibly others, md?, mpath?) so this is likely to hit problems in some other circumstances, so I wouldn't recommend it.
Probably better just to get everyone to use the luksnnnn names and leave the old cryptroot stuff to rot. Those who insist on doing it the old way will just have to learn not to put root= in their bootloaders.
Quote:
Originally Posted by Erik_FL
In my humble opinion it would be less confusing to remove the parameter from the "mkinitrd" command.
I agree, but it would mean getting everyone away from using the old-style encryption parameters first.
Last edited by GazL; 10-20-2013 at 05:20 PM.
Reason: Added partial fix patch, but I wouldn't recommend it.
Mon Oct 21 07:30:10 UTC 2013
Looks like we get a Slackware 14.1 release candidate 2... but things are
pretty much nailed down at this point. Please test and report any last
minute issues!
a/kernel-generic-3.10.17-x86_64-2.txz: Rebuilt.
a/kernel-huge-3.10.17-x86_64-2.txz: Rebuilt.
a/kernel-modules-3.10.17-x86_64-2.txz: Rebuilt.
a/sharutils-4.14-x86_64-1.txz: Upgraded.
ap/slackpkg-2.82.0-noarch-12.tgz: Rebuilt.
Corrected typos in the slackpkg man page.
Thanks to sycamorex.
d/gcc-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-g++-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-gfortran-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-gnat-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-go-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-java-4.8.2-x86_64-1.txz: Upgraded.
d/gcc-objc-4.8.2-x86_64-1.txz: Upgraded.
d/kernel-headers-3.10.17-x86-2.txz: Rebuilt.
d/libtool-2.4.2-x86_64-2.txz: Rebuilt.
Rebuilt to update GCC version, which is detected at compile time.
Thanks to Larry Hajali.
k/kernel-source-3.10.17-noarch-2.txz: Rebuilt.
kde/kdelibs-4.10.5-x86_64-2.txz: Rebuilt.
Reverted three upstream commits which (although technically correct) have
the effect of causing KDE to display the wrong icons in some cases.
Thanks to alienBOB.
l/qt-4.8.5-x86_64-2.txz: Rebuilt.
Adjusted the SlackBuild to make sure that libwebcore (which is used
internally for the Qt build) doesn't end up in QtWebKit.pc.
Thanks to Larry Hajali.
n/mutt-1.5.22-x86_64-1.txz: Upgraded.
Thanks to Markus Reichelt for the updates to the ./configure options.
n/samba-4.1.0-x86_64-2.txz: Rebuilt.
Added symlinks for libtalloc.so and libpytalloc-util.so.
Thanks to Adis Nezirovic.
xap/MPlayer-1.1_20130819-x86_64-2.txz: Rebuilt.
Added a patch to fix subtitles in the case where MPlayer is recompiled
on a system that has libass. Thanks to Marin Glibic.
xap/rdesktop-1.8.0-x86_64-2.txz: Rebuilt.
Patched to fix crash with -P and/or -N.
Thanks to mancha.
isolinux/initrd.img: Rebuilt.
kernels/*: Rebuilt.
usb-and-pxe-installers/usbboot.img: Rebuilt.
Yes I have narrowed it down to this . in 14.0 with the new nvidia kernel 319 from the 310 it broke my ability to capture in kdenlive. rolled back was fine.
In 14.1 rc the restrictive build is broken for me I reply For me it does compile and it does limited functions then will Segmentation fault on some codecs.
the same one compiled in the 14.0 environment used in the 14.1 rc does fine . So I will start a new thread in the future on the kdenlive because the newest one coming out the kdenlive 1.0 is going to be very different from what we been seeing. This is the ffmpeg 1.2 that I been compiling with my builds and also with Alien Bob build 14.0.
The Alien Bob 14.0 build works fine in 14.1 rc but that is built in the 14.0 environment.
thanks for all the feed back you slackers are the best.
Tested with this NVIDIA-Linux-x86_64-331.13-beta in 14.1 rc with 14.0 restrictive build, built in 14.0 ffmpeg 1.2.
fixed with 14.1 rc 2 update from October 22 to October 25 2013
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.