Can the Fedora TK1 distribution be used to boot the TX1?

I would like to use Fedora on the TX1, I am completely unfamiliar with Ubuntu. The .deb package management software seems non-sensical compared to dnf.
Can the 32 bit Fedora that can be installed to an SD card with arm-image-installer be used on the TX1?

If not, can anyone explain how to install Fedora Aarch64 on to an SD card? U-boot Fedora 27 has support for the Tegra 2371-2180.

TX1’s should use 64-bit distributions (arm64/aarch64). Anything 32-bit (armhf/ARMv7) is a slow compatibility mode. I too prefer Fedora, and although I believe there is a Fedora distribution which works, it won’t have full hardware access (especially the GPU…it’d be software-only rendering).

The .deb is to .rpm, but apt-get is what does the same as dnf. Typically for just a package update:

sudo -s
apt update
apt-get upgrade
exit

For search:

apt search something

The non-default repos are commented out in “/etc/apt/sources.list”. You can uncomment them and then use “apt update”…after that the packages in the changed repo list will show up.

Regardless of which distribution you use on SD expect it to be a benefit to first flash to the L4T R28.1 (this can be done either through driver package plus sample rootfs, or via JetPack3.1). Then you can edit the “/boot/extlinux/extlinux.conf” to point at the SD card…if you have a serial console, then you can select which boot entry you want at startup. Life is much easier with that serial console.

Perhaps one of the biggest pains will be in learning about device trees if you plan to port a kernel or distribution.

Fedora aarch64 has p2371-2180 u-boot and the device trees in it now, it just does not have a way to correctly write it to an SD card.

You try to make using Ubuntu sound simple, it is far from it. First, I do NOT want to have to go to an icon on the side of a screen to close a window. I had installed xfce4, but it was only available for the ubuntu account, not available for the nvidia account. Trying to remove the Gnome/unity desktop, I ended up not being able to log into the Jetson TX1. So I reinstalled.

Since the reinstall, wifi does not work. The TX1 did this the first time I installed ubuntu. I have tried to get the program to check to see if I have a bad wifi, but that was never followed through by the Nvidia help person.

It took four weeks, but finally I discovered how to use apt-mirror to download all of the ubuntu xenia arm64 packages for a local repository. Apparently I am the only person in the world who wants to use them personally, not put them on an apache server.

So how do I get the correct entry into /etc/apt/sources.list.d?

deb file:///media/nvidia/tosh/arm64/mirror/mirrors.mit.edu/ubuntu-ports/ does not work: apt can not find the Packages.gz files. So I tried adding /pool/main/ etc etc over and over and no luck.

So I move all of the .deb files to /main, /multiverse, /universe, run dpkg-scanpackages, and apt can not find the Packages.gz files.

In Fedora, I would have just gone to a mirror, created a file of" /http:/some/where/fedora/aarch/a/ . /b/. etc" and used “wget -c -r -l 1 -A*.rpm -i file-of-urls” and downloaded the files. I have a 2 MB/sec connection at work, but can only carry in so much stuff. Then in the directory run “createrepo_c -v .” and waited for it to finish.

No "dpkg-scanpackages . {or what goes here?} /dev/null | gzip -9c > Packages.gz.

There must be some rebel, some dare devil. at Nvidia who has installed Fedora on the TX1; please tell me how to do it. I downloaded the minimal root file system, and following the instructions here
https://elinux.org/Jetson/Porting_Fedora
with modifications, and got the Driver Packages installed into the root files system. But how do I flash or dd that to an SD card? What I have done so far does not work. And the instructions I have found that flash.sh with jetson-tx1 mmcblk1p1 does NOT write to the SD card.

I tried to use Ubuntu 12 years ago after buying my sister’s old Dell. I quickly found the Fedora 4 book in the library with CD in the back, installed and never considered using a debian derivative again until buying a Raspberry Pi last summer, I quickly installed Fedora.

Do beware that any ssh related connection may be seeing a different key (and thus think man-in-the middle) and refuse connection. For WiFi I don’t know if there is anything similar, e.g., maybe something in the router needs to be cleared/rebooted.

I too prefer Fedora, that is what my PC runs. When I use the Jetson I almost always use "ssh -Y " and display on my desktop (simplified because I have ssh login via keys set up).

