/usr/bin changes and grub legacy

Baryon · 2013-06-03 13:20:34

Hello,
Grub legacy is one of the packages that keeps its binaries in /sbin. I'm just wondering if this means that I have to replace grub legacy with another bootloader before I upgrade my system? I certainly wouldn't know how to update grub legacy so that the binaries are found in /usr/bin.
Thanks.

karol · 2013-06-03 13:31:56

Moving to syslinux is very easy.
You can also wait, maybe grub-legacy in the AUR will be updated.

teateawhy · 2013-06-03 20:36:37

Installing a new bootloader is the way to go.
https://wiki.archlinux.org/index.php/Syslinux
https://wiki.archlinux.org/index.php/GRUB

owain · 2013-06-03 20:49:30

I just did the upgrade to Grub. The wiki is perhaps a bit dense and it's hard to know which sections apply to you, but read it thoroughly and follow the instructions.

Thorsten Reinbold · 2013-06-03 20:52:54

Is there any special reason you're still using grub-legacy? As mentioned before, upgrading to an up to date bootloader will do the trick.

WonderWoofy · 2013-06-03 21:27:39

You could simply move the contents of the package to /usr/bin and then change the paths in /var/lib/pacman/local/files to match where you changed them to. It would seem that if you are still using grub-legacy, your intention is to continue to do so, so I don't think it will hurt anything, so long as those paths did not conflict with other packages.

On my home file server, I am still using the lvm and device-mapper packages from before the lvmetad change, as I have not been able to find a viable solution otherwise. The binaries for those packages are stored in /sbin. So I just moved them to /usr/bin, then made the changes to /var/lib/pacman/local/files about where they were, and all is well on that machine. And when I do finally figure out how to deal with that situation, I can still upgrade knowing that the files in question are still tracked and will be removed as usual.

nixpunk · 2013-06-03 22:27:12

I just used it as an excuse to update Grub.

WonderWoofy · 2013-06-03 22:35:43

nixpunk wrote:

I just used it as an excuse to update Grub.

Yeah, but grub-legacy was so much more sane, IMO. It is not that grub2 doens't provide some really neat features, it is just that for 99% of users, none of those neat features will be of any use. So in the case of the bootloader, it is not like it is a running binary on your system that can produce a threat, it is simply a bootloader that does its job, then quits. So no matter what you are using, if it works and you are happy with it, I see little reason to change it.

Scimmia · 2013-06-03 22:36:30

Which is why so many people went to syslinux instead.

WonderWoofy · 2013-06-03 22:37:21

Yeah, I was one of those people. But in reality it is just my backup, as I use UEFI.

karol · 2013-06-03 22:39:45

WonderWoofy wrote:

no matter what you are using, if it works and you are happy with it, I see little reason to change it.

Yup, the devil you know ...
I had one system still using grub-legacy and initscripts and updated it to syslinux and systemd a couple days ago, because I had systemd and filesystem in IgnorePkg ;P and was afraid things would break horribly.

Trilby · 2013-06-03 22:44:27

My home system uses grub(-legacy). I did once try to change over to syslinux which I use on every other system. It failed miserably, though. And this is on a very old iMac that will not boot to any external media, and has only one CD drive that is on its very last leg - it took several hours and hundreds of failed attempts to even boot to a live-CD once. Once in the live environment, I quickly changed back to grub(-legacy) and decided I should never touch the bootloader on that machine again.

So, this will be a fun evening.

WonderWoofy · 2013-06-03 23:15:39

@Trilby, don't change it! I remember that debacle! Just move the files to /usr/bin manually, and then change the location of the lifes in /var/lib/pacman/local. Either that or simply uninstall grub-legacy (keeping the package in your cache), then do the update. Then reinstall grub legacy from your pacman cache. For now, pacman will still accept packages being installed along symlinks, so it will put it into /usr/local anyway. Though in this case, you should still change the stuff in /var/lib/pacman/local to point to the files along their "correct" paths.

