Fedora 39 - mysqlワークベンチのインストール

Fedora 39にmysql Workbenchをインストールする際にいくつかの問題があります。私はフォローしていますhttps://idroot.us/install-mysql-workbench-fedora-37。 > sudo dnf install https://dev.mysql.com/get/mysql80-community-release-fc39-2.noarch.rpm Last metadata expiration check: 0:11:31 ago on Thu 25 Apr 2024 06:33:11 AM CEST. mysql80-community-release-fc39-2.noarch.rpm 13 kB/s | 10 kB 00:00 Package mysql80-community-release-fc39-2.noarch is already installed. Dependencies resolved. Nothing to do. Complete! > sudo rpm -Uvh mysql80-community-release-* warning: mysql80-community-release-fc39-1.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 3a79bd29: NOKEY Verifying... ################################# [100%] Preparing... ################################# [100%] package mysql80-community-release-fc39-2.noarch (which is newer than mysql80-community-release-fc39-1.noarch) is already installed > sudo dnf install mysql-workbench-community Last metadata expiration check: 0:14:06 ago on Thu 25 Apr 2024 06:33:11 AM CEST. No match for argument: mysql-workbench-community Error: Unable to find a match: mysql-workbench-community なぜパッケージが見つからないのですか？

Admin 2024-07-07

Fedora 40から39にロールバック

私はFedora 40ベータをインストールしましたが（予想通り）いくつかの拡張機能が壊れて、OSを再インストールせずに39にロールバックする方法がないかどうか疑問に思いました。私はsudo dnf install system-upgrade --releasever=39 --allowerasing前に試しましたこれ問題が発生 しても機能しない場合は、次のエラーが発生しますNo match for argument: system-upgrade Error: Unable to find a match: system-upgrade。

Admin 2024-07-07

Fedoraへのパスのインポートのインストール

pip経由でpass-importをインストールしました。 pip install pass-import Defaulting to user installation because normal site-packages is not writeable Requirement already satisfied: pass-import in ./.local/lib/python3.12/site-packages (3.4) Requirement already satisfied: pyaml in /usr/local/lib/python3.12/site-packages (from pass-import) (23.9.7) Requirement already satisfied: zxcvbn in /usr/local/lib/python3.12/site-packages (from pass-import) (4.4.28) Requirement already satisfied: requests in /usr/lib/python3.12/site-packages (from pass-import) (2.28.2) Requirement already satisfied: PyYAML in /usr/lib64/python3.12/site-packages (from pyaml->pass-import) (6.0.1) Requirement already satisfied: charset-normalizer<4,>=2 in /usr/lib/python3.12/site-packages (from requests->pass-import) (3.2.0)Requirement already satisfied: idna<4,>=2.5 in /usr/lib/python3.12/site-packages (from requests->pass-import) (3.4) Requirement already satisfied: urllib3<1.27,>=1.21.1 in /usr/lib/python3.12/site-packages (from requests->pass-import) (1.26.18) しかし、実行しようとすると、次のようになります。 pass import bitwarden bitwarden_export_20240104164527.json Error: import is not in the password store. これが私の道です： /home/hhlp/.local/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/opt/p4v/bin:/opt/p4v/bin しかし、私はそれを動作させるのに十分ではないと思います。 https://github.com/roddhjav/pass-import#readme 1つの解決策は次のとおりです。 fedora COPR repoで有効にしてインストールするだけです。 https://copr.fedorainfracloud.org/coprs/tofik/password-store/packages/ sudo dnf copr enable tofik/password-store それからインストールしてください sudo dnf install pass-import しかし、これを行うには、pipの下の公式バージョンを使用したいと思います。

Admin 2024-07-07

SSH経由で接続されたRHELシリーズシステムで私のシェルが正しく機能しないのはなぜですか?