The correct way to add a repo in Ubuntu is probably with the “apt-add-repository”, but I tend to find the information and simply edit “/etc/apt/sources.list” with vi. The trick is to know which repository. You’ll find the existing sources.list, by default, has most of what you’d want if you simply uncomment the correct lines in it…this is what I did. Uncomment and “sudo apt update”.

I have never set up a repository, but I’d expect Packages.gz to be a list of packages the repo has available. In the case of a Jetson where the CUDA or various other “local” repositories go into “/var/” there will be a Packages.gz which goes with it…this is not a web repository, but a file-based local repository. This is what the CUDA repo “.deb” puts in place (along with adding an entry in “/etc/apt/sources.list”).

I’ve not used dpkg-scanpackages, but it looks like it would go something like (this is probably how the Packages.gz was created for the cuda-repo deb):

dpkg-scanpackages /some/dir/which/has/deb/packages > Packages
gzip -9 Packages

Here’s the part you may find of interest. You can flash just ordinary Ubuntu and get most of what you need in terms of boot file and hidden partition infrastructure. Then add an alternate entry for a Fedora boot in “/boot/extlinux/extlinux.conf” naming your different rootfs (such as the SD card at “/dev/mmcblk1p1”) and then this alternate entry would not need anything in its own “boot” directory. This sounds confusing, but here is a bit of a clarification…

During boot several partitions and device tree content (within partitions) set up the board for U-Boot (some setup differs depending on carrier board). U-Boot eventually reads the “/boot” partition of mmcblk0p1 (eMMC, though this could be changed) to see extlinux.conf and to see any files referred to in extlinux.conf. For a TX1 or TX2 under R28.1 or newer this means basically only the Image file of the kernel is read there (don’t bother with zImage, uImage, or any other format…just Image).

You might see references to dtb files or initrd files, but these typically are not used and are a leftover artifact of older versions (you will find dtb has migrated into partitions and the initrd is normally 0 bytes). So if you copy the default entry into a new entry and name “root=/dev/mmcblk1p1” instead of “mmcblk0p1”, then your rootfs will be on SD card. No flashing is required there…it is just a pure copy of the sample rootfs onto the first GPT partition of the SD card which was formatted as ext4 (without 64-bit extensions in most cases would be preferable…in some cases 64-bit extensions will break things, but typically only if it is the “/boot” partition). “/boot” of the SD card will be ignored, everything else will come from the SD card.

If you installed normally to eMMC and have edited extlinux.conf, then on your host you might mount your SD card on “/mnt”, and then as root do something like:

cp -adpR /where/ever/fedora/root/is /mnt

If you are dealing with a live running system you have to not copy pseudo files, e.g., “/sys” and “/proc” are not real files so you wouldn’t want to copy them…when the system is turned off those go away. Otherwise it is just a recursive copy operation.

Thanks for the reply.
I guess I didn’t properly explain: I have essentially no wifi at home, local city provided slow/flaky wifi. Since the TX1 will usually not connect to it (and my desktop with USB dongle will) I want to get a local depository of ALL arm64 packages to install.

Making the local repository is impossible with the information available from a Google search. Creating the repo data with Fedora is so simple; dpkg-scanpackages is never explained and then Packages.gz when created, is never found. I understand from seeing the CUDA local repositories (and entries into /etc/apt/sources.list.d) that it can be done. I just can not discover how to do it.

I do have the 45000+ .deb files downloaded; I now need to get the TX1 and apt to see that they are in a local repository. All that I can find on line is to make an apt-mirror download available from an apache server.

I would like a ‘pure’ Fedora, not a Debian with Fedora root file system; I am sure that Fedora in its present state can actually do it. I just like most things, do not know how to do it.

I bought a Cubbieboard 1 four years ago; it was simple to get it running compared to the TX1. Since this is the cpu/gpu in an Nintendo Switch, I assumed that at least FreeBSD would be available for installation. Supposedly Automotive Grade Linux is available; its website is as circular as the Nvidia site.

It seems that a group completely unmanaged has put together a weekend project: only Ubuntu 14.04 on the desk/laptop to flash, wifi connection to download three needed files to install CUDA (why not include them in the base file system?), CUDA installed into /usr/local/bin/cuda-8.0 and needing a ‘find it’ entry into the .bashrc, and more and more surprizes every time I turn it on.

Nvidia stock could quadruple if someone could manage the software projects used by the hardware.

Reading “The Mythical Man Month” years ago by Fred Brooks changed my life.

