Re: [CentOS] Help with multi-monitor Xorg stuff
Cracked this. The solution was that I needed to specify the correct
driver ("radeon") in the xorg conf file to use the open source driver,
e.g.
Section "Device"
Identifier "aticonfig-Device[0]-0"
Driver "radeon"
BusID "PCI:1:0:0"
EndSection
All the other bits from the conf file I could keep the same as before.
On Wed, Sep 19, 2018 at 10:41 AM Richard G wrote:
>
> I have an unusual use case. I wonder if anyone can help. We use a PC
> with 8 HDMI outputs for powering a video wall in an operations centre.
> We use two Matrox video cards, each with 4 outputs. "lspci" reports
> these cards as" [AMD/ATI] Cape Verde PRO [FirePro W600]".
>
> On an older version of CentOS 7, I used the proprietary AMD/ATI
> driver. This had a utility (I roorget the name) that generated a
> working xorg.conf file. I could them throw up the
> "matchbox-window-manager" on each monitor in turn using
> "DISPLAY=:0.0", "DISPLAY=:0.1" etc and then throw up a full-screen
> chrome web browser in kiosk mode on each monitor after that. This all
> worked great.
>
> In a recent version of CentOS 7, this all broke. The proprietary
> driver no longer works. The good news is that the open source driver
> seems to work fine with multi-monitor in Gnome for example.
>
> My only issue is that I don't want to use Gnome across multiple
> monitors. I want to use matchbox-window-manager or similar, and
> specify individual X screen (":0.0", ":0.1" etc). How do I generate
> an xorg.conf file with the new open source drivers? Am I doing this
> all wrong?
>
> Thanks!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] Help with multi-monitor Xorg stuff
I have an unusual use case. I wonder if anyone can help. We use a PC
with 8 HDMI outputs for powering a video wall in an operations centre.
We use two Matrox video cards, each with 4 outputs. "lspci" reports
these cards as" [AMD/ATI] Cape Verde PRO [FirePro W600]".
On an older version of CentOS 7, I used the proprietary AMD/ATI
driver. This had a utility (I roorget the name) that generated a
working xorg.conf file. I could them throw up the
"matchbox-window-manager" on each monitor in turn using
"DISPLAY=:0.0", "DISPLAY=:0.1" etc and then throw up a full-screen
chrome web browser in kiosk mode on each monitor after that. This all
worked great.
In a recent version of CentOS 7, this all broke. The proprietary
driver no longer works. The good news is that the open source driver
seems to work fine with multi-monitor in Gnome for example.
My only issue is that I don't want to use Gnome across multiple
monitors. I want to use matchbox-window-manager or similar, and
specify individual X screen (":0.0", ":0.1" etc). How do I generate
an xorg.conf file with the new open source drivers? Am I doing this
all wrong?
Thanks!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Marketing Mail] Re: LVM and Backups
Il 19/09/2018 09:28, Lange, Markus ha scritto: On Wed, 2018-09-19 at 08:55 +0200, Alessandro Baggi wrote: Il 18/09/2018 17:14, Gordon Messmer ha scritto: On 9/17/18 11:38 PM, Alessandro Baggi wrote: Il 17/09/2018 22:12, Gordon Messmer ha scritto: That doesn't look right. It should look more like 1) stop or freeze all of the services (httpd and database), 2) make the snapshot, 3) start or thaw all of the services, 4) mount the snapshot, 5) back up the data, 6) remove the snapshot. About database setup I perform backups via pg_dump so how the snapshot affects pgsql database? What your suggestion I must perform database backup copying only filesystem file and not pgsql.sql database dump? If you want a plain-text dump of the DB, you can do that before the LVM snapshot sequence: 1) pg_dump, 2) stop or freeze all of the services (httpd and database), 3) make the snapshot, 4) start or thaw all of the services, 5) mount the snapshot, 6) back up the data, 7) remove the snapshot. Typically, the reason you want to use snapshots for the backup is that you don't need to do pg_dump to get a consistent DB backup, though. pg_dump style backups are extremely slow to restore. If you freeze the DB, make a snapshot, and thaw, you can make a safe, consistent backup of the DB files directly, and restore in minimal time. Are you using bacula's built-in snapshot support, or are you rolling your own? No I'm using pre/post job script where I have lvm commands to create and destroy snapshot volume. I really recommend using a ready-made process rather than rolling your own. Bacula has snapshot support. Alternately, my project can manage snapshots and handle freezing / thawing PostgreSQL services. I think it's a better option than Bacula's, but either is better than reinventing this wheel. https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Thank you for the suggestion. I don't know why I considered pg_dump better then filesystem backup. At this moment I prefer pg_dump because in this mode I can restore data on different version of postgresql. With filesystem dump I can restore only for a specific version. Is right? I will give a try. Thank you again for suggestions. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Hi, an restore may need additional attention while restoring database files to a different version of postgres. However, while the versions does not differ that much (an official upgrade path exists, or no layout change was made between the versions) the files work just as if you updated the database using yum (check out spec file from source pkg to find out what happens on package upgrades, you may need to do upgrade steps manually). This should only be a problem when you try to restore to a new major version of postgres. But in that case I would recommend an additional pg_dump backup to have a save fallback. best regards ps: I do not use postgres, please understand my testimony as not tested practically. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Thank you for the suggestion. Best regards ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Marketing Mail] Re: LVM and Backups
On Wed, 2018-09-19 at 08:55 +0200, Alessandro Baggi wrote: > Il 18/09/2018 17:14, Gordon Messmer ha scritto: > > On 9/17/18 11:38 PM, Alessandro Baggi wrote: > > > Il 17/09/2018 22:12, Gordon Messmer ha scritto: > > > > That doesn't look right. It should look more like 1) stop or > > > > freeze > > > > all of the services (httpd and database), 2) make the snapshot, > > > > 3) > > > > start or thaw all of the services, 4) mount the snapshot, 5) > > > > back up > > > > the data, 6) remove the snapshot. > > > > > > About database setup I perform backups via pg_dump so how the > > > snapshot > > > affects pgsql database? What your suggestion I must perform > > > database > > > backup copying only filesystem file and not pgsql.sql database > > > dump? > > > > > > If you want a plain-text dump of the DB, you can do that before the > > LVM > > snapshot sequence: 1) pg_dump, 2) stop or freeze all of the > > services > > (httpd and database), 3) make the snapshot, 4) start or thaw all of > > the > > services, 5) mount the snapshot, 6) back up the data, 7) remove > > the > > snapshot. > > > > Typically, the reason you want to use snapshots for the backup is > > that > > you don't need to do pg_dump to get a consistent DB backup, > > though. > > pg_dump style backups are extremely slow to restore. If you freeze > > the > > DB, make a snapshot, and thaw, you can make a safe, consistent > > backup of > > the DB files directly, and restore in minimal time. > > > > > > > > Are you using bacula's built-in snapshot support, or are you > > > > rolling > > > > your own? > > > > > > No I'm using pre/post job script where I have lvm commands to > > > create > > > and destroy snapshot volume. > > > > > > > I really recommend using a ready-made process rather than rolling > > your > > own. Bacula has snapshot support. Alternately, my project can > > manage > > snapshots and handle freezing / thawing PostgreSQL services. I > > think > > it's a better option than Bacula's, but either is better than > > reinventing this wheel. > > > > https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot > > > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > Thank you for the suggestion. > > I don't know why I considered pg_dump better then filesystem backup. > At > this moment I prefer pg_dump because in this mode I can restore data > on > different version of postgresql. With filesystem dump I can restore > only > for a specific version. Is right? > > I will give a try. > > Thank you again for suggestions. > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos Hi, an restore may need additional attention while restoring database files to a different version of postgres. However, while the versions does not differ that much (an official upgrade path exists, or no layout change was made between the versions) the files work just as if you updated the database using yum (check out spec file from source pkg to find out what happens on package upgrades, you may need to do upgrade steps manually). This should only be a problem when you try to restore to a new major version of postgres. But in that case I would recommend an additional pg_dump backup to have a save fallback. best regards ps: I do not use postgres, please understand my testimony as not tested practically. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
