You are not logged in.

#1 2013-05-28 14:38:15

ibrunton
Member
From: Canada
Registered: 2011-05-05
Posts: 270

File locations in /boot: can I move them?

I want to create a multi-boot system (no Windows---only multiple Linux distros).  I have Arch up and running just fine, and I have lots of hard drive space for creating extra partitions.  My bootloader is syslinux.

What I'm wondering is whether the boot images and vmlinuz need to be in /boot or whether I could move them to, say, /boot/arch and make corresponding changes to the syslinux.cfg file, so that additional Linux distros won't overwrite Arch's boot files.

Offline

#2 2013-05-28 14:41:23

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: File locations in /boot: can I move them?

Try it.
Copy these files, don't move, and change the configuration of only the first boot option (e.g. the stock Arch kernel image), so that you can still boot if thing don't work (e.g. using the fallback image you left intact).

Offline

#3 2013-05-28 15:18:38

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: File locations in /boot: can I move them?

If you use syslinux, the kernel and initramfs need to be on the same partition as the syslinux.cfg.  This is why the example in the syslinux.cfg is a relative path (ie. ../vmlinuz-linux) as it is the location of th kernel from the config.

If you use grub or lilo (I think) then you can have the kernel and config on separate partitions.  But as long as the kernel is on the same partition (in syslinux's case) then it can be anywhere you want on that /boot so long as you have the config poitning to the right place.  A good example of this is the UEFI spec states that the ESP should be a particular heirarchy, which if you follow, does not put your kernel at /boot/vmlinuz-linux.  But as long as you point it to the right place, it is fine.

The bigger issue is what you do during updates to have the kernel and initramfs moved to the right place.  Again, UEFI users grapple with this problem.  So in that case, there is a "solution" on the arch wiki UEFI page.  Personally, I use a systemd.path unit that points to a oneshot systemd.service file.  So when the kernel is detected as being written to /boot/vmlinuz-linux, it moves it to where I want it.  Then I have mkinitcpio looking for the kernel to build against at the new location, then actually just plops the new initramfs right where I want it.  Of course, you then have to pay attention to what the output of mkinitpcio tells you during installation, as if the service fails and doesn't move the kernel, then it will not be able to find the modules necessary for the building of the initramfs.

Normally during an update if there is failure to move the kernel to its new location (where mkinitcpio is looking for it) then it will give you a pretty visible error saying ti can't find the modules.  This is particularly the case if you are going from something like 3.8 to 3.9, and also pretty evident when moving from 3.9.1 to 3.9.2 fr example.  But it is not quite as apparent if it fails when it just bumps the pkgrel.  So for example, going from 3.9.2-1 to 3.9.2-2.

Most of the time though, (I'd say 95% of the time) it works flawlessly.  But just be sure you pay attention if you go this route. 

Honestly, if you are using syslinux, I would recommend just not sharing the /boot partition and then having it chainload to other instances of syslinux installed to the partition boot record.  An example of how to do this can be seen on the syslinux wiki page (I put it there).  I think that if you are using simple bios booting, it is not worth all the hassle to be moving kernels around and whatnot.  And unless you have all different dinstributions on your machine, then there *should* be no kernel conflicts if you do share the /boot partition.

Offline

#4 2013-05-31 14:18:34

ibrunton
Member
From: Canada
Registered: 2011-05-05
Posts: 270

Re: File locations in /boot: can I move them?

@WonderWoofy:

I hadn't thought about the issue of having to move the images every time the kernel gets updated.

For chainloading, do the other distros have to use syslinux as well?  What I want to install are Slackware and Debian, and I don't believe either installs syslinux by default; I haven't yet been able to determine whether either even offers the option of installing syslinux as the bootloader during OS installation.  I think Slackware uses LILO and Debian uses GRUB.  In the Arch wiki entry on syslinux, would this be the "Chainloading other Linux systems" section, with the "extlinux -i" command, or am I misunderstanding the wiki? I.e., does that command install syslinux on the mounted system?

Sorry if I'm sounding confused.  This is the first time I've dealt with any bootloader other than grub-legacy or a multi-Linux boot set-up.

Offline

#5 2013-05-31 14:26:55

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: File locations in /boot: can I move them?

That command will install syslinux to the partition boot record.  So say you have a second OS mounted on /mnt.  If you wanted to install syslinux/extlinux to that partition (not the MBR), you would use "extlinux -i /mnt" though if you had a separate /boot partiton that was moutned to /mnt/boot then you would use "extlinux -i /mnt/boot".  Then the MBR copy of syslinux (the one you dd to sda or install with syslinux-install_update -iam) will boot then its configuration can be pointed to chainload this other sopy of itself that you have put on the partition boot record.

If you plan on using something else, then just use something else.  Syslinux is awesome if you have a relatively simple setup.  But once you start chainloading and chainloading it gets a bit messy.  The only thing about syslinux's amazing simplicity is that it doesn't give it the ability to read kernels (or initramfs') from other partitions.  It can only read the config and kernels from the partition marked as bootable, unless you then chainload to a PBR installed copy.

As a fan of elilo, I would recommend using lilo if you are planning on using slackware.  That is what it uses as its default bootloader, and it works quite well.  THe configuration is very simple.  Grub on the other hand has gotten far too bloated for my taste. It offers many features, but these things only get around layouts that one shouldn't really use in the first place.  For instance, the ability to read /boot off an LVM... why would you do that!?!?

Offline

Board footer

Powered by FluxBB