Thank you for the info, Bourdieu. I'll give this a try tonight to see if I can help the OP.

Unless you beat me to it.

Did this ever got solved? It seems relevant to my problem:

The firmware of my internal m4 mSATA SSD drive that has the slackware install on it needs upgrading and now I have to find a way to keep working when this drive is taken out. For that reason, I am trying to boot a uefi-system from an external hard drive (a 1 TB HGST Touro mobile pro drive).

I am using -current with refind installed, which I copied to a partitition on the external drive (labeled 'slack').

Booting works from an external usb-stick (from the usb-pxe-install folder) and the external usb hard drive and its efi-partition are also recognized (on the usb3 port, not the usb2) by refind. The computer boots ok but hangs in the same way as described above:
I checked other -very helpful- posts on using external hard drives:

booting-usb-hard-drive-on-uefi-machine-in-legacy-mode-4175525891/
trouble-booting-current-from-an-usb-hard-disk-kernel-3-10-14-a-4175479742/

I used this script for making the initrd.gz (which is copied to the EFI partition of the external usb hard drive)
The initrd.gz is loaded as cat /proc/modules shows that the mentioned modules are present.

lsblk (included by adding it to /bin in the initrd-tree and then rerunning mkinitrd by itself) shows all internal drives to be present but the external drive is not recognized.

/proc in / of the external drive is empty
/etc/fstab and /etc/mtab on the external drive
have the labels in there.
I've got the feeling that something, needed to point to the external drive, is missing but what and where???

Does anyone have a clue?? Thanks in advance....

BtrFS can't be detected by Grub-2.00 or later without a patch to force the older Grub-1.xx detection mode and algorithms. This is especially true if you use a GPT partition table.

Even if you use an ext2/3/4 /boot partition, the Grub configuration tool can not read the /dev node of the devtmpfs and will usually pop up an error, or it will detect the UUID but will fail to setup the device read commands properly.

I have a patch for Grub-2.02~beta2 in my Slackworks to restore Grub-1.xx legacy detection to allow a BtrFS filesystem to be readable by Grub-2.xx. Word of warning, it will not work with Grub-2.00 which is shipped with Slackware, it will require 2.02~beta2.

1 members found this post helpful.

Well, the problem I experience has nothing to do with btrfs or grub. They are not used. Booting is done with refind or elilo: both work from the internal drive; refind can boot an external usb flash-drive but with an external hard drive, this leads to: rootdev-not-found-by-sbin-init-from-initramfs. At that point the initrd has kicked in, as far as I understand, at this point the root is remounted rw but the drive with / is not found. How come? It was used during boot...

Did you assign the drive mapping via label or UUID?

Yes, I used LABEL= to assign the drive. In the mkinitrd that is. Refind uses UUID. But when I check the presence of drives with lsblk at the prompt when boot stalls, the external drive does not show at all (no /dev/sdc or /dev/sdd)... I added udev to the mkinitrd; does it need more, some rules or so?

Try setting it to UUID rather than label. Label only looks up the /dev node of the device if it exists in the system on the preset mountpoints. Because a USB drive is counted as a removable device, it will not have the same /dev node each boot, and devices on USB drives will not be static in the system. If you use a UUID mapping, the device's UUID code will be read rather than the /dev node and the drive will be properly assigned during boot.

Try using UUID in the initramfs/initrd and it might get it working. Do this in /etc/fstab also.

Static devices like SATA, IDE, SCSI, and SAS drives will work with labeling because the device node is static to that device. USB, eSATA, and Firewire devices must be set via their UUID code because the device is considered a dynamic device, or removable.

Hi, Thanks for the tip but it did not change a thing; the boot from the external drive stalls again after loading the initrd.gz with the message that /mnt cannot be found in /etc/fstab.

During my read up I understood that UUID and LABEL (As long as it is unique among all partitions present) would do the same thing, so this lack of result might not be surprising....

Something else is lacking from those initrds I make.....

Did you load the USB drivers into the initrd?

yes, cat /proc/modules at the boot prompt when the boot stalls displays the drivers I put in: usb-storage:xhci-hcd:ehci-hcd:ehci-pci:uhci-hcd:ehci-platform:ext4

Left field question, but does it boot with the default Huge kernel?

OK I made several folders in the ESP on my external drive to test different possiblities:
A) /EFI/BOOT as in the slackware64-current tree
B) /EFI/BOOT2 as in the boot.img provided in the usb-pxe-installers folder
C) /EFI/Slack-huge_b/ , containing a vmlinuz-huge-4.1.6, and initrd.gz (made with mkinitrd -c -k 4.1.6 -r /dev/sdb1 -o initrd-4.1.6-sdb1.gz, a refind-linux.conf with pointers to the internal mSATA drive /dev/sdb1 as root)
D) /EFI/Slack-huge_c/ with the same kernel but with initrd.gz and refind-linux.conf pointing to / on the external usb hard drive (=/dev/sdc7).