SSHを介してRHELシリーズホスト（Fedora、CentOS、実際のRHELなど）に接続しても、シェルの動作に関する問題が引き続き発生します。 SSHを介してこのLinuxディストリビューションスイートに接続すると、この問題が発生するようです。これは、選択したときにそのディストリビューションの使用を完全に中止する予定があるほど残念です。 望ましくない動作は、ターミナル行の先頭を認識できないことです。これにより、以前に使用したコマンドを修正することが非常に困難になります。 私は$ TERMがSSHクライアントとホスト上で一致していることを確認するなど、過去にいくつかの診断を確認しました。以下のデモでは、両方とも同じように使用します。 nborgers@Persons-Laptop ~ % echo $TERM xterm-256color nborgers@Persons-Laptop util % ssh gateway -t 'bash -ic "echo $TERM"' xterm-256color Connection to 10.212.100.192 closed. このデモでは、私のクライアントはMacOSですが、WSL（したがってLinux VM）でSSHを実行すると同じ問題が発生します。 検証済みソリューションの適用：Ansibleプレイブックと違って私が間違っている部分は次のとおりです。 nborgers@Persons-Laptop host-config-as-code % git diff --ignore-space-at-eol diff --git a/ssh/terminal_colors.yaml b/ssh/terminal_colors.yaml index 6751809..33bb779 100644 --- a/ssh/terminal_colors.yaml +++ b/ssh/terminal_colors.yaml @@ -12,6 +12,6 @@ lineinfile: path: /etc/bashrc state: present - line: 'export PS1="\e[0;{{ color }}m[\u@\h \W]\$ \e[m "' + line: 'export PS1="\[\033[01;{{ color }}m\]\u@\h \[\033[0m\]\W $ "' when: ansible_os_family == 'RedHat' 明らかに、いくつかのシェーディング構成でこの問題が発生しました。以前にこの問題を実行していないコンピューターでこの問題を見たようですが、もう再現できません。

Admin 2024-07-07

xrandrでモニターヘルツを144に設定すると、モニターは画面の半分をブロックします。

こんな感じです。写真下部はターミナル部分です。私が実行すると、これが起こります。xrandr --output HDMI-1 --mode 1920x1080 -r 144これは私のパターンです。xrandr --output HDMI-1 --mode 1920x1080 -r 144また、i3が/etc/X11/xinit/xinitrcファイルから起動する前に実行しようとしましたが、うまくいかないようです。 この問題をどのように解決できますか？私のシステム。 Fedora i3スピンリリース

Admin 2024-07-07

Thinkpad X1 Carbon Gen 6（2018）（Fedora 38）では、トラックパッドがランダムに動作を停止して消えます。

私はしばらくこの問題を調査してきましたが、提案された解決策のどれも役に立たないようです。 Biosでトレースポイントを無効にし、grubファイルに "psmouse.synaptics_intertouch = 1"を追加しようとしましたが、両方が機能しませんでした。いくつかの状況では、Fedora 38を実行しており、すべてのファームウェアが最新です。私は20KHモデルを持っていますが、他の所有者は通常この問題に遭遇しません。私のdmesg出力は次のとおりです。。これが非常に明確な事実であれば、事前に謝罪します。私はLinuxを初めて使用します。一週間以上この問題に悩んでいるので、助けてくださって本当にありがとうございます。

Admin 2024-07-07

トンネルルーティングが停止する理由を確認するには？

私たちの近所にはIPv6を提供するプロバイダはありません。私はVultrを通して宣言した2001:67c:2284::/48を所有しています。 私はnmcliを使用してオフィスで2001:67c:2284:1::/64を使用するようにSITトンネルを設定しようとしています。しかし、詳しくは見ていませんでした。 サーバーは、Bird2とFirewalldのみを実行するFedora 38の最小インストールです。 BirdがVultrに正しく接続されている。 私のIPv4オフィスのIPアドレスを保護するために、これを###.###.###.###に変更し、サーバーIPをSSS.SSS.SSS.SSSに変更し、/ 64プレフィックスを設定します。空のパスに変更し、一度機能したら変更してください。 私が実行しているサーバーから： nmcli con add type 'ip-tunnel' con-name 'sit1' ifname 'sit1' mode 'sit' remote '###.###.###.###' -- ipv4.method 'disabled' ipv6.method 'manual' ipv6.address '2001:67c:2284:1::1' ip-tunnel.ttl 64 私のラップトップ（またfedora 38）から： nmcli con add type 'ip-tunnel' con-name 'sit1' ifname 'sit1' mode 'sit' remote 'SSS.SSS.SSS.SSS' local '###.###.###.###' -- ipv4.method 'disabled' ipv6.method 'manual' ipv6.address '2001:67c:2284:1::2' ipv6.gateway '2001:67c:2284:1::1' ip-tunnel.ttl 64 ping6 または mtr を使用すると両方のシステムの IP から応答を受け取りますが、リモート ipv6 アドレスで実行しようとすると ping は宛先に接続できないことを示し、mtr にはホストへのパスがないことを示します。 cat /proc/sys/net/ipv6/conf/all/forwardingサーバーで実行すると 1 が返されるため、IPV6 転送が有効になります。 ip -6 r は以下を出力します。 サーバー：2001:67c:2284:1::1 dev sit1 proto kernel metric 675 pref medium ラップトップ：2001:67c:2284:1::1 dev sit1 proto static metric 675 pref medium 2001:67c:2284:1::2 dev sit1 proto kernel metric 675 pref medium default via 2001:67c:2284:1::1 dev sit1 proto static metric 675 pref medium テストのためにNATの問題を防ぐためにルータでDMZを有効にしましたが、問題は解決されませんでした。 どんなアドバイスも本当にありがとうございます。

