 |
Sidebar 
|
 行の最初の"$"は入力する必要はありません。
いらないものをつけるなよ！！ debain 起動が遅い a start job is running for dev-desk-by
毎回起動のたびにでるんです。60秒待ちとか 原因 ディスクの UUIDが変わったことが原因らしい。
/etc/fstab と sudo blkid で値の違いを確認します swapのUUIDが変わっている可能性があるそうです。 私の場合は、swapのUUID情報が破損していました blkidでswapのUUIDが表示されずPARTUUIDだけでした。 swapのPARTUUIDをいれて再起動しても状況は変わりませんでした swapを再作成することにしました。 まずswapを切断します swapoff -a
パーティションエディター gpartedを開き、 swapの領域を再作成します(ファイルタイプを選択するだけ再フォーマットになります) blkidで確認すると PARTUUIDだけになったものが、UUIDも表示されるようになりました。 どうもSWAPのUUID情報が壊れていたようです UUIDを確認して、fstabに書き込みます 再起動します 直りました apt-get update
apt-get upgrade したら壊れた。 原因 debianのopensslのパッケージのミス。
解決手段
考察 : 公開サーバー このような不具合を起こすOSで公開サーバーにするとコンテンツが長期間落ちるので、今後debian,ubuntuの選択はないと思いました。
公開サーバーのOSは、Cent OS, FreeBSDのほうがましなのかもと思いました。 考察 : desktop 前からアプリはバージョンが古くて更新もなかなかないことは知っていましたが、エラーでデバッグもできないし、困りますね。
Cent OSは、デスクトップに向いていないし、FreeBSDは、デスクトップにするともさっとするので、開発環境としては、debian系にしておきたいです。debian ver8（7から）にネットワーク障害があるので、起動後一度アダプタを全切断して再接続しないとネットにつながらないのです。 debian8の再インストールする労力を考えると、めったに起動しないのでアダプタ切断したほうが楽なので放置状態です。 再インストールするとデータの移動が面倒なので、アップグレードしかないのです。 再インストールなんかは、ディスクの破損がない限りしないですよ。 一応仮想環境にfreebsdもあり困らないので、debianは半年くらいそのまま放置してから debian9にアップグレード後、どうするか考えます。 エラー $ openssl version OpenSSL 1.0.2 22 Jan 2015
$ pkg-config --print-provides openssl libssl openssl = 1.0.2
libssl = 1.0.2 $ php -i | egrep -i "^\\s*openssl" php: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by php)
php: /usr/local/lib/libssl.so.1.0.0: no version information available (required by php) php: /usr/local/lib/libssl.so.1.0.0: no version information available (required by php) openssl OpenSSL support => enabled OpenSSL Library Version => OpenSSL 1.0.2 22 Jan 2015 OpenSSL Header Version => OpenSSL 1.0.1t 3 May 2016 Openssl default config => /usr/local/openssl/openssl.cnf openssl.cafile => no value => no value openssl.capath => no value => no value OpenSSL support => enabled $ php -v php: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by php)
php: /usr/local/lib/libssl.so.1.0.0: no version information available (required by php) php: /usr/local/lib/libssl.so.1.0.0: no version information available (required by php) PHP 5.6.30-0+deb8u1 (cli) (built: Feb 8 2017 08:50:21) 配布パッケージの破損なので、自然に直るのを待つしかなさそう。 自分でビルドして別フォルダにインストールしているものはエラーがでない $ php56 -v PHP 5.6.30 (cli) (built: Feb 16 2017 21:29:36)
Delphi 2.0 ロゴ画面で止まる Windows10
症状 2016年4月は、Windows10で起動していました。
2017年2月に起動するとロゴから起動しなくなっていました。
原因： おそらくWindows10のメジャーアップデートもしくはセキュリティソフトが原因です
一時的な対処方法 Workaround (1) bin\CMPLIB32.DCL 名称変更. CMPLIB32-.DCLなどなんでもいい。 (2) Delphi 2.0 を起動します 次のエラーが表示されるのでOKをクリックします
Cannot open component library C:\Program Files\Borland\Delphi 2.0\BIN\CMPLIB32.DCL (error code 126).
(3) (1)のファイルを元の名前に戻します(4) コンポーネント - ライブラリを開く をクリックします (5) bin\CMPLIB32.DCL を選択します (6) コンポーネントがロードされ、一応動作可能になります ※ (1)と(3)はレジストリ変更でも同様のことができます。 ※ 次回起動するとロゴで停止するので、毎回処理が必要です。 一時的な対処方法 Workaround その２
(1) タスクマネージャーで フリーズしたDelphi2 を強制終了する (2) コンポーネント読み込めないように 名称変更する C:\Program Files\Borland\Delphi 2.0\BIN\ CMPLIB32.DCL を bin\CMPLIB32-.DCL に変更する (3) Delphi2を起動する 起動しない場合は、ほかの原因 (4) コンポーネントを読み込む コンポーネント - ライブラリを開く (2) のファイルを選択する (5) ライブラリの編集：問題のコンポーネントを削除する (5-1) コンポーネント - インストールをクリック インストールされた ユニット 「QuickRep」を選択し削除する (5-2) 次に ライブラリ名を CMPLIB32.DCL にして (5-3) OKをクリックする (6) IDEを再起動してみる 問題なければ起動ができるはず Windows10で動かすための,そのほかの確認事項は以下の通りです (1) 現在ログイン中のユーザーにフルアクセス権限に設定するには、 icacls "C:\Program Files\Borland\Delphi 2.0" /grant %USERNAME%:F /t /c /l /q (2) C:\Program Filesは、Windows VirtualStoreが管理しているのでそちらも念のため確認が必要です。 をWindows VirtualStoreを無効にするも参考にしてください (3) HKEY_CURRENT_USER\Software\Borland\Delphi\2.0\Library ComponentLibrary
SearchPath
キーワード Delphi 2.0 ロゴ画面で止まる Windows10 Stop on the Delphi 2.0 logo screen %Y年%m月%d日
文字化け 2017年02朁Ed日
strftime('%Y年%m月%d日') ランダムに発生する 2度目の表示でなおる 原因 setlocaleの２番目の間違い 0ではなく"0" if (!extension_loaded('mbstring'))
return strftime($format, $timestamp); $locale = setlocale(LC_CTYPE, "0"); if ($locale == 'C') $locale = setlocale(LC_CTYPE, ""); if (($locale != 'Japanese_Japan.932')) return strftime($format, $timestamp); return mb_convert_encoding(strftime(mb_convert_encoding($format, 'CP932', 'UTF-8'), $timestamp), 'UTF-8', 'CP932'); gitの2038年問題
32bit環境下でgitには、2038年問題が存在するようです TortoiseGit 日時: 2038/01/19 12:14:07
シェルの場合 Date: Thu Jan 1 00:00:00 1970 +0000
になってしまうようです。 gitは 内部で、unix timeで保存されているのでしょうか？ なんと 2038/01/19 12:14:07 を超える日付は扱えないようです 16ビットＯＳが消えたように あと15-20年後には３２ビットOSは消滅していると思いますので心配しないで大丈夫です！！ |
 |
Sidebar |
無料など
