Moving /boot to it's own partition

Kotrfa · 2013-09-02 07:55:59

Hi,

I want to move my /boot partition, which is on the same partition with the rest of the linux system (number 1 on the list below) to it's own partition n.3 (freshly formated to ext4). Mainly because of security reasons.
Is this right process?

parted print

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  25.0GB  25.0GB  primary   ext4
 4      25.0GB  85.3GB  60.3GB  extended
 5      25.0GB  85.3GB  60.3GB  logical   ext4
 3      95.8GB  95.9GB  106MB   primary   ext4
 2      95.9GB  128GB   32.2GB  primary   ntfs         boot

# mkdir /mnt/newboot
# mount /dev/sda3 /mnt/newboot
# cp -dpR /boot/* /mnt/newboot/
# cp /boot /oldboot
# mkdir /boot

Now add to /etc/fstab:

 /dev/sda3 /boot ext4 ro 0 0

Mount new /boot partition.

mount /dev/sda3 /boot

Now just install new grub:

grub-mkconfig -o /boot/grub/grub.cfg

I'm afraid of the last step - does grub-mkconfig handle everything? I also have Windows partition on /dev/sda2.

Thank you

edit: cp instead mv

Last edited by Kotrfa (2013-09-08 21:04:25)

Arctus · 2013-09-02 10:01:33

Seems right to me. Just keep a install media close, in case of any mistakes.

Actually, I'm not sure you need the copy line.

Last edited by Arctus (2013-09-02 10:02:28)

graysky · 2013-09-02 10:12:43

Why making /boot as ro in the fstab? Doesn't this mean you cannot write to it... makes updates a bitch.

Trilby · 2013-09-02 12:04:12

I've never done this myself - but you seem to be missing some very important steps: you never move the kernel or initramfs images.

I'd first mount the new partition somewhere else (eg /mnt/newboot/) then ~~move~~(edit: copy) the contents of boot ( mv cp /boot/* /mnt/newboot/), unmount the newboot and remount it on ~~the now empty~~ /boot/, then regen/reinstall any bootloader code.

(edited per the comments below)

Last edited by Trilby (2013-09-03 17:39:03)

Roken · 2013-09-02 17:30:09

personally, I'd cp, rather than mv /boot to /newboot. That way you have an easy fix if something goes wrong.

WonderWoofy · 2013-09-02 19:56:05

Roken wrote:

personally, I'd cp, rather than mv /boot to /newboot. That way you have an easy fix if something goes wrong.

Meh, I'd mv because I laugh in the face of danger! But you are probably right that since the OP is struggling with the ideas behind making this change, a fallback is probably not a bad idea.

It should be pointed out though that when success is achieved, there will be the files still in place, but hidden under the newly mounted /boot. So just be sure to go clean that up afterwords. It might seem at first like a good idea to leave them there just in case, but the moment there is a kernel update, that backup solution will be simply broken.

BTW, it has been a long time since I have used MBR partitioning, but it appears as though your extended/logical partitions are smack in the middle of the disk. Is this a legit things to do? I had always thought that it needed to be at the end of the disk… or is it the numbering that matters? I honestly don't acutlaly remember, but I just noticed that and it seemed questionable in my head.

Roken · 2013-09-03 17:09:16

WonderWoofy wrote:

Roken wrote:
personally, I'd cp, rather than mv /boot to /newboot. That way you have an easy fix if something goes wrong.
Meh, I'd mv because I laugh in the face of danger! But you are probably right that since the OP is struggling with the ideas behind making this change, a fallback is probably not a bad idea.

Me too, but this backup would only exist until the new /boot is shown to be working. Once that's done, the backup can be safely removed.

Trilby · 2013-09-03 17:37:44

I concur with the above - the cp then rm when all is set is definitely the better way to go.

clfarron4 · 2013-09-03 20:28:15

graysky wrote:

Why making /boot as ro in the fstab? Doesn't this mean you cannot write to it... makes updates a bitch.

I with graysky on this one.

As for cp + rm vs mv? Probably the first one.

WonderWoofy · 2013-09-03 20:31:27

Although mounting it read-only would indeed be a pain in the ass during upgrades, there is a security advantage I think. If you are really concerned about what might end up in your /boot directory, having a separate /boot would enable you to mount with nodev, nosuid, and noexec. But I'm not entirely sure what you think might end up in there.

