LinuxQuestions.org - [SOLVED] Upgrade from Slackware 14.0 to 14.1: unable to boot.

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

- - Upgrade from Slackware 14.0 to 14.1: unable to boot. (https://www.linuxquestions.org/questions/slackware-14/upgrade-from-slackware-14-0-to-14-1-unable-to-boot-4175511904/)

Upgrade from Slackware 14.0 to 14.1: unable to boot.

Hi,

I wanted to upgrade from Slackware64 14.0 (multilib) to Slackware64 14.1 multilib.

However, during the process, I made almost all of the possible errors, since I blindly followed the instructions here http://docs.slackware.com/howtos:sla...ystemupgrade?s[]=upgrade by blacklisting the kernel and then updating slackpkg itself, followed by system-upgrade, forgotting that the old blacklist file was put aside by the new slackpkg.

Thus, the kernel was also updated. Since I already had a generic kernel, I created a new initrd by following the same instructions, while replacing initrd_3.2.29.gz by initrd_3.10.17.gz I made sure to modify appropriately the lilo.conf file and to run lilo after.

As I rebooted, exactly what I wanted not to occur, occurred. After the LILO menu and I selected the entry, I was greeted by the following message:

Code:

Loading LinuxEBDA is big: kernel setup stack overlaps LILO second stage

Thus, the only way for me is to chroot the system. Should I use a Slackware 14.1 CD for this, or a 14.0 CD would still be fine?

The lilo version you used is too old to be used on Slackware 14.1. Either use the distribution media to go straight into your upgraded system, as stated in installer's very first screen or chroot in it from an installer (it doesn't matter if you use a CD for 14.0 or 14.1 I think, as long as you don't mix architectures). If you chroot, don't forget to bind mount proc dev and sys before. Then, just run lilo from your upgraded system (provided that you didn't forget to upgrade lilo itself, of course :-)

This is strange. I chrooted in my environment and a quick uname-a displayed that it still uses kernel 3.2.29.

This is my lilo.conf file:

Code:

# Linux bootable partition config begins

image = /boot/vmlinuz-generic-3.10.17

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = 3.10.17



image = /boot/vmlinuz-generic-3.2.29

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = Linux



image = /boot/vmlinuz

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = Linux

  read-only

# Linux bootable partition config ends

The first entry is thought to be the new system, while the 2nd entry was kept, just in case. The third is huge kernel.

However, at boot, LILO shows only "Linux" and "Linux-failsafe" not "3.10.17", and the 2 entries don't boot but only show the error message.

Code:

# ls -1 /boot/vmlinuz*

/boot/vmlinuz

/boot/vmlinuz-generic-3.10.17

/boot/vmlinuz-huge-3.10.17

first off I started using grub legacy in extra. then grub2 in slackware 14.1 when it became part of the full install. Nothing against lilo it has served me well.
this allows me to to point to /boot/vmlinuz for upgrades with kernels.

I use Slackpkg to handle all my upgrades. here is a script I wrote for me and some friends.Run it from run level 3 for distro upgrade. I also set it to run as root in terminal from kde menu.
I named it slack_multi_update.sh and I put it in my /usr/local/bin. or you can run it locally. it does require you to have already installed multilib.
and places the repo in /var/cache/multilib . For /etc/slackpkg/blacklist I keep it like this.

Code:

# 2This is a blacklist file. Any packages listed here won't be

# upgraded, removed, or installed by slackpkg.

#

# The correct syntax is:

#

# To blacklist the package xorg-server-1.6.3-x86_64-1 the line will be:

# xorg-server

#

# DON'T put any space(s) before or after the package name or regexp.

# If you do this, the blacklist will NOT work.



#

# Automated upgrade of kernel packages aren't a good idea (and you need to

# run "lilo" after upgrade). If you think the same, uncomment the lines

# below 

#

#kernel-firmware

#kernel-generic

#kernel-generic-smp

#kernel-headers

#kernel-huge

#kernel-huge-smp

#kernel-modules

#kernel-modules-smp

#kernel-source



#

# aaa_elflibs can't be updated.

#

aaa_elflibs



# You can blacklist using regular expressions.

#

# Don't use *full* regex here, because all of the following 

# will be checked for the regex: series, name, version, arch, 

# build and fullname.

#

# This one will blacklist all SBo packages:

[0-9]+_SBo

[0-9]+alien

[0-9]+compat32

then the script I use slack_multi_update.sh

Code:

 

 #!/bin/bash

# Init

FILE="/tmp/out.$$"

GREP="/bin/grep"

#....

# Make sure only root can run our script

if [ "$(id -u)" != "0" ]; then

  echo "This script must be run as root " 1>&2

  exit 1

fi



# ...



slackpkg update



echo -e "\e[1;33m If this is a Distro version update please read 

http://slackware.org.uk/slackware/slackware64-current/CHANGES_AND_HINTS.TXT

 so you can remove any unused packages\e[0m"





sleep 5



slackpkg install-new



echo -e "\e[1;33m Remember to select ok and press Enter\e[0m"





sleep 5



slackpkg upgrade-all



echo -e "\e[1;33m Going to upgrade multilib \e[0m"

sleep 5



##UPGRADE MULTI-LIB

rsync -r -a -v --bwlimit=100 --delete --progress --stats rsync://rsync.slackware.org.uk/people/alien/multilib/current/ /var/cache/multilib/

cd /var/cache/multilib

upgradepkg --install-new *.t?z

cd /var/cache/multilib/slackware64-compat32

upgradepkg --install-new *?/*.t?z



echo -e "\e[1;33m system is up to date \e[0m"

sleep 5







exit

This has worked well for me for a long time. 14.0 to 14.1 there was some system changes.
up to you to edit your slackpkg mirrors and the slack_multi_update.sh to reflect what version you are using.

I just edited my last message, adding more useful informations.

Will this script work from Slackware 14 to 14.1?

Quote:

Originally Posted by lensilvan (Post 5207762)

This is strange. I chrooted in my environment and a quick uname-a displayed that it still uses kernel 3.2.29

Of course as the boot sector was not updated because lilo failed.

Quote:

This is my lilo.conf file:

Code:

# Linux bootable partition config begins

image = /boot/vmlinuz-generic-3.10.17

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = 3.10.17



image = /boot/vmlinuz-generic-3.2.29

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = Linux



image = /boot/vmlinuz

  initrd = /boot/initrd.gz

  root = /dev/sda3

  label = Linux

  read-only

# Linux bootable partition config ends

You have two lilo stanzas with the same label "Linux". This of course can't work. Also, as the file /boot/vmlinuz-generic-3.2.29 doesn't exists any more the second stanza won't work anyway.

Quote:

However, at boot, LILO shows only "Linux" and "Linux-failsafe" not "3.10.17", and the 2 entries don't boot but only show the error message.[/The first entry is thought to be the new system, while the 2nd entry was kept, just in case. The third is huge kernel

Of course as again the boot sector was not updated.

Code:

# ls -1 /boot/vmlinuz*

/boot/vmlinuz

/boot/vmlinuz-generic-3.10.17

/boot/vmlinuz-huge-3.10.17

Please type instead

Code:

ls -l /boot/vmlinuz*

Type the letter l after the hyphen, not the digit 1 so we can check the target of the symlink.

Fix the labels in the /etc/lilo.conf then run while chrooted "lilo -t -v" and report the results. If all goes well just run "lilo" then.

In my opinion Drakeo's post don't directly answer your issue, so that would be another topic.

it should I used it. but remember I do not use lilo my boot loader will always have a entry to /boot/vmlinuz for falling back on. remember vmlinuz is linked to
vmlinuz huge. and edit your

Quote:

rsync -r -a -v --bwlimit=100 --delete --progress --stats rsync://rsync.slackware.org.uk/people/alien/multilib/current/ /var/cache/multilib/

Quote:

rsync -r -a -v --bwlimit=100 --delete --progress --stats rsync://rsync.slackware.org.uk/people/alien/multilib/14.1/ /var/cache/multilib/

if using lilo then I guess you need to edit lilo before running lilo. A little thing about building a new initrd.image I always
use the mkintrid script in /usr/share/mkintrid/ but every time I do after editing it for the new installed kernel modules it never does boot right with the generic vmlinuz.
but when I boot into the new kernel and run it it works fine. Have to look into this.
because should be able to compress any /lib/modules/kernel-you just _installed/ into a image. weird.

@Drakeo: again, this won't solve the OP's issue, which at the moment is just being unable to boot normally.

Quote:

In my opinion Drakeo's post don't directly answer you issue, so that would be another topic.

I think your right.
So boot from a cdrom and then edit /etc/lilo.conf and run /sbin/lilo. and make sure next time to edit lilo first before rebooting.

But that script has taken me from 13.37 to 14.1 and to current through the days.
I do not see any one doing a slackpackage multilib update except slackpkg+.

Multilib takes work to handle. some of SBO stuff goes into the distro. but if a little old friends can upgrade from 14.0 to 14.1 with it with a click of a mouse
using grub2 I am sure it can be just fine.
and my answer to this

Quote:

Hi,

I wanted to upgrade from Slackware64 14.0 (multilib) to Slackware64 14.1 multilib.

Salut,

Code:

# ls -l /boot/vmlinuz*

Code:

lrwxrwxrwx 1 root root    20 Jul 16 19:37 /boot/vmlinuz ->vmlinuz-huge-3.10.17

-rw-r--r-- 1 root root 3450176 Feb 15 07:40 /boot/vmlinuz-generic-3.10.17

-rw-r--r-- 1 root root 6436992 Feb 15 07:40 /boot/vmlinuz-huge-3.10.17

I deleted the second stanza on lilo.conf, while the first stanza was renamed "Test" and the other remaining is"Linux-failsafe" .

Then, I ran lilo -t -v. The result is in the attachment.

Also, the first warning is due that I normally use nvidia as a graphic driver, which configuration may have been overwritten by my disastrous upgrade.

Is it still fine that I run LILO and reboot?

Quote:

Originally Posted by lensilvan (Post 5207786)

Is it still fine that I run LILO and reboot?

I think so. None of these warnings looks lethal (and two of them may be caused by the fact that you forgot to bind mount proc dev and sys before chrooting).

EDIT I should have been more accurate. Let's assume you mounted your upgraded system's / partition as /mnt

Code:

mount --bind /proc /mnt/proc

mount --bind /sys /mnt/sys

mount --bind /dev /mnt/dev

OK, I rebooted and LILO works well.

However, I end up with this message, after booting through test.

Code:

No kernel modules found for Linux 3.10.17.

mount: mounting /dev/sda3 on /mnt failed: No such device.

ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.

      You can try to fix it. Type "exit" when things are done.



/bin/sh: can't even access tty; job control turned off.

Which means that I did not installed correctly kernel 3.10.17?

Please show your full /etc/fstab.

Could be that you forgot to ship a needed driver in your initrd, we'll see. Please show the full command you used to output the initrd.

Of course the modules are installed in /lib/modules/3.10.17?

The fstab file was uploaded on this message (under chroot).

I used the following command for creating the initrd:

Code:

mkinitrd -c -k 3.10.17 -f ext4 -r /dev/sda3 -m usbhid:hid_generic:ehci-hcd:mbcache:jbd2:ext4 -u -o /boot/initrd_3.10.17.gz

I confirm, the modules are well there, in lib/modules/3.10.17:

Code:

build

kernel

modules.alias

modules.alias.bin

modules.builtin

modules.builtin.bin

modules.dep

modules.dep.bin

modules.devname

modules.order

modules.softdep

modules.symbols

modules.symbols.bin

source

In the mkinitrd command, you have:

Code:

-o /boot/initrd_3.10.17.gz

but in /etc/lilo.conf:

Code:

initrd = /boot/initrd.gz

Unless the latter be a symlink to the former, this can't work.

That would explain that you can't boot, as the initrd is not loaded (at least not the good one, in case you have another one)

To make sure, please show full output of:

Code:

ls -l /boot/initrd*