LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 10-20-2013, 01:17 PM   #76
GazL
Senior Member
 
Registered: May 2008
Posts: 3,319

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881

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.
 
1 members found this post helpful.
Old 10-20-2013, 02:35 PM   #77
rkfb
Member
 
Registered: Oct 2003
Location: Guildford, England
Distribution: slackware
Posts: 289

Rep: Reputation: 39
Quote:
Originally Posted by GazL View Post
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.
 
Old 10-20-2013, 02:44 PM   #78
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
Quote:
Originally Posted by GazL View Post
/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.
 
Old 10-20-2013, 02:59 PM   #79
kingbeowulf
Member
 
Registered: Oct 2003
Location: WA
Distribution: Slackware64 14.1, Slackware 14.1
Posts: 519

Rep: Reputation: 137Reputation: 137
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!!
 
Old 10-20-2013, 03:04 PM   #80
kingbeowulf
Member
 
Registered: Oct 2003
Location: WA
Distribution: Slackware64 14.1, Slackware 14.1
Posts: 519

Rep: Reputation: 137Reputation: 137
Quote:
Originally Posted by Erik_FL View Post
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.
 
Old 10-20-2013, 03:09 PM   #81
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 2,451
Blog Entries: 3

Rep: Reputation: 182Reputation: 182
Quote:
Originally Posted by GazL View Post
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
 
Old 10-20-2013, 04:35 PM   #82
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,497

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
Quote:
Originally Posted by kingbeowulf View Post
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.
 
Old 10-20-2013, 04:36 PM   #83
GazL
Senior Member
 
Registered: May 2008
Posts: 3,319

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
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 View Post
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.
 
Old 10-20-2013, 06:29 PM   #84
GazL
Senior Member
 
Registered: May 2008
Posts: 3,319

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
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.

Last edited by GazL; 10-20-2013 at 06:44 PM. Reason: Version 2. tightened up, just to be safe.
 
Old 10-20-2013, 07:16 PM   #85
andrewthomas
Senior Member
 
Registered: May 2010
Location: Chicago Metro
Distribution: Arch, Gentoo, Slackware
Posts: 1,690

Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
Quote:
Originally Posted by kikinovak View Post
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

Last edited by andrewthomas; 10-20-2013 at 09:53 PM. Reason: added info
 
Old 10-21-2013, 05:08 AM   #86
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,399

Rep: Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852
a new gcc!
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.
 
Old 10-27-2013, 08:34 PM   #87
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 2,451
Blog Entries: 3

Rep: Reputation: 182Reputation: 182
Quote:
Originally Posted by Drakeo View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Please test Slackware 14 release candidate 4 Didier Spaier Slackware 1 08-31-2012 02:59 PM
LXer: First release candidate for Slackware 14 LXer Syndicated Linux News 0 08-13-2012 11:10 AM
Slackware 13, Release Candidate 2. cwizardone Slackware 17 08-07-2009 01:33 AM
LXer: Slackware 12.0 release candidate 1 is out. LXer Syndicated Linux News 0 06-16-2007 11:31 AM
LXer: Slackware 11.0 release candidate 4 LXer Syndicated Linux News 0 09-03-2006 08:54 AM


All times are GMT -5. The time now is 03:36 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration