0

I am trying to install fedora on a flash drive and then boot off of it from a pc that is not especially accessible. I tried setting every thing to by label to get past the uuid issue. I got it to the error message of no /dev/disk/by-label/... looked and dracut did not have a /dev/disk/ by-label or the raw disk nodes /dev/sda1 Any suggestions on how to bring the label option back in to dracut would be appriciated. I suspect its adding/forcing a module load or something for the dracut rebuild but havent found helpfull informatinon in that area yet.

Having the ability to boot from an internal flash drive instead of a more costly ssd is what I am hoping for speed isn't as much an intrest as no moving parts...

Kendrick
  • 601
  • 1
  • 6
  • 17

1 Answers1

1

You need to include the usb storage drivers in the initramfs (dracut). It depends on the type of your controller. For modern computers you probably want xhci-pci, ehci-pci, uas and their depenencies (e.g. xhci-hcd, ehci-hcd, usb-storage...which I assume dracut would pull automatically?)

Tom Yan
  • 9,075
  • 2
  • 17
  • 36
  • Btw I am not sure what "uuid issue" you are talking about. But FWIW, there is nothing wrong with using UUID to locate any kind of drive. I hope you are not talking about the wrong idea mentioned by some silly guy on youtube that UUID isn't really supported in Linux or whatsoever. LABEL is fine to use as well if you have set LABEL for the root filesystem. Don't mix up UUID/PARTUUID and LABEL/PARTLABEL though. – Tom Yan Feb 07 '16 at 15:38
  • fedora22 recognzes flash drives but is set to install around UUID of partitions. those uuid's are "secure" aka don't port to another machine making a portable flash drive boot useless. i need /dev/sda1 back in the options of boot but i have not been able to find out how to add label or partition back in to dracut based boot images. I have tried mirroring what was done in centos7 as it IS portable by default and uses /dev/sda1 by default. – Kendrick Feb 10 '16 at 01:08
  • 1
    "secure"? what are you talking about? fs uuid stays persistent as long as the filesystem is intact (i.e. as long as you don't reformat the partition with mkfs.*). on the contrary, /dev/sdX is not gonna be persistent. for example, you usb drive might appears to be sda on machine A and appears to be sdb on machine B (actually, it can change among boots on the same machine). also it doesn't have much to do with dracut, but the root= kernel param of your bootloader entry. – Tom Yan Feb 10 '16 at 18:49
  • consistant on THAT pc alone. it uses information from bios/pci/etc... sources inside the pc that you boot from to generate the UUID. its like a finger print. even if you stick a ring on another persons finger that finger print is still the same on each seperate persons hand. i can take screen shots to prove that building a fc22 image in a vm on a flash drive dos not work due to uuid changing between systems. It seems they are using it like microsoft does the secure boot stuff. – Kendrick Feb 11 '16 at 13:31
  • 1
    You simply have a wrong idea about UUID. It's simply randomly generated upon mkfs and stored on the header of the filesystem. – Tom Yan Feb 11 '16 at 17:02
  • 1
    For example: http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/misc/mke2fs.c?h=v1.42.13#n2646 ; FWIW you can even choose to specify a UUID instead. – Tom Yan Feb 11 '16 at 17:16
  • after generating the bootable linux flash drive in the vm the uuid of the partition was 54... when booting off of a live cd on the phisical pc after booting failed due to not finding root @ 54... live cd would read the uuid on the partition and it would be 67.... not 54 like it was on the vm. – Kendrick Feb 12 '16 at 20:09
  • by "54..." and "67..." you mean long strings like this: `de305d54-75b4-431b-adb2-eb6b9e546014`, right? how exactly did you check the UUID of the FILESYSTEM (not the partition, unless you mean PARTUUID) in BOTH CASE? `blkid` / `lsblk -f`? Have you made sure that you are checking the same drive (e.g. check with `lsusb.py`; it's sda in the vm doesn't means it's sda in the physical machine). Just bare in mind that UUID doesn't work the way you mentioned coz in that way UUID is pointless. The "change" you noticed is most likely due to some pebkac. – Tom Yan Feb 12 '16 at 23:44
  • Also, "not finding" a filesystem by UUID doesn't necessarily mean the UUID is changed. As I've mentioned, you need the necessary drivers (which can be a variable due to machine change, virtual or physical) in the initramfs, so that the drive can be properly detected and probed, Otherwise it's only natural that the init "cannot find" the filesystem. – Tom Yan Feb 12 '16 at 23:46