Okay. After several days of digging, I think I have dsu working well enough.
But I still have one or two questions; hopefully someone has looked into this before: Do the exit codes of a "dsu --non-interactive" or similar, happen to indicate whether or not a reboot is needed? Is there some other automated way of determining whether a reboot would be needed? You see, we want to automate this process across about 1000 nodes, but don't want to reboot unnecessarily (eg. when an iDRAC needs updated). But without an automated way to determine whether it's necessary, it's hard to know for certain. I've been testing the exit codes of a "dsu --non-interactive", and here's what I've found so far: no updates -> exit code 1 iDRAC update only -> exit code 0 BIOS update only -> exit code 8 Updates including BIOS, iDRAC, Ethernet -> exit code 8 Now, I'd like to think that this is causal, and I can rely on it for this purpose. But since I can't find any documentation about the exit codes of the dsu application, I'm a little nervous to assume this. On 04/28/2017 08:36 AM, Lloyd Brown wrote: > > I actually had already set a similar "proxy" line in /etc/yum.conf, > and it didn't seem to be effective. I've also put proxy lines in the > specific /etc/yum.repos.d/dell* location, as you suggest, and had > similar issues. > > I have had some luck by setting the "http_proxy" environment variable, > but even then, it still seems to be error-ing out, thus why I was > wondering if anyone else has gotten it to work and it's just me, or if > there's something else going on: > >> [root@m7stage-1-2 ~]# export http_proxy=http://proxy1:8888 >> [root@m7stage-1-2 ~]# dsu --inventory >> Dell System Update 1.4 >> Copyright (C) 2014 Dell Proprietary. >> Verifying catalog installation ... >> Installing catalog from repository ... >> Fetching dsucatalog ... >> Reading the catalog ... >> Fetching invcol_RPTVF_LN64_17.03.200.987_A00 ... >> Could not download inventory collector >> Retrying ... >> Fetching invcol_RPTVF_LN64_17.03.200.987_A00 ... >> Could not download inventory collector >> Exiting DSU! >> [root@m7stage-1-2 ~]# >> > > > I guess it's time to pull out the strace again, and see if I can > figure out what exactly is failing. > > > Lloyd > > > > On 04/27/2017 08:42 PM, 603912411 wrote: >> hi， >> >> dell dsu for linux use YUM to download dups, so you should setting >> proxy for dell yum repo, and dsu will download dups by proxy. >> >> like this: >> ____________________________________________ >> [dell-dsu] >> name=dell dsu >> baseurl=http://linux.dell.com/repo/hardware/dsu/os_independent/ >> proxy=http://proxyhost:proxyport >> gpgcheck=0 >> ____________________________________________ >> >> 2017-04-28 >> ------------------------------------------------------------------------ >> 603912411 >> ------------------------------------------------------------------------ >> >> *发件人：*Lloyd Brown <[email protected]> >> *发送时间：*2017-04-28 04:28 >> *主题：*[Linux-PowerEdge] DSU, proxy >> >> *收件人：*"[email protected]"<[email protected]> >> *抄送：* >> >> Has anyone successfully used dsu to update firmware from Linux, working >> through an http proxy? Given the storage requirements, I'd rather do >> that, than have a local copy of the entire linux.dell.com repository. A >> caching proxy would give me most of the advantage of local storage, >> without requiring me to download EVERYTHING. >> >> Of course, to make things more complicated, this is a RHEL7 system, >> booted using an NFS root, therefore most of the / volume is read-only, >> unless I explicitly list it in /etc/rwtab, /etc/rwtab.d/*, or >> /etc/statetab, etc. I've already added the following to rwtab.d, and >> therefore are bind-mounted on a tmpfs, but there may be something else >> I'm missing: >> >> > # cat /etc/rwtab.d/dell /etc/rwtab.d/yum_cache >> > files /opt/dell >> > files /usr/libexec/dell_dup/ >> > files /var/cache/yum >> >> Thanks, >> >> Lloyd >> >> -- >> Lloyd Brown >> Systems Administrator >> Fulton Supercomputing Lab >> Brigham Young University >> http://marylou.byu.edu >> >> _______________________________________________ >> Linux-PowerEdge mailing list >> [email protected] >> https://lists.us.dell.com/mailman/listinfo/linux-poweredge >> > > -- > Lloyd Brown > Systems Administrator > Fulton Supercomputing Lab > Brigham Young University > http://marylou.byu.edu > > > _______________________________________________ > Linux-PowerEdge mailing list > [email protected] > https://lists.us.dell.com/mailman/listinfo/linux-poweredge -- Lloyd Brown Systems Administrator Fulton Supercomputing Lab Brigham Young University http://marylou.byu.edu
_______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge
