IRC log of #cubox of Sun 25 Jan 2015. All times are in CET < Back to index

17:13 balrog I was trying to use mmcroot=UUID= or PARTUUID but it didn't work
17:14 balrog was I doing something wrong or does uuid just not work with mmcroot?
17:16 Artox as far as I know, balrog, uuid does work
17:16 balrog Artox: I could simply not get it to work
17:16 balrog try as I might
17:16 balrog this is with kernel on sd card and rootfs on sata
17:16 Artox but the kernel actually takes root=
17:17 Artox not mmcroot
17:17 mk01_ balrog: kernel don't recognise UUID/LABEL
17:17 balrog I tried that too
17:17 Artox unless yourefer to the uEnv.txt
17:17 Artox of which I am no expert
17:17 balrog Artox: uenv.txt
17:17 balrog mk01_: ^
17:17 Artox that text file requires some magic to pass useful stuff to kernel
17:17 mk01_ (so for UUID/LABEL one needs initramfs (and resolve via findfs for instance)
17:17 balrog right now I don't have a boot.scr (didn't need one yet)
17:17 Artox oh
17:17 Artox uuid thign is not builtin?
17:17 balrog mk01_: do you need initramfs for PARTUUID? apparently you don't
17:17 Artox that'd explain it, my opensuse distros always laod an initrd
17:17 Artox so no trouble there
17:17 balrog I'm using arch
17:18 balrog well I worked around this for now by specifying a reboot on panic
17:18 Artox so, balrog, chances are the part that handles uuid is not builtin but a module (but I really dont know)
17:18 balrog the issue was that on reboot, the usb drive would be treated as rootfs and fail since sata hadn't come up yet
17:18 balrog http://unix.stackexchange.com/questions/93767/why-cant-i-specify-my-root-fs-with-a-uuid
17:18 balrog was looking at that
17:18 balrog thing is the kernel doesn't seem to be able to use PARTUUID either.
17:19 balrog oh, that's GPT onle.
17:19 balrog only*
17:19 balrog ahh...
17:20 balrog that would explain it
17:20 Artox if sata hasnt come up yet
17:20 Artox one can pass rootwait
17:20 Artox I believe
17:20 mk01_ * Convert a name into device number. We accept the following variants:
17:20 mk01_ *
17:20 mk01_ * 1) device number in hexadecimal represents itself
17:20 mk01_ * no leading 0x, for example b302.
17:20 mk01_ * 2) /dev/nfs represents Root_NFS (0xff)
17:21 mk01_ * 3) /dev/ represents the device number of disk
17:21 mk01_ * 4) /dev/ represents the device number
17:21 mk01_ * of partition - device number of disk plus the partition number
17:21 mk01_ * 5) /dev/p - same as the above, that form is
17:21 mk01_ * used when disk name of partitioned disk ends on a digit.
17:21 mk01_ * 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
17:21 mk01_ * unique id of a partition if the partition table provides it.
17:21 mk01_ * The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
17:21 mk01_ * partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
17:21 mk01_ * filled hex representation of the 32-bit "NT disk signature", and PP
17:21 mk01_ * is a zero-filled hex representation of the 1-based partition number.
17:21 mk01_ * 7) PARTUUID=/PARTNROFF= to select a partition in relation to
17:21 mk01_ * a partition with a known unique id.
17:21 mk01_ * 8) : major and minor number of the device separated by
17:21 mk01_ * a colon.
17:21 mk01_ thats do_mount from 3.19
17:21 mk01_ the same is for 3.14
17:22 mk01_ so should work in this formats
17:48 balrog oh hmm, SSSSSSSS-PP
18:56 mETz Looks like the PSU that shipped with my cubox-i4pro is faulty or does not fit
18:57 mETz just rotating or applying minimal pressure to the jack makes the box loose power, no such problems with a PSU from a different iMX6 device (5V 4A)
18:58 mETz anybody else had trouble with a HNP18-050 PSU?