Yes,

Sometimes it's the simple things in life that trip us up and make us fall flat on our face.

After some nagging "issues" with my installation I decided to stop using swaret for upgrades, and use the UPGRADE.TXT file's instructions instead.

After grabbing the latest /slackware directory I decided to give it a try, without thinking that I _MAY_ not have enough room for the new packages. Now my system will not boot.

I guess that I need to try and rescue the system, so I come to the group for advice.


I have the 10.0 disc set available to me, and I can get the system to boot as long as I don't try to use "boot bare.i root=/dev/hda3 noinitrd ro " when booting with the second CD.

My question is if this would be the best way to rescure my system.
I was running a fairly recent snapshot of -current

Use the 2nd CD from 10.0 to boot, then chroot into my system?
Obviously I need to clean up the / partition a bit ( remove old packages left behind by swaret)
Then, should I be able to use upgradepkg or pkgtool to bring my system back to life?

I had issued the command upgradepkg --install-new /root/slackware/*/*.tgz
I watched the first 20 packages get upgraded then walked away... when I returned the system was already hosed. I could move about in my directory tree with the cd command, but could not issue any commands at all. ls, less, cat, were all gone. telinit would not even work.


I know I could always reinstall... but I want to try and learn more from this mistake.
Thanks for the advice!

[EDIT #1]
Booting with the rescue cd (slack 10.0 disc #2) allowed me to mount my root filesystem,
starting MC (midnight commander) showed me my problem,
I was able to compare my /lib with the one created at bootup from the cd.
I noticed some 0 length lib files and bad symlinks. Thankfully there was an incomming folder with the libs still intact, so I managed to copy the files to the correct location, and edit the symlinks to the correct lib files.
After this process, I was able to exit MC and chroot to my old system.
Not sure if the system will run on it's own, but it's looking better.
[END EDIT #1]

Swaret is probably a great software as long as you use with the following recommandations in mind :

1. you really try to read Swaret's documentation before using it as it contains many warnings/informations a Swaret user must know. We are talking about a package manager here, not a new icon editor program aim to be intuitive.
2. you only use Swaret to upgrade Slackware's official packages (and probably packages which you have built by yourself).
3. you get rid of third party sources in the Swaret's configuration file (/etc/swaret.conf) : you can even start by removing LinuxPackages entries.
4. you do not use Swaret to upgrade from Slackware Linux N to Slackware Linux N+1.

These are the main things you should remember from this experience. Oh, and next step is obviously to reinstall a new Slackware Linux system : it will be quicker and easier, and you will have a clean environment to work/learn with.

-- LiNuCe

Er, there is no reason to reinstall here...

Just booting the system with any LiveCD, and mounting your root partition will allow you to clear out unwanted files and packages to enable enough free space to actually boot.

If there is any lesson to learn here, it is that you need to purge those downloaded packages once and awhile. Should also clear out /tmp on occasion as well, since Slackware doesn't delete anything in there default.

It would also be a good idea to spread your system out on a few more partitions if possible.

For instance, slapt-get by default saves all downloaded packages to /var (not sure about swaret0 so i put that on it's own partition.

This way, if I ever manage to let the cache get out of control, it will only lock up that partition, and not my entire system.

I am sure swaret will let you setup the download cache wherever you chose, so moving it to another partition other than the root one shouldn't be a problem.

Just something to keep in mind for the future. We learn from our mistakes after all.

Also, slapt-get will calculate how much space is needed on the drive based on the advertised uncompressed size of the package (along with the size of the download). From there it uses the statvfs(2) syscall to find out if the device that the working directory is located on has enough space, and will warn and halt if it does not.


take care,
jason

Thanks for the info guys!
But, I am not ready to throw in the towel on the system yet.
Somehow, reinstalling seems TOO Much like a M$ product and offers little chance to really learn.

Tried chroot from the second cd, and got /bin/bash not found...
seems logical to me since no commands would execute after the crash.
Deleting / purging 2.5 Gb of tgz files didn't make any difference.

booting with boot:bare.i root=/dev/hda3 noinitrd ro hangs with
INIT: cannot execute "/sbin/agetty"

so I'm off the plan my attack...

Thanks again guys.

You have mounted the file system with a LiveCD (no need to actually root into it) and removed files and it didn't allow you to boot with it?

What FS are you using? Have you tried running a FS check on it after deleting all of the files?

By the way, that is something I didn't know jaos. I am actually pretty surprised slapt-get has that ability, since I have managed to lock a partition with apt-get in the past when the cache got too large.

Perhaps the original needs to learn some tricks from the clone.

OK,

I was running a compiled kernel (2.6.10)

*After booting the second cd and creating about 2.5 Gb of free space*

When I boot normally and select my 2.6.10 kernel, it freezes.
with the message "Loading 2.6.10EBDA is big; kernel setup stack overlaps LILO second stage"
I understand that because lilo could have been updated, and because of the crash, I didn't have a chance to run /sbin/lilo. I know that it installed the latest stock kernel, so that all makes since to me.

If I select another kernel (2.6.7)
It gets further in the boot process before hanging with the message
"INIT: cannot execute /sbin/agetty" about 10 times then
"INIT: Id "c6" respawning too fast:disabled for 5 minutes"
"INIT: no more processes left at this run level"

If I boot from cd#2 (the 10.0 rescue cd) and type
boot:bare.i root=/dev/hda3 noinitrd ro
I get the same error as booting my 2.6.7 kernel

I can boot from cd#2 without any extra commands and the machine will boot to a prompt
I can mount my / filesystem, but can't chroot into my system:
mount /dev/hda3 /mnt/hd
chroot /mnt/hd produces this error message
"chroot:cannot run command 'bin/bash' :no such file or directory" and I return to the prompt
root@rescuedisk:~#
When I check out the filesystem, I do have /bin/bash (/mnt/hd/bin/bash is present)

That leads me to think that there are some libraries that didn't get written to the disk during the upgrade, or symlinks are bad...

I haven't had time to update this thread, just to give a update on my system.

I could now boot my system, although it did have a few problems.

A quick check of /boot revealed a newly installed kernel and /usr/src/linux now pointed to a new directory /usr/src/linux-2.4.31
To be exact, my old 2.4.24 kernel was replaced by the 2.4.31 and the symlinks pointing to my 2.6.10 directory were changed as well.
Easy enough to fix.
Edit /etc/lilo.conf editing the entry for 2.4.24 to reflect 2.4.31


then remove the symlink from 2.4.31 and point it back to my 2.6.10 directory
Now I need my old kernel installed back to my /boot ( it was overwritten during the upgrade)
so cd /usr/src/linux and run make install

Now I have my system back up and operational - almost...

I notice that I am getting some messages about truncated files.
Pressing the scroll lock key allows me to make note of them and their location.

Checking these show 0 byte files.
Seems easy enough to fix, just locate my packages and uninstall/ reinstall the failing files.

All that being said...

My system is now 99% I still have some investigating to do, but I didn't have to do a clean install and I managed to learn a bit in the process.