=== chris14_ is now known as chris14 | ||
MTecknology | dbungert: Were you able to also replicate the disk overwrite prompt when autoinstall is provided? | 02:47 |
---|---|---|
dbungert | MTecknology: security or all> yea, those are the options, sorry. overwrite prompt> I do a lot of autoinstall testing and I haven't seen that prompt in a long time except when I expect to. This one is not at all clear to me. All I can think of is to confirm on the system being installed that it's actually there? Quoting issues somehow? | 02:52 |
MTecknology | I'm still typing out that line by hand on each installation attempt. I could be mistyping autoinstall, but I'd have to be doing it quite consistently | 02:53 |
MTecknology | everything else seems to work as-if it's an autoinstall ... | 02:53 |
MTecknology | dbungert: How much of your daily usage requires the user providing at least one piece of information but otherwise using autoinstall? | 02:55 |
dbungert | much less common. I'm usually testing something related to interactive behavior if I'm doing that. Usually I automate everything so I can tab to the next window until test results are ready. | 02:59 |
MTecknology | I /want/ to automate everything except the hostname ... | 02:59 |
MTecknology | this installer doesn't seem to support that :( | 02:59 |
dbungert | it's a solid feature request | 02:59 |
MTecknology | I still don't understand what actual issue this was meant to resolve in the first place. For all these added bugs/issues, what actual benefit is there? | 03:01 |
MTecknology | dbungert: To be clear ... that's not even "a prompt for just the hostname" ... that would be lovely, but adding that specific extra step to documentation is easy enough -> "You must provide matching passwords, but this value is unused; provide 'a' for each field." The problem is that the other bugs keep the rest from working the way it's supposed to. | 03:06 |
MTecknology | I'm also still having weird issues when I remove systemd-timesyncd as well. It gets flagged as removing a critical system package, even though that's definitely not critical and that's the *only* removal happening in that apt command. | 03:08 |
=== PeGaSuS_ is now known as PeGaSuS | ||
znf | I keep wondering why did Ubuntu 22.04 change locale time to 12 hours time instead of 24 hours like it used to be in 20.04 and below | 15:58 |
rbasak | znf: it depends on your locale setting. I'm not aware that there's a general change here. Are you sure you don't have a different locale setting to before? | 16:06 |
znf | Very aware | 16:06 |
znf | All my servers since at least 12.04 had en_US.UTF-8 set everywhere | 16:07 |
znf | And suddenly the 22.04 locale changed it to 12 hour time | 16:07 |
znf | There's a more thorough explanation/demo here: https://askubuntu.com/a/1500471 | 16:07 |
rbasak | The US uses 12 hour time though? | 16:14 |
rbasak | If you don't want that, change your time locale to something else? | 16:14 |
rbasak | Here's the change: | 16:19 |
rbasak | https://git.launchpad.net/ubuntu/+source/glibc/tree/localedata/locales/en_US#n123 | 16:19 |
rbasak | "At the end of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H." | 16:19 |
-ubottu:#ubuntu-server- Bug 24046 in evolution (Ubuntu) "After upgrade, evolution frecuently crashes when sending email" [Medium, Fix Released] https://launchpad.net/bugs/24046 | 16:19 | |
rbasak | (2018 upstream - it'd take some time to filter through to an Ubuntu release) | 16:20 |
rbasak | Here's the upstream bug that resulted in the change: https://sourceware.org/bugzilla/show_bug.cgi?id=24046 | 16:21 |
-ubottu:#ubuntu-server- sourceware.org bug 24046 in glibc "en_US locale doesn't define date_fmt" [Normal, Resolved: Fixed] | 16:21 | |
znf | yeah, I do understand that it got changed because the US is 12 usually | 16:23 |
znf | Just slightly annoying to fix a bug after 20+ years | 16:23 |
sebokie | hello, on Ubuntu server 22.04.4 LTS the settings in /etc/hdparm.conf are not applied upon boot, what do I have to do to have them applied? | 16:57 |
MTecknology | WTH? Which setting keeps causing my display to blank every few minutes?! | 21:03 |
MTecknology | It feels like the terminal blanking timeout is getting into X, although I have absolutely no clue which setting it actually is. All the screensaver and other settings I can find are set to at least half an hour. | 21:08 |
rfm | MTecknology, the settings that seem to get me are the X dpms (Power Management) I seem to have to enable dpms but set all the timers to 0. | 22:22 |
MTecknology | rfm: Thanks!! It was enabled, so I'm super hopeful that this is it. :D | 22:33 |
=== alucardromero6 is now known as alucardromero | ||
MTecknology | Interesting; after running "xset s off -dpms" and sitting for a while, I lost the ability to provide keyboard input and it was like the up arrow was stuck down, except none of the typical fixes worked and I had to hold the power button 30 seconds | 23:08 |
MTecknology | also ... when did the default change to 30 seconds?? | 23:08 |
MTecknology | s/default/delay/ | 23:08 |
trippeh | I've had it go to 30 seconds or so a few times, ignoring the gnome control panel setting, reboot "fixed" it | 23:10 |
* MTecknology is using cinnamon | 23:13 | |
MTecknology | Which setting is that? (where is it found?) | 23:14 |
trippeh | power -> screen blank | 23:14 |
MTecknology | Ah, that might be Power > Turn off the screen when inactive for: | 23:15 |
MTecknology | I have both power and battery set to never | 23:15 |
=== miceiken4 is now known as miceiken | ||
trippeh | there is def a bug somewhere | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!