On 02/15/2016 06:42 PM, Mike Wright wrote: > Does the boot process leave any footprints behind telling where it > booted from? Don't know if you have legacy grub or not. With legacy grub, you can change the names in menu.lst--put a 1 or 2 or whatever after the description, and when you start up, the display will let you choose which is which. Your display at boot time will look like: Fedora 1 Fedora 2 Fedora 3 Windows Mint

On 02/15/2016 03:42 PM, Mike Wright wrote: > Does the boot process leave any footprints behind telling where it > booted from? > You can always "cat /proc/cmdline" to see what the boot command line was. In my case: [root@prophead ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.3.4-200.fc22.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8 So it booted the 4.3.4-200.fc22.x86_64 kernel (yes, this machine is still F22) and the current /dev/mapper/fedora-root is the root of my filesystem. Digging a bit more: [root@prophead ~]# ls -l /dev/mapper/fedora-root lrwxrwxrwx. 1 root root 7 Feb 1 15:09 /dev/mapper/fedora-root -> ../dm-1 [root@prophead ~]# ls -l /dev/dm-1 brw-rw----. 1 root disk 253, 1 Feb 1 15:09 /dev/dm-1 So, /dev/mapper/fedora-root is is /dev/dm-1 or device major 253, minor 1. Dig a bit deeper: [root@prophead ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 931G 0 part ├─fedora-swap 253:0 0 15.6G 0 lvm [SWAP] ├─fedora-root 253:1 0 606.8G 0 lvm / ├─fedora-home 253:2 0 293G 0 lvm /home └─fedora-tmp 253:3 0 15.6G 0 lvm /tmp sdb 8:16 0 465.8G 0 disk └─sdb1 8:17 0 465.8G 0 part /media/500GB-Drive sr0 11:0 1 2K 0 rom So you can see my boot partition is a plain-old partition on /dev/sda1 and the root filesystem (block device 253:1) is a Linux LVM living on /dev/sda2. Does that help any?

I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it

Does the boot process leave any footprints behind telling where it booted from?

Hi everybody, I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.

At the GRUB menu, type pager=1 set Look for variable 'prefix=' this will be drive, partition, and path, to the GRUB directory where its cfg and modules are found.

On 02/16/2016 08:15 AM, Chris Murphy wrote: > At the GRUB menu, type > > pager=1 > set > > Look for variable 'prefix=' this will be drive, partition, and path, to > the GRUB directory where its cfg and modules are found. All right Chris! While at the boot prompt I have no access to anything and had forgotten the "pager=1" bit so after getting into grub> it was hit or miss with huge text overflowing the screen. By habit I typed ls and don't know if what it did was what I expected but near the bottom of the screen was the prefix= line. Ahhh, serendipity. I copied, with pencil and paper, the 102 character string, cursing the entire time the genius behind this madness, and rebooted. A portion of that string, reformatted without slashes and hyphens, was located in one of /dev/disk/by-id's 107 entries and which turned out to be a sym-link to dm-16. dm-16 was claimed by a sym-link in /dev/mapper. (Editors comment: this crap could only have been created by somebody with a cast of thousands and an unlimited budget and would have gotten an "F" at the Oscars.) And there was a recognizable quatrain of stanzas minus any commenting other than the title. After editing and changing the module lines to refer to the current kernel (when booting Xen kernels and initrds are modules) I rebooted and... WTF? the original unmodified boot page. So apparently grub.cfg is ?compiled? into some other secret location know only to the bootloader. I have the sinking feeling I have to run some grub2 magic spell to get the modified boot file into wherever it goes but am loathe to try anything. The reason I have a stripped down grub.cfg is because the last one generated for me was pushing 200K and the boot lines in each stanza had, so help me, nineteen swap files included in each one. Now the question: Is there a command that will take my simplified grub.cfg and install it without modifying it in any way and leave me with a bootable system? (please please please say yes).

In GRUB legacy, if you get the boot menu displayed, type "c" to get a "grub>" command prompt, then you can enter the command "root" and see which BIOS drive and partition is being used.

Allegedly, on or about 15 February 2016, Mike Wright sent: > I have several large disks filled with experiments and multiboots... Once you sort this out, you want to plan how you do multiboots in the future. Way back when I tried it, and even two is a pain, one good solution was to make your own custom boot partition, and all it did was let you select which partition to boot, it chainloaded the next one.

Whatever the /next/ one was, is a Fedora install with its own boot partition. Whenever that installation does any kernel updates, it only touches files in its own /boot. Likewise, the alternative /next/ thing to boot, was a CentOS install, with its own boot partition. And whenever it does any kernel updates, it only messes with file in its own /boot. I treated new installations as if they were a complete new hard drive to themselves, whether that's actually the case (and dedicating a whole drive to an OS tends to be easier), or whether I was halving a drive between two OSs, but still acting as if each OS was the only drive in the box.

Other people eschew multibooting for running virtual machines. In essence, you have a container that pretends its the hard drive for a machine. Everything that instance does to itself, is all within that container. I've since reclaimed my sanity by not multibooting. I use more than one computer. Much more precise division between things that way.

Tim: >> Once you sort this out, you want to plan how you do multiboots in the >> future. Way back when I tried it, and even two is a pain, one good >> solution was to make your own custom boot partition, and all it did was >> let you select which partition to boot, it chainloaded the next one. Mike Wright > That sounds like the ideal approach for what I do. Do you have an > example of that you'd be willing to share? I've never used chain > loading and have only seen it referenced on this list. Back in the old GRUB 1 days, that was easy enough. And I suppose you could install a version 1 bootloader onto a single /your/ boot partition. It'd be left alone by your installs. This is from a very old system, which had an entry to chainload from a floppy disk. By using a hd0 instead of fd0 entry, or whatever drive and partition number pertained to the partition that you wanted to boot, you could chainload to another hard drive: title Fedora Core (2.6.17-1.2142_FC4) root (hd0,0) kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=LABEL=/ acpi=force initrd /initrd-2.6.17-1.2142_FC4.img title Boot from floppy disk drive lock rootnoverify (fd0) chainloader +1 'twas as simple as that. I'm far from impressed by the incomprehensible mess that GRUB 2 is. > I use a very similar approach. Since a lot of my installs are intended > to be run in a custom Xen environment they can't even single boot but I > still need the kernels and initrds to copy elsewhere. The problems > arise when the installer does what it thinks is best for me and starts > screwing with my LVM setup or goes scarfing through all my disks > creating boot stanzas for installations that are incapable of standalone > boots. Gets really big and really ugly really fast. I have had much > better luck with Ubuntu installers. I think there were options to not probe for other systems. But I haven't done an install for ages. Of course, if you're going to dedicate an entire hard drive to an installation, the simple solution is to unplug the others while installing. Or, disable their port in the BIOS, temporarily, so they're not found. Personally, I favoured dedicating whole drives to an install, rather than partition. There's a few advantages: More space for it to use. Very easy to unplug to disable, archive, or transfer. Since I don't install bi-annually, I used to get a new drive for a new install, and try it out independent from prior installs, with it as the sole drive. If it hoses anything, it only does itself. The old drive gets connected, later, data copied over, and the old drive left as an archive. I never seemed to get a collection of un-used drives, though. It's never long before one gets put into a completely new box, or replaces another drive that's knackered.

Allegedly, on or about 17 February 2016, g sent: > gone are the 'good old days' of boxes 4 and 5 5" drive bays where one > could install install 3" drives in removable drive carriers and swap > drives. Yet computer cases are still ridiculously huge... Most PC cases that I see on sale tend to be desktop towers, with an array of internal bays. And, thankfully, these days they face out sideways, so you don't have to try and manoeuvre a drive out over the top of the motherboard, between the cards, and through the cables.