You are not logged in.
Calm down, please.
If you want to continue to use grub-legacy (and many here do), then just install it from AUR. It has been rebuilt to comply with the new filesystem structure.
Then identify any other packages that need the same treatment: either uninstall, upgrade or replace them with something else.
Waiting another month won't change your situation; all of the packages have been rebuilt so you may as well tackle it now. If you work methodically through the instructions, it will work out fine.
Offline
Paul, there is hardly any need to really read all 29 pages (30 now). Read one - all the others are just more of the same.
We don't have 29 pages of people who had trouble with this upgrade - we have 1 pages of users who didn't bother to read the other 28 pages, 1 page that didn't read the previous 27, 1 that didn't read 26, etc, etc.
You have been given the advice you need - if you want to ignore it, best of luck, but your grub *will* be broken after the update if you don't follow the suggested advice.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
I think I got my grub legacy before it was moved to AUR. I guess the assurance, "GRUB legacy... will stay fully functional," on the grub legacy wiki page, now needs to be updated.
I'm thinking of going to syslinux since it is in core, and since it is not grub 2. I hope it's not slated to be kicked out to AUR like grub legacy was.
Offline
Grub legacy will remain fully functional - I have it on the computer I'm on right now. But you don't have grub legacy installed - the suggestion provided to you was to install it, but you refuse.
Nothing will remain fully functional if you refuse (for no apparent reason) to follow simple instructions.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
I am attached to legacy grub, not because it is so wonderful, but because grub 2 is so awful.
Then either use the AUR grub-legacy package or switch to something else (personally, I like syslinux).
You guys act like everyone is on top of exactly what the system is doing.
Yes, that's because you're expected to. If you haven't already, please read The Arch Way.
This upgrade is NOT "like pretty much always"; that's why you have a 29-page thread full of users bricking their systems.
1. "bricking" implies that their systems aren't recoverable. 2. Those users—if you read the thread, you'll notice—are users that didn't follow the instructions.
At some point it may dawn on you that the instructions need some work, for example like breaking it into two parts, one for package maintainers and another for users, and trying to explain what the user needs to do and what the upgrade handles automatically (e.g. links). Oh, and whether files need to be moved - there is still confusion on this point on page 29 of this thread.
No, the update announcement (like pretty much always—as stated before) is for the user doing the manual intervention. If you are still confused, then you haven't read anything from the thread. The directions are perfectly clear, and for any part that isn't clear for you in the instructions, I'd bet almost anything that it's been covered in the thread. Arch users are expected to maintain and understand their system; this situation is no different.
I am sorry if I appear to be coming across as terse or unkind, but this has very clearly been covered before…
All the best, (I honestly don't mean this in any unkind way, it's my signature, and I mean it genuinely—always)
-HG
Offline
Those users—if you read the thread, you'll notice—are users that didn't follow the incomprehensible instructions.
There, I fixed it for you.
Thanks for the link, but I did read the Arch Way. That's why I am here. I was attracted by the quality of documentation. But that does not imply it's all of equal quality. 30 pages ought to be a clue.
But never mind; I get what is going on here. Have a nice day.
Offline
For what it's worth, here is what happened when I tried to reinstall grub legacy as you suggested:
[root@myhost pacman.d]# cd /root/AURBuilds
[root@myhost AURBuilds]# ls
grub-legacy grub-legacy.tar.gz
[root@myhost AURBuilds]# cd grub-legacy
[root@myhost grub-legacy]# ls
040_all_grub-0.96-nxstack.patch grub.install
05-grub-0.97-initrdaddr.diff i2o.patch
PKGBUILD install-grub
automake-pkglib.patch intelmac.patch
ext4.patch menu.lst
grub-0.97-ldflags-objcopy-remove-build-id.patch more-raid.patch
grub-inode-size.patch special-devices.patch
[root@myhost grub-legacy]# makepkg
==> ERROR: Running makepkg as root is a BAD idea and can cause permanent,
catastrophic damage to your system. If you wish to run as root, please
use the --asroot option.
[root@myhost grub-legacy]# su paul
[paul@myhost grub-legacy]$ makepkg
mkdir: cannot create directory ‘/root’: Permission denied
==> ERROR: You do not have write permission to create packages in /root/AURBuilds/grub-legacy.
Aborting...
[paul@myhost grub-legacy]$ exit
exit
[root@myhost grub-legacy]# makepkg --asroot
==> Making package: grub-legacy 0.97-25 (Fri Jun 28 18:45:27 PDT 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
-> gcc-multilib
==> ERROR: Could not resolve all dependencies.
[root@myhost grub-legacy]# pacman -S gcc-multilib
resolving dependencies...
warning: dependency cycle detected:
warning: lib32-gcc-libs will be installed before its gcc-libs-multilib dependency
looking for inter-conflicts...
:: gcc-libs-multilib and gcc-libs are in conflict. Remove gcc-libs? [y/N]
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: gcc-libs-multilib and gcc-libs are in conflict
[root@myhost grub-legacy]#
So much for the legacy update...
In retrospect it was a bad idea to move grub legacy (broken by this system update) into AUR, given that it is so crucial to booting for so many users (and has the potential for breaking a lot of systems if neglected). BTW I didn't just copy it from somewhere as someone implied; looking in my pacman log it was installed from core or wherever it used to be before it was banished to AUR.
I know some people think grub legacy should just curl up and die, but you usually have to provide something better for that to happen. Grub 2 ain't it.
Offline
This is not what anyone was telling you, can if you had simply read the errors of the pacman/makepkg output when you tried to install in the above post, you would have been able to install just fine.
The grub-legacy package in the AUR is not "broken by this system update" nor did anyone imply that you just copied it from somewhere. There are multiple threads in these forums about how to modify your existing package to conform to the new filesystem, but apparently you are unable to use a serach function. Though if you can't figure out why gcc-multilib won't install when you don't accept the dependencies, I think there might be no real hope for manual modification of packages on your part.
Offline
So much for following instructions on how to install from the AUR. You did nearly everything possible there incorrectly - it's no suprise it doesn't work.
No one thinks grub-legacy will curl up and die: it's still maintained in the AUR - the PKGBUILD works perfectly (when used properly), and Grub 2 is not the only alternative.
If you want help, follow the directions that have been provided for you (here, on the front page, and in the wiki). If you want to intentionally ignore those instructions and do things incorrectly, don't blame anyone else when things don't work. If you just want to rant and complain, get a blog.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
Not that you guys give a damn, since you are having more fun looking down your snooty noses than actually providing some help or getting some data points on the quality of your last update, but I didn't tell it to wipe out gcc-libs because it might be being used by something else. The default "N" on the removal question at least suggested that. Maybe gcc-libs-multilib is supposed to replace gcc-libs? How would I know? Anyway the aur listing for grub-legacy didn't list gcc-libs-multilib as a dependency.
I have to laugh. The Arch forum has turned into the Twilight Zone when I wasn't looking.
Offline
Not that you guys give a damn, since you are having more fun looking down your snooty noses than actually providing some help or getting some data points on the quality of your last update...
<snip>
I have to laugh. The Arch forum has turned into the Twilight Zone when I wasn't looking.
No twilight zone here, just a shitty attitude from you, and the expectation that either your hand will be held through this process, or someone will use a search engine in your honor.
Offline
+1 Wonderwoofy
I've been around a little while--ahem--and I am sorry PaulBx1 is encountering problems. I find alot of people who just want to use Arch, even though they chose to ignore the disclaimer that Arch is for competent linux users and people are expected to put in some effort to maintain their systems.
Having said that, I personally don't really like grub2 and have been using syslinux for quite some time. I'm quite sure that if I wanted to use grub legacy, I could figure it out but that won't help PaulBx1. Too much complaining lately and nothing we can do but suggest that you use a linux distro that will do more automagically for you.
Last edited by bgc1954 (2013-06-29 02:47:24)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
You are NOT supposed to be moving files. Nowhere do the instructions tell you to do that and the stickied thread explains many times why this is a Very Bad Idea.
Wait, I'm confused. I did this a few weeks ago, and I thought that
If you have files in /bin, /sbin or /usr/sbin that are unowned by any package, you need to move them
meant that we were supposed to manually move files listed by
$ find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
to /usr/bin. Was this not true?
Last edited by bananagranola (2013-06-29 03:03:03)
Offline
@PaulBx1,
The advantage of a package manager is it deals with this stuff for you. So long as you don't tell it explicitly to force things or to ignore dependencies, it will not remove something required by something else without replacing it. You can safely replace gcc-libs with the multilib version.
I do realise that you are extremely frustrated. However, abusing people here who are trying to help you is counter-productive.
If you are trying to install an AUR package, you should read up a bit on using AUR packages. For example, you should understand why it is generally a bad idea to run makepkg as root. I am not sure what point you hope to make here but if you just wish to vent please go find a bag of potatoes to punch. If you actually want to fix your system and are prepared to learn enough to do so, then take a break. Go do something else and come back to this later. You are not getting anywhere right now and are just going to make things worse.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
meant that we were supposed to manually move files listed by
$ find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
to /usr/bin. Was this not true?
No, it meant that you were supposed to rebuild and fix the unsupported packages you were using such that they didn't install files to the wrong place.
All the best,
-HG
Offline
No, it meant that you were supposed to rebuild and fix the unsupported packages you were using such that they didn't install files to the wrong place.
All the best,
-HG
OK, thanks. Apparently not only did I wrongly tell someone something stupid, I did something stupid. Thankfully, I was corrected immediately. Sorry, everyone.
Last edited by bananagranola (2013-06-29 03:16:32)
Offline
cfr wrote:You are NOT supposed to be moving files. Nowhere do the instructions tell you to do that and the stickied thread explains many times why this is a Very Bad Idea.
Wait, I'm confused. I did this a few weeks ago, and I thought that
If you have files in /bin, /sbin or /usr/sbin that are unowned by any package, you need to move them
meant that we were supposed to manually move files listed by
$ find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
to /usr/bin. Was this not true?
It depends what they were but generally, no, you shouldn't move them manually. First you should make sure that you understand why they do not belong to any package. There are cases in which moving them is OK but they are exceptions and just saying you should move some things will encourage the already evident tendency of people to move the contents of those directories wholesale and then wonder why their systems broke.
What did you move? On a well maintained system, this command should produce a minimal list, at most.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It depends what they were but generally, no, you shouldn't move them manually. First you should make sure that you understand why they do not belong to any package. There are cases in which moving them is OK but they are exceptions and just saying you should move some things will encourage the already evident tendency of people to move the contents of those directories wholesale and then wonder why their systems broke.
What did you move? On a well maintained system, this command should produce a minimal list, at most.
Unfortunately, I honestly don't remember; I just remember that the list wasn't very long, 2-3 items or so. I just checked again, and I don't have any unowned packages in /usr/bin right now. But in any case, I understand now that that was stupid, and I was lucky to walk away unscathed. I've left my earlier post in for posterity, with a strikethrough so that no later readers will try to do the same.
Last edited by bananagranola (2013-06-29 03:17:00)
Offline
I thought that ... unowned by any package ... we were supposed to manually move files listed
Actually you may have been right to do that if they were really not owned by any package. But the current issue were files owned by a local pacakage.
That said, you probably shouldn't have any files not owned by packages in any of those directories. If these are your own tools/scripts, it may be better to keep them somewhere in ~ (eg ~/bin) then add that directory to your path.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
Actually you may have been right to do that if they were really not owned by any package. But the current issue were files owned by a local pacakage.
That said, you probably shouldn't have any files not owned by packages in any of those directories. If these are your own tools/scripts, it may be better to keep them somewhere in ~ (eg ~/bin) then add that directory to your path.
Yeah, I'm 100% certain that they where not my own tools/scripts, so I'm pretty sure now that I wasn't supposed to move them.
But in any case, to recap: I recommended something stupid (risking someone else's system), was corrected, admitted I did something stupid, and had 3 different members of the community explain my idiocy to me more gently than I would have done to myself. So thanks a lot. At least from my personal experience, the Arch community has been more forgiving and kind than I could have expected.
Offline
Hi All,
I updated my system and must have done something wrong when following the guide (https://www.archlinux.org/news/binaries … ervention/).
As a result I initially got the error quite a few people have got:
Error: Root device mounted successfully, but /sbin/init does not exist.
Bailing out, you are on your own. Good Luck
However, I got past this by adding init=/usr/lib/systemd/systemd
but now have the following errors below displaying on boot. Any help would be greatly appreciated.
Many thanks
http://i.imgur.com/z17d681.jpg
-- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --
Offline
Please search before posting. There is a huuugge thread about this already. Though the thread is many pages, it is the same issues over and over again, so don't be intimidated by the sheer number of posts. I believe that the thread is even stickied.
Offline
Thanks for the reply WonderWoofy. Just to clarify, would the thread in question be https://bbs.archlinux.org/viewtopic.php?id=164312 ?
I just wanted to raise it because I have been doing quite a bit of searching (I think I've just closed about 40 arch linux tabs in firefox ) but can't seem to find a definitive answer and I'm quite hesitant to play with the system in case it breaks any further. Thanks again
Offline
That is indeed the thread I was talking about. Here's a hint: the solution for your case is going to involve chrooting. Posts from Scimmia are particularly of use since Scimmia provided the biggest level of support throughout that thread.
Offline
Thanks again, I've had the machine chrooted going through that and have spotted the following:
Scimmia
dwal42, what's the output of pacman -Qo /usr/sbin
It should just be the filesystem package. If it's any other package, fix them.
Looks like filesystem 2013.03.12 is the only one
Scimmia
When I came to
# pacman -Su
, I still got the "exists in filesystem" error. I hadn't the time to fix it at this moment, so I shutdown my system.
I think we need a facepalm emoticon.
Anyway, do the /bin, /sbin, and /usr/sbin dirs exist? If so, what's in them?
For my system /bin contains sh and bash, /sbin doesn't even exist and /usr/sbin is empty
I ended up moving /bin to /bin-old then creating symlinks to /usr/bin
All seems fine now and boots correctly but the networking and perhaps some other things are not functioning correctly so there's a new barrel of fun to get in to
Offline