Nah, I run my updates maybe once a week on average. If afterwards something breaks, I simply do a complete Rollback (with e. g. snapshots). If after the next update its still broken, then I start to dig in „what“ is broken and how I might fix it
But as I said, it didn‘t happen to me yet - but I‘m also fairly new to Arch as well, so that‘s at least my plan on how I would go after it.
Rolling release 🤷🏻♂️ there might be updates which cause issues where you might need to rollback, if you can handle that it shouldn‘t be a problem.
I‘m using Arch myself since about 2 months and never happened that an update break something for me - when something broke it was my own fault.
Awesome! Will look to register tonight or tomorrow, when I find the time. Thanks for letting me know :)
Ok. I think Im gonna test it out aswell once migration is done
So the migration to mbin is done or just wanted to fix that first anyways? ^^
Its working since months, so I guess you have the drivers installed. For me I needed the „wayland-protocols“ package to work on my RTX3070
And the obvious once others have pointed out, the kernel parameters
@darth
did test that as well, but didn’t help as the kernel didn’t boot up at all.
In the end, after also trying to reach out to ASUS Support (and ofc without any proper solution from their side), I did replace my custom built, noname, (trash) motherboard and now it works flawless.
So, I think it was something with the ACPI/DSDT Tables f’d up on the old MoBo and ASUS just couldn’t (or didn’t want to) fix that…
Alright, no worries! Appreciate you trying to help, thank you
Yep, saw this entries already and tried with it. To no change unfortunately.
Did some research and also found the suggest to try with
acpi=noirq noapic
but also tried to no change.
Regarding the BIOS options, I did also check for these options, bug they simply aren‘t there 🤷🏻♂️ but will look again after those. Got told that this error might be due to the acpi=off thingy
there you go:
https://pastebin.com/kNFqya2L
taken with acpi=off boot.
Since without acpi=off it’s not possible to boot and there is absolutely no output after grub (as if the kernel wouldn’t load at all) there simply nothing to show …
Sure. The whole output or something like dmesg -T --level=emerg,alert,crit,err,warn ?
Well the startup kernel messages. Looking for something specific?
ok took me 3 days to test, apologies :D
but unfortunately, no, doesn’t work. Even the “old” iso stucks at the exact same position with the exact same behavior :(
got some news. I don’t think, that it might change something, but who knows.
I added in grub the option “insmod progress” (which I found by googling somewhere). It should show, if kernel and initrd do load or not and now I can see, that the vmlinuz and initrd are loading to 100% and after that it hangs. So it looks like the kernel loads but then stucks.
As said before, I don’t think that this might change something in regards to further tests with my actual mobo, but I didn’t want to left that out …
One last question, what would you suggest for looking up which hardware (mobo in general) would play nice (or at least at all) with linux? Is linux-hardware.org the way to go?
@Guenther_Amanita
I don‘t know about the perfectly fine piece of hardware if it‘s making me so much trouble 🤣 but thank you for your opinion on this, appreciate it
Oh I absolutely can relate haha
Maybe one day I‘ll be here asking dumb questions again, watch out 😁
Alright, no worries! You invested so much time and effort trying to help me out, I can‘t thank you enough for that, really really appreciate it much!
Yeah I already got one in mind and looked it up on linux-hardware.org - any other option I‘d have to make sure the next one is alright? (Besides socket and compatibility with my other hw)
Iptables. Because in the end its iptables, so I learned it from the beginning „the right way“ and i am therefore not locked into one or another