[SOLVED] Current is moving again

astrogeek · 07-12-2016, 05:05 PM

Quote:

Originally Posted by mralk3

I install or upgrade everything, all with Slackpkg. Worst thing that has happened is I had to reboot with the slackware install disk, chroot in, and reinstall the broken package(s).

There is no need to manually delete anything. pkgtools handles the kernels too unless you built a custom kernel. Even then, if you use Pat's scripts in the source directory, you can package your custom kernel too. I like to avoid having any software on my system that is not tracked by the package manager database. Old habits die hard I guess.

See: http://mirrors.slackware.com/slackwa...rent/source/k/

When I said I manually remove (and install) them, I meant that I manually invoke installpkg/removepkg to do that. I should have been more clear - I did not mean that I delete files and directories manually, sorry for the confusion.

Pkgtools (installpkg, upgradepkg, removepkg) is "manual". Slackpkg is automation - automated invocation of the pkgtools scripts.

Using this method I have never experienced a "worst thing that could happen".

But to each his own.

I have been using slackpkg on a couple of my machines for a little over a year, and am mostly happy with it - nice tool! But I still blacklist the kernel packages and always manage those manually (with pkgtools scripts)- I never trust that to an automated process, even slackpkg.

I agree that if you build your own kernels, you should still use Pat's scripts to make a package as opposed to using make install on the system.

Agreed, always install/uninstall using packages with pkgtools.

mralk3 · 07-12-2016, 05:15 PM

Quote:

Originally Posted by slackb0t

Excellent. Thanks

btw: To remove manually would you simply remove the relevant items from:

/boot
/lib/modules
/usr/src
old entries in the boot loader config (in my case elilo.conf)

Quote:

Originally Posted by astrogeek

When I said I manually remove (and install) them, I meant that I manually invoke installpkg/removepkg to do that. I should have been more clear - I did not mean that I delete files and directories manually, sorry for the confusion.

Using this method I have neer experienced a "worst thing that could happen".

But to each his own.

@astrogeek, I was referring to slackb0ts above comment about manually deleting files. I totally agree with your methods, I was not bashing you, but agreeing with you.

astrogeek · 07-12-2016, 05:23 PM

AH!

My head is doing the Linda Blair thingy today...

Thanks!

slackb0t · 07-12-2016, 09:54 PM

Quote:

Originally Posted by mralk3

@astrogeek, I was referring to slackb0ts above comment about manually deleting files. I totally agree with your methods, I was not bashing you, but agreeing with you.

So you were bashing me.. wtf?

lol joking of course. Thanks for the input guys I appreciate the responses. I will not delete any directories / files manually.

astrogeek · 07-12-2016, 10:48 PM

Quote:

Originally Posted by slackb0t

So you were bashing me.. wtf?

lol joking of course. Thanks for the input guys I appreciate the responses. I will not delete any directories / files manually.

Well, it is about 11 years late, but as this is the first time I recall having encountered you, welcome to Slackware and LQ! Actully, you have been a member longer than I, so the upper hand is on the other foot, or something like that!

Good luck!

kjhambrick · 07-13-2016, 04:53 AM

Quote:

Originally Posted by astrogeek

I remove them with removepkg after making, and double-checking, a list of those I want to remove.

For example, if I had installed a newer set of kernel packages than my stock 14.1 kernel, I would do this, or something similar...

Code:

removepkg kernel-generic-3.10.17-i486-3
removepkg kernel-generic-smp-3.10.17_smp-i686-3
removepkg kernel-headers-3.10.17_smp-x86-3
removepkg kernel-huge-3.10.17-i486-3
removepkg kernel-huge-smp-3.10.17_smp-i686-3
removepkg kernel-modules-3.10.17-i486-3
removepkg kernel-modules-smp-3.10.17_smp-i686-3
removepkg kernel-source-3.10.17_smp-noarch-3

...<<snip>>...

astrogeek --

I too am a 'manual update' person ( installpkg / upgradepkg / removepkg ).

One question.

There is no version info in the kernel-headers so I've always done kernel-related packages like this:

Code:

upgradepkg kernel-headers-$VERSION-$ARCH-$TAG.txz

installpkg kernel-generic-$VERSION-$ARCH-$TAG.txz
installpkg kernel-huge-$VERSION-$ARCH-$TAG.txz
installpkg kernel-modules-$VERSION-$ARCH-$TAG.txz
installpkg kernel-source-$VERSION-$ARCH-$TAG.txz