Kotrfa · 2013-09-08 21:03:56

First in all, cp is definetely better. Edited.

WonderWoofy wrote:

Roken wrote:
personally, I'd cp, rather than mv /boot to /newboot. That way you have an easy fix if something goes wrong.
Meh, I'd mv because I laugh in the face of danger! But you are probably right that since the OP is struggling with the ideas behind making this change, a fallback is probably not a bad idea.
It should be pointed out though that when success is achieved, there will be the files still in place, but hidden under the newly mounted /boot. So just be sure to go clean that up afterwords. It might seem at first like a good idea to leave them there just in case, but the moment there is a kernel update, that backup solution will be simply broken.

BTW, it has been a long time since I have used MBR partitioning, but it appears as though your extended/logical partitions are smack in the middle of the disk. Is this a legit things to do? I had always thought that it needed to be at the end of the disk… or is it the numbering that matters? I honestly don't acutlaly remember, but I just noticed that and it seemed questionable in my head.

I'm confused - when I mount something_1 over something_2 and something_2 is ignored?

I've never heard about problems connected with logical partitions in the middle of the disc. Does anyone know any sources, where it can be assured?

WonderWoofy · 2013-09-08 21:23:47

You can make files disappear when you mount over them. A good example of when this is actually useful can be seen in the arch-chroot script. Instead of simply copying over the /etc/resolv.conf to <mountpiont>/etc/resolv.conf, it actually uses a bind mount. So the bind moutned resolv.conf takes effect, but does not wipe out a potentially used configuration on the chrooted system. So if you typically use a static IP, for example, the resolv.conf wouldn't be created dynamically and you would want to keep whatever is there. This is achieved with the bind mount.

I have heard of people doing things like moving something like /var or /home to a new partition or disk. They use rsync or tar or cp -a to copy the contents over, then set things up in theri fstab. Then they reboot and forget about all the stuff now hidden in the original /var or /home. Months later they cannot figure out why their df output is so seemingly far off.

Again, I have no idea bout the extended partition being in the middle. That is why I was asking, as I am totally unsure. I have been using GPT for a while now, and have not had any reason to have dealings with the old ms-dos partitioning.

clfarron4 · 2013-09-08 21:29:26

Kotrfa wrote:

I've never heard about problems connected with logical partitions in the middle of the disc. Does anyone know any sources, where it can be assured?

I've had no problems with my extended/logical partition being "in front" of primary partitions... Here's my partition table if you want to have a looksie.

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x0ad1d3bf

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      409599      203776    7  HPFS/NTFS/exFAT
/dev/sda2      1206865912  1945198394   369166241+   7  HPFS/NTFS/exFAT
/dev/sda3      1945202688  1953521663     4159488    c  W95 FAT32 (LBA)
/dev/sda4          417627  1206847487   603214930+   f  W95 Ext'd (LBA)
Partition 4 does not start on physical sector boundary.
/dev/sda5          417690    78541784    39062047+  83  Linux
Partition 5 does not start on physical sector boundary.
/dev/sda6        78541848  1165887487   543672820   83  Linux
/dev/sda7      1165889536  1206847487    20478976   83  Linux

Partition table entries are not in disk order

Last edited by clfarron4 (2013-09-08 21:32:57)

Arch Linux

#1 2013-09-02 07:55:59

Moving /boot to it's own partition

#2 2013-09-02 10:01:33

Re: Moving /boot to it's own partition

#3 2013-09-02 10:12:43

Re: Moving /boot to it's own partition

#4 2013-09-02 12:04:12

Re: Moving /boot to it's own partition

#5 2013-09-02 17:30:09

Re: Moving /boot to it's own partition

#6 2013-09-02 19:56:05

Re: Moving /boot to it's own partition

#7 2013-09-03 17:09:16

Re: Moving /boot to it's own partition

#8 2013-09-03 17:37:44

Re: Moving /boot to it's own partition

#9 2013-09-03 20:28:15

Re: Moving /boot to it's own partition

#10 2013-09-03 20:31:27

Re: Moving /boot to it's own partition

#11 2013-09-08 21:03:56

Re: Moving /boot to it's own partition

#12 2013-09-08 21:23:47

Re: Moving /boot to it's own partition

#13 2013-09-08 21:29:26

Re: Moving /boot to it's own partition

Board footer