LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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 12-06-2018, 12:42 PM   #1066
GazL
Senior Member
 
Registered: May 2008
Posts: 4,794
Blog Entries: 14

Rep: Reputation: Disabled

Quote:
Originally Posted by Aeterna View Post
I wish linux had similar facility as BSD's that is last good kernel is automatically backed up and in the case of new kernel failure one can easily boot system again from the old working kernel. Unfortunately it seems that this would be more difficult to automate in comparison to BSD (or Solaris)
Nah, that's easy. just set a unique CONFIG_LOCALVERSION, and you end up with something like this:
Code:
$ ls -l /boot/vmlinuz* /lib/modules/
lrwxrwxrwx 1 root root      22 Dec  3 09:59 /boot/vmlinuz -> vmlinuz-generic-4.19.6
-rw-r--r-- 1 root root 6189104 Dec  5 19:40 /boot/vmlinuz-4.19.7-local
lrwxrwxrwx 1 root root      26 Dec  5 20:05 /boot/vmlinuz-4.19.y-local -> /boot/vmlinuz-4.19.7-local
lrwxrwxrwx 1 root root      22 Dec  3 09:59 /boot/vmlinuz-generic -> vmlinuz-generic-4.19.6
-rw-r--r-- 1 root root 6080384 Dec  1 23:51 /boot/vmlinuz-generic-4.19.6

/lib/modules/:
total 8
drwxr-xr-x 3 root root 4096 Dec  3 10:00 4.19.6
drwxr-xr-x 3 root root 4096 Dec  5 20:05 4.19.7-local
$
I use '-local' for mine, and keep Pat's generic kernel just in case I ever cock mine up.
 
2 members found this post helpful.
Old 12-06-2018, 01:18 PM   #1067
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 129

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post
Nah, that's easy. just set a unique CONFIG_LOCALVERSION, and you end up with something like this:
Code:
$ ls -l /boot/vmlinuz* /lib/modules/
lrwxrwxrwx 1 root root      22 Dec  3 09:59 /boot/vmlinuz -> vmlinuz-generic-4.19.6
-rw-r--r-- 1 root root 6189104 Dec  5 19:40 /boot/vmlinuz-4.19.7-local
lrwxrwxrwx 1 root root      26 Dec  5 20:05 /boot/vmlinuz-4.19.y-local -> /boot/vmlinuz-4.19.7-local
lrwxrwxrwx 1 root root      22 Dec  3 09:59 /boot/vmlinuz-generic -> vmlinuz-generic-4.19.6
-rw-r--r-- 1 root root 6080384 Dec  1 23:51 /boot/vmlinuz-generic-4.19.6

/lib/modules/:
total 8
drwxr-xr-x 3 root root 4096 Dec  3 10:00 4.19.6
drwxr-xr-x 3 root root 4096 Dec  5 20:05 4.19.7-local
$
I use '-local' for mine, and keep Pat's generic kernel just in case I ever cock mine up.
Thank you but this is not what I had in the mind (I always keep working backup kernel). BSD's and Solaris automatically backup kernel when one does system/kernel upgrade without user intervention. So even for someone not experienced booting machine from old kernel is easy to do. In fact Solaris backups all system if one is running system upgade.
 
Old 12-06-2018, 05:39 PM   #1068
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by Aeterna View Post
BSD's and Solaris automatically backup kernel when one does system/kernel upgrade without user intervention.
And Ubuntu, Debian etc. too.

But personally I think that strategy is stupid and dangerous.

Personally I prefer to keep the original 14.2 huge kernel in /boot[*] as a permanent emergency kernel, untracked by Slackware's package management (by removing /var/log/packages/kernel-huge-4.4.14-x86_64-1).

And then I never need to edit lilo.conf, or mkinitrd.conf. And I can safely upgrade kernels with slackpkg like any other package, instead of all the messing about with blacklists and installpkg that other people here at LQ sometimes suggest.

