New Openbox respin soon : issue with mkinitramfs

Forum Forums antiX-development antiX Respins New Openbox respin soon : issue with mkinitramfs

  • This topic has 4 replies, 3 voices, and was last updated Feb 26-4:14 pm by melodie.
Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #54944
    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!

    #55003
    Member
    skidoo
    Helpful
    Up
    0
    :D

    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?

    #55005
    Member
    melodie
    Helpful
    Up
    0
    :D

    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. 🙂

    #55009
    Member
    fatmac
    Helpful
    Up
    0
    :D

    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

    #55011
    Member
    melodie
    Helpful
    Up
    0
    :D

    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 3 months, 3 weeks ago by melodie.
Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.