mkinitrd ...          # if running kernel-generic
vim /etc/lilo.conf    # add a 'stanza' for the new kernel
lilo                  # rerun lilo to activate new kernel

I don't recall where I 'learned' this or if I decided to do it this way on my own.

But I've always been afraid to removepkg kernel-headers, again because there is no version info.

Should I be doing installpkg on the kernel-headers ?

Seems like a catch-22 on the removepkg no matter how I do it ...

Or if I installpkg kernel-headers, is removepkg smart enough to leave behind ALL the files from any other versions of kernel-headers ?

-- kjh

This is a snip from slackware64/d/kernel-headers-4.4.14-x86-1.txz showing the directories in the Package.

Note that there is no version-related info.

Code:

$ tar -tvf slackware64/d/kernel-headers-4.4.14-x86-1.txz |grep '/$' 

./
install/
usr/
usr/include/
usr/include/rdma/
usr/include/rdma/hfi/
usr/include/asm-generic/
usr/include/scsi/
usr/include/scsi/fc/
usr/include/asm-x86/
usr/include/video/
usr/include/mtd/
usr/include/sound/
usr/include/linux/
usr/include/linux/tc_ematch/
usr/include/linux/dvb/
usr/include/linux/netfilter_ipv6/
usr/include/linux/isdn/
usr/include/linux/hdlc/
usr/include/linux/sunrpc/
usr/include/linux/tc_act/
usr/include/linux/netfilter/
usr/include/linux/netfilter/ipset/
usr/include/linux/netfilter_bridge/
usr/include/linux/spi/
usr/include/linux/netfilter_arp/
usr/include/linux/byteorder/
usr/include/linux/nfsd/
usr/include/linux/caif/
usr/include/linux/android/
usr/include/linux/can/
usr/include/linux/iio/
usr/include/linux/netfilter_ipv4/
usr/include/linux/wimax/
usr/include/linux/hsi/
usr/include/linux/raid/
usr/include/linux/mmc/
usr/include/linux/usb/
usr/include/uapi/
usr/include/misc/
usr/include/xen/

EDIT: oops ... took so long to construct my post that I forgot to include install/doinst.sh for kernel-headers.

AND ... there is no clever symlinking going on in kernel-headers like you'll find in the other kernel-packages:

Code:

# cat doinst.sh                     # from kernel-headers

( cd usr/include ; rm -rf asm )
( cd usr/include ; ln -sf asm-x86 asm )

# cat doinst.sh                     # from kernel-generic

( cd boot ; rm -rf vmlinuz-generic )
( cd boot ; ln -sf vmlinuz-generic-4.4.14 vmlinuz-generic )
( cd boot ; rm -rf config )
( cd boot ; ln -sf config-generic-4.4.14 config )
( cd boot ; rm -rf System.map )
( cd boot ; ln -sf System.map-generic-4.4.14 System.map )
( cd boot ; rm -rf vmlinuz )
( cd boot ; ln -sf vmlinuz-generic-4.4.14 vmlinuz )

hitest · 07-13-2016, 08:00 AM

Quote:

Originally Posted by mralk3

I install or upgrade everything, all with Slackpkg. Worst thing that has happened is I had to reboot with the slackware install disk, chroot in, and reinstall the broken package(s).

I too install and upgrade everything with slackpkg. The slackpkg utility that ships with Slackware works well for me. Like you I've rarely encountered a glitch using it.

mralk3 · 07-13-2016, 01:38 PM

Quote:

Originally Posted by slackb0t

So you were bashing me.. wtf?

lol joking of course. Thanks for the input guys I appreciate the responses. I will not delete any directories / files manually.

I wasn't trying to bash anyone!

I am glad you did not take offense. I've seen what happens to systems where files are deleted versus using the package manager. I would not wish such a circumstance upon anyone.

astrogeek · 07-13-2016, 02:16 PM

Quote:

Originally Posted by kjhambrick

astrogeek --

I too am a 'manual update' person ( installpkg / upgradepkg / removepkg ).

One question.

There is no version info in the kernel-headers so I've always done kernel-related packages like this:

Code:

upgradepkg kernel-headers-$VERSION-$ARCH-$TAG.txz

