71–80 of 80 posts
Earlier quoted context omitted.
Pretty sure the conflation has been around ever since rocket science and brain surgery have been used as a comparison. :)
I don't tend to link youtube videos on HN, particularly of the comedic type, but I'm just going to leave this here for anyone who wants a good laugh for their morning. https://www.youtube.com/watch?v=THNPmhBl-8I
Earlier quoted context omitted.
Something like this has been my default way of installing Linux for years - and I've installed Debian, Ubuntu (with debootstrap), Gentoo and Arch this way. Typically I just create another partition to my LVM volume group, chroot and install over there and then reboot without removing the old OS install and I run the install procedure from the old OS (instead of booting from a Live CD / usb stick). I do this because I…
You really only need two (kernel and initrd/initramfs), at least to get into a basic running state. This requires building your own initrd, of course, but it's pretty common in non-graphical Linux installers (Slackware's install media still does this, IIRC). I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.
This choice creates a very nice upgrade-management strategy for CoreOS clusters: rather than letting each machine have its own boot partition and asynchronously downloading updates into it, you can just stand up a PXE server to serve the current CoreOS kernel+initramfs and tell your machines to boot from that. Now the entire OS (~200MB) is streamed to each machine on boot; to "update" a machine, you just reboot it. (And, unlike a shared NFS/iSCSI rootfs disk server, you don't have to be careful when updating to tiptoe around the machines that haven't rebooted yet; they just stay happily on the old OS until you kick them over.)
As an added benefit, if the programs you're running on those CoreOS nodes don't need any persistent storage either (i.e. they're not database nodes), then they can be entirely diskless, and just let the rootfs tmpfs hold everything.
Another nice trick of this family (with reboots, or without with using systemd-nspawn) lies with clever btrfs usage. Long story short: * use btrfs, and create your main root filesystem as a btrfs partition subvolume and another btrfs subvolume for snapshots (also a sub of master btrfs partition) * to start any experiment (e.g. installing whole gnome and 500 different packages you MIGHT WANT TO REVERT in the future) c…
Congratulations, you've reinvented ZFS Boot Environments :)
Earlier quoted context omitted.
I recommend to copy a rescue disk iso image or/and network installation image to boot partition and add it to GRUB menu. This way it is possible to boot into working environment without risk to damage root partition. https://wiki.archlinux.org/index.php/Multiboot_USB_drive
That usually doesn't work for remote servers because you can't access the grub menu over SSH and you want something that works even in those cases that grub or your boot record are trashed. So you just want to do a netboot from a generic rescue iso. Zero dependencies. Works even when your hard drives are severely damaged and you just need to /bin/dd some raw sectors.
Depends on your environment. My hosting company offers a remote console you can enable that gives access to a virtual serial console via SSH; with that, you can access your bootloader.
Earlier quoted context omitted.
You really only need two (kernel and initrd/initramfs), at least to get into a basic running state. This requires building your own initrd, of course, but it's pretty common in non-graphical Linux installers (Slackware's install media still does this, IIRC). I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.
Yes, it's a fun exercise to build a tiny Linux install that's fully on the initrd. Not that you'd want to have that kind of system in daily use outside of special applications. > I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that. Yes, the kernel config has an option to embed the initrd in the kernel image. I'm not sure if there are any advantages to th…
Earlier quoted context omitted.
How most sane distros do it. Build a kernel with the most common hardware built into it, and use that to bootstrap. No need for messy things like balled up temporary rootfs in a ram drive. Initrd/initramfs have become an excuse for piling on complexities that frankly should be added by the sysadmin after initial install.
The purpose of the initrd to have the initrd bootstrap to rootfs. This involves userspace tools like mdadm, lvm2, cryptsetup, zfsprogs, etc. It's not very common to need kernel modules (drivers) on initrd on typical hardware.
You can of course accomplish similar things by just recompiling the kernel (which Slackware makes very easy to do), but if you still need to use 'mkinitrd' anyway (perhaps because you're using LVM or softraid or LUKS), it's often more convenient to just throw in the modules you need while you're at it.
Earlier quoted context omitted.
You really only need two (kernel and initrd/initramfs), at least to get into a basic running state. This requires building your own initrd, of course, but it's pretty common in non-graphical Linux installers (Slackware's install media still does this, IIRC). I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.
Yes, it's a fun exercise to build a tiny Linux install that's fully on the initrd. Not that you'd want to have that kind of system in daily use outside of special applications. > I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that. Yes, the kernel config has an option to embed the initrd in the kernel image. I'm not sure if there are any advantages to th…
This comes to mind: http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-l...
Earlier quoted context omitted.
You really only need two (kernel and initrd/initramfs), at least to get into a basic running state. This requires building your own initrd, of course, but it's pretty common in non-graphical Linux installers (Slackware's install media still does this, IIRC). I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.
Yes, it's a fun exercise to build a tiny Linux install that's fully on the initrd. Not that you'd want to have that kind of system in daily use outside of special applications. > I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that. Yes, the kernel config has an option to embed the initrd in the kernel image. I'm not sure if there are any advantages to th…
Earlier quoted context omitted.
Haha yes, this is the default install procedure for Gentoo! :D
Something like this has been my default way of installing Linux for years - and I've installed Debian, Ubuntu (with debootstrap), Gentoo and Arch this way. Typically I just create another partition to my LVM volume group, chroot and install over there and then reboot without removing the old OS install and I run the install procedure from the old OS (instead of booting from a Live CD / usb stick). I do this because I…
And networking, fully functional networking.
If you've missed out the FW packages for your wifi drivers, you will have a hard time using your package manager to get those missing bits ;)
Probably not an issue for servers, but for those who'd like to do "complex" desktop/laptop install with ZFS/btrfs roots or whatever, it's an easy mistake to make.
Earlier quoted context omitted.
How most sane distros do it. Build a kernel with the most common hardware built into it, and use that to bootstrap. No need for messy things like balled up temporary rootfs in a ram drive. Initrd/initramfs have become an excuse for piling on complexities that frankly should be added by the sysadmin after initial install.
The purpose of the initrd to have the initrd bootstrap to rootfs. This involves userspace tools like mdadm, lvm2, cryptsetup, zfsprogs, etc. It's not very common to need kernel modules (drivers) on initrd on typical hardware.