This is what I got:
1) with huge kernels from the two uefi-installers: i.e. from usb-pxe-folder or from EFI folder in slackware64-current:
-1a: both boot as if from usb-stick/DVD, into slackware setup
-1b: but when given the option , or when pointing to the internal drive with root (/dev/sdb1), booting ends with kernel-panic:
this kernel-panic is probably related to a wrong initrd.gz being loaded (see below, point 2a)

-1c: trying to evade setup and the huge.s from usb-pxe-folder, by loading the standard vmlinuz-huge-4.1.6 kernel using boot instructions
(i.e. directing to the internal /) works (when starting up from the external hard drive)
-1d: but the same gives above kernel-panic when directing to / on the external drive (root=/dev/sdc7).


2) booting using refind with the standard vmlinuz-huge-4.1.6 (from slackware64/a/kernel-huge-4.1.6.txz)
-2a: by itself from the internal ESP (/dev/sdb1): ends in the same kernel-panic. This because refind does not get enough info (it extracts from an initrd.gz)
-2b: but doing the same including an initrd.gz (for the root= and rootfs= info pointing to the internal /dev/sdb to make refind work): the computer boots.
-2c: also when booting from the ESP on the external hard drive (/dev/sdc) when pointing to the internal drive (/dev/sdb1) for / in the included initrd.gz and refind-linux-conf files, the computer boots fine.


3) Now the rescue-trial: boot to an external root (what I used to be able to do with lilo/MBR and fast eSATA connections when these were on laptops a while back):
-3a: doing the boot from 2c but now pointing to the / on the external hard drive (/dev/sdc7, as defined by edited initrd.gz and refind-linux.conf), ends with same error as when using the vmlinuz-generic-4.1.6 kernel with initrd.gz pointing to this drive as reported in the previous posts (no /mnt in /etc/fstab etc).

Before the above kernel-panic occurs: in all cases the partitions of both internal drives (/dev/sda and /dev/sdb) are recognized; the external (/dev/sdc) is never shown.


4) Btw, booting with the huge kernel from the usb-pxe-folder installer and directing this to / on the internal disk (/dev/sdb1) at the boot prompt:
goes, but X does not work (EE no screens found) although this is better than doing this with root=/dev/sdc7 as parameter, which gave above kernel panic)

So, things went the same as before with the generic kernel. It shows again that the external drive is not found/available as a device for /, which makes it impossible -it seems- to boot a Slackware system on an external drive using the above methods. I do not know whether this is is according to UEFI-specs but very unhelpful to try to get my internal mSATA repaired that contains the whole system.

I still have to try to do this after unplugging the mSATA (/dev/sdb1) and check whether the external drive is then suddenly used but somehow I doubt this will work.... It probably comes down to having to install slackware on the other internal hard drive but that does defies the idea: having a back-up system ready that can be used by just plugging in a usb-drive.

SWITCH USB port. It does not work on USB3, only on USB2!


First I found something very interesting, well it seemed so at the time,

https://bbs.archlinux.org/viewtopic.php?id=183190

This post mentioned a quirk with the exact kind of drive I have been using (Touro from HGST)

added a usb-storage.conf to /etc/modprobe.d/ with contents:
# https://bbs.archlinux.org/viewtopic.php?id=183190
# lsusb -v
# Bus 004 Device 003: ID 4971:1012 SimpleTech
## Device Descriptor:
## bLength 18
## bDescriptorType 1
## bcdUSB 3.00
## bDeviceClass 0 (Defined at Interface level)
## bDeviceSubClass 0
## bDeviceProtocol 0
## bMaxPacketSize0 9
## idVendor 0x4971 SimpleTech
## idProduct 0x1012
## bcdDevice 0.00
## iManufacturer 10 HGST
## iProduct 11 Touro Mobile Pro
## iSerial 3 21001311260002300213
## bNumConfigurations 1
#
options usb-storage quirks=0x4971:0x1012:u

made a new initrd.gz with /etc/modprobe.d/usb-storage.conf copied to /boot/initrd.tree/lib/modprobe.d/

but this did not make a difference.

What made it work was plugging the drive into a USB2 port; the USB3 port I used before did not support the procedure.
Pfui, ......

I suspect the initrd is missing the btrfs module and/or tools needed to initialize with...

Sure, something is missing, maybe the [SOLVED] tag