cfr · 2013-06-03 23:27:30

@Trilby,
Did you try booting it in target disk mode at all? I thought all recent Macs could do that. (I know you say it is "old" but if it is capable of running Arch it is newer than any Mac I've worked with and therefore counts as "recent" by a considerable margin for these purposes.) This is obviously only useful if you then have something to hook it up to i.e. firewire, I expect, and I'm not quite sure how that would work with Linux. Just a thought... I believe target disk mode is pretty Mac-specific and even Mac users tend to forget about it.

Trilby · 2013-06-03 23:48:51

Actually WW this is my *other* mac. This is a ~2004 iMac. If this ever had target disk mode, I'm pretty sure that was part of the funky mac boot manager stuff I did away with. I think I'll go with WW's suggestion and just move the files.

cfr · 2013-06-04 00:01:11

It had it once but it may well be part of what you did away with . Target disk mode was introduced on PPC hardware. Anything intel had it. (That's why I knew yours must count as "recent" by my standards - I've never had an intel Mac.)

Trilby · 2013-06-04 00:07:50

EDIT: THE FOLLOWING WILL NO LONGER WORK.
As of ~23 June 2013, pacman will relpace grub-0.97 with grub-2.xx. Installing grub-legacy from the aur will avoid this. So installing grub-legacy is now the only way to keep grub 0.97.

OP, I did just follow WW's suggestion, and successfully upgraded, and rebooted without any issue at all - which should really be no surprise in hindsight, as none of those files should actually be needed for grub to boot properly (AFAIK) - they are all tools for reconfiguring or updating the MBR code (I think!).

But in any case, this was the extent of it

mv /sbin/grub* /usr/bin/
mv /sbin/install-grub /usr/bin/
mv /bin/mbchck /usr/bin/
$EDITOR /var/lib/pacman/local/grub-<VERSIONNUMBER>/files

Once in the editor, the needed changes are pretty obvious.

Last edited by Trilby (2013-06-24 14:37:19)

tjanson · 2013-06-04 02:20:12

Trilby wrote:

But in any case, this was the extent of it

mv /sbin/grub* /usr/bin/
mv /sbin/install-grub /usr/bin/
mv /bin/mbcheck /usr/bin/
$EDITOR /var/lib/pacman/local/grub-<VERSIONNUMBER>/files

Not sure if it’s a typo on your part or not, but in my case it was called

mbchk

. Thanks for the help, by the way, seems to have worked for me (though I haven’t rebooted yet).

Trilby · 2013-06-04 02:33:39

Yup, that was a typo, thanks.

shariebeth · 2013-06-04 03:26:35

Excellent thread and thank you Trilby and WonderWoofy. I had been toying with this but all the gloom and doom of the other threads made me hesitate. My netbook is still on grub-legacy (intentionally so) and calls up it's window manager in .xinitrc with consolekit.
I ran pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm - and most I could remove other than grub.
Everything else that remained in /bin and /usr/sbin I moved with mv command over to /usr/bin/, edited the grub file to change the paths, removed the empty /bin and /usr/sbin directories, and ran the update. Rebooted. Reinstalled consolekit from /var/cache/pacman/pkg/consokekit-versionnumber. (I guess I can actually use dbus instead if I wanted to.) Worked like a charm.

WonderWoofy · 2013-06-04 03:42:29

Why is it that you feel as though you still need consolekit? Are you not using systemd?

shariebeth · 2013-06-04 03:52:37

WonderWoofy wrote:

Why is it that you feel as though you still need consolekit? Are you not using systemd?

Not on this netbook, no. (I have systemd on my main pc though, although I fought it there too for a long time)
As for consolekit, it calls up my wm in my .xinitrc when I startx: exec ck-launch-session startlxde. It's always worked so never saw a reason to change it.

WonderWoofy · 2013-06-04 04:04:54

The reason to change to systemd is that the daemon scripts in /etc/rc.d are disappearing, as are hte /etc/conf.d stuff. It will break sooner or later (probably sooner) and I am actually really surprised it hasn't already. There is a reason why the news indicated that you should switch, as the old initscripts are not longer supported. That means more than just not getting updates, the files that make that work are slowly being pulled from the packages (and slowly in Arch is not very slow at all).

As for consolekit, it is an unmaintained piece of software. Its functionality has been replcaed by systemd's logind (quite successfully I mgith add) which is another reason why you should switch.

I'm not saying that you have to switch, as there are other alternatives out there that you could use. There is a whole thread on how to use openrc, and some stuff about using various other thigns as well, like runit or even the busybox init. But I have seen very little quality stuff in regard to maintenance of the old initscripts. Sticking with this is not something you should really want to do. I think in the end, you will end up with a much larger headache than simply ironing out any issues may have with moving to systemd.

shariebeth · 2013-06-04 04:21:36

Every update I wonder if it's THE update that will break things beyond repair so I am well aware I'm on borrowed time on this machine. Fortunately I can afford to take the risk as I have other boxes that have my main stuff on them. This is just an extraneous little netbook I putter around with, and there's not much on it. I prefer legacy grub anyway (maybe because that's what I started with so it feels the most natural) and I enjoy the learning curve of finding the workarounds. So I'll tinker with it as long as I can.

