[arch-general] How best to adapt grub configuration?
Hi Jeanette,
in my opinion, the easiest option is to just write grub.cfg by hand.
Fortunately, in Arch, grub.cfg will never be overwritten by an update.
For basic functionality, grub.cfg may e.g. look like the following:
---
set default=0
set timeout=5
play
menuentry 'Arch' {
play
search --fs-uuid --set=root --hint=(hdX,gptY)
linux /vmlinuz-linux root=UUID=
initrd /initramfs-linux.img
}
menuentry 'Debian' {
play
search --fs-uuid --set=root --hint=(hdU,gptV)
linux /boot/vmlinuz- root=UUID=
initrd /boot/initrd.img-
}
menuentry 'OpenBSD' {
play
search --fs-uuid --set=root --hint=(hdR,gptS)
insmod chain
chainloader /BOOTX64.efi
}
---
assuming /boot is on a separate partition on Arch, but not on Debian.
And, for OpenBSD, that you are using (U)EFI.
In case you use Debian or another Operating System where parameters like
the kernel path change, you will have to update it manually though (or
by using a custom script running after update).
I am not sure where you would like the sounds to hear, so you might have
to change things. Also, I assumed the sound files to be located on the
current partition, i.e. - unless changed - the partition GRUB's
configuration files reside on.
Also, you should make sure, grub.cfg is not overwritten by another
distribution's package manager, like Debian's.
Note that the sounds will be played once the respective OS is about to
be booted. I don't know whether it is possible to hear the sound just
upon just selecting an option using arrow keys.
Also, you might consider writing functions for the separate boot options
that you can just call from the GRUB command line.
Regards,
Einhard
On 2018-04-16 13:20, Jeanette C. via arch-general wrote:
> Hey hey,
> how would I best adapt Grub's configuration file (gurb.cfg)?
>
> The usecase: I use Grub's play command to play different melodies for
> different entries and one when Grub is ready to be used. The reason
> behind it: I'm blind and like to know quite early on what is happening.
>
> Where would I best put these changes so they will survive Grub updates
> and regeneration of the config file?
>
> Thanks and best wishes,
>
> Jeanette
>
>
> * Website: http://juliencoder.de - for summer is a state of sound
> * SoundCloud: https://soundcloud.com/jeanette_c
> * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
> * GitHub: https://github.com/jeanette-c
> * Twitter: https://twitter.com/jeanette_c_s
>
> You should never try to change me
> I can be nobody else
> And I like the way I am <3
> (Britney Spears)
Re: [arch-general] makepkg - any way to recompile only newly patched files in large packages?
On 2017-08-07 09:39, David C. Rankin wrote: > On 08/06/2017 10:23 PM, David C. Rankin wrote: >> All, >> >> There was a fix for a gtk2 bug I filed regarding the recentchooserdefault.c >> file. (it was a one-line fix where a variable needed reset to 0). Is there >> any >> way I can configure makepkg to behave as if the gcc -MP -MD options had been >> given to have it only recompile the one patched source without rebuilding the >> entire package -- again? >> >> I've been through the wiki and the man page, and other than --repackage, >> there doesn't seem to be anything that would work (or I'm just missing it). > > If it wasn't clear, I have already built the gtk2 package yesterday to > --enable-debug=yes so I have all of the files in a state I could call > --repackge on, except for the gtk/gtkrecentchooser.c file with the one line > change. I was wondering if there was a way to avoid the full 15 minute rebuild > of all of gtk2 and just compile gtkrecentchooserdefault.c to object and then > --repackage? > That should be precisely the job of make. All the other preparation steps such as ./configure or patching should not harm either, likely rather be necessary. Hence, you could just try to rerun makepkg, providing that the $srcdir is still in the state after the last successful build. In fact, I already had problems doing this. Suppose a sed script replacing 'x' by 'xx', inline. In such cases one might consider using the --noprepare flag. In any case, it is a good idea to read the PKGBUILD (as always) and possibly modify it or even do all the work manually.
Re: [arch-general] (Off-topic) Command-line torrent download tool
On 2017-07-25 03:05, Kryptxy via arch-general wrote: > Hi there, > I'm not sure if the PKGBUILD will be accepted in AUR. I had once posted a > thread in open-source contributions in arch formus, but was taken down due to > legal issues (end of the day, TPB is illegal :P). So I didn't put effort in > building PKGBUILD. > That's the ONLY reason I posted about it here. As far as I know, thepiratebay.org by itself is not illegal, only much but not all of the _linked_ content. As an example, you can most likely find a torrent-link for an Arch ISO. > > Also, it's not a torrent client. It just scraps thepiratebay proxy sites, and > displays results in console window.
Re: [arch-general] Removing infinality
On 2016-09-24 23:57, Paul Marwick via arch-general wrote: > A short while ago, I installed the infinality bundle and fonts as an > experiment. Hit problems with some applications, so I'd like to revert > to the standard font handing. But I'm having all sorts of problems doing > so. My first attempt was this: > > fang@altair ~]$ sudo pacman -S --asdeps freetype2 cairo fontconfig > lib32-fontconfig lib32-cairo ttf-ubuntu-font-family ttf-droid > ttf-liberation ttf-dejavu > resolving dependencies... > looking for conflicting packages... > :: cairo and cairo-infinality-ultimate are in conflict. Remove > cairo-infinality-ultimate? [y/N] y > :: fontconfig and fontconfig-infinality-ultimate are in conflict. Remove > fontconfig-infinality-ultimate? [y/N] y > :: freetype2 and freetype2-infinality-ultimate are in conflict. Remove > freetype2-infinality-ultimate? [y/N] y > :: lib32-cairo and lib32-cairo-infinality-ultimate are in conflict. > Remove lib32-cairo-infinality-ultimate? [y/N] y > :: lib32-fontconfig and lib32-fontconfig-infinality-ultimate are in > conflict. Remove lib32-fontconfig-infinality-ultimate? [y/N] y > :: ttf-dejavu and ttf-dejavu-ib are in conflict. Remove ttf-dejavu-ib? > [y/N] y > :: ttf-droid and ttf-droid-ib are in conflict. Remove ttf-droid-ib? [y/N] y > :: ttf-liberation and ttf-liberation-ib are in conflict. Remove > ttf-liberation-ib? [y/N] y > :: ttf-ubuntu-font-family and ttf-ubuntu-font-family-ib are in conflict. > Remove ttf-ubuntu-font-family-ib? [y/N] y > error: failed to prepare transaction (could not satisfy dependencies) > :: ibfonts-meta-base: removing ttf-dejavu-ib breaks dependency > 'ttf-dejavu-ib' > :: ibfonts-meta-base: removing ttf-liberation-ib breaks dependency > 'ttf-liberation-ib' > :: ibfonts-meta-extended-lt: removing ttf-droid-ib breaks dependency > 'ttf-droid-ib' > :: ibfonts-meta-extended-lt: removing ttf-ubuntu-font-family-ib breaks > dependency 'ttf-ubuntu-font-family-ib' > :: lib32-freetype2-infinality-ultimate: removing > freetype2-infinality-ultimate breaks dependency > 'freetype2-infinality-ultimate > > I asked around, and had a suggestion that I should remove > ibfonts-meta-base ibfonts-meta-extended-lt and > lib32-freetype2-infinality-ultimate first. Tried that, and got this result: > > |fang@altair ~]$ sudo pacman -R ibfonts-meta-base > ibfonts-meta-extended-lt lib32-freetype2-infinality-ultimate checking > dependencies... error: failed to prepare transaction (could not satisfy > dependencies) :: ibfonts-meta-extended: removing > ibfonts-meta-extended-lt breaks dependency 'ibfonts-meta-extended-lt' :: > lib32-fontconfig-infinality-ultimate: removing > lib32-freetype2-infinality-ultimate breaks dependency > 'lib32-freetype2-infinality-ultimate' :: lib32-harfbuzz: removing > lib32-freetype2-infinality-ultimate breaks dependency 'lib32-freetype2' > So I'm stuck. I really need to get back to the standard font rendering, > but so far I've been unable to find a way of getting past the conflicts. > I really don't want to reinstall - this Arch install has been around for > several years, and I'd much rather find a way of fixing it. Can anyone > tell me how to get back to normal? Paul. | You have not by chance installed the infinality-bundle group? In that case, you should be able to simply remove the whole group. Also, you might like to use the --recursive option to prevent no longer needed dependencies from filling your disk.
Re: [arch-general] pacman upgrade confusion
On 2016-04-04 18:10, message wrote: >> Readers, >> >> An announcement >> (https://www.archlinux.org/news/required-update-to-pacman-501-before-2016-04-23/) >> >> states that users must upgrade to pacman501. >> >> pacman -S pacman >> warning: pacman-5.0.0-1 is up to date -- reinstalling >> resolving dependencies... >> looking for conflicting packages... >> >> Packages (1) pacman-5.0.0-1 >> >> Firstly, I tried: >> >> yaourt -Syua >> package-query: error while loading shared libraries: libalpm.so.9: >> cannot open shared object file: No such file or directory >> >> Then: >> >> pacman -S pacman >> warning: pacman-5.0.0-1 is up to date -- reinstalling >> resolving dependencies... >> looking for conflicting packages... >> >> Packages (1) pacman-5.0.0-1 >> pacman --version >> >> .--. Pacman v5.0.0 - libalpm v10.0.0 >> / _.-' .-. .-. .-. Copyright (C) 2006-2016 Pacman Development Team >> \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet >> '--' >> This program may be freely redistributed under >> the terms of the GNU General Public License. >> >> What am I doing wrong, to prevent update to pacman501? You should run `pacman -Syu' to fully upgrade you system.
Re: [arch-general] startx on arch vm running on ESXI (when accessed via ssh - do I need a DM?)
On 2016-03-18 20:21, David C. Rankin wrote: > All, > > When I ended up with a hand-me-down supermicro server from a local ISP, I > decided to try virtualizing all my hosts. The company I got this from > recommended vmware ESXI as the hypervisor. It was a pleasant surprise to find > that ESXI is a basic Linux system. (albeit a very limited and quirky setup). > > I've installed Arch as the first vm, assigning 8-cores and 16G of RAM. It is > up and running fine. (it is installed on a raid1 array volume from a LSI > controller which exists as a single datastore in esxi -- if that makes any > difference) > > I am trying to setup fluxbox on arch so I can access the vm via rdesktop (or > something similar) via a GUI on a as needed basis. I would rather not have a > display manager running all the time, so I'm attempting to use the startx > route. > > I've used the following to try and get this going: > > https://wiki.archlinux.org/index.php/Fluxbox > https://wiki.archlinux.org/index.php/Xinitrc > https://wiki.archlinux.org/index.php/xorg > https://wiki.archlinux.org/index.php/Display_manager > > The configuration is good, but I'm stuck attempting to start X. X is > refusing > to start due to the fact I'm accessing Arch by ssh. When I try to start x, I > receive the following error telling me that "Only console users are allowed": > > $ startx > > /usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X > server > > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > Couldn't get a file descriptor referring to the console > > I understand that it wants X only to be started from the actual physical > console, but when I access the vm over ssh, I don't have one. (I am starting > the > vm, ssh'ed into esxi with 'vim-cmd vmsvc/power.on 1', so there is no console > anywhere else) > > What would be the best solution? Have arch boot to the graphical target > loading a display manager? ... or is there some way I can simply startx as > needed so I don't leave the dm running all the time on the vm? Thanks for any > help you can provide. > If you only want to run individual applications, you can use the -X switch of ssh and then simply execute the respective applications as you would normally. Note that this requires the ssh-session being opened in a local graphical terminal. If you however want to have a full graphical environment, you will have to use VNC or something comparable, or so I think.
Re: [arch-general] Alternative init system proposal
On 2016-02-13 17:35, João Miguel wrote:
> The decision was to have systemd as a default, not to forbid any other
> init system to be mentioned. I don't agree with the OP of this thread
> when he said there should be an official version of Arch with OpenRC,
> that's too much work.
>
> I mean this: https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC
> should be here: https://wiki.archlinux.org/index.php/OpenRC. So that
> this: http://systemd-free.org/ is not necessary, but instead just a nice
> plus.
>
> Best regards,
> João Miguel
I agree with you on the point, that the possibility of choice should not
be suppressed, but instead be welcome on the Wiki.
However, I also see how having two ways of doing something rather
unusual and officially unsupported may create notable confusion or at
least makes the article hard to read.
Hence I would suggest creating a totally new Wiki entry which explains
solely artoo's way, named e.g. 'OpenRC (eudev)'.
To prevent identical sections of both articles, your one should only
address the differences, i.e. sections 1{,.3} (Installation and Booting)
and 2.3 (Network) and some notes on further differences.
Obviously, the two articles should point to each other as a respective
alternative.
Re: [arch-general] Update php 5.6 to 7.0.1 problems
On 2016-01-26 21:30, Wolfgang Mader wrote: > On 01/26/2016 09:21 PM, Maykel Franco wrote: >> [000][+][[user@arch-xbmc: /etc/php]] $ php --version >> PHP Warning: PHP Startup: Unable to load dynamic library >> '/usr/lib/php/modules/mysql.so' - /usr/lib/php/modules/mysql.so: >> cannot open shared object file: No such file or directory in Unknown >> on line 0 >> PHP Warning: PHP Startup: Unable to load dynamic library >> '/usr/lib/php/modules/openssl.so' - /usr/lib/php/modules/openssl.so: >> cannot open shared object file: No such file or directory in Unknown >> on line 0 > > If I recall correctly, openssl is now integrated so no module must be > loaded any more (and so this module has vanished). > >> PHP Warning: PHP Startup: Unable to load dynamic library >> '/usr/lib/php/modules/posix.so' - /usr/lib/php/modules/posix.so: >> cannot open shared object file: No such file or directory in Unknown >> on line 0 >> >> Can I help me please? And the mysql module has been removed in favour of mysqli and PDO. You seem to have updated to PHP 7 without having had a look at the php.ini.pacnew, which is the way to go now.
Re: [arch-general] Firefox without signature checking
On 2016-01-03 06:11, Kyle Terrien wrote: > On 01/02/2016 05:24 PM, Magnus Therning wrote: >> The larger, and very philosophical question is "How user un-friendly can >> upstream make it before Arch decides to *not* package as upstream >> intends?" (Answering this requires keeping in mind that Arch users are >> unlikely to fall squarely into the target group of upstream.) > > This is a very good question to ask imho. In a perfect world, we would > just fork and be done with it. However, it is not a perfect world. > Forking requires time and effort, and it generally kills the software. > (Here I am with several installs that have both Firefox and Pale Moon > for compatibility reasons.) What is wrong with e.g. IceWeasel, IceCat, Abrowser? And in which regard does forking "kill the software"? Especially if it only means applying certain patches upon each update of the original project? I totally agree with the decision of Arch's developers. If we stick with Firefox as provided upstream, this simplifies much: - Less work for the Arch developers - The features are exactly as expected, i.e. there is no Arch Firefox. - If the users dislike upstreams decisions, they will use a possibly newly created fork instead. If that achieves a sufficiently big user base, it will most likely be taken into the official Arch repositories. This has the side effect of making the original less popular and thereby making them think about their decision. > Most Arch users definitely do not fall into Mozilla's target group (an > imaginary "average Joe" as I like to call it). We made this decision > when we decided to install Arch as opposed to Ubuntu, Mint, OpenSUSE, or > any other distro that does a decent job of configuring itself > automatically. In my opinon, it is actually very simple: If somebody does not fall into Mozilla's target group, he either - does not use it or - accepts that Mozilla does not care about his needs. When one decides to install Arch, one does also decide to get software as provided by upstream, patched as little as possible.
