40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  Cryo Lab eLog  Not logged in ELOG logo
Entry  Tue Feb 2 09:52:19 2021, aaron, Computing, DAQ, cymac to Debian buster 
    Reply  Wed Feb 3 08:23:12 2021, Chris, Computing, DAQ, cymac to Debian buster 
       Reply  Tue Feb 9 16:33:31 2021, aaron, Computing, DAQ, cymac to Debian buster 
          Reply  Thu Feb 11 18:51:39 2021, aaron, Computing, DAQ, cymac to Debian buster Screen_Shot_2021-02-11_at_19.27.21.png
             Reply  Mon Feb 15 18:25:19 2021, Chris, Computing, DAQ, cymac to Debian buster 
                Reply  Tue Feb 16 14:29:04 2021, aaron, Computing, DAQ, cymac to Debian buster 55B5D301-4243-45DA-9B03-45EF87B2A684.jpeg4C7FE7DC-E8A0-4770-9A49-14EB491F76E2.jpeg13D67AB6-5A77-4C94-A2A4-FE7FDF065B01.jpegC84B3054-269B-4969-817F-1429BB671C7A.jpeg
                   Reply  Thu Feb 18 16:16:38 2021, aaron, Computing, DAQ, cymac to Debian buster 15A01777-A1C5-4710-8180-28C8B68A07AE.jpegF90CD5EF-1A26-4C4A-9C84-046E49642545.jpeg
                      Reply  Fri Feb 19 14:43:09 2021, aaron, Computing, DAQ, AI chassis diagnosis 
                   Reply  Tue Mar 9 14:03:12 2021, aaron, Computing, DAQ, oma model 
Message ID: 2625     Entry time: Wed Feb 3 08:23:12 2021     In reply to: 2624     Reply to this: 2635
Author: Chris 
Type: Computing 
Category: DAQ 
Subject: cymac to Debian buster 

I’ll add a note here for future readers of the log, because previous logs on the subject of cymac1 OS upgrades may have made it appear a little too easy.

If you are reading this because you're having an issue with cymac1 (or another front-end computer), you may be wondering: Should I try upgrading the OS on cymac1 to fix my problem?

The answer to that question is: A resounding no!

An OS upgrade is almost never going to be the solution to any problem you may have with cymac1. In fact, it is almost guaranteed to create many new problems that you will have to solve before cymac1 becomes usable again.

Upgrading the OS on cymac1 should only be undertaken if you know exactly why it is absolutely necessary, AND when you have a lot of free time on your hands to troubleshoot the problems it will inevitably create, AND after you have verified there's a backup of the existing system that you can restore to if needed.

UPDATE: the system is running and acquiring data again (although a DAC status bit remains red). Things that had to be fixed to recover from this upgrade were the following:

  1. update daqdrc config file, environment variables in env/systemd_env, and provide symbolic links to additional config files in /etc/advligorts
  2. get new standalone_edc service running to pull in data from external epics channels
  3. rtcds build and rtcds install all models (some had been built but not installed)
  4. add advligorts user to controls group
  5. add group write permissions to files under /opt/rtcds and /frames
  6. get new local_dc service running, to combine data from all front ends for ingestion by daqd
  7. disable mx_crc_only service that is no longer needed

Also to note, rtcds start was working to get front end codes started, but rtcds stop apparently fails to remove the front end modules sometimes (follow it with rmmod when that happens).

ELOG V3.1.3-