Hi. My first thread here, long time slacker (20+ years). I'm a little stumped by this one, although I haven't ever tried to participate in the beta process before either..

I grabbed the very latest "current" from Alien Bob last night (MD5 sum checked out). Installed on an old machine I threw together from leftover parts (ECS 7050 mb, athlon x2 5600+, 2GB RAM, GTX 650, 130 GB PATA hard drive). Created a few partitions, installed to one, much like always.

Kernel panic on reboot. I can boot from the DVD using "huge.s root=/dev/sda1 initrd= ro". Still doesn't see my ethernet card, but one thing at a time. It seems the installation is only installing the generic kernel, but not the huge. On my main machine, looking in /boot, I see both generic AND huge, and I'm using huge.

So, it seems generic has an issue booting on this system. It may also be a lilo/MBR thing, although I've tried various combinations, and usually don't have this much trouble with it. I tried to copy (from the DVD) /kernels/huge.s, rename bzImage to vmlinuz-huge-4.4.4 and System.map to System.map-huge-4.4.4, then symlink those to /boot/vmlinuz and /boot/System.map, reran lilo, and then when I rebooted, I got:
L 99 99 99 99 99 (...)

One thing I did NOT have before was the bootable flag set on /dev/sda1, so maybe that was it? I'm re-formatting and re-installing now, just to test that theory.

What does the "99 99 99 ..." mean? I think I was supposed to uncompress the bzImage because lilo doesn't do compressed kernels? But man, it's been SO long since I had to do that, I forgot the commands for it. And why isn't the huge kernel installed also (or at least an option for it)?

Not a huge priority, because my other 2 systems are working (file server and "work" machine), and I won't spend a lot of time on it, but I was planning to bring up this spare machine to create my new 4TB raid setup and test the disks before moving them over to my fileserver (to reduce downtime).

Thanks for any help,
sD

Well, that's a pretty common issue so what surprises me is that you has to wait 20+ years before coming across it

Probably your lilo.conf is wrong. Use the same command to start your system from the DVD, fix lilo.conf, then run lilo -t -v to check it (look at the error messages) and fix it, then double check (lilo -t -v again) before just running lilo. If that doesn't help please post the whole content of lilo.conf here.

Also, a generic kernel is only usable if you associate it with a an initrd referenced in lilo.conf.

To be safe, check that /dev/sda be bootable ot put the boot sector on the MBR, and use a huge kernel. Only if/whan all goes add a lilo stanza for the generic one, keeping the old one just in case.

I have run into it a few times, but it was always a simple case of either:
1) lilo.conf was wrong
2) forgot to re-run lilo after compiling a new kernel
and I was able to fix it in a few minutes.

If a generic kernel can only work with an initrd, why is it installing the generic kernel by default? I've just gone with "huge" the last few times (13.0, 13.1, 13.37, etc), because I didn't care about a few KB of kernel mem.. I think that's the main problem: why isn't it picking the huge kernel by default?

It still does. I will try in a virtual machine (again!) to be 101% sure.

Just tried with only A and AP to save time, and something's funny: at boot I get:IIRC that was the message people got at first upgrading form 13.37 to current (or was it 14.0 to current?) and was solved upgrading lilo. Let me investigate further, then I will edit this post...

EDIT Wait, I had a GPT. Will wipe it out and redo it.

EDIT2: it worked as it should, /boot/vmlinuz being a symlink to the huge kernel.

Ok, this time it did get huge - very strange. And it can reboot. So perhaps it was just that I marked /dev/sda1 bootable from fdisk, but still no idea why huge wasn't there during the first install.

However, now a bunch of other stuff is really messed up.

No ethernet - neither eth0 (mboard) or eth1 (add-in GB card). mboard is MCP67 (old nvidia), add-in is RTL8169 (pretty standard stuff). lspci shows them both. But ifconfig doesn't show them - can't do "ifconfig plumb" or anything else.

On bootup, several messages that /lib/modules/huge-4.4.4 is not found. Indeed, no /lib/modules - at all. It's there on my 14.1 system for the stock 3.10.17 kernel.

So, go to /usr/src/kernel, try "make modules". Uh oh - no gcc. /usr/bin/g++-gcc-5.3.0.3 (something like that) is there, and symlinked to g++, so g++ exists, but not to gcc. So, I symlink it to gcc, now I have gcc.

Again, try "make modules", and it complains that it can't find stddef.h from types.h, using #include <stddef.h>. It's there in /usr/include/linux, but not found.

