You are not logged in.
I opened up my Arch today which I'm running off a usb. And I got this error message saying there was an error mount /boot and dependency failed for Local File Systems. I went into emergency mode, I was able to comment out my root system in my fstab and that got me out of emergency mode. I tried to pacman -S linux lts but I got an error code saying code error. mirror host not connected. I can't connect to my wifi I wasn't able to connect for some reason . Can someone explain to me what's going on. I'm not able to do anything in my Arch. Startx gives me an xsession failed. Can't open up firefox. First time something like this occured I ran pacman Syu before I shut off my laptop to update after not using my computer for 2 weeks.
Last edited by Scubba91 (2024-03-07 14:22:59)
Offline
This topic is a little hard to read, but to fix this, you may have to reinstall the system.
Offline
what does `uname -r && pacman -Q linux` give you (replacing 'linux' with a different kernel package if that's not what you're running)?
No, reinstalling the system is not the fix.
Offline
Uname -r
6.6.16-1-lts
Pacman -Q linux
Linux 6.7.4.arch1-1
I can't really go to the website using my phone to reply.
Offline
As uname gives you linux-lts the pacman query would be
pacman -Q linux-lts
instead.
Can you bring up the system by booting an archiso install media, mount the partitions and use arch-chroot to get into it?
If so try a
pacman -Syyu
to update the system and then reinstall grub by
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub
grub-mkconfig -o /boot/grub/grub.cfg
Please report any errors/issues along the way.
Offline
As uname gives you linux-lts the pacman query would be
pacman -Q linux-lts
instead.
This part is correct, and why I specified to use the correct kernel package when I asked for the info.
Can you bring up the system by booting an archiso install media, mount the partitions and use arch-chroot to get into it?
If so try apacman -Syyu
to update the system and then reinstall grub by
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub grub-mkconfig -o /boot/grub/grub.cfg
Please report any errors/issues along the way.
None of this is correct. First off, don't use the double 'y' when updating. Second, they haven't said anything about grub, why are you assuming they're using it? Third, we don't want to be reinstalling it before we figure out what's going on.
Offline
cryptearth wrote:As uname gives you linux-lts the pacman query would be
pacman -Q linux-lts
instead.
This part is correct, and why I specified to use the correct kernel package when I asked for the info.
cryptearth wrote:Can you bring up the system by booting an archiso install media, mount the partitions and use arch-chroot to get into it?
If so try apacman -Syyu
to update the system and then reinstall grub by
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub grub-mkconfig -o /boot/grub/grub.cfg
Please report any errors/issues along the way.
None of this is correct. First off, don't use the double 'y' when updating. Second, they haven't said anything about grub, why are you assuming they're using it? Third, we don't want to be reinstalling it before we figure out what's going on.
Although I learned to deal with toxicity in the linux community - I'm not comming down that step. Rather let me help you to come up one ...
Yes, I just assumed that OP might by using grub - but from literally decades of experience: The simples solution is often the easiest and fastest: Why to bother figuring out why the boot loader fails if a simple reinstall is very likely to fix it?
From what OP gave us is this: A few weeks ago they updated thier system and instead of restarting they just shut it down - and didn't touched the system until recently - and now it "doesn't work anymore". So for some reason something broke back then causing the issues right now.
A simple way to check if it's the boot environment or the installed system is to just check if a chroot is possible from a rescue system - and if so re-install the bootloader to get it back to known workng state.
As Arch is targeted to at least advanced users knowing what they're doing to anyone with the required skill level it should be obvious to substitute my "do you use grub?"-guess with what they actual use: efistub, systemd, refind, whatever. For me writing "a wild guess in the blue" specifically generic like "re-install and re-configure your bootloader" isn't all that different - and more towards communities like the ubuntu-family or suse.
Also: Aside from the bootloader stuff - just trying a simple chroot to see if the main system is still accessible and recoverable from within itself to me is a valid point. Just mashing it together with the bootloader and call it all invalid ... well, that is invalid to me.
As for why I'm used to the extra y when updating my mirrors: Because for some reason although I do run reflector on a regular basis with both --latest and --age parameters set for some reason it sometimes happen that core doesn't get properly updated with just the single y. What's causing it? I don'T know - but I acutally also don't care. It sure could very well be that the mirror that is top most in my currently list is just right now in some resync and therefore not consistent within itself. Unfortunately it seems pacman doesn't really offer some mechanisem a mirror can set a flag "doing resync right now - please ignore me and use the next mirror in the list please" - but, at least to my knowledge, neither do aptitude nor zypper support such feature. I also don'T know how to provide a mirror works - like do you do the sync to a shadow directory and just flip it when done kind of like double-buffering works in 2d desktop? TLDR: I had issues in the past that got solved by just adding a second y and forcing a resync of all selected repos.
Or to put it this way: I just recently got recommened: "don'T use efibootmgr -v ... but use efibootmgr -u". As I didn't know the -u option I looked up the manpage - which says, that the -u option only affects additional parameters comming after it like when adding a new entry. For just simple listing it doesn't do anything at all. So - should I now shoot down said user with "using efibootmgr -u is all wrong ... don'T use it!!!"? No, but I rather should just point: "-u isn't useful in a simple listing - hence just calling efibootmgr without any option is sufficient". It's a simple, neutral and informative reply to something someone else seem to got wrong.
So can we get done with all this kindergarten nonesense beefing around why someone does this while someone else does something different and focus back on OPs issue?
You made your point - and I accept them as valid - but it doesn't make my reply invalid.
Offline
So can we get done with all this kindergarten nonesense beefing around why someone does this while someone else does something different and focus back on OPs issue?
I agree cryptearth, please do.
First, I just read the man page for efibootmgr and have not a clue what you are going on about. You might try again,
Second, -Syy is abusive of our servers. Don't do it. I don't care if you don't know or care why something is broken on your system.
Third, your assumption that Arch users are probably using GRUB is wrong, and your guess will lead someone to break their system.
I don't know what 'toxic' means. At 63 years old, I assume from context it means one does not like getting called out by a demonstrated subject mater expert for giving terrible advice; thus justifying petulant behavior in response.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Although I learned to deal with toxicity in the linux community - I'm not comming down that step. Rather let me help you to come up one ....
Asking people to stop giving out bad info is not toxicity.
Yes, I just assumed that OP might by using grub - but from literally decades of experience: The simples solution is often the easiest and fastest: Why to bother figuring out why the boot loader fails if a simple reinstall is very likely to fix it?
Reinstalling the bootloader without knowing how their partitions are set up, where the kernel is supposed to be, and even what bootloader is being used is flat out irresponsible. From my literally decades of experience, you ask questions and understand what's going on instead of papering over the problem at best, and break the system at worst. And no, it's not likely to fix it.
A simple way to check if it's the boot environment or the installed system is to just check if a chroot is possible from a rescue system - and if so re-install the bootloader to get it back to known workng state.
You realize they're in the system now, right? Since the problem is likely kernel related, no, booting a kernel from totally outside the system isn't going to give us any info, and again, reinstalling the bootloader is not some fix-all solution.
TLDR: I had issues in the past that got solved by just adding a second y and forcing a resync of all selected repos.
So you've had issues you don't understand and avoid it by putting extra load on the servers and recommending others do the same. And you don't care. Great, well we care. Anyone that cares about this distro cares.
Or to put it this way: I just recently got recommened: "don'T use efibootmgr -v ... but use efibootmgr -u". As I didn't know the -u option I looked up the manpage - which says, that the -u option only affects additional parameters comming after it like when adding a new entry. For just simple listing it doesn't do anything at all. So - should I now shoot down said user with "using efibootmgr -u is all wrong ... don'T use it!!!"? No, but I rather should just point: "-u isn't useful in a simple listing - hence just calling efibootmgr without any option is sufficient". It's a simple, neutral and informative reply to something someone else seem to got wrong.
I don't even remember what release it was that made the output we want default and made -v extremely verbose that we *do not* want. Your info there was severely out of date, and I'm the one that replied to you. I did and do want to use -u, because it *is* useful whenever the output includes other OSs, specifically Windows. So yes, use -u as a matter of course because it's likely to be useful and doesn't hurt anything when it's not.
You made your point - and I accept them as valid - but it doesn't make my reply invalid.
When your reply abuses the servers and may break someone's system? Yes, it does make the reply invalid.
Offline
I was able to boot into my arch. Using a live usb I had to delete linux and Linux preset in mkinicipio
Pacman -S linux and also linix-lts then them fo a mkicipio linux while chrooted.
After rebooting I was able to get into my Arch. Though my startx wasn't working to launch my stuff. Also cannot connect wireless.
Using lspci and ip link I can see my wireless card isn't working which is a iwlwifi sorry for the typos. I'm kinda glad I got this far because I carelessly broke my arch more but was able to get this far. Still booting up at the moment but I got to figure out why isn't it connection. Pacman doesn't work gives me an error with mirror. Though I guess it's not working because it's not online.
Offline
I am running grub but I broke my arch more by running pacman -syu. After running that command I just got dropped into emergency mode. When I boot I have to be in legacy support if that matters without that I won't be able to boot my arch. Not sure how to fix that.
Offline
cryptearth wrote:So can we get done with all this kindergarten nonesense beefing around why someone does this while someone else does something different and focus back on OPs issue?
I agree cryptearth, please do.
First, I just read the man page for efibootmgr and have not a clue what you are going on about. You might try again,
Second, -Syy is abusive of our servers. Don't do it. I don't care if you don't know or care why something is broken on your system.
Third, your assumption that Arch users are probably using GRUB is wrong, and your guess will lead someone to break their system.I don't know what 'toxic' means. At 63 years old, I assume from context it means one does not like getting called out by a demonstrated subject mater expert for giving terrible advice; thus justifying petulant behavior in response.
Hm, let me put it this way:
There's quite a gap between teaching someone, why some advice was wrong - like you did: "-yy causes excessive stress on the infrastructure" or a simple "don't assume everyone uses grub"
and the middle finger I got:
None of this is correct.
It's not like I wouldn't accept to get corrected - but I disagree with how it was done: "You're wrong - I disagree with you - and that's why YOU are the stupid!".
I'm just someone standing up and tell you: "Hey buddy, you crossed a line here - don't shoot me down like this!" - and the way scimmia confronted me I just fired back the very same way.
Offline
As uname gives you linux-lts
pacman -Syyu
to update the system and then reinstall grub by
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub grub-mkconfig -o /boot/grub/grub.cfg
Please report any errors/issues along the way.
Think I'm doing this correctly. I didn't add the extra y just -Syu but this further damaged. And the didn't need to reinstall the grub just Linux and Linux lts and change the mkincipio.
Booting up in arch now I'm missing my wireless driver. So can't use Pacman anymore. Gives me an error message in mirrors. Figures because I'm not connected. Tries arch-chroot to install linux-firmware but I believe that gave me an error message.
At the moment can't connect online. Xorg is always not working. Not sure if because my system still needs to be updated
Offline
what does `uname -r && pacman -Q linux` give you (replacing 'linux' with a different kernel package if that's not what you're running)?
No, reinstalling the system is not the fix.
Still waiting for this, making sure to read the part in perens.
Offline
Uname -r
6.6.17-1-lts
Pacman q linux
Linux 6.7.5.arch-1-1
Pacman q linux-lts
Linux-lts 6.6.17-1
Guessing the fact both uname -r and linux lts the same means it's working the right kernel. But for some reason I still can't go online. My network adapter isn't working.
At the moment ran dmesg | grep firmware it gave me error -22 no suitable firmware found for iwlwifi
Offline
That can be normal if the kernel queries newer firmwares than are available but there should be lines where it eventually finds something. But assuming it doesn't load indeed
pacman -Qkk linux-firmware
if that doesn't show changed files, did you add a botched NoExtract pacman.conf directive that would omit firmwares? Output of
pacman-conf
Offline
I would request `pacman -Qkk linux-lts` as well. Missing firmware shouldn't affect /boot.
Offline
pacman -Qkk linux-firmware
Gave me a warning SHA256 checksum mismatch , MD5 checksum mismatch and just more of that
pacman-conf
Never added anything to this I believe
Offline
I am able to boot now. But my programs isn't working right including vim. Just clarifying I can boot.
Offline
Reinstall linux-firmware if it gives you checksum errors
Also if this happened "randomly" chances are your USB is dying. They have very limited write cycles and aren't exactly intended to run an actively changing operating system on them
Last edited by V1del (2024-02-18 18:15:47)
Offline
Reinstall linux-firmware if it gives you checksum errors
I used my live usb again. Mounted and used pacman -S linux-firmware but I got an error message. And didn't know usb can die. Forgot what it said. Using pacman without booting into live usb just gives me an error message about mirrors.
Offline
What error message?
Offline
Saying firmware exists in file system. It's a bunch of them. Saying about of firmware exist in file system. All in /usr/licenses/Linux firmware. At the moment in my Arch.
Offline
https://wiki.archlinux.org/title/Pacman … )%22_error
In this case it's likely safe to do a
pacman -S --overwrite '*' linux-firmware
but as mentioned be prepared that the stick might be dying
Offline
Not sure how I can tell if my usb is dying. Pacman overwrite worked. I am able to see my wlan0 but having trouble
ip link set wlan0 up but still in a down state.
I also ran pacman Qyy to see if I have more issues which gave me some errors.
If I run pacman Syu will that help make sure my system is fully updated? Which I give the output but still can't use my Firefox. Using my phone
Offline