Hi All,

I'm trying to change my root by using pivot_root on Ubuntu 16.04 LXDE.

What I did to follow the steps below.

1. mkdir /mnt/lower
2. mount -t ext4 /dev/mmcblk3p2 /mnt/lower
3. mkdir /mnt/rw/upper
4. mkdir /mnt/rw/work
5. mkdir /mnt/newroot
6. mount -t overlay -o lowerdir=/mnt/lower,upperdir=/mnt/rw/upper,workdir=/mnt/rw/work overlayfs-root /mnt/newroot
7. mkdir /mnt/newroot/ro
8. mkdir /newroot/rw
9. unshare -m
10. cd /mnt/newroot
11. pivot_root . mnt

All this command worked good so far.

I need my new root to mount on / as the new root and will always mount it after reboot the system.

And that's why I need to umount the original root form / first.

How can I do ?

Or have an other way to do it?

http://manpages.ubuntu.com/manpages/...ot_root.8.html

Might look at for more information.

I don't think you can mount the new root to the old root. Pivot root puts root directory in a different location. The old root directory remains mounted. It just isn't recognized as the root directory.

Thanks for the information.

I will try on the example that it had show in the website.

Is what you mean the second steps is wrong?

If it is than how can I get another root file system to change it?

I cannot really understanding you.

Can you explain it more specific?

What I mean is the root changes to a different location that the process sees as root.

When I run pivot_root the root changes to a different location to be the new root.

What you mean is the process sees it as old root or sees the authorize as root?

After I pivot_root to new root, I wanna start system service and desktop in the new root.

Is that possible to do it?

If can how can I do that?

i've never heard of switch_root

pivot_root(1) was/is the "newer preffered" way over chroot(1), although for my needs i continue to use chroot for temporary use because it's easier and "works" in typical "jail" type use

the link above leading to pivot_root , which is not the question you asked (you asked about switch_root) I find _annoying. #1 because ubuntu deleted your question in newbie (locked out responses) then tacitly answered your question by avoiding the question: giving you the manpage for a different command. without saying why the "new command" doesn't work, without telling you what the implications are.

the problem with chroot(1) was

"pivot_root(1) requires use of chroot(1). pivot_root moves old root "to a directory" before chroot is used" . this always confused me. it can't move root before chroot because the kernel has no disk if / has been "moved". when is it moved? is it accessible in the new or old root (meaning in the shell that does it, not system wide of course)

" pivot_root moves the root file system of the current process to the directory put_old and makes new_root the new root file system." . but that can be tamperous. how can something "move /" while a process still needs to USE / to execute the chroot(1) command? where does it go? how can it go there?