jasonwryan · 2013-06-04 04:31:47

shariebeth wrote:

I enjoy the learning curve of finding the workarounds...

You are free to row your own boat, of course, but I can't help remarking on the fact that you are investing effort in learning redundant or deprecated technologies and hacks; as opposed to spending the same amount of energy looking to--and learning for--the future. Check out syslinux; it is wonderfully simple (and supported).

Arch Linux

#1 2013-06-03 13:20:34

/usr/bin changes and grub legacy

#2 2013-06-03 13:31:56

Re: /usr/bin changes and grub legacy

#3 2013-06-03 20:36:37

Re: /usr/bin changes and grub legacy

#4 2013-06-03 20:49:30

Re: /usr/bin changes and grub legacy

#5 2013-06-03 20:52:54

Re: /usr/bin changes and grub legacy

#6 2013-06-03 21:27:39

Re: /usr/bin changes and grub legacy

#7 2013-06-03 22:27:12

Re: /usr/bin changes and grub legacy

#8 2013-06-03 22:35:43

Re: /usr/bin changes and grub legacy

#9 2013-06-03 22:36:30

Re: /usr/bin changes and grub legacy

#10 2013-06-03 22:37:21

Re: /usr/bin changes and grub legacy

#11 2013-06-03 22:39:45

Re: /usr/bin changes and grub legacy

#12 2013-06-03 22:44:27

Re: /usr/bin changes and grub legacy

#13 2013-06-03 23:15:39

Re: /usr/bin changes and grub legacy

#14 2013-06-03 23:27:30

Re: /usr/bin changes and grub legacy

#15 2013-06-03 23:48:51

Re: /usr/bin changes and grub legacy

#16 2013-06-04 00:01:11

Re: /usr/bin changes and grub legacy

#17 2013-06-04 00:07:50

Re: /usr/bin changes and grub legacy

#18 2013-06-04 02:20:12

Re: /usr/bin changes and grub legacy

#19 2013-06-04 02:33:39

Re: /usr/bin changes and grub legacy

#20 2013-06-04 03:26:35

Re: /usr/bin changes and grub legacy

#21 2013-06-04 03:42:29

Re: /usr/bin changes and grub legacy

#22 2013-06-04 03:52:37

Re: /usr/bin changes and grub legacy

#23 2013-06-04 04:04:54

Re: /usr/bin changes and grub legacy

#24 2013-06-04 04:21:36

Re: /usr/bin changes and grub legacy

#25 2013-06-04 04:31:47

Re: /usr/bin changes and grub legacy

Board footer