IRC channel logs
2025-08-12.log
back to list of logs
<gnucode>hello friends, the new metadata journal prototype... <gnucode>does it intend to fix most filesystem corruption issues... <gnucode>my understanding is that it would not fix any file content corruptions. Does that sound accurate? <damo22>gnucode: journaling just helps you recover from not cleanly unmounting your fs <damo22>if you have existing corruption, that is not going to be fixed by adding a journal <nexussfan>hello everyone, I was testing hurd (amd64) on a thinkpad t420 and the netinst requires internet. is there an offline install disk (similar to DVD-1 on normal debian) but for hurd? <gnucode>nexussfan: you should be able to write to the disk directly...via rumpusbdisk...I think. <nexussfan>What i mean is that the netinst doesn't work because it needs internet (obviously) and for some reason the ethernet doesn't work on the thinkpad t420. <gnucode>speaking of that...damo22 with your new rumpnet work, what hardwore would work well with hurd amd64 with working internet? <gnucode>nexussfan: I wish I had an answer for you. I believe the T400 should work, but I don't know for certain. <nexussfan>gnucode: Yeah, but I was able to use the hurd preinstalled image and put it on an SATA device and it booted perfectly fine. Still no ethernet though... <gnucode>you could donate some money to damo22. He's the one working on rumpnet. Adding device drivers for ethernet devices. <gnucode>nexussfan: you could try running the Hurd on xen. <gnucode>That would let you run the Hurd and linux in parallel. <gnucode>You could also take a look at apt offline. <nexussfan>gnucode: I saw the page on the wiki. I'll try it out <gnucode>The Hurd runs just fine on my T43. :) It would be nice to update to a more powerful machine. <nexussfan>gnucode: Yeah, but Ethernet may not work which is a bummer. I also saw a report of the T410 working on hurd, but I don't think t420 is documented as tested. <damo22>ne need to donate any money, it does not speed up my contributions <nexussfan>Ok. I'll continue to use debianaptoffline for now and it works well <damo22>nexussfan: rumpnet might work on the t420 if its an intel gigabit nic <gnucode>damo22: may I ask why you are targeting rumpnet to support intel gigabit nics ? Are they the most common/that's the hardware that you have? <damo22>because that is what rumpnet supports currently <nexussfan>damo22: On debian gnu/linux using lspci I'm told that it uses "Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)" as the Ethernet controller. <damo22>but you might need to compile rumpnet manually <youpi>sneek: later tell nexussfan netinst does not need internet access, you can skip that step. You will still have the base installed already, and you can install the rest from the installed system <gnucode>hey friends, I've noticed that occassionally, my thinkpad's (T43) mouse will occassionally freeze on X. <gnucode>Everything else is fine. i3 continues to work, as do the various applications. <gnucode>Any clues about how I could restart the mouse ? <gnucode>I've tried restarting X, but so far the mouse was still stuck. <ik5pvx>I had an amd64 vm that I installed earlier in the year from the december 2024 netinst. In the last few days one upgrade broke it, "../i386/i386/apic.c:426: hpet_init" and so on <ik5pvx>I trashed it and tried to reinstall from the july 2025 netinst. It gets stuck exactly at the same point. <ik5pvx>is there a way to maybe disable apic and move on? <etno>ik5pvx: just a guess, but maybe using a more modern emulated machine would solve it ? <ik5pvx>I'm using qemu/kvm, I chose the Q35 chipset with BIOS (couldn't get UEFI to cooperate). <gnucode>ik5pvx: can you show us your qemu invocation ? <ik5pvx>I'm doing it via virt-manager, I can dump the xml <gnucode>ik5pvx: I don't know of any hurd developer using virt-manager. They all use qemu or xen. <gnucode>I don't know anyone that regularly tests to make sure that the Hurd runs on virt-manager. :( <gnucode>Try it in qemu. It might work better. <ik5pvx>this is the qemu invocation that comes out of the above xml <ik5pvx>also, the 32 bit one still works <azert>I think that many virtualization packages disable hpet by default <azert>since most common operating systems have other alternative timers if they don’t find an hpet <azert>someone should write a tsc driver <azert>gnumach would need to check if the tsc is of the reliable time, and in that case use the tsc otherwise try out the hpet. <azert>but what if the tsc is unstable and the hpet unavailable? <azert>I think that if the TscInvariant cpuid bit is set, implementing a tsc driver the same way as hpet is implemented should be a straightforward patch <youpi>because it depends on the cpu clock speed <azert>one could check on that and fall back on hpet <youpi>"not always" doesn't help :) <azert>tells you if it depends on clock speed or not <azert>afaik on newer models this is set <ik5pvx>well, I removed the no-hpet option and now it boots properly <ik5pvx>azert, it boots if I remove the -no-hpet option. <ik5pvx>I wonder what had changed that broke it <azert>now apic is enabled by default <azert>and on gnumach apic depends on the hpet <azert>I think that the way forward is to support a combination of timers and clock sources like other kernels <azert>disabling apic is not a good idea on real hardware <azert>the part about the forced detection of hpet sucks