Keep in mind that having the install of the standard Ubuntu L4T does not have anything to do with Ubuntu during the boot loader stage (and this also provides a rescue boot). The extlinux.conf file itself is read by U-Boot and Linux has not yet begun. If you name an alternate location and put your own kernel in, and if that location is Fedora, then you are not running anything from Ubuntu at all. You’re just taking advantage of the boot infrastructure. If you exchanged “U-Boot” for “GRUB”, would you say the system booted by GRUB becomes the one the binary is from originally? I heavily multi-boot or chain load in the PC world…I get what I choose regardless of the original GRUB install being from Fedora (e.g., I can even boot Windows 7…once there, it isn’t even slightly inheriting from Linux).

The device tree early on in boot is sort of like a short hand notation to assign addresses and values to a more generic driver. This way the driver does not have to include all hardware in its source…things like the register offset or register value may be the same concept among hardware for a single driver and the device tree is the glue which brings them together without polluting the driver itself.

In early boot U-Boot uses some of the device tree. At some point U-Boot loads a full device tree which will be used by the Linux kernel, and also loads into memory the Linux kernel itself. The version used by the Linux kernel may need things U-Boot does not, and in fact may use different values in some cases during early boot versus when the Linux kernel takes over. When you install from the regular flash system, this is what you are installing. If at run time the kernel takes over and the rest is Fedora, then it is truly Fedora. If a part of the device tree is in common because the same hardware is used regardless of being Fedora or Ubuntu, then this does not make it a mix of distributions…it makes it the same hardware.

I would suggest if you want to go down this route you also use the same kernel as from the L4T. It’s still Fedora, although you’d have to blacklist the kernel RPMs from auto update. You could go through the device tree one item at a time and find out if the Fedora kernel has a configuration which can use this as an exact match, but you’re asking for a long and tedious job when you could just use the Linux kernel from L4T which already matches this device tree.

Personally I am a fan of Fedora. Unless we are talking about using the Jetson as a desktop distribution though, I can work with Ubuntu almost as seamlessly as I can from Fedora. If I didn’t develop from my desktop I’d probably have to find an alternative. I have found the LXDE and KDE flavors of Ubuntu though work well for desktop development (I have LXDE Ubuntu on an underpowered atom laptop). If I were to use the Jetson for a desktop I would be more likely to fit the LXDE flavor onto the existing distribution than I would be to fit Fedora onto the Jetson. Even on Fedora I use the KDE spin.

I was later thinking that, it seems, the latest L4T is using part of the eMMC like an x86 BIOS.

So I bought a new SD card yesterday, and I am wondering if I didn’t format it correctly. When I tried to copy the eMMC – from the running TX1 – to the card I was given an “unable to keep permissions” followed by “operation not allowed” for about every file. It would then boot using the card to 6.XXXXXXXX and reboot every 30 seconds.

Realizing that the SD card can be used to boot, I copied the Tegra Drivers modified Fedora aarch64 root file system to that card: same copy problems. But it booted to 7.XXXXXXXXX.

I am not able to waste time on it again until Friday evening.

I tried to reduce the TX1 run level to 1 (having read that, unlike Fedora, 3 is not no graphics) thinking that copying a running file system would be much better in cli mode. I could not get the TX1 to open a terminal after
sudo init 1. Lots of protests, slow, slow reactions and then nothing.

I use XFCE, Gnome 3 was the end of the line for me in resource wasteful desktops. What problem(s) in Gnome 2 were solved by Gnome 3? On my old computer, KDE caused the CD drive light to flash about ever minute.

So it seems I am getting closer to running Fedora on the TX1. And I was expecting to use the TX1 running Fedora as my ‘working’ computer. The good laptop I was using, discarded at work, stopped working this summer and the Raspberry Pi is just to slow for any functioning.

PC motherboards with old style BIOS hit the 32-bit limits of the BIOS style partitions, and so we ended up with UEFI which offloads some of that to the operating system so that limitations on certain parts of the software are no longer manufactured into the motherboard itself (there is an attempt at “future-proofing”)…this in turn implied the creation of GPT partition schemes and some of what the BIOS might have known ended up as part of the invisible pieces of the GPT layout and device tree or firmware. U-Boot integrates much of this in itself since it never had a BIOS. Many embedded systems (including Jetsons) make significant use of partitions which might not exist if there were a real or old style BIOS. This supporting infrastructure is often used only during boot setup and ignored once Linux has taken over. The operating system itself usually has no knowledge of this content.

