| === chris14_ is now known as chris14 | ||
| DriveFailureProb | Hello - I have put together a NAS that I was planning on running ZFS on. When I initially got the drives, I ran a long test and everything came back fine. Today after getting the rest of the hardware and bring it overseas, I am seeing a drive fail out and I can't tell if it is the HBA / SATA card, or the drive itself. Attached is a log file of | 13:15 |
|---|---|---|
| DriveFailureProb | ata12 and /dev/sdf: https://pastebin.ubuntu.com/p/yFJpTMHSqh/ | 13:15 |
| DriveFailureProb | I was trying to make this a low-power consumption server, so it could be that powertop or a BIOS configuration caused this, but, I just wanted to be absolutely sure that it wasn't the drive itself failing before I dig in any further. | 13:21 |
| DriveFailureProb | I don't know of a way to re-enable the drive remotely, | 13:27 |
| DriveFailureProb | Whoops, but I also see another drive that shows "SmartSelfTestStatus: Interrupted" | 13:27 |
| DriveFailureProb | Posted in here instead: https://ubuntuforums.org/showthread.php?t=2493444&page=2&p=14176659#post14176659 | 14:00 |
| DriveFailureProb | As I likely need to hop off soon. | 14:00 |
| patdk-lap | I dunno about the rest, you didn't post any smart data from the drive | 14:05 |
| patdk-lap | but smartd is saying your drive is 65c | 14:05 |
| patdk-lap | it really shouldn't be over 50c, I like to keep mine around 40c | 14:05 |
| patdk-lap | heh, it's *technically allowed* | 14:07 |
| patdk-lap | 0°C to 65°C | 14:07 |
| SuperLag | Any of you folks use Cockpit on your Ubuntu servers? | 15:32 |
| patdk-lap | never, no | 15:42 |
| rbasak | @pilot out | 15:46 |
| rbasak | Ahem | 15:46 |
| sergiodj | for those who are already on Matrix, we have a Server room now: "#server:ubuntu.com" (https://matrix.to/#/#server:ubuntu.com) | 15:47 |
| lotuspsychje | sergiodj: will there be a bridge to here too? | 15:49 |
| sergiodj | I'm not sure | 15:49 |
| sergiodj | the folks responsible for setting up the Ubuntu matrix server probably know | 15:50 |
| lotuspsychje | #ubuntu and #ubuntu-next are already bridged for testing, maybe after a succes time, more will be bridged | 15:51 |
| patdk-lap | my 10s reading of matrix.to doesn't make any sense | 15:51 |
| patdk-lap | it says it's to free you from using a specific app, irc has never had an *app* | 15:51 |
| lotuspsychje | element is nice patdk-lap | 15:53 |
| patdk-lap | dunno what that even means | 15:53 |
| lotuspsychje | Element is both a secure messenger and a productivity team collaboration | 15:54 |
| lotuspsychje | app that is ideal for group chats while remote working. This chat app uses | 15:54 |
| lotuspsychje | end-to-end encryption to provide powerful video conferencing, file sharing | 15:54 |
| lotuspsychje | and voice calls. | 15:54 |
| patdk-lap | ya, I dont need another app | 15:55 |
| nibbon_ | o/ | 16:38 |
| nibbon_ | quick question: run-qemu.mount is supposed to work out of the box in stock Jammy? /cc cpaelzer | 16:38 |
| cpaelzer | nibbon_: yes, if you upgrade you should have the modules of the old qemu on that mount point to allow still running old guests to load them | 16:52 |
| nibbon_ | cpaelzer: so, the expected behavior is to have that systemd unit enabled and running and not to restart after an upgrade, amirite? | 16:53 |
| nibbon_ | because with kernel 5.15.0 the unit is disabled on boot and never gets enabled after upgrades | 16:54 |
| cpaelzer | yeah, I'd have expected it to be on and running and that is how I see it here on jammy with kernel 6.5 | 16:55 |
| cpaelzer | it will be empty, that is ok | 16:55 |
| cpaelzer | until you upgrade | 16:55 |
| nibbon_ | I recently installed linux-image-6.2.0-39-generic and now I get the unit enabled and up, and every time I upgrade qemu-block-extra it restart the unit wiping out whatever it's in /run/qemu | 16:55 |
| nibbon_ | I don't get why with 5.15 that unit remains disabled | 16:57 |
| nibbon_ | also, I don't get why this https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/rules?h=ubuntu/jammy-updates#n432 isn't respected | 16:58 |
| nibbon_ | iiuc on upgrade it shouldn't restart the unit, should it? | 16:58 |
| cpaelzer | nibbon_: yes, I'd ignore 5.15 kernel for now | 16:59 |
| nibbon_ | okay, I was asking out of curiosity :) | 17:00 |
| cpaelzer | nibbon_: but the fasct that the debhelper magic seems to ignore all the --no and restarts it is bad | 17:00 |
| nibbon_ | yeah, tell me about that. I've lost data :/ | 17:00 |
| cpaelzer | the only impact should be that you can't hot add devices of not-loaded drivers to guests that started in the past | 17:00 |
| nibbon_ | not a biggie, because a stop/start of the domain will restore. Still annoying | 17:01 |
| nibbon_ | hmm, never had this issue. I assume it goes beyond my use case(s) | 17:02 |
| cpaelzer | it surely worked when we added it, and it later got changed a lot (how it is handled in d7rules) | 17:03 |
| cpaelzer | having a look what is affected ... | 17:03 |
| nibbon_ | thanks | 17:03 |
| nibbon_ | I'm okay with having that new mount point. However, it must be persistent for the whole lifecycle of the machine | 17:04 |
| cpaelzer | yep, it should be started at the beginning - populated with content on upgrades (the modules of the qemu version that is going away) and cleaned by a reboot | 17:05 |
| nibbon_ | hmm, so should I expect some process running rm in that directory? | 17:06 |
| cpaelzer | no, not rm | 17:06 |
| nibbon_ | okay, as long as it's addition it's fine | 17:06 |
| cpaelzer | the removal maintainer script of qemu will back up its modules there, to be available for guests of that version that might still run and can only load those old bits | 17:07 |
| nibbon_ | what's the removal maintainer script of qemu? | 17:10 |
| cpaelzer | the prerm / postrm scripts of qemu-block-extra in this case | 17:12 |
| cpaelzer | you'll see in there how it does the backup on upgrade, the removal on remove and only stops the mount unit on purge | 17:13 |
| nibbon_ | I don't see any prerm / postrm script in jammy-updates: https://git.launchpad.net/ubuntu/+source/qemu/tree/debian?h=ubuntu/jammy-updates | 17:16 |
| nibbon_ | I only see this https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/qemu-block-extra.postinst?h=ubuntu/jammy-updates | 17:17 |
| cpaelzer | yeah, because of magic - the lines like https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/rules?h=ubuntu/jammy-updates#n185 will make it exist in the final package | 17:17 |
| cpaelzer | I have the feeling that when switching to the mount unit this was ok, but then undetected the logic changed and since then this restarts the unit and thereby is wasted effort | 17:18 |
| nibbon_ | aha, that makes sense | 17:19 |
| cpaelzer | so far my check, working in focal, broken in jammy, working in mantic | 17:19 |
| cpaelzer | so it is not doomed everywhere | 17:19 |
| cpaelzer | likely some unexpected dh_systemd behavior restarting the unit there | 17:19 |
| nibbon_ | <sigh> | 17:19 |
| cpaelzer | nibbon_: have you already filed a bug I can add info to? | 17:20 |
| nibbon_ | not yet, I wanted to understand the behavior before filing a bug | 17:20 |
| cpaelzer | I'll file one right now and pass you a url in a bit | 17:20 |
| nibbon_ | sounds good, thanks | 17:21 |
| nibbon_ | willing to help to solve the issue | 17:21 |
| cpaelzer | nibbon_: bug 2051153 | 17:31 |
| -ubottu:#ubuntu-server- Bug 2051153 in qemu (Ubuntu Jammy) "run-qemu.mount is restarted on upgrades" [Undecided, Confirmed] https://launchpad.net/bugs/2051153 | 17:31 | |
| cpaelzer | IÄm off for the day then, maybe sergiodj can be a rubber duck on this confirming if he can see the same | 17:31 |
| cpaelzer | the actual debug and fix will take some time | 17:31 |
| cpaelzer | mostyl to find why it does not behave as it should | 17:31 |
| cpaelzer | I had very similar issues in other packages, but never realized this might affect this as well | 17:31 |
| nibbon_ | debhelper sounds like opening a can of worms :/ | 17:32 |
| cpaelzer | it helps, therefore its name | 17:32 |
| cpaelzer | but I've seen it often to behave unexpectedly on .socket and now it seems on .mount units | 17:32 |
| nibbon_ | can you give me some pointers where I could look at to figure this out? | 17:33 |
| nibbon_ | thanks for filing the bug | 17:33 |
| cpaelzer | nibbon_: I've left more info on the bug now, drilling down to where it goes wrong | 17:44 |
| cpaelzer | nibbon_: and linked an old case where this affected .socket units | 17:44 |
| cpaelzer | that provides plenty of study material | 17:44 |
| nibbon_ | cpaelzer: perfect, I'll go read. | 17:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!