|
please update inxi -! 11 to 1.9.8-3-b1
I had a typo in the zypp path, it should work now. :: Code :: zypp_repo_dir='/etc/zypp/repos.d/'Now that inxi is in sid/debian I have to be good and use the branches for dev testing before putting a version live trunk. Back to top |
|||||
|
:: Code :: inxi -rI
Repos: Active zypp sources in file: /etc/zypp/repos.d/KDE_extra.repo KDE_extra ~ http: //download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed Active zypp sources in file: /etc/zypp/repos.d/KDE_new.repo KDE_new ~ http: //download.opensuse.org/repositories/KDE:/Release:/410/openSUSE_12.3/ Active zypp sources in file: /etc/zypp/repos.d/Packman_Tumbleweed.repo Packman_Tumbleweed ~ http://packman.inode.at/suse/openSUSE_Tumbleweed Active zypp sources in file: /etc/zypp/repos.d/google-chrome.repo google-chrome ~ http: //dl.google.com/linux/chrome/rpm/stable/x86_64 Active zypp sources in file: /etc/zypp/repos.d/google-earth.repo google-earth ~ http: //dl.google.com/linux/earth/rpm/stable/x86_64 Active zypp sources in file: /etc/zypp/repos.d/openSUSE_Current_non-oss.repo openSUSE_Current_non-oss ~ http://download.opensuse.org/distribution/openSUSE-current/repo/non-oss/ Active zypp sources in file: /etc/zypp/repos.d/openSUSE_Current_oss.repo openSUSE_Current_oss ~ http: //download.opensuse.org/distribution/openSUSE-current/repo/oss/ Active zypp sources in file: /etc/zypp/repos.d/openSUSE_Current_updates.repo openSUSE_Current_updates ~ http: //download.opensuse.org/update/openSUSE-current Active zypp sources in file: /etc/zypp/repos.d/openSUSE_Tumbleweed.repo openSUSE_Tumbleweed ~ http: //download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Active zypp sources in file: /etc/zypp/repos.d/openSUSE_non-oss_Current_updates.repo openSUSE_non-oss_Current_updates ~ http://download.opensuse.org/update/openSUSE-non-oss-current/ Active zypp sources in file: /etc/zypp/repos.d/opensuse-guide.org-repo.repo opensuse-guide.org-repo ~ http: //opensuse-guide.org/repo/12.3/ Info: Processes: 186 Uptime: 4:24 Memory: 974.9/16027.7MB Client: Shell (bash) inxi: 1.9.8-3-b1 Please note that if opensuse can support say, yum AND zypp, I'd have to modify that a little bit to show the files for both, complicated though. Back to top |
|||||
|
Just a note: inxi 1.9.17 fixes a glitch where gnome version fails to show.
This is because gnome, of course, changed their syntax, for no real reason, so now we have to also test for: gnome-session (previous default was: gnome-about) to get the version number from that. Also, the gtk version is failing to show in some instances, I assume another change happened, the command: :: Code :: pkg-config --modversion gtk+-3.0was supposed to return gtk 3 version info, but it says no such package found, which suggests gtk/gnome changed something there too, of course, what would gnome be if it actually kept basic stuff working without pointless changes? If you run gnome 3 and that command fails to return a gtk version, please figure out what command will show the gtk version, why this stuff has to change like this is just bizarre. [update] I'm told the online info was wrong, this method is for when you have dev files installed, so that's a bad test to use anyway. Back to top |
|||||
|
Version 1.9.18: new -xx feature: show default system runlevel. This should support, unless there's a bug, systemd (showing for example: graphical.target), upstart/sysv (showing the default init number, like 2, or 5). If systemd systems show either N/A or a number, it means default.target was not set. If it shows a number, it means it's using /etc/inittab to get its default from.
Also fixed, sort of, gtk version detection for desktops, this may now work for gnome on a basic user system that runs pacman or apt. I didn't get the data for rpm systems and didn't feel like waiting for it so that will come later. Ie: the command with rpm to show package version. This is inxi's first venture into systemd/upstart areas, and paves the way for another new feature, init type. I still haven't decided what to call that, since systemd is not an init system, but sysv is. It gets confusing, I still haven't decided what word to use to describe the various types, ie, systemd/upstart/sysv/openrc, etc. wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems gentoo has a nice chart of the basic systems, they call them all init, and I think I will use that term too, ie: :: Code :: init: systemdUnless someone suggests something better.. I still have not figured out how to positively identify each type, I believe i have systemd/upstart figured out, but the others I don't know how to show without error that they actually started the system. Back to top |
|||||
|
Just an FYI.
inxi -xx didn't show it, inxi -Ixx did (That's a capital "eye", not an L) GoinEasy9@openSUSE311kde64fx:~> inxi -xx CPU~Octa core AMD FX-8150 Eight-Core (-MCP-) clocked at 4153.245 Mhz Kernel~3.11.6-4-desktop x86_64 Up~1:45 Mem~1144.1/16025.5MB HDD~1620.3GB(5.2% used) Procs~223 Client~Shell inxi~1.9.18 GoinEasy9@openSUSE311kde64fx:~> inxi -Ixx Info: Processes: 222 Uptime: 1:42 Memory: 1138.7/16025.5MB Runlevel: 5 default: runlevel5.target Gcc sys: 4.8.1 Client: Shell (bash 4.2.45 running in konsole) inxi: 1.9.18 Back to top |
|||||
|
the -x options only enhance other line options, alone they do nothing, so inxi interprets that as inxi, with no options.
It's interesting to see how the various distros are handling runlevels and defaults, siduction for example basically forgot to set the default value so it goes to 5, from /etc/inittab. Arch, which I believe is one of the most 'pure' systemd releases currently, has no runlevel command at all, which is correct, though annoying because that leaves literally no way to get the current runlevel that I have discovered yet, and their wiki, also fedora wiki, show a patently wrong statement about equivalent method to get runlevels on systemd: :: Code :: systemctl list-units --type=targetwhich is NOT equivalent to: runlevel, all it does is show the units or type target, about 10 of them, that are loaded, and their status. I'm surprised that this bug has repeated on all the documentation, you'd think someone had noticed by now that list-units does not give you a runlevel, just all the levels that are loaded. Back to top |
|||||
|
Thanks for the clarification, it took me a few minutes to figure it out.
BTW - In case you didn't know, inxi is in the openSUSE Packman repo. Unfortunately, it comes in with version 1.7.23. Fortunately, they didn't disable the -U option, so, it's easy to upgrade. As far as runlevels and defaults, I think their definitions have changed, and, I'm still not understanding the new definitions clearly. I use "systemctl stop kdm" before a dist-upgrade in siduction, and, that seems to do what I need it to do in place of init 3, and, it doesn't shut off the networking like "systemctl isolate multi-user.target" does. Thanks for trying to keep up with systemd in inxi, I wish I had the time to figure it out further. Back to top |
|||||
|
I'm going to have to look at the the smxi/sgfxi x kill functions, for systemd I'm using systemctl isolate multi-user.target which worked fine on my siduction vm test system, ie, networking did not shut down, I would say networking shutting down is a bug and should be fixed, that's the same as gui wifi networking tools dumping the connection on x exit, which was a permissions problem on the wifi tools, not a feature of going out of x.
lan wired networking does not change on multi-user.target. However, I believe I can also use the systemctl stop kdm.service or whatever the full command is since smxi/sgfxi generally 'know' what the dm is via tests. Back to top |
|||||
|
It's really confusing. I guess systemctl isolate multi-user.target works for some, and doesn't work for others. In the siduction forums there are many complaints, the most recent was in this thread:
forum.siduction.org/index.php?topic=4189.0 Then again, some got around it by using: apt-get update apt-get dist-upgrade -d systemctl isolate multi-user.target apt-get dist-upgrade At some point I'm going to have to figure out what Lennart thinks init 3 does in systemd. Or, try to figure out why multi-user.target works for some, and not others. Back to top |
|||||
|
The issue is related to wifi, it's not a bug I believe, this is an old problem with various network managers and their user permissions, I'm not familiar with the siduction setup.
As you can see from the thread, the initial issue is wifi, as I predicted. When you change to a core new technology there are going to be a lot of learning curve issues, that's certain. I would investigate on arch linux forums, or fedora, those both will have more experience with full systemd setups and issues that may require different handling. I have seen this issue of wifi disconnecting on init 3, ie, multi-user.target, so many times that I actually stopped doing in person support for Mint and Mepis, both suffered from this network manager permissions problem. That issue was a bug in the configuration shipped by the distros, not in anything related to me or anything else. the trick is to track down WHY the wifi connection is shutting down, not to find workarounds, in my opinion. To repeat, my siduction vm setup is of course wired, totally standard, right off the install iso, no changes, and lan networking works fine. As I would expect. Track down what creates the wifi connection, track down its permission structure, when it is enabled / disabled, etc. I am a beginner at systemd but reading the siduction thread I saw a lot of legacy advice for networking that indicate that the knowledge base is the main bug, not the tools, ie, people are applying pre systemd thinking to systemd networking issues, it's going to take a while to get around that on debian/ubuntu systems because debian has not yet decided or determined what default init systems they will be using, read that meeting log of the recent irc debian discussion of systemd/upstart/openrc: meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-01-16-17.58.log.html phoronix.com/forums/showthread.php?94248-Debian-May-Be-Leaning-Towards-Systemd-Over-Upstart normally I find phoronix reasonably useless in their forums, but this one a few people actually had interesting points I thought. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||