[*] or /boot/efi/EFI/Slackware

Last edited by 55020; 12-06-2018 at 05:40 PM.
 
5 members found this post helpful.
Old 12-06-2018, 06:48 PM   #1069
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 668

Rep: Reputation: Disabled
Quote:
Originally Posted by 55020 View Post
And Ubuntu, Debian etc. too.

But personally I think that strategy is stupid and dangerous.

Personally I prefer to keep the original 14.2 huge kernel in /boot[*] as a permanent emergency kernel, untracked by Slackware's package management (by removing /var/log/packages/kernel-huge-4.4.14-x86_64-1).

And then I never need to edit lilo.conf, or mkinitrd.conf. And I can safely upgrade kernels with slackpkg like any other package, instead of all the messing about with blacklists and installpkg that other people here at LQ sometimes suggest.

[*] or /boot/efi/EFI/Slackware
If you don't edit lilo, then how is the new kernel used?
 
1 members found this post helpful.
Old 12-06-2018, 07:02 PM   #1070
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 129

Rep: Reputation: Disabled
Quote:
Originally Posted by PROBLEMCHYLD View Post
If you don't edit lilo, then how is the new kernel used?
he probably means that lilo/grub is updated auomatically during new kernel installation. So no user intervention is needed.

I don't know how Debian/Ubuntu do this but I never had problems with booting BSD or Solaris. Why this would be stupid?

Not sure though why huge kernel is needed (as backup) instead of keeping working generic. If generic kernel works then huge has no advantage.
 
Old 12-06-2018, 08:25 PM   #1071
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,522

Rep: Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267
Quote:
Originally Posted by PROBLEMCHYLD View Post
If you don't edit lilo, then how is the new kernel used?
If you set one kernel entry to point directly to the original kernel and use the symlinks for any newer versions, then all you'd need to do is run lilo and you wouldn't need to touch lilo.conf. The following is based on using the huge kernel, if you use generics, you'd need to add entries for the initrd.

Code:
image=/boot/vmlinuz-huge
        label=Latest-kernel
        root=/dev/sda2
        read-only

image=/boot/vmlinuz-huge-4.4.14
        label=Original-kernel
        root=/dev/sda2
        read-only
 
5 members found this post helpful.
Old 12-06-2018, 09:07 PM   #1072
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 668

Rep: Reputation: Disabled
Quote:
Originally Posted by 55020 View Post
And Ubuntu, Debian etc. too.

But personally I think that strategy is stupid and dangerous.

Personally I prefer to keep the original 14.2 huge kernel in /boot[*] as a permanent emergency kernel, untracked by Slackware's package management (by removing /var/log/packages/kernel-huge-4.4.14-x86_64-1).

And then I never need to edit lilo.conf, or mkinitrd.conf. And I can safely upgrade kernels with slackpkg like any other package, instead of all the messing about with blacklists and installpkg that other people here at LQ sometimes suggest.

[*] or /boot/efi/EFI/Slackware
I'm tempted to try this intriguing method, not sure I understand fully though. Here is my elilo.conf

Code:
chooser=simple
default=4.19.7
delay=1
prompt
timeout=1
image=vmlinuz
  append="boot=live config union=overlay noswap noprompt ip=frommedia live-media-path=/dmt/live toram=filesystem.squashfs vga=788" 
  initrd=initrd.img
  label=0.32.0
  root=/dev/sda2
image=vmlinuz-generic-4.19.7
  append="resume=/dev/sda3"
  initrd=initrd.gz
  label=4.19.7
  read-only
  root=/dev/sda2
Since I use generic, then it probably won't work? RIGHT????
 
Old 12-07-2018, 12:07 AM   #1073
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 FVWM
Posts: 561

Rep: Reputation: 152Reputation: 152
Quote:
Originally Posted by Aeterna View Post
What do you mean? .config is compiler independent. when you open it .config just list available compiler. In fact I used .config-4.13.11 to built 4.19.7 kernel.
I didn't say that I was concerned about the compiler being compatible with the config. I said I was concerned about features that were turned on for newer hardware and the possible impact.