So, gcc is broken, kernel modules are broken (I know I've had to recompile/install them long long ago when I installed a new kernel back in the 1.x and early 2.x kernel days, but for Slack 13.x, 14.0, 14.1, as I recall, modules were just "there" for the out-of-the-box kernel), networking is down (presumably due to modules being broken). Not sure how to continue at this point..

I should have. Only possibility I can think of: you didn't install it but only installed the generic one.

I think that for some reason not all packages were installed. That would explain pretty much everything.

Assuming that you made a full installation (do you confirm?) I can just think of packages missing from the installation media for some reason. You can check that.

Both times I selected the default list of packages (everything but KDEi), and hit "install everything". I've done "install everything" for at least the last 10 years..

I did a bit more digging: pci id of add-in ethernet card is 01:06. Grepping for 01:06 in /var/log shows that it did some tests on it and determined that it was compatible for various D1/D2 HOT/COLD states - I'm guessing this is related to sleep/wake and/or hot-plugging. It did NOT mention 01:0a, the onboard MCP67 ethernet (which I verified in the BIOS is set to auto, which may have disabled it since it found the RTL8169, I don't know).

ifconfig -a shows only "lo".

I have half a mind to try the TP-Link PCI-E GB adapter I have here lying around.. But still - RTL8169 not detected/configured?? There's something seriously wrong. Those have worked for quite some time..

I'm using the very latest current, just built yesterday. I grabbed it as soon as it was finished (within seconds), but the MD5 sums matched up, so I assume it's the full .iso..

This is easy to check. Please mount it as /mnt then type:The result should be close to 1332.

It certainly sounds like your install media isn't complete (Didier's command should help figure that out). It could've been that when the ISO was generated that the mirror hadn't completed syncing, so you downloaded a screwed up ISO. You could resolve that by syncing a mirror yourself and then creating your own boot media. Eric has a script for that.

Got 1332..

EDIT: and the MD5SUM matches, according to k3b
Running "tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less" now to see if all packages pass their individual checksums. So far, only complains about ./extra/source and ./pasture (which, I believe, is the way things are supposed to be).

I saw the readme_dvd.mkisofs script in his directory:
http://taper.alienbase.nl/mirrors/sl...4-current-iso/

Didn't rsync get disabled from Eric's machine? Is there a HOWTO somewhere on how to rsync a mirror? I don't have that much time to devote to this, but would like to help out if I can, to make sure 14.2 is rock solid..

EDIT: Ok, trying Eric's "mirror-slackware-current" script.. Will see how it goes..
EDIT2: seemed to work, wrote this one to a USB drive (much faster to reboot :-), doing a brand new install, new partitions (less than 32GB, just in case, etc).
EDIT3: ok, I think that worked. Detected my ethernet cards, booted much more normally (started nouveau, had to disable it, etc..). Oh. x86, not x86_64.. Well, it's a 2GB machine, so probably doesn't matter, but can't re-use the NVIDIA binary I already had.. Oh well..
EDIT4: and for some reason, my gigabit ethernet is only connecting at 100Mbit - that's bad - I was planning to use it to mirror to/from my file server..
EDIT5: ok, looks like a bad "5e" cable.. Now getting 30 MB/s at least..

To cover your question about rsync, Eric did disable rsync for his taper.alienbase.nl server, but if you didn't already figure it out, you can use his script to mirror any Slackware mirror. If you end up wanting to rsync his slackbuilds/packages, there's other mirrors out there that stay synced with his machine, probably the fastest being http://slackware.uk/people/.

Depending on your intended uses of this machine, it might be worth reinstalling with Slackware64, but that's up to you.

But I'm glad to see it's working. I'm not sure what happened with your initial install (I'm still guessing his mirror wasn't fully synced when the ISO was generated), but I'm glad you were able to sync it and build the ISO yourself.

Yeah, I might still do SW64.. But, it's only a 2GB machine, so not sure I'd actually benefit much from it..

[offtopic rambling]
Would benefit more from a better ethernet card - I got the old RTL8169 up to 40 MB/s (PCI) by installing the Realtek driver (required a kernel recompile), but this mboard is so old they say at the beginning: in theory, this board can support 16 GB. However, since only 2GB modules exist, we've only been able to test 4 GB (DDR2). And no PCI-E slot, so I can't use the newer GigE card I have.

My main purpose for this machine is to set up my new 4TB mdadm array and copy over data from my 2 1TB arrays plus assorted other drives, then move the new drives into my file server and decide what to do about the old drives. My fileserver needs an upgrade from 14.0 anyway, so my plan was to wait for 14.2 and then upgrade and install the new disks. However, I need to test the disks before 30 days are up, hence my desire for using current - I'm pretty sure a few mdadm/filesystem things have changed since kernel 3.2.29.. Have even thought about btrfs, but I think I'll just stick with mirrored/striped raid 10 and put extfs4 on top. That should last several years, and I don't have to learn about LVM, btrfs vs zfs, etc..

At that point, this machine becomes entirely superfluous - my initial intent was to use it to replace an even older Athlon XP machine in my wife's classroom that's so old, Chrome isn't supported on it anymore. Then I found out that they're not supporting Chrome on XP for much longer either (all her other computers are still running XP), so not sure it's worth the hassle.