LinuxQuestions.org - Slackware 14.1

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware 14.1 - Release candidate 1! (https://www.linuxquestions.org/questions/slackware-14/slackware-14-1-release-candidate-1-a-4175480780/)

You'll get those mail messages added every time you update the aaa_base package. it's nothing to worry about. just clean them out after an update.

Quote:

Originally Posted by GazL (Post 5049191)

You'll get those mail messages added every time you update the aaa_base package. it's nothing to worry about. just clean them out after an update.

Thank you, I didn't think there was too much to it, just curious.

Quote:

Originally Posted by GazL (Post 5048618)

/boot/README.initrd

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.

For the curious...

Just did a clean install on a Dell Latitude E6400 (you can find full specs online).

Code:

# lspci                                                                                                                                                          

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)                                                                                

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)                                                          

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)                                                                

00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)                                                                                    

00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)                                                                                

00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)                                                                                

00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)                                                                                

00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)                                                                              

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)                                                                                    

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)                                                                                        

00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)                                                                                        

00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)                                                                                        

00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)

00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)

00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)

00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)

00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)

00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)

00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)

03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)

03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)

03:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)

0c:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01)

and Samsung 840EVO SSDHD 250GB; dual boot WinXp and -current RC1 as of Sat Oct 19 03:42:15 UTC 2013.

I gotta say, so far I am tickled pink. I might even switch back to KDE (for the 1st time since 3.5.10). The BCM4322 chip is working too (but still no 802.11n): I fixed up the SBo scripts (filenames and locations) for the newer firmware and fw-cutter from from here:
http://www.lwfinger.com/b43-firmware...163.46.tar.bz2
http://bues.ch/b43/fwcutter/b43-fwcutter-018.tar.bz2
and am posting this via my home wifi.

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!!

Quote:

Originally Posted by Erik_FL (Post 5049230)

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.

Quote:

Originally Posted by GazL (Post 5048752)

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.

Quote:

Originally Posted by kingbeowulf (Post 5049238)

I gotta say, so far I am tickled pink. I might even switch back to KDE (for the 1st time since 3.5.10).

Same experience here. KDE 4.10.5 made me switch back to KDE as main desktop.

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:

Code:

diff -Nurp mkinitrd.orig/init mkinitrd/init

--- mkinitrd.orig/init  2013-03-21 04:05:12.000000000 +0000

+++ mkinitrd/init      2013-10-20 22:56:50.939139096 +0100

@@ -113,6 +113,9 @@ for ARG in $(cat /proc/cmdline); do

    resume=*)

      RESUMEDEV=$(echo $ARG | cut -f2 -d=)

    ;;

+    root=/dev/mapper/*)

+      ROOTDEV=$(basename $(echo $ARG | cut -f2 -d=))

+    ;;

    root=/dev/*)

      ROOTDEV=$(echo $ARG | cut -f2 -d=)

    ;;

... 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 (Post 5049230)

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.

follow-up:

I think this would safely fix the case of "mkinitrd -r cryptroot" and root=/dev/mapper/cryptroot

Code:

diff -Nurp mkinitrd.orig/init mkinitrd/init

--- mkinitrd.orig/init  2013-03-21 04:05:12.000000000 +0000

+++ mkinitrd/init      2013-10-21 00:41:17.084017915 +0100

@@ -113,6 +113,13 @@ for ARG in $(cat /proc/cmdline); do

    resume=*)

      RESUMEDEV=$(echo $ARG | cut -f2 -d=)

    ;;

+    root=/dev/mapper/*)

+      a=$(echo $ARG | cut -f2 -d=)

+      if [ $(basename "$a") != "$ROOTDEV" ]; then

+        ROOTDEV="$a" 

+      fi

+      unset a

+    ;;

    root=/dev/*)

      ROOTDEV=$(echo $ARG | cut -f2 -d=)

    ;;

Not tested.

Quote:

Originally Posted by kikinovak (Post 5049273)

Same experience here. KDE 4.10.5 made me switch back to KDE as main desktop.

I second this notion.
I haven't used KDE since version 3.2.
I am impressed.

I am now updating a system from KDE-4.5.5/GNOME-2.32 to current.

clean-system was lengthy

install-new was giant

I am still waiting on upgrade-all

a new gcc! :cool:

Code:

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.

Quote:

Originally Posted by Drakeo (Post 5049243)

fixed with 14.1 rc 2 update from October 22 to October 25 2013