installpkg kernel-generic-$VERSION-$ARCH-$TAG.txz
installpkg kernel-huge-$VERSION-$ARCH-$TAG.txz
installpkg kernel-modules-$VERSION-$ARCH-$TAG.txz
installpkg kernel-source-$VERSION-$ARCH-$TAG.txz

mkinitrd ...          # if running kernel-generic
vim /etc/lilo.conf    # add a 'stanza' for the new kernel
lilo                  # rerun lilo to activate new kernel

I don't recall where I 'learned' this or if I decided to do it this way on my own.

But I've always been afraid to removepkg kernel-headers, again because there is no version info.

Good point!

HA! I tend to use that same argument and method for kernel-firmware (which is why I left it off my list in a previous post).

Although I don't think it matters in either case.

I do not update kernels frequently anyway so I always make a list and check it twice or three times each time that I do it. I recall always asking myself these same questions each time, which is what I had in mind when I said I would do it like this, "..or something similar...".

Actually, what happens is that I usually fall back onto my ultimate confidence that installpkg/upgradepkg/removepkg always get it right.

Upgradepkg works by invoking installpkg on the new one then removepkg on the old one. This works because removepkg will not remove a file that is also in another package, and also considers the doinst.sh scripts to keep symlinks right.

Of course, if you use upgradepkg to install the new one, there is no old one laying around to remove, but the process and outcome are the same. I recall that upgradepkg does a final duplicate install after the removepkg as a "just in case" measure, not sure how necessary that may be, but it is the (only?) essential difference in the two methods.

Either way we end up with the new package and a consistent package DB.

Quote:

Originally Posted by kjhambrick

Should I be doing installpkg on the kernel-headers ?

Seems like a catch-22 on the removepkg no matter how I do it ...

Or if I installpkg kernel-headers, is removepkg smart enough to leave behind ALL the files from any other versions of kernel-headers ?

I cannot say what you should be doing

, only that you should do what works for you and makes you feel happy when it completes!

Yes, removepkg is smart enough to not break the newer package when removing the older one. It is in fact how upgradepkg does it (with the possibly important caveat mentioned above).

bormant · 07-13-2016, 04:56 PM

Quote:

Originally Posted by astrogeek

Code:

vim /etc/lilo.conf    # add a 'stanza' for the new kernel

Note1: boot/vmlinuz is a symlink by default to latest installed kernel (kernel-*.t?z/install/doinst.sh reset it to package's kernel binary).

Note2: since 14.0 kernel-huge{,-smp} and kernel-generic{,-smp} set personal vmlinuz-huge{,-smp} and vmlinuz-generic{,-smp} symlinks.

So you can always use default /etc/lilo.conf (Note3: kernel-huge{,-smp} installs late than kernel-generic{,-smp} and sets /boot/vmlinuz to vmlinuz-huge{,-smp}) for kernel-huge{,-smp} (as no needs to update /boot/initrd.gz).
Just launch after installing new kernel-*:
# lilo

You can always use unmodified /etc/lilo.conf (exclude first time addition "initrd = /boot/initrd.gz" line) after rebuild /boot/initrd.gz and resetting /boot/vmlinuz symlink:

Code:

# mkinitrd -r -k new.kernel.version other options | sh
# ( cd /;/var/adm/scripts/kernel-generic-new.kernel.version-* )
# lilo

You can always use one time modified /etc/lilo.conf with two "image"s:

Code:

image = /boot/vmlinuz-generic-smp #for 32-bit
image = /boot/vmlinuz-generic     #for 64-bit
  initrd = /boot/initrd.gz
  root = ...
image = /boot/vmlinuz-huge
  root = ...

# lilo
will use the latest installed kernel by it's actual symlink...

kjhambrick · 07-14-2016, 04:20 AM

Thanks astrogeek.

I like what I read about upgradepkg / removepkg ... I'll have to take a look at the shell scripts.

Sounds like I can learn something from the code, especially the algorithm where upgradepkg = ( install new + remove old ).

And yes, I too always upgradepkg kernel-firmware ...

Good point bormant !

I should have written 'add a stanza for the OLD kernel' instead of the NEW kernel.

This is what I always do, just in case I get into trouble with the NEW kernel, I can fall back to the OLD kernel.

-- kjh

bormant · 07-14-2016, 04:35 AM

kjhambrick,

one more candidate to "old kernel" is
http://docs.slackware.com/howtos:sla...stall_from_hdd