Quote:
Originally Posted by Aeterna View Post
After saving, run diff and all new options added will pop up and old options not used anymore will wanish. Then deselect what you don't need or enable more options.

.config is just editable file that lets you change some options (using proper editor), but not all. It does not depend on gcc (what you see in the editor is information regarding available (not required) compiler.
I use make menuconfig to look at the settings for adapting the config to the PC's Pentium D processor and turn-off most network cards which will never touch the PC. This optimizes the config better for the target PC. However, it was easier to start from a 4.19.y generic config than to go through all the changes presented with make oldconfig when going from 4.4.y to 4.19.y.
Quote:
Originally Posted by Aeterna View Post
...snip... However claiming after few hours after installation that "kernel runs fine" is not more informative that stating that kernel boots.
Not sure of what you are claiming or suggesting with this statement. Since I don't understand the reference I'll leave it as a non-sequitur, along with the following statement which is also not true or germane to my comments or bassmadrigals help and explanations.
Quote:
Originally Posted by Aeterna View Post
I wish linux had similar facility as BSD's that is last good kernel is automatically backed up and in the case of new kernel failure one can easily boot system again from the old working kernel. Unfortunately it seems that this would be more difficult to automate in comparison to BSD (or Solaris)
Cheers!
 
Old 12-07-2018, 12:13 AM   #1074
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 FVWM
Posts: 561

Rep: Reputation: 152Reputation: 152
Quote:
Originally Posted by bassmadrigal View Post
If you set one kernel entry to point directly to the original kernel and use the symlinks for any newer versions, then all you'd need to do is run lilo and you wouldn't need to touch lilo.conf. The following is based on using the huge kernel, if you use generics, you'd need to add entries for the initrd.

Code:
image=/boot/vmlinuz-huge
        label=Latest-kernel
        root=/dev/sda2
        read-only

image=/boot/vmlinuz-huge-4.4.14
        label=Original-kernel
        root=/dev/sda2
        read-only
Doesn't everyone have at least two stanza's in their lilo.conf? Mine has 3. I rotate "Latest kernel" and "Latest LTS", while PV's latest release is always the default "Failsafe". With all three presented by the boot menu so I can choose which one to use if the latest installed is failing to boot. Cheers.
 
1 members found this post helpful.
Old 12-07-2018, 04:19 AM   #1075
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Bassmadrigal wins the prize! The whole point of the vmlinuz, vmlinuz-generic and vmlinuz-huge symlinks is to enable this model of lilo.conf. I normally use a generic kernel, so lilo.conf has

Code:
image = /boot/vmlinuz-generic
  initrd = /boot/initrd.gz
  read-only
  label = Slackware

image = /boot/vmlinuz-huge
  addappend = " root=/dev/sda1"
  read-only
  label = emergency
All the other details are in mkinitrd.conf, which is different on every box, for example

Code:
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
KERNEL_VERSION="$(uname -r)"
KEYMAP="uk"
MODULE_LIST="ext4"
ROOTDEV="/dev/sda1"
ROOTFS="ext4"
RESUMEDEV="/dev/sda2"
UDEV="1"
MODCONF="0"
WAIT="1"
MICROCODE_ARCH="/boot/intel-ucode.cpio"
After upgrading the kernel, I don't run lilo directly from slackpkg, because I need to create a new initrd.gz, so I exit from slackpkg as normal and run

Code:
mkinitrd -F -k 4.19.7
lilo
This setup isn't perfect, because (1) I still need "root=/dev/sda1" in the emergency stanza, so I can't use the same lilo.conf on boxes where the root is different, and (2) I still need to specify the new kernel version when I run mkinitrd. But I can live with that. It's still better than editing version numbers in lilo.conf all the time.

If you're paying close attention to what I said above, you'll be worried whether the huge kernel has the modules that it needs. On some boxes, you can boot and type on the console without the modules, but on other boxes you need to keep the modules from kernel-modules-4.4.14-x86_64-1 in /lib/modules/4.4.14 -- just installpkg kernel-modules-4.4.14-x86_64-1.txz and then rm /var/log/packages/kernel-modules-4.4.14-x86_64-1

On EFI, I use refind. After upgrading the kernel, I run mkinitrd, and then manually copy the new vmlinuz and the new initrd.gz from /boot into /boot/efi/EFI/Slackware. The old vmlinuz-huge stays in /boot/efi/EFI/Slackware permanently. No config file is needed.
 
2 members found this post helpful.
Old 12-07-2018, 04:49 AM   #1076
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by Aeterna View Post
he probably means that lilo/grub is updated auomatically during new kernel installation. So no user intervention is needed.
No, see the above post

Quote:
Originally Posted by Aeterna View Post
I don't know how Debian/Ubuntu do this but I never had problems with booting BSD or Solaris. Why this would be stupid?
The Debian/Ubuntu ever-growing pile of old kernels in grub is *definitely* a problem.

It's stupid because it doesn't address the use cases, which are

(A) I want a fallback in case I do something wrong with the package management.
(B) I want a fallback in case upstream sends me a bad kernel.

In both cases there is no guarantee that the previous kernel is ok.

In case (B) we have seen exactly this situation play out with the ext4 corruption bug in 4.19

Quote:
Originally Posted by Aeterna View Post
Not sure though why huge kernel is needed (as backup) instead of keeping working generic. If generic kernel works then huge has no advantage.
With generic, the kernel is a single point of failure, and the initrd is a single point of failure, and the modules are a single point of failure.

generic-4.19.7 needs 4.19.7's modules and 4.19.7's initrd
generic-4.19.6 needs 4.19.6's modules and 4.19.6's initrd
etc

Worse still, they are interdependent -- if you modify one, you *must* modify the other two -- and each upgrade cycle is a risk of doing that wrongly.

huge-4.4.14 doesn't need an initrd, and on a lot of boxes it is usable without modules. That's just one single point of failure instead of 3. And the upgrade cycle (== risk cycle) is once every two or three years, not once or twice per week.
 
2 members found this post helpful.
Old 12-07-2018, 09:15 AM   #1077
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,288

Rep: Reputation: 980Reputation: 980Reputation: 980Reputation: 980Reputation: 980Reputation: 980Reputation: 980Reputation: 980
On my 14.2 server that always freezes after a day or two on the 4.4.x kernels, I periodically build the latest stable kernel. Then, I run this script:

Code:
#!/bin/bash                                                                     
#                                                                               
# This script installs a new kernel, assumed to be built already (including     
# bzImage and modules) in the source directory /usr/src/linux-$KERNEL_VERSION   
#                                                                               
                                                                                
if [ $# -lt 1 ]; then                                                           
  echo "Usage: $0 KERNEL_VERSION"                                               
  exit 1                                                                        
fi                                                                              
KERNEL_VERSION=$1                                                               
                                                                                
set -e                                                                          
                                                                                
# Rotate backup kernel                                                          
mv /boot/config-latest /boot/config-backup                                      
mv /boot/initrd-latest.gz /boot/initrd-backup.gz                                
mv /boot/vmlinuz-latest /boot/vmlinuz-backup                                    
                                                                                
# Install new kernel                                                            
cd /usr/src/linux-${KERNEL_VERSION}                                             
cp .config /boot/config-latest                                                  
cat arch/x86/boot/bzImage > /boot/vmlinuz-latest                                
make modules_install                                                            
mkinitrd -c -k ${KERNEL_VERSION} \                                              
         -f ext4 -r /dev/sda1 \                                                 
         -m usb-storage:xhci-hcd:jbd2:mbcache:crc32c-intel:ext4 \               
         -u -o /boot/initrd-latest.gz                                           
lilo -v
The kernels section of my /etc/lilo.conf looks like this:
Code:
# Linux bootable partition config begins
# initrd created with 'mkinitrd -c -k ${KERNEL_VERSION} -f ext4 -r /dev/sda1 -m usb-storage:xhci-hcd:jbd2:mbcache:crc32c-intel:ext4 -u -o /boot/initrd-latest.gz'
image = /boot/vmlinuz-latest
  initrd = /boot/initrd-latest.gz
  root = /dev/sda1
  label = latest
  read-only
# Linux bootable partition config ends
# initrd created with 'mkinitrd -c -k ${KERNEL_VERSION} -f ext4 -r /dev/sda1 -m usb-storage:xhci-hcd:jbd2:mbcache:crc32c-intel:ext4 -u -o /boot/initrd-backup.gz'
image = /boot/vmlinuz-backup
  initrd = /boot/initrd-backup.gz
  root = /dev/sda1
  label = backup
  read-only
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /boot/vmlinuz-huge
  root = /dev/sda1
  label = huge
  read-only
# Linux bootable partition config ends
Of course, the mkinitrd parameters would need to change for different machines. This way I always have two backups: the previous generic kernel, and Pat's huge kernel (emergency use only). It is pretty painless, and I don't really think that a fully automatic backup would serve me any better.
 
1 members found this post helpful.
Old 12-07-2018, 09:23 AM   #1078
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.2 (4.19.9) UEFI enabled
Posts: 505

Rep: Reputation: 178Reputation: 178
Anyone building their own kernel might want to look into
Code:
make localmodconfig
greatly reduces the kernel size and modules as well as speeds up the 'make'
builds a kernel and modules customized for your local hardware configuration.

don't just jump in, but study what it does and proper implementation first.
HTH
john
 
2 members found this post helpful.
Old 12-07-2018, 09:37 AM   #1079
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 129

Rep: Reputation: Disabled
well it started with someone's incorrect statement that there is a gcc dependent .config in the context of building custom kernels. What we have here is more of the idea how to maintain system secure with least effort regarding kernels

Quote:
(B) I want a fallback in case upstream sends me a bad kernel.

In both cases there is no guarantee that the previous kernel is ok.

In case (B) we have seen exactly this situation play out with the ext4 corruption bug in 4.19
this is very optimistic and not true:
if file system gets corrupted no kernel will help (including huge kernel). This happened to me just before officially this issue was reported.
So the only sane approach is to keep using LTS kernels. How often do you update them is up to you.

Quote:
(A) I want a fallback in case I do something wrong with the package management.
yes, this makes sense, but I don't need huge kernel for this to work.

Because I don't use initrd, then bad initrd file does not concerns me.

I never had an issue with modules, but bad software kernel did happen. So I think that in my case
having
vmlinuz-LTS
vmlinux-last
vmlinux-exp
is enough to do as little as possible (that is no need to edit lilo.conf just run lilo), and yes once in a while I need to clean /usr/src /lib/modules (which takes less time than building initrd). But this is a consequence of building my own kernels.

Quote:
The Debian/Ubuntu ever-growing pile of old kernels in grub is *definitely* a problem.

It's stupid because it doesn't address the use cases, which are
The Debian/Ubuntu ever-growing pile of old kernels in grub is *definitely* a problem.

It's stupid because it doesn't address the use cases, which are

(A) I want a fallback in case I do something wrong with the package management.
(B) I want a fallback in case upstream sends me a bad kernel.

In both cases there is no guarantee that the previous kernel is ok.
(A) I want a fallback in case I do something wrong with the package management.
(B) I want a fallback in case upstream sends me a bad kernel.

In both cases there is no guarantee that the previous kernel is ok.
if you build your own kernels, just boot your last that worked (of course assuming that your current kernel just did not boot, not that it destroyed file system).
That is not how BSD's deal with the kernels (you have just one last good kernel as backup)
You have no guarantee that last will work (see above regarding fs and/or partition table destruction). No way to predict all possible scenarios.

@AlleyTrotter
you can use
localyesconfig
which is even faster, still need to edit and modify stuff manually wherever required.

@montagdude
Quote:
It is pretty painless, and I don't really think that a fully automatic backup would serve me any better.
same thing: if fs is destroyed, backup is best option otherwise it would very long and uncertain way of rescuing all data from e.g. corrupted partition

Last edited by Aeterna; 12-08-2018 at 06:30 PM.
 
1 members found this post helpful.
Old 12-07-2018, 11:29 AM   #1080
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,522

Rep: Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267Reputation: 3267
Quote:
Originally Posted by PROBLEMCHYLD View Post
I'm tempted to try this intriguing method, not sure I understand fully though. Here is my elilo.conf

Code:
chooser=simple
default=4.19.7
delay=1
prompt
timeout=1
image=vmlinuz
  append="boot=live config union=overlay noswap noprompt ip=frommedia live-media-path=/dmt/live toram=filesystem.squashfs vga=788" 
  initrd=initrd.img
  label=0.32.0
  root=/dev/sda2
image=vmlinuz-generic-4.19.7
  append="resume=/dev/sda3"
  initrd=initrd.gz
  label=4.19.7
  read-only
  root=/dev/sda2
Since I use generic, then it probably won't work? RIGHT????
In this case, you would run into an issue unless you rename every new kernel to be vmlinuz-generic-4.19.7. If you use a more generic name like vmlinux-generic-latest, then you would just copy whatever new kernel you get into /boot/efi/EFI/Slackware/ and name it vmlinuz-generic-latest. You'd also want to make sure your initrds are named differently. In this case, you have initrd.img and initrd.gz, which will work. But if you end up gzip'ing both of them, you would want to do something like initrd-latest.gz to ensure they stay separate names.

elilo doesn't require you to run anything to save the new kernels, so all you should need to do is replace the old files with new ones of the same name and when you reboot, it will automatically boot the new kernel and initrd.

Quote:
Originally Posted by bamunds View Post
Doesn't everyone have at least two stanza's in their lilo.conf? Mine has 3. I rotate "Latest kernel" and "Latest LTS", while PV's latest release is always the default "Failsafe". With all three presented by the boot menu so I can choose which one to use if the latest installed is failing to boot. Cheers.
By default, no. Slackware only includes one stanza in its lilo.conf pointing to /boot/vmlinuz. This kernel is usually a symlink to the huge kernel. This allows slackpkg to update the kernels without requiring any editing of lilo.conf and all the user needs to do is run lilo to save the new kernel location to the MBR.

Now, if you tweak your lilo.conf, it's always a good idea to have at least two entries, but not all Slackers do that. In fact, I don't do it on my htpc, as it runs just Slackware and kodi (along with the required dependencies for kodi). I still have the original lilo.conf on there. If something ever goes wrong, I can easily boot off a thumbdrive and repair the system. But on my desktop, I usually upgrade the kernel many times, never sticking with the stable kernel series, so I have any stanzas on that version allowing me to bounce back and forth between various kernels (although, I usually only need the last two kernels, but I'm lazy and have the space, so I don't bother removing the others).
 
1 members found this post helpful.
  


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
Linux.conf.au: Latest Linux kernel release due early March DragonSlayer48DX Linux - News 0 01-18-2010 11:43 PM
No video on latest kernel release Tralce Linux - Kernel 3 11-30-2006 08:48 AM
What is the latest Redhat release TILEMANN Linux - Software 5 11-20-2006 11:48 PM
LXer: News: OpenVZ To Release Support, Patches for Latest Kernel LXer Syndicated Linux News 0 11-01-2006 11:54 PM
latest debian release? doralsoral Linux - Software 5 12-25-2004 01:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:33 AM.

Main Menu
Advertisement
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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration