New Openbox respin soon : issue with mkinitramfs

[Member melodie]

Hello,

I wanted to recreate an initramfs so here I go, as root:

# update-initramfs -u

nothing happened.

where is the command? Well, it is in /usr/sbin

is /usr/sbin in the path? No it isn’t, “echo $PATH” confirms. So here I go, as root:

# /usr/sbin/udpdate-initramfs -u

can’t find mkinitramfs.

Well, same thing, this poor program looks for mkinitramfs in the wrong place.

I have solved it by creating two symlinks in /usr/bin/

If this is a bug, I’ll leave it to you to check about this, and do whatever can be done.

Thanks for your work!

[Anonymous]

Helpful

Up

0

::

udpdate-initramfs

typo, or actual?

FWIW, tested just now on antiX19 w/ stable repositories and I did not encounter the issue you described.

this poor program looks for mkinitramfs in the wrong place.

What is the name (or full path) of “this poor program” ?
If a typo exists within some pre-installed script and “something need to be done about it”, that’s a necessary detail to mention, eh?

[Member melodie]

Helpful

Up

0

::

Anonymous wrote:

What is the name (or full path) of “this poor program” ?

invoking:
# /usr/sbin/update-initramfs -u

it didn’t find mkinitramfs.

So I added a symlink in /usr/bin, for both update-initramfs and mkinitramfs.

If it works in the mother edition, then something has gone wrong in the way, but I don’t know what.

typo : yes, well done! I wrote udpdate instead of update. Thanks for the fix. 🙂

[Member fatmac]

Helpful

Up

0

::

The sbin directories are root owned, that’s why as a normal user you didn’t achieve your goal. 😉

(As a regular user, use sudo.)

Linux (& BSD) since 1999

[Member melodie]

Helpful

Up

0

::

fatmac wrote:

The sbin directories are root owned, that’s why as a normal user you didn’t achieve your goal.

(As a regular user, use sudo.)

As stated in the first post, I did start the program as root :

$ su
passwd
# update-initramfs -u

then, this didn’t work, because /usr/sbin *isn’t in the environment path* so I did – as root :
# /usr/sbin/update-initramfs -u

this didn’t work either because mkinitramfs is also in /usr/sbin/, so I just did symlinks in /usr/bin.

I still don’t know why some programs and which, in antiX need “su” and some need “sudo” (or gksu for windowed applications, of course).

ie : I could not launch Lightdm GTK Greeter Settings from the menu. It just didn’t work. I found after several trials in console, that I had to change the Exec command line in the desktop file to “Exec=gksu lightdm-gtk-greeter-settings-pkexec” (and save the file in my “~/.local/share/applications” directory, for obvious reasons – don’t want it to be replaced in case of future update).

Same with minstall.desktop : in antiX it is “Exec=su to root … minstall”. I replaced it with “Exec=sudo minstall”, or in my spinoff it would trigger a window requesting a password. (I already had done so in the former i486 respin).

Thanks for further explaining… su ≠ sudo in antiX programs. 🙂

• This reply was modified 2 years, 2 months ago by melodie.

[Author]

Posts