@Videonauth Actually, what about just moving the stuff about mounting /boot down into the footnote with the stuff about mounting /dev/, /dev/pts, /proc, and /sys?
I'll reread the answer first to make sure I still think it makes sense, then I'll do the edit if I think it does. I'm not sure how soon I'll get to it, though.
> An error occurred during a connection to www.gnu.org. The OCSP server has refused this request as unauthorised. Error code: SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST
@EliahKagan no, it doesn't heat up a lot :) It's very cool and quiet and nice to use. But I call it a toaster because in one of his PM's to me harryharryharry said something like
> I totally recommend installing Arch, on any device that will run it better than the X205TA. Like, your toaster
@Videonauth I think it does make sense to have those as separate footnotes. But now it is back to asserting that it's necessary to mount /boot in order to reset a password.
No, it is still not needed. You never need to mount a separate /boot partition to reset user passwords. Neither passwords nor the commands used to reset them are ever stored on a separate /boot partition.
If you install, remove, or update kernels or GRUB, /boot needs to be mounted if it is a separate partition. Besides for booting the system, that's pretty much it. You could really remove the stuff about /boot entirely... but you had seemed to want to include it in the post in some way. It is definitely not needed to reset passwords, though.
well it was simply the way i tested it, and i tend to give chroot everything it needs. but then I'm someone who tends to do other things then too if i just chroot into a machine, like checking if its up to date with its software etcetc
What do you mean by "everything it needs"? For example, you didn't set up locales in the chroot. Isn't that necessary for a number of operations, including package management? Guides for chrooting to use the package manager usually advise running something like export LC_ALL=C inside the chroot before proceeding. When you use a chroot, you can choose how much like a booted, running system you want to make it.
If you go all the way, you really are running the system, i.e., you perform a transition analogous to the one is performed during boot when the system going from the initial ramdisk into a normal running system, all the virtual consoles are created and managed from inside the chroot, if a display server is running then it is running only inside the chroot, all daemons except kernel services are started from inside the chroot, and so forth.
Yes, though that's sort of less "all the way" than if you simulate a full boot. That is, you can go even further than that and actually run init in the chroot. (I think it would be hard to manage this except by chrooting from the initial ramdisk, though.)
and well on a established system copying hosts and resolv.conf is not binding neccesary becasue the files it has from a previous booted state are fine, resolv.conf might cause only errors if the information has changed in the actual session
if you want a longer read : videonauth.dyndns.org/index.php/2016/05/26/… and its still being worked on. for example at the moment im trying to figure out the EFI way of making this work
My point, though, is that anytime anyone ever uses a chroot, they are making decisions about how to set it up, or they are following decisions someone else has made (which is fine--I am not objecting to that). There is no one way to do it that always works or is always reasonable. So, personally, I don't think it makes sense to mount extra stuff unless you are doing something in the chroot where that stuff is necessary or useful.
@Videonauth Thanks -- that's cool!
Does that procedure work for creating a Knoppix system that is installed on disk?
nice catch tho, it might work, just to figure out how to debootstrap from there
That article begun here on AU btw sometime back but still i hate the question the OP made from this so much that i begun to extend it and put it on my blog
It's been a while since I've used Knoppix. I do remember installing software with apt-get in the live environment, though. I don't mean with persistence; it went away on shutdown. What I'm not sure about is if that repo is just for that, or if it is also possible to build a whole Knoppix system from that repo.
and if you have gone through this ultra long question which answers itself practically youre less inclined to read through the answer again just parroting the question? or?
@EliahKagan i would have done that too already but i guess only the room owner can do that