[SOLVED] latest slackpkg upgrade-all bricks system on slackware64-current

Darth Vader · 01-03-2018, 10:49 AM

Yep, that works, BUT only from a proper booted installation. Either way, mkinitrd will be confused about the root device.

jkh2cpu · 01-03-2018, 10:50 AM

Are you trying this with the latest offerings from slackware64-current?

And yes, my mkinitrd is about the same as yours, without the stuff after -m ext4.

John.

Darth Vader · 01-03-2018, 10:52 AM

More precisely, what command you use?

sombragris · 01-03-2018, 10:52 AM

Situation seemingly back to normal here. This thread has been priceless.

Thanks for the info. This answer by Darth Vader was especially useful.

However, a caveat: mkinitrd_command_generator may not be generally useful. Be careful.

I booted using an old kernel 3.8x bootable media I had around, followed the steps, and everytyhing went alright save for the mkinitrd_command_generator part. Somehow it prepares its modules taking into account the boot media. So when I applied the command generator, all I got was "No modules for kernel 3.8.x". Not useful.

I would suggest reading README.initrd in your root directory. In my case, while chrooting, I just typed:

Code:

  mkinitrd -c -k 4.14.11 -m ext4 -f ext4 -r /dev/sda2

and that simple command line generated a working initrd. After that I was able to boot.

Hope everyone could recover from this snafu without much sweat.

sombragris · 01-03-2018, 10:56 AM

Quote:

Originally Posted by Darth Vader

You are only a victim of your own laziness.

You are supposed to switch to the generic kernel and initrd after the first boot of your operating system. The huge one is/was only a workaround for the first boot, nothing more.

I resent being called lazy. That was completely uncalled for and totally inappropriate.

I do switch to a generic kernel!

After a kernel upgrade I boot once into the upgraded huge kernel, generate my initrd, and then reboot into the generic kernel.

However, this particular problem presented itself when I was supposed to boot that single time from the huge kernel.

Darth Vader · 01-03-2018, 10:56 AM

You can specify to mkinitrd_command_generator.sh which kernel you want to target, using something like.

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.14.11

Darth Vader · 01-03-2018, 10:59 AM

Quote:

Originally Posted by sombragris

I resent being called lazy. That was completely uncalled for and totally inappropriate.

I do switch to a generic kernel

After a kernel upgrade I boot once into the upgraded huge kernel, generate my initrd, and then reboot into the generic kernel.

However, this particular problem presented itself when I was supposed to boot that single time from the huge kernel.

Fair enough! I apologize!

And yes, I agree that the latest kernel updates contained an unexpected surprise.

Darth Vader · 01-03-2018, 11:04 AM

For the record, there is how I do myself:

I have a file called "/boot/mkinitrd.sh" with the following content

Code:

#!/bin/sh

KVERSION=4.14.11

KMODULES="xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4"

ROOTDEV="UUID=35689c2a-bb39-4444-90f1-1cdec17f85e4"
ROOTFS="ext4"

SWAPDEV="UUID=21e3d368-6558-4b12-b1ff-9b3da262f340"


mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -w 5 -o /boot/initrd-${KVERSION}.gz

#
ln -sf initrd-${KVERSION}.gz initrd.gz

lilo

Then, I always INSTALL manually, BUT I do NOT UPGRADE the kernels, then I update KVERSION and execute the script.

After a successful reboot, eventually I remove the old kernels. Manually, too.

To note that I modify the /etc/lilo.conf accordingly and I have always the ability to boot the previous kernel, via another LILO entry.

Petri Kaukasoina · 01-03-2018, 11:08 AM

It's also possible to add parameters to /etc/mkinitrd.conf. See /etc/mkinitrd.conf.sample and 'man mkinitrd.conf'.

mralk3 · 01-03-2018, 11:12 AM

Quote:

Originally Posted by Petri Kaukasoina

It's also possible to add parameters to /etc/mkinitrd.conf. See /etc/mkinitrd.conf.sample and 'man mkinitrd.conf'.

Beat me too it! Also:
https://docs.slackware.com/slackbook:booting#mkinitrd

Darth Vader · 01-03-2018, 11:14 AM

You guys are both right, but I have my personal taste on treating this business, as everyone.

And I consider the boot a very serious business, which I prefer to handle step-by-step with my own hands.

jkh2cpu · 01-03-2018, 11:18 AM

OK, fixed.

I needed to add mount -o bind /usr /mnt/usr for mkinitrd to run to completion.

Darth, you make it sound much harder than it actually is.

That machine boots.

Thanks for the help, guys.

John.

Darth Vader · 01-03-2018, 11:26 AM

Quote:

Originally Posted by jkh2cpu

OK, fixed.

I needed to add mount -o bind /usr /mnt/usr for mkinitrd to run to completion.

Darth, you make it sound much harder than it actually is.

That machine boots.

Thanks for the help, guys.

John.

Yeah, man! You are right! I need to throw my crystal ball, it not seen your custom /usr mount point. Sorry!

BUT, so far so good for you. Maybe you are kind to mark this thread as solved?

Psst. Marking some guys responses as useful, may make them a bit happy, too...

sombragris · 01-03-2018, 11:39 AM

I would expect a new -current update with a fixed huge kernel before marking this as solved. The issue persists and many folks are going to be bitten by this "surprise" (as Darth Vader said and which describes the situation very well).

sombragris · 01-03-2018, 11:52 AM

Well, one thing is clear. A situation like this in other distros would have us reinstalling at the very least. Thankfully in Slackware we have a robust architecture, tools that work, and fellow users which are patient and willing to guide others to a solution. I am really grateful for Slackware.