search order for the /porteus folder
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
Suppose I have multiple /porteus (and /porteux) folders on different partitions and disks
I'd like the booting process to find the right one in the following order:
1. All (adjacent) partitions on the current drive -- the drive which we're booting from
2. All partitions on other plugged in drives in whatever order
Is that the case already for both Porteus and PorteuX?
What I DON'T want is the search order to be simply: /mnt/sda*, /mnt/sdb*, /mnt/sdc* etc.
I'd like the booting process to find the right one in the following order:
1. All (adjacent) partitions on the current drive -- the drive which we're booting from
2. All partitions on other plugged in drives in whatever order
Is that the case already for both Porteus and PorteuX?
What I DON'T want is the search order to be simply: /mnt/sda*, /mnt/sdb*, /mnt/sdc* etc.
search order for the /porteus folder
On PorteuX if you run the installer for Linux it will create an UUID in the storage initrd, and that will be used during boot time to try to boot from this unit first (including all partitions).
I couldn't find any other way to identify the booting unit during initrd time, which is the moment we look for the base modules. If you find a better approach, I'll be happy to use it.
I couldn't find any other way to identify the booting unit during initrd time, which is the moment we look for the base modules. If you find a better approach, I'll be happy to use it.
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
Thanks I don't run any installers though. In my case a simple grub loader in the /EFI folder loads vmlinuz/initrd passing a from-label cheatcode. But even without that cheatcode the /porteus folder is somehow found anyway! The question is how. I'm going to have to look into initrd myself to find out. I'm preparing for multiple /porteus folders scenario and need to know the search logic. I don't want to use any UUID, LABEL etc., nor any other "from" cheatcode.
- Ed_P
- Contributor
- Posts: 8578
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
search order for the /porteus folder
I use grub2 to boot my porteus/x USB systems and in the grub2 boot menu I use Search to find a file on the drive and set Root to the drive's address.
I've also used:
search -f /edsdrv.txt --set=root
Code: Select all
set bootmgr=/EFI/boot/bootx64.efi #grubx64.efi # bootx64.efi
set bootdrv=$root
search -f $bootmgr --set=root
echo bootmgr: $bootmgr
sleep -v -i 3
if [ $root != $bootdrv ]; then
chainloader $bootmgr
else
echo "----------------------------------------"
echo USB drive NOT found.
echo
sleep -v -i 10
fi
set root=$bootdrv
-or-
set porteus_parms="volume=33 reboot=cold extramod=/Modules"
set bootdrv=$root
search -f /boot/syslinux/vmlinuz --set=root
if [ $root != $bootdrv ]; then
linux /boot/syslinux/vmlinuz $porteus_parms
initrd /boot/syslinux/initrd.xz
else
echo "----------------------------------------"
echo USB drive NOT found.
echo
sleep -v -i 10
fi
set root=$bootdrv
}
search -f /edsdrv.txt --set=root
search order for the /porteus folder
I'm afraid there's no generic/agnostic way to do that.
During initrd time there's no way to know which unit it was loaded from. Putting UUID either inside initrd or in porteu[s/x].cfg seems to be the only way. If you find another way, that would be genious and we would be forever grateful, really
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
Anyway, it is the linuxrc that finds the /porteus folder (aka the location of the porteus-...cfg file and the location of the /porteus/changes) even without any "from" cheatcode. The question is how it chooses the right /porteus folder when there are more than one of those!?
Could you help me with my experiment below? My porteus USB is always recognized as /dev/sdb, but I now have an identical grub loader on my /dev/sda drive which happens to be the system static SSD disk. At boot, in the UEFI menu I choose to boot the grub from /mnt/sda1/EFI. It "successfully" finds the porteus folder on /mnt/sdb2! Actually, it's hard to make it forget that location!
I don't want to unplug the USB yet. Instead I want the initrd to start finding a new, fresh porteus on /mnt/sda2. A simple /mnt2/sda2/porteus folder with the porteus-...cfg file, with properly populated /mnt/sda2/porteus/base, and an empty /mnt/sda2/porteus/changes still aren't enough: initrd even though loaded off /mnt/sda1 is still finding and using the /mnt/sdb2/porteus! Why?! What's so special about that copy of /porteus Maybe initrd favours USB drives over static disks? Or does it favor "b" over "a"?
search order for the /porteus folder
It lists the available units using ls /mnt | tac and search in this order. In this case tac will revert the lines that normal ls outputs, and because portable units are usually in the end, by using tac we are most likely booting over portable units, which makes sense given the portable characteristics of the system.
Of course you can change that to be in any order you want, but as I said, there's no way to determine which unit initrd is booting from.
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
OK then. We're going to have to help initrd find the right /porteus. After all we know the right one. In my case different /porteus folders live on differently Labelled partitions. So, even if my frugal sda installation will be a copy of my sdb (USB) installation, there will be at least one difference. Let's make /mnt/sda1/local.cfg and /mnt/sdb1/local.cfg with respectively:
and
then inside both grub.cfg we have the same lines, for example:
So no need for either initrd or grub to introspect where they're loading from: the user would have edited the local.cfg with the right Labels in each installation
Code: Select all
set PorteusLabel=PorteuSX
set PorteuXLabel=PorteuSX
Code: Select all
set PorteusLabel=PorteusUSB
set PorteuXLabel=PorteuXUSB
Code: Select all
#get local PorteusLabel, PorteuXLabel
source /local.cfg
menuentry 'Porteus 1920x1080' {
linux /boot/vmlinuz from=LABEL:$PorteusLabel changes=EXIT:/porteus login=root load=1920x1080 fsck
initrd /boot/initrd.zst
}
-
- Contributor
- Posts: 678
- Joined: 26 Jun 2013, 14:03
- Distribution: x64 Openbox
- Location: Russia is causing the immense damage to humanity
- Contact:
search order for the /porteus folder
Thomas M added from=ask cheatcode, see:
https://github.com/Tomas-M/linux-live/c ... c1ba9b47ff
https://github.com/Tomas-M/linux-live/c ... c1ba9b47ff
You have mind and feelings. Be wise and clever.
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
OK. I've made identical installations of my PorteusUSB and Porteus-labeled internal disk (let's call it the frugal installation).
When the USB is NOT plugged I can run the frugal Porteus no problem!
Now I plug the PorteusUSB. Again, from the UEFI BIOS menu I choose the correct grub EFI bootloader that lives on the internal (always identified as sda1) FAT32 partition and has in the local grab.cfg:
However, this time, the presence of sdb makes initrd confused trying to find the right porteus folder, I think:
After I press Enter it then finds and loads porteus from /mnt/sdb3/ instead of /mnt/sda5 !!
Even though we still have:
Looking at that section (?) in initrd/linuxrc I don't see any sh/mkdir/rm commands at all:
Could someone please help me understand this mystery? Which code and where tries to still work with sdb USB when I try my best to point everything at sda internal disk?
When the USB is NOT plugged I can run the frugal Porteus no problem!
Now I plug the PorteusUSB. Again, from the UEFI BIOS menu I choose the correct grub EFI bootloader that lives on the internal (always identified as sda1) FAT32 partition and has in the local grab.cfg:
I see the right grub menu then, using the above grub.cfg, I'm quite sure.from=LABEL:Porteus
However, this time, the presence of sdb makes initrd confused trying to find the right porteus folder, I think:
After I press Enter it then finds and loads porteus from /mnt/sdb3/ instead of /mnt/sda5 !!
Even though we still have:
Code: Select all
root@porteus:~# echo $from
LABEL:Porteus
root@porteus:~# blkid -s LABEL -o value /dev/sdb3
PorteusUSB
root@porteus:~# blkid -s LABEL -o value /dev/sda5
Porteus
Code: Select all
# Find *.cfg file:
echo $i"searching for $CFG file"
if [ $IP ]; then BOOTDEV=network; CFGDEV=/mnt/nfs
for x in `lspci | grep 0200: | cut -d: -f3-4 | sed s/:/.*/g | tr a-z A-Z`; do modprobe `grep $x /lib/modules/$(uname -r)/modules.alias | tail -n1 | rev | cut -d" " -f1 | rev` 2>/dev/null; done
ls /sys/class/net | grep -q eth || { for x in `find /lib/modules/$(uname -r)/kernel/drivers/net -name "*.ko" | sed 's/.ko//g'`; do modprobe `basename $x` 2>/dev/null; ls /sys/class/net | grep -q eth && break || modprobe -r `basename $x` 2>/dev/null; done; }
mkdir -p /mnt/nfs/porteus /mnt/nfs/storage; udhcpc; modprobe nfsv4; mount -t nfs4 $IP:/srv/pxe/porteus /mnt/nfs/porteus -o ro,nolock 2>/dev/null || { modprobe nfsv3; mount -t nfs $IP:/srv/pxe/porteus /mnt/nfs/porteus -o ro,nolock 2>/dev/null; }
MAC=`ifconfig | grep eth0 | cut -d: -f5-7 | sed s/://g | cut -d" " -f1`
if [ "$CHANGES" = /srv/pxe/storage ]; then
if lsmod | grep -q nfsv3; then
mount -t nfs $IP:/srv/pxe/storage /mnt/nfs/storage -o rw,nolock 2>/dev/null && { mkdir -p /mnt/nfs/storage/client-$MAC/changes/home; CHANGES="/storage/client-$MAC"; }
else
mount -t nfs4 $IP:/srv/pxe/storage /mnt/nfs/storage -o rw,nolock 2>/dev/null && { mkdir -p /mnt/nfs/storage/client-$MAC/changes/home; CHANGES="/storage/client-$MAC"; }
fi
fi
elif [ $ISO ]; then CFGDEV=/mnt/isoloop
locate -e $FROM && { BOOTDEV=/mnt/$DEV; mkdir /mnt/isoloop; mount -o loop /mnt/$DEV/$LPTH /mnt/isoloop; ISOSRC=/mnt/$DEV/$LPTH; }
else
if [ $FROM ]; then
locate -e $FROM/porteus/$CFG
if [ $? -eq 0 ]; then
DIR=`echo $LPTH | rev | cut -d/ -f3- | rev`; [ $DIR ] && FOLDER=$DIR/porteus
else
echo -e "${YELLOW}from= cheatcode is incorrect, press enter to search through all devices${RST}"
read -s; search -e porteus/$CFG
fi
else
search -e porteus/$CFG || lazy -e porteus/$CFG
fi
CFGDEV=/mnt/$DEV
fi
search order for the /porteus folder
If not mistaken what you want.Suppose I have multiple /porteus (and /porteux) folders on different partitions and disks
My system is multiboot, I can boot porteus/porteux as many I want in the same partition or many partition(s) on internal and/or external media.
Boot parameter is absolute necessary. Porteus/porteux must be in subfolder like P1...Pn/porteus or Px1...Pxn/porteux. Have fun!
- Ed_P
- Contributor
- Posts: 8578
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
search order for the /porteus folder
When booting with multiple systems present I find the use of UUID works best.
Code: Select all
APPEND changes=EXIT:UUID:C23A-6012/changes/50save.dat extramod=UUID:C23A-6012/Modules
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
OK, thanks, I should try it then. But in theory, from:LABEL should work too!
The above section of initrd/linuxrc calls the locate() function defined in the initrd/finit:
Code: Select all
# Find location of Porteus files
locate() { LPATH=`echo $2 | cut -b-5 | sed s@/dev@/mnt@`
if [ $LPATH = /mnt/ ]; then
DEV=`echo $2 | cut -d/ -f3`; LPTH=`echo $2 | cut -d/ -f4-`; SLEEP=6
while [ $SLEEP -gt 0 -a ! -b /dev/$DEV ]; do nap; let SLEEP=SLEEP-1; fstab; done
[ -d /mnt/$DEV ] || mount_device $DEV
[ $1 /mnt/$DEV/$LPTH ]
elif [ $LPATH = UUID: -o $LPATH = LABEL ]; then
ID=`echo $2 | cut -d: -f2 | cut -d/ -f1`; LPTH=`echo $2 | cut -d/ -f2-`; DEV=`blkid | grep $ID | cut -d: -f1 | cut -d/ -f3`; SLEEP=6
while [ $SLEEP -gt 0 -a "$DEV" = "" ]; do nap; let SLEEP=SLEEP-1; fstab; DEV=`blkid | grep $ID | cut -d: -f1 | cut -d/ -f3`; done
[ -d /mnt/$DEV ] || mount_device $DEV
[ $1 /mnt/$DEV/$LPTH ]
else
LPTH=$2; search $* || lazy $*
fi }
We did establish earlier that we have to help initrd find the right porteus folder, on the correct partition. I thought differentiating them by different labels would be best, so I have
Code: Select all
linux /boot/vmlinuz from=LABEL:Porteus
- ncmprhnsbl
- DEV Team
- Posts: 4098
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
search order for the /porteus folder
just quickly skimming through this topic, am i correct that your two labels are Porteus and PorteusUSB ?
in this case simple grep won't differentiate if the target is Porteus .. the other way around should be ok..
eg.so using grep -w might be the way
in this case simple grep won't differentiate if the target is Porteus .. the other way around should be ok..
eg.
Code: Select all
$ echo -e "Porteus\nPorteusUSB" > test
$ cat test
Porteus
PorteusUSB
$ grep Porteus test
Porteus
PorteusUSB
$ grep PorteusUSB test
PorteusUSB
## -w, --word-regexp match only whole words
$ grep -w Porteus test
Porteus
Code: Select all
ID=`echo $2 | cut -d: -f2 | cut -d/ -f1`; LPTH=`echo $2 | cut -d/ -f2-`; DEV=`blkid | grep -w $ID | cut -d: -f1 | cut -d/ -f3`; SLEEP=6
while [ $SLEEP -gt 0 -a "$DEV" = "" ]; do nap; let SLEEP=SLEEP-1; fstab; DEV=`blkid | grep -w $ID | cut -d: -f1 | cut -d/ -f3`; done
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
-
- Warlord
- Posts: 718
- Joined: 04 Jan 2014, 04:27
- Distribution: Porteus 5.0 x64 OpenBox
- Location: NZ
- Contact:
search order for the /porteus folder
Oh that's so funny Yes, the crazy thought of trying different labels did cross my mind. I thought it was too childish though. Thanks for spotting it! Well done! I've relabeled the internal Porteus partition to PortInt, so that I now have "PortInt" and "PorteusUSB" -- 2 words that aren't substrings of the other. But, it is a bug, would you agree Would you fix it maybe in the next version of initrd, please?