WHY NOT JUST MOUNT OLD ROOT inside the new root if and only if one wishes to access it in the new root? (note: as you'd expect, when you exit chroot, old root is resumed. so that also is not the issue)

"http://tiebing.blogspot.com/2014/02/linux-switchroot-vs-pivotroot-vs-chroot.html"

this china hacker says "switchroot moves /proc /mnt xxxx" switch_root moves already mounted /proc, /dev and /sys to newroot

but if your root does that, then this is WRONG. so depends on your chroot if you even want that done IF IT WORKS. who said it works?

--------------------------------------

your answer is this:

they are suggesting you use pivot_root (to do what isn't necessary), switch_root (to do what your / might do or can easily do - "mount -a" to mount proc), then also use chroot(1).

I would suggest using chroot(1) and doing all that bull only if you find a __need for more refinements (that are "in binaries" you didn't compile yourself, so for all you know: its' a virus binary).

--------------------------------------

possible hang-ups specific to UBUNTU, LFS (not xlfs, which isn't suggested) and some other linux, but not necessarily freebsd:

Your libraries in /lib. Ubuntu "keys" them so your libc cannot use chroot to switch them out. If your using /new to change libc during runtime: beware ubuntu doesn't want you to. they want you to use ONLY provided binary libs and not be able to switch to alternate ones during run-time.

IT IS CALLED "rpath", and what is does is this: libraries refuse to load unless they are in the path they are in /lib (or /usr/lib). because they are "already there" you can't put one there without CRASHING the system - plus it'd refuse to load anyway.

it was possible in older linux to get into a chroot, and from the chroot replace libs in the old / (do an ldconfig), then exit back. whala, lib replaced runtime. you could also just steer ldconfig to change path order. not allowed to do that anymore either. while that "protects you from naughty apps" (none that do it have ever been cited), it is one of many things that prevents you from "not using their libs exclusively". of course their libs are all version hacked so if you replace a lib and reboot: you might find yourself un-bootable. it means developers can test libs quickly, but END USERS are s crewed.

---------------------------------

what that all ads up to:

chroot in ubuntu if you have any working root (that works with your linux kernel version)

do not chroot in ubuntu if your trying to change libs runtime (you could in old linux, you can't now). you can run alternate libs inside the chroot, but cannot swap lib versions in the / you booted from.

really more complex isn't better

chroot(1) "just works"

pivot_root is broken, it doesn't work until you learn why it doesn't work, obstructing you

switch_root is broken, obstructing you again until you lean pivot_root until you learn chroot.

when you do learn all of that junk you find: you could have just done the mounting of (old root or /proc) by hand if needed, and kernel or libc asks you do to so with nifgy messages if you do somethign that requires it. on the other hand: it's NOT always required or wanted to do these things: sometimes it's the whole point NOT TO.

obstruction first is not a good "policy"

So let's be more practical. Say your not trying to replace a system lib or a broken crypto lib that was reported as having a bug in the new version.

Say your just dealing with X.org , your desktop. You can't replace a lib of an older or newer version graphic driver (without rebooting and possibly finding: you now can't even boot and need a whole rescue disk thing). let's just say you got a video hang, X won't load after an upgrade (typical ubuntu), and you just want to use that older video driver lib file.

Sure you could boot into a mini / that doesn't run X and then un X from inside a chroot as part of your boot scripts But ubuntu isn't going to help you there: is a "not supported" thing to be doing. It expects if not demands that your running xorg from the origiinal / you booted from and that / is the system you'll use as they provided it

so you end up where if they want to disable your video - your stuck, they have video you don't (not in any practical time span). you'd have to revert the whole OS, but that takes a long time and you can't stay there: since everthing depends on upgrading (support for anything new, bugfixes, etc).

your stuck. if they rip your video, your stuck, so sorry

now compare this to OLD slackware linux. you could replace even a system lib runtime without rebooting. X libs were never intertwined with system libs (ie crypto) so compilile/install X11 or switching X versions was not an issue to begin with.

this is like the difference between win95 and linux: win95 you had to pancake (reinstall) w95 frequently, while in linux you never _had to reboot, you were always up and never _forced_ to reboot for practically anything (except to change kernels, which was a feature added sometime later). newbies rebooted simply due to lack of experience.

in w95 you continually had to reboot for the wrong reasons also reinstall, "dll hell". in (older) linux / freebsd you never had to reboot for practically anything

Thanks for your reply!

Actually this page that I ask is based on pivot_root that I used.

The other thread is the question that I used switch_root!

I think this two commands were different so that's why I add two threads for pivot_root and switch_root.

For all these researches and tryings that I had done past two weeks just for the one purpose to replace overlayroot.

Why I do that?

Because even when I install overlayroot package and modify the overlayroot.conf to enable it, it still can not work with no debug message.

All the steps I did on the X86 based platform with Ubuntu 16.04 was worked fine but not worked on ARM based.

I just can not tell is overlayroot can just work with X86 or there is problem with my Ubuntu 16.04 LXDE.

That's why I need to do all the researches and try all the commands.


Based on overlayroot, it will mount the old root on /media/lower/ro as read-only file.

And mount the other place as tmpfs here /media/upper/rw.

After all these complete it will mount all these as overlay with this command Finally it will mount /media/newroot on / instead of the old root.

So If I change anythings inside the system it will not change your old root file but change it in tmps.

I tried to use pivot_root and sure which I asked in this thread.

But now I had stuck with pivot_root.

I just can't understand how did overlayroot do to replace old root on / and change all the file system to /media/newroot.

If chroot can do what overlayroot can do then it's fine to use it. I have no problem on this.

But the reason why I did not use because it cannot change all the things.

If I want my desktop and all the system service start on my new root, how can I suppose to do that?

Like you said if I'm doing all these things on the old root which mount on / .

How can it possible to remount / with other new root?

But for overlayroot it can!

I think chroot just can work on the console that you open, if you open another console out it will start with old root and I do not want it works like that.

I want it to work all on new root and not on the old root.

Can chroot do what overlayroot do?

Overlay root makes all changes to root to a different file system, so the system can run without writing to root.

Yes, I know how it works !

Let me reorganize the problem that I had dealing with.

This is what I want to do.

The old root filesystem which is mounted on / when the system first reboot and is located on /dev/mmcblk3p2.

And I wish to have the other overlay type root filesystem that mounted on / for instead.

For overlay type root filesystem I will need lowerdir which will mounted /dev/mmcblk3p2 on /mnt/lower with -o read-only and upperdir which will mounted tmpfs on /mnt/rw/upper.

This is what I will do to make new root filesystem.
What I want to do is to remounted /mnt/newroot on / for instead.

Previously I tried to do it with pivot_root but there still got problem that I can not really change the root filesystem.

The desktop and console and so on are all related to the old root filesytem and that makes me crazy.

I need to know is that possible to do it and how to do it ?