Admin 2024-07-07

HPノートブックにUbuntu以外のものをインストールするのは難しく、インストール/アップデート後にGRUBは表示されません。

知人はHPノートブックにDebian 12またはFedora 38をインストールしようとしましたが、Debianではインストール後にまったく起動せず、Fedoraでは起動しましたが、アップデートは中止されました。 Ubuntuはよくインストールされました。グラフィックカードの問題であると疑われます。彼らはiGPU Core i7-7500U x 4とIntel HD Graphics 620を使用しています。彼は両方のオペレーティングシステムがインストール/アップデート後にGRUBメニューを表示しないと述べた。彼はまた、過去に他のシステムにDebianを正常にインストールしたと述べた。ここで何が起こっているのでしょうか？

Admin 2024-07-07

ハイブリッド GPU モードは Fedora インストールでは使用できませんが、ライブ ISO では使用できます。アイデアはありますか？

私のラップトップはLenovo Legion 5 Pro 16IAH7Hノートブックです。 2枚のグラフィックカードがあります。 Intel i7-12700Hプロセッサ用iGPU dGPU NVIDIA RTX 3070 何らかの理由で、認知ブレンドモードはFedora Workstation 38ライブではうまく機能しますが、私がインストールした環境では機能しません。まさにFedora Workstation 38はそれです！ ライブISOを使用している場合は、両方のカードが一覧表示されます。これとは対照的に、FedoraのインストールにはIntelカードのみが表示されます。 [gremo@fedora ~]$ switcherooctl list Device: 0 Name: Intel Corporation Alder Lake-P Integrated Graphics Default: yes Environment: DRI_PRIME=pci-0000_00_02_0 しかし、Nvidiaカードが検出され、lspci専用ドライバを正常にインストールしました。ライブISO：これはうまくいかないので、Neuveauドライバを試してみるように頼むことができます。 [gremo@fedora ~]$ lspci -n -n -k | grep -A 2 -e VGA -e 3D 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c) Subsystem: Lenovo Device [17aa:3aed] Kernel driver in use: i915 -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104M [GeForce RTX 3070 Mobile / Max-Q] [10de:24dd] (rev a1) Subsystem: Lenovo Device [17aa:3833] Kernel driver in use: nvidia 何が問題なのか知っていますか？

Admin 2024-07-08

停電後にBTRFSパーティションをマウントできません。

BTRFSパーティションでFedora 38を実行していますが、システムの停止によりハード電源を切る必要がありました。これでシステムは起動時に緊急モードに入ります。現在Fedora Live CDを実行していますが、デフォルトのシステムパーティションはインストールを拒否します。 GUIを介してこれを行うと、次のようになります。 /run/media/liveuser/8ae5f957-a101-4486-991d-36558ce61b24 で /dev/nvme0n1p8 をマウント中にエラーが発生しました。 mount(2) システムコールが失敗しました。ファイルが存在します。 btrfsチェックを実行しましたが、エラーは報告されませんでした。 どんなアイデアがありますか？助けてくれてありがとう。今すぐ再起動し、緊急モードで正確なエラーを取得しようとします。しかし、役に立つ情報を提供していないようです。

