After reboot, liloconfig not working and lilo.conf missing
 

So I'm finally working on installing Slackware last night, everything is going well. I manually installed LILO using the liloconfig script, which worked fine but I forgot to make a setting I needed in my lilo.conf for my dual-boot setup, so I thought no big deal, I'll just boot from the CD and fix it up real quick...right?

This lead to an interesting situation. After booting from the disc, I opened all my encrypted LVM's, mounted them under /mnt, and chroot'ed into it. When I tried to edit my lilo.conf, I found it was not there. There was a lilo.conf_example but it didn't look like what I'm used to seeing.

So I thought I could just run liloconfig and have it create a new lilo.conf for me, but when I do that nothing happens, it just returns me to a prompt on the next line, with no messages or errors or anything. If I run it directly after the install but before rebooting it works fine, but after a reboot it just stops silently with no indication as to why.

One other little thing I noticed, was that when I chroot into my mounted install folders, there was no color coding, every folder in root was listed in white text, and my prompt never changed. When I exit and run ls on the live system, the color coding is present. I'm not sure if this is normal behavior, but it caught my attention.

So I guess my question in in three parts:

1) Why does my lilo.conf disappear when I reboot after install?

2) Why does liloconfig stop working after I reboot?

3) Does Slackware handle mounting a system and using chroot to access it differently than other distros?

1) and 2 ) How you reboot your system ?
3) Yes.

I used Ctrl-Alt-Del to reboot.

To mount my system afterwards, I use the following commands:

mkdir /mnt/root
mount /dev/vgroot/root /mnt/root
mount /dev/vghome/home /mnt/home
mount /dev/sda3 /mnt/root/boot
mount -o bind /proc /mnt/root/proc
mount -o bind /dev /mnt/root/dev
mount -o bind /sys /mnt/root/sys
chroot /mnt/root

These commands are based from my previous experience with other distros, but the color-coding thing was what led to my thinking that perhaps something may be different here.

*Edit: I forgot to include the unencrypted /boot partition, corrected

I would think that the simplest explanation is that the etc/lilo.conf used during installation is not the /etc/lilo.conf on your encrypted root partition. If you're also getting a vanilla profile when logging in, it could be that sample profile files are not being installed to give you e.g. colorised ls. It would seem that the etc directory being used during installation is not the one on disk. Are there other .conf.samp files which do not have corresponding .conf files, for example is networking configured? It may be helpful to investigate exactly what is mounted where during installation.

My first post, so here's hoping I'm not talking out of my derriere!

Do you have a separate /boot partition? Lilo is not able to boot directly from an encrypted /-partition or LVM, but I can't see you mounting that partition. Also, have you tried to run the liloconfig script from within pkgtool? I found this to work better sometimes.

It's normal. I'm not sure if it's possible to source profile scripts during chrooting, but you could try a little "trick" from Gentoo handbook.
Last command is optional, but really useful if you need to do non-trivial changes and don't want to get lost between liveCD and chrooted environment.

@P.T. Firefly: That was my initial thought as well, so I booted from the disc thinking that I could run liloconfig from there and create another one, but I was unable to do so. As for the color-coding in the chroot environment, I thought that this was a feature of ls, but you and another poster mentioned something about profiles so my ideas about that must be incorrect.

@TobiSGD: I neglected to include that line in my earlier post this morning, but yes I do have an un-encrypted boot partition. I edited my earlier post to reflect that, thanks for pointing that out. As for running liloconfig from pkgtool, no I have not tried that. I was attempting to just run it from the command line, but I'm going to try this out and see what happens here in a bit.

@yenn: Thanks for confirming this, I thought that it might be, but combined with the prompt not changing (which I'm used to seeing in other distros) I couldn't help but feel like there must be something else going on here. I don't mind living without the color-coding in chroot, it was just an observation I made and I honestly wasn't sure if it was related to my issue or not, so I thought I'd mention it. tuxbg replied earlier that Slackware does indeed handle chroot differently, but didn't elaborate on how exactly, so I don't know if the commands I'm using are correct in this case.

I'm going to try running liloconfig from pkgtool as TobiSGD suggested and I'll report back with the results.

Well, the good news is that running liloconfig from pkgtool worked. It complained about not being able to detect my video hardware and falling back to text-only mode, but it creates a new lilo.conf file that I can edit as needed, which is exactly what I was after. Still kinda curious why it disappears after every reboot though, I don't recall having that problem in the virtual machine I used to test all of this, I'll have to go back and check.

However, I'm faced with a new problem now...kernel panic: can't mount root filesystem...that ought to be interesting. Gonna try to hack around on my own and see if I can figure it out without opening another thread...but I may be back if that's ok. =)

Thanks for all the replies and suggestions, much appreciated!

When you run lilo you should not be in the chroot environment, all the real boot mount points must be mounted and valid.

[EDIT]
That was written in an interrupted hurry... let me say it better...

When you run lilo, the real boot/ location (i.e., lilo image=... location) must be mounted and visible exactly as it appears in the lilo stanza, which is probably not true within your chroot environment unless you have made it so.

Also, your root=... device at boot time must be the same as specified in your lilo.conf, which might differ from what appears when you boot to DVD and chroot.

In other words, make sure that your lilo.conf boot/ is mounted when you run lilo, and that the root/ agrees with exists at boot time. - Hope that helps.

[/EDIT]

@astrogeek: I have the /boot partition mounted within the chroot, and the only errors I've seen when running lilo were something about not detecting my video hardware. I also see the changes I made to lilo.conf properly reflected in the MBR after rebooting, which indicates that lilo is working correctly.

The root= is a little different story because of the LUKS/LVM setup. I have an encrypted root partition on /dev/sda4, which when opened and activated maps to /dev/vgroot/root, and have created an initrd using the built-in script. If I'm remembering right, passing the -C option with /dev/sda4 is the part of the command that tells initrd to open the LUKS container there during boot, and this is handled by the rc.S script.

I suspect that something with the initrd/rc.S is not performing this step for some reason, but I'm not sure why yet. I had this all setup in a virtual machine before attempting it on the real thing, and had it all working in there, and I'm pretty sure I did the exact same thing on the laptop now. I still have the VM so I was thinking about taking a look at it later today to see if I can find any differences in the two.

I was a little hesitant to dive into this new problem in the same thread, I was thinking that wasn't good forum etiquette since future problem-solvers might have a hard time finding the solution if it's under a different title. I traditionally read far more than post, so I might be overly cautious about things like that. =)

Indeed. Please open a new thread for your new topic and mark this one as solved.