Be sure to use a GPT partition scheme on your SD card (e.g., “gdisk” instead of “fdisk”). Verify partitioning is valid with “sudo gdisk -l /dev/whatever”.

In terms of SD card formatting Linux itself can pretty much deal with anything ext4. You will find U-Boot has some limitations and is not able to understand some of the newer 64-bit extensions. On the system from which you are doing the “mkfs.ext4” check your “/etc/mke2fs.conf”…be certain the ext4 options do not include “64bit” or “metadata_csum”. If they do, then your mkfs.ext4 must include the option to not use those options (mmcblk1p1 is just an example, adjust for your case):

sudo mkfs.ext4 -O ^metadata_csum,^64bit /dev/mmcblk1p1

One of the biggest mistakes in trying to copy a file system is not telling the copy to ignore other file systems. For example, a naive copy might try to copy pseudo files which are not real files in “/dev”. Imagine how long it will take to copy the content of “/dev/urandom” or “/dev/zero”…not to mention the required disk size :P

Most of the time you also do not want to copy symbolic link content…you just want the link.

One reason to use utilities like “find” would be options such as “-xdev” to not descend into other file systems…a copy here from “/” would automatically avoid copying pseudo file systems such as from “/proc”, “/sys”, or parts of “/dev” (find in combination with cpio is reliable). rsync has some similar options, e.g., “-x”. Using dd or a clone has the advantage that only the partition content is copied, and things the partition might point at are ignored (the trick with dd is that you don’t want the file system changing while you do the copy).

The driver package utility “apply_binaries.sh” has a “-r” option where you can name an alternate destination. So if you have an SD card mounted on “/mnt”, then you should be able to run “sudo ./apply_binaries.sh -r /mnt” and not worry about copy details.

On a correctly functioning Fedora system (modern ones at least) you should be able to add this to the extlinux.conf “APPEND” key/value data pair (space delimited between values…it’s a single very long line):

# Console mode only:
systemd.unit=multi-user.target
# GUI mode:
systemd.unit=graphical.target
# Command line switch to console:
sudo systemctl isolate multi-user.target
# Command line switch to GUI:
sudo systemctl isolate graphical.target

Ubuntu differs and has not transitioned as far as Fedora has in adoption of systemd (at least not for Ubuntu up through 16.04). Unfortunately the L4T variations also do not completely support normal systemd options for changing runlevels…you have to do alternate workarounds such as disabling lightdm altogether.

I think the main issue with using Fedora will be whether or not you can get the GPU driver to function. This driver is tied to the Xorg ABI, which if you use the L4T kernel, you will know is possible…even so this is a very extensive list of files if you are to keep an older Xorg ABI within a newer distribution. The Xorg server is typically misunderstood by people and gets inaccurately labeled as being used only for graphical display…this server is in reality an ABI for accessing the GPU hardware, so it is used with CUDA even if you never log in with a graphical environment. Losing the Xorg ABI implies falling back to the Nouveau driver and losing GPU access for both desktop and CUDA.

Thank you for your informative reply.

With the formatting of the new SD card, I started copying, after trying to install Fedora TK1 to it. Of course, the root file had not been expanded, so it filled and stopped copying. I was hoping that perhaps the 32 bit Fedora would run and give me a framework to then copy the aarch6 into for testing.

So I used gparted to expand the file system. I think perhaps that the SD card is now ‘root’ owner, not user owner. I didn’t think of that until last night and can not do any thing to test it until Friday when I have time.

Again, thanks for your help and I hope someone else is interested in installing Fedora on the TX1. If not, if I can finally get a repo mirror to function, I can install all of the software that I want with out carrying the TX1 to work or the library, or having its wifi work.

What matters are the numeric user and group IDs contained within the ext4 file system of the boot media. If you used root to unpack the sample rootfs, and to run the “apply_binaries.sh” step of an L4T install, then this would be preserved and valid. For another rootfs, e.g., Fedora, you would still have valid permissions if you used root for the unpack and if that rootfs started with valid permissions. You can probably run the apply_binaries.sh onto the Fedora rootfs just like you would apply it to the L4T rootfs (I haven’t tried though).

I’m not sure what issues you might be running into on your host for permissions, but any mount point where you operate on the SD card content as root should be allowed (you would not want to unpack anything onto your SD card rootfs as any user other than root). “root” has the special property that by default it unpacks all files while preserving the numeric ID of user and group…any other user will remap to your running system as a subset of that system.