User Tools

Site Tools


blog:2023:0930_fedora_release_upgrade_without_an_rtc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
blog:2023:0930_fedora_release_upgrade_without_an_rtc [2023/09/30 18:47] davekblog:2023:0930_fedora_release_upgrade_without_an_rtc [2024/05/18 01:09] (current) davek
Line 7: Line 7:
 Since I have a pijuice hat, I spent a bunch of time trying to get the RTC to handle the issue in the upgrade. Eventually I decided it would be simpler to find the source of September 17th and change that. Since I have a pijuice hat, I spent a bunch of time trying to get the RTC to handle the issue in the upgrade. Eventually I decided it would be simpler to find the source of September 17th and change that.
  
-It turns out systemd in the absence of a source of time such as an RTC set the system time to systemd's build time. Ok, I don't want to rebuild systemd. So what else can be done?+It turns out systemd in the absence of a source of time such as an RTC at initialization sets the system time to systemd's build time. Ok, I don't want to rebuild systemd. So what else can be done?
  
-It turns out systemd will also use a kernel command line parameter to seed the system time: systemd.clock_usec. That allowed me to set the RPi time to something after the certificate valid dates and enable the system upgrade to proceed.+systemd will also use a kernel command-line parameter to seed the system time: systemd.clock_usec. That allowed me to set the RPi time to something after the certificate-valid dates and enable the system upgrade to proceed.
  
-Since after a full boot my RPi would have its time set correctly by ntp, I examined the initial time by looking at:+Since after a full boot my RPi would have its time set correctly by ntp, I determined the initial time by looking at:
 <code>journalctl -b -0</code> <code>journalctl -b -0</code>
  
 As a quick refresher, here's what to do with systemd.clock_usec in Fedora: As a quick refresher, here's what to do with systemd.clock_usec in Fedora:
-  * pick the time you want; date +%s will give you epoch time right "now" which is a good place to start; make it into usec by adding 6 0's to the end +  * pick the time you want; <code>date +%s</code> will give you epoch time in seconds right "now" which is a good place to start; make it into usec by adding 6 0's to the end 
-  * edit /etc/default/grub; find the line GRUB_CMDLINE_LINUX and add another argument to the end inside the quotes; after make the edit, my line looked like this:  +  * edit /etc/default/grub; find the line GRUB_CMDLINE_LINUX and add another argument to the end inside the quotes; after making the edit, my line looked like this: <code>GRUB_CMDLINE_LINUX="rhgb quiet console=tty0 systemd.clock_usec=1696097631000000"</code> 
-<code>GRUB_CMDLINE_LINUX="rhgb quiet console=tty0 systemd.clock_usec=1696097631000000"</code> +  * regenerate grub config like this: <code>sudo grub2-mkconfig -o /boot/grub2/grub.cfg</code>
-  * regenerate grub config like this: sudo grub2-mkconfig -o /boot/grub2/grub.cfg+
   * prepare for the disti upgrade and do the system-upgrade reboot   * prepare for the disti upgrade and do the system-upgrade reboot
-  * after you are done with your upgrade, remove the systemd.clock_usec to put your system back to normal 
  
 +After you are done with your upgrade, remove the systemd.clock_usec to put your system back to normal.
  
  
 {{tag>}} {{tag>}}
  
- +~~LINKBACK~~ 
-~~DISCUSSION~~+//~~DISCUSSION~~
  
blog/2023/0930_fedora_release_upgrade_without_an_rtc.1696099632.txt.gz · Last modified: 2023/09/30 18:47 by davek