Slackware and the grub boot loader.

I didn't.

Do su - and then type passwd to set your root password.

I already set the root password. I did it first thing after I installed.

Originally Posted by stf92 My apologies. It was me who typed the password, not the system. What happens is that entering 'su -' gives me a root prompt without having to type the password. I was used to enter the password always after su - so I automatically typed the password and pressed enter. Still why does su - not asks me for the password?

I think I now know what happens. When the installer asked if I wanted to set the password, I answered "no". Then when I finally boot the system, I ran passwd and set the root password. But the system still thinks the root password is the empty string. So when I do 'su -' the system does not ask for the password. It's the only explanation I find.

Slackware64-current
kernel 5.4.50

Something unbelievable: first note in this machine, Acer Aspire One Cloudbook 14 (A01-431-C8G8), the hardware clock can't be set by the OS. Only the BIOS knows how to write to it (I've tried with arch and with debian). Now I see the top bar clock (Xfce 4.12) is lagging. So I boot, enter the BIOS menu and set the clock to 12.30 (current time). I boot and run Xfce and I see the time is 6.30. I use the date command (just in case slackware can write the hardware clock) and set to 12.35. I boot and see the BIOS shows 12.36 which is true. I boot and I get time= 9.30. What happens here?

I think the O.S. does not know how to read the hardware clock. At boot time a message is displayed which says something like "Reading the hardware clock...", and it elapses about 10s before it displays the following message, which seems odd.

Run timeconfig as root and make sure that you have the correct answer for "Is the hardware clock set to local time or UTC?" (paraphrasing). My guess is you have it set that the hardware clock set to UTC. If you set it so the hardware clock is local, then it should match the time when you boot up into xfce.

No, it's not that. I ran timeconfig and after rebooting the clock was right. But today I turned on the machine and the clock was lagging three hours. It's what I said above. The system does not know how to read the hardware clock:

root@darkstar:~# hwclock
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
root@darkstar:~#

Try changing your CMOS battery

This is a laptop. Has it a CMOS battery?

If your still duel booting with debian select hardware clock set to utc.
Maybe this will help
https://www.linux.org/threads/how-to...ackware.23706/

For the time being I'll put 'netdate time.nist.gov' in /etc/profile. This will correctly set the system clock (date command) when I boot the O.S. But the problem is this: the time given by the date command, or by the top bar clock in the DE if you prefer, is not the same as the time in the BIOS menu. Or forget about the BIOS.

root@darkstar:/home/bill# hwclock --get
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
root@darkstar:/home/bill#

However Debian has no problem reading the hardware clock. It just can't write it.

Hi: suppose I have foo.txz in the working directory and I run removepkg. Will foo.txz be preserved or will it be deleted?

Originally Posted by stf92 Hi: suppose I have foo.txz in the working directory and I run removepkg. Will foo.txz be preserved or will it be deleted?

It will be preserved.

The only thing removepkg is look at the package database for an entry with that package name and will remove it. It won't affect the actual package itself, just removing any of the package that was installed on the system.

Thanks. I ask because having slackware64-current installed, I want to remove the entire d (development) series. Now, I plan to mount the installation USB stick, go to the slackaware/d directory and issue 'removepkg *.txz'. Latter on, I could installpkg gcc, which I think includes the linker, in case I want to build a slackbuilds package, for instance.

I have been trying to do with 14.2 the same thing I did with current. Namely, to make it boot when the "hard disk" is an eMMC device. The conditions are:

(a) I use BIOS legacy, not UEFI. (b) I use MBR. (C) I use grub. (d) In partition /dev/mmcblk02 I have slackware64-current up and running.

My intention is to install 14.2 in /dev/mmcblk01. It must be said that the installer has no trouble with the eMMC. The thing is that once the installation is finished and I boot, I get kernel panic. And what we discovered is that there were some drivers lacking. So the remedy consisted in adding those drivers, which the installer did use, to the initrd.gz. Here's the procedure I followed:

1. I downloaded and installed slackware64-current.

2. I ran setup again and chose 'Exit'. So now I have the prompt and it is the installer who is running.

3.
# mount /dev/mmcblk0p1 /mnt
# mkdir -p /mnt/{dev,proc,sys}
# mount -o bind /dev /mnt/dev
# mount -o bind /proc /mnt/proc
# mount -o bind /sys /mnt/sys
# chroot /mnt
# sh /usr/share/mkinitrd/mkinitrd_command_generator.sh>pepe
# chmod +x pepe
# ./pepe
# mkinitrd -w 10 -m mmc_core:sdhci:cqhci:sdhci-pci:usb-storage:xhci-hcd:mbcache:uas:mmc_block:xhci_pci:ext2
These are the modules the installer was using.
# exit

4. I boot current.

5. # grub-mkconfig -o /boot/grub/grub.cfg
Then I edited grub.cfg replacing, in the linux line, the 14.2 kernel with the 5.4.50 kernel (the current kernel) and made sure there was a linne initrd /boot/initrd.gz

6. I booted and now, the messages I got:

udevd[156]: starting eudev-3.1.5 
No kernel modules found for Linux 5.4.50

This is the end of the story. Now, what am I doing wrong?