Admin 2024-07-07

丸太

さて、ちょっと変です。さまざまなサービスを実行するFedora Linuxサーバーがあります。いくつかの例は次のとおりです。 Nginxリバースプロキシ Wireguard VPN（Dockerコンテナ内で実行） SSH Fedoraコックピットユーザーインターフェース 主にDockerコンテナである他の多くのコンテナがありますが、私はいつもSSHやNginxを介してアクセスするので言及していません。 システムが正常に動作しています。ほとんどの場合--ここで問題が発生します。数日間は問題なく実行できますが、時には「停止」することがあります。 SSH接続が機能せず、Nginx経由でプロキシされたホスト型Webサイトはローカルネットワークまたは外部からアクセスできず、Cockpit（Nginxによってプロキシされていない）でも同様です。手動で強制終了してサーバーを再起動すると（電源ボタンを介して）、再び動作する可能性が高くなります。その後、何が起こっているのかを確認するためにシステムログをチェックすると、システムがある時点で停止し、デバッグ情報も記録せず、何も記録しないことがわかります。 奇妙な部分は次のとおりです。この場合、すべてのサービスが中断されても、Wireguardは正常に動作します！動作が停止しません。他のネットワークからローカルアドレス（ルーター設定ページ@など192.168.1.1）にアクセスすることもできるため、VPNは期待どおりに機能します。また、Wireguardを使用せずにSSHポートを転送して直接接続しようとしましたが、成功しませんでした。 私は80％の場合、すべてがうまく機能することを強調したいと思います。 したがって、ファイアウォール、Nginx の構成などの問題ではない可能性が高くなります。パッケージを更新した後、システムは午前4時ごろのように再起動されます。 今後1ヶ月間家を空にする予定なので、今は手動でサーバーにアクセスできません。 （例：このような場合、自宅でサーバーを再起動してくれる他の人が必要で、何が起こっているのか教えられない。必ず必要です（わかっています、賢い動きではありません）。 みんなありがとう 丸太 システムログ サーバーの最新ログです。午後13時30分にサーバーを再起動しましたが、午前6時1分から午後13時30分までログがありません。 6:01 AM [CROND] - (root) CMDEND (run-parts /etc/cron.hourly) 6:01 AM [run-parts] - (/etc/cron.hourly) finished 0anacron 6:01 AM [run-parts] - (/etc/cron.hourly) starting 0anacron 6:01 AM [CROND] - (root) CMD (run-parts /etc/cron.hourly) 5:59 AM [audit] - SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pmie_farm_check comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 5:59 AM [systemd] - pmie_farm_check.service: Deactivated successfully. 5:59 AM [audit] - SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pmie_farm_check comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 5:59 AM [systemd] - Started pmie_farm_check.service - Check and migrate non-primary pmie farm instances. 接続しようとしたときのSSHの詳細出力 $ ssh 192.168.1.240 -v OpenSSH_9.0p1 Ubuntu-1ubuntu8.5, OpenSSL 3.0.8 7 Feb 2023 debug1: Reading configuration data /home/efiocchi/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to 192.168.1.240 [192.168.1.240] port 22. debug1: Connection established. debug1: identity file /home/efiocchi/.ssh/id_rsa type 0 debug1: identity file /home/efiocchi/.ssh/id_rsa-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_ecdsa type -1 debug1: identity file /home/efiocchi/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/efiocchi/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_ed25519 type -1 debug1: identity file /home/efiocchi/.ssh/id_ed25519-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_ed25519_sk type -1 debug1: identity file /home/efiocchi/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_xmss type -1 debug1: identity file /home/efiocchi/.ssh/id_xmss-cert type -1 debug1: identity file /home/efiocchi/.ssh/id_dsa type -1 debug1: identity file /home/efiocchi/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.0p1 Ubuntu-1ubuntu8.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.0 debug1: compat_banner: match: OpenSSH_9.0 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.1.240:22 as 'efiocchi' debug1: load_hostkeys: fopen /home/efiocchi/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent Connection closed by 192.168.1.240 port 22 その他のログ Wireguard dockerログやNginxログには奇妙なことがないようです。ただし、他のログが必要な場合はお知らせいたします。

Admin 2024-07-08