SSD doesn't boot

[Yotaphoner]

­Hi. I have a Raspberry pi 3B+ and I tryied to use a SSD as the bootable device where the filesystem is (so no SD) and I didn’t had luck. To do that I copied the entire filesystem of the SD card to the SSD with the SD CARD COPIER that comes with Raspbian Strecht, but when I try to boot the Ssd it doesn’t work. The SD CARD COPIER does the job without no errors, and after the first failed try I formatted the SSD and copied again the SD with SD CARD COPIER marking the “New partitions UUID” option, but neither worked.

Before all that, I tried to clone the SD card through windows, with a program called easeUS Todo backup, and also nothing.

What am I doing wrong?

(I really don’t want to make a fresh install of Raspbian)

[wh7qq]

Sorry, but I am just going to tell you to make a fresh copy of Raspbian. You can probably still use the original download but forget about formatting it and download the free utility "Etcher" which will unzip the Raspbian file, format your uSD and burn the OS in a single step. It works really well and reliably. There are a number of posts on this forum and elsewhere outlining the procedure for booting from USB (SSD, HD, or USB memory). Go for the most recent, as they seem to vary with the version of Raspbian. I don't use USB booting so I don't know what the current steps are but it does involve setting a special bit in the 2B, 3B, 3B+ cpu to allow booting from sources other than uSD. I have done it in the past and found that the boot was slower than before but I never updated it after Jessie went to Stretch. Follow the instructions exactly so that you do not leave any necessary steps out.

[davidcoton]

it does involve setting a special bit in the 2B, 3B, 3B+ cpu to allow booting from sources other than uSD.

The 3B+ (and 3A+, IIRC) have the USB boot bit factory set, so no special arrangements are needed.

Assuming it is Raspbian Stretch that you are copying, check that Raspbian Stretch is fully up-to-date before copying:

Code: Select all

sudo apt update
sude apt full-upgrade

If it's another OS just copied by Stretch, all bets are off.

[Yotaphoner]

It still doesn't work.

I did the "apt upgrade" and "apt distro-upgrade" and then copied again with the SD CARD COPIER the whole partition to the SD. Also one time with the "Change uuid" option unmarked and then marked.

To clarify, I am doing everything while I am running on the filesystem which I want to copy to the SSD, and yes, it is the Raspbian Strecht.

And as said, the Raspberry version I have doesn't need any bit to be set to properly boot from USB

Any other suggestion?

[vinaypundith]

Check the boot partition files for any mention of the root partition being at "/dev/mmcblk0p2". The disk partitions are labeled as /dev/mmcblk0, mmcblk0p1 and mmcblk0p2 on an SD card but for any other type of drive (HDD, SSD, flash drive, etc) it is usually labeled as "/dev/sda", sda1, and sda2.

Also, some drives are just not suitable for booting from. I have read that this is because of them having too long a delay before initializing, by which time the Pi has already concluded that there is no bootable media. This (no booting at all) happened to me while trying to boot my Pi 3B+ from a hard drive. If this is your case, then you will have to keep a small (even 128MB will do) SD card for the boot partition and transfer the root (OS filesystem) partition to your SSD.

BTW, I think the command is "apt-get dist-upgrade", not "apt-get distro-upgrade".

[davidcoton]

Read my last post for the correct upgrade command. apt-get will still work, apt is easier to type and is tuned for interactive use rather than batch use.

Note that both partitions (boot and root) must be transferred to the SSD, not just one. I forget what trick is needed to get the boot links right, I think SD Card Copier does it for you.

Otherwise, just use Etcher to write a new Raspbian to the SSD (that method works), and sort out anything you need to transfer afterwards.

[HawaiianPi]

Post the output of the following commands:

• cat /etc/os-release
• uname -a
• cat /sys/firmware/devicetree/base/model;echo
• ls -l /dev/disk/by-partuuid

Also, post the contents of the /etc/fstab and /boot/cmdline.txt files from the USB drive (in code tags).

Depending on the information requested above, the rest of this post may or may not be relevant.

The /boot/cmdline.txt and /etc/fstab files contain critical device identifications, which used to point to the micro SD card, but in more recent versions of the OS they point to a partition identifier (PARTUUID), which is a more foolproof way to do it. This is why it's recommended to start fresh by writing the latest Raspbian image directly to the USB drive, rather than copying an existing card.

To fix an older image you must first find the PARTUUID of the USB drive, and if your current Raspbian install was made using NOOBS you really should start over from scratch (NOOBS does not get updated with Raspbian and quickly goes out of date).

After copying the card to the USB drive (with the New Partition UUIDs option checked), enter the following command in the CLI or a terminal:

Code: Select all

ls -l /dev/disk/by-partuuid

The output should look something like this:

Code: Select all

HawaiianPi@Pi3SSD:~ $ ls -l /dev/disk/by-partuuid
total 0
lrwxrwxrwx 1 root root 10 Jan  5 11:27 13f2d64f-01 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan  5 11:27 13f2d64f-02 -> ../../sda2
lrwxrwxrwx 1 root root 15 Dec 24 11:17 8debe07a-01 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Dec 24 11:17 8debe07a-02 -> ../../mmcblk0p2
HawaiianPi@Pi3SSD:~ $

Note the PARTUUID of the USB drive (sda1 and sda2 if you have no other USB drives connected). If your /etc/fstab and /boot cmdline.txt files do not contain this PARTUUID then you must edit them on the USB drive. Also note that /boot/cmdline.txt points to the 2nd partition (not the boot partition). Then end result should look similar to this (with your PARTUUID).

/boot/cmdline.txt

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=a1b2c3d4-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

/etc/fstab

Code: Select all

proc            /proc           proc    defaults          0       0
PARTUUID=a1b2c3d4-01  /boot           vfat    defaults          0       2
PARTUUID=a1b2c3d4-02  /               ext4    defaults,noatime  0       1

Again, these are the files on the USB drive, not the micro SD card (although with the correct PARTUUID it will work on either). Use a pure text editor, not a word processor to edit the files, and make sure that cmdline.txt is only a single line (no breaks). Once these changes have been made to the USB drive, you can shut down, remove the micro SD card, and the system should boot from USB.

If that doesn't work, format a spare micro SD card with the FAT32 file system and download bootcode.bin here (bootcode.bin) then copy only that file to the FAT32 micro SD card, put that bootcode.bin only micro SD in the system and see if the USB/SSD boots.

[Yotaphoner]

Davidcoton, don't worry, the Raspbian is well upgraded.

HawaiianPI, I edited the /root/etc/fstab and the /boot/cmdline.txt. Now look like this:

/MEDIA/PI/ROOT/ETC/FSTAB:

Code: Select all

proc            /proc           proc    defaults          0       0
PARTUUID=00061ae7-06       /boot           vfat    defaults          0       2
PARTUUID=00061ae7-07       /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

/MEDIA/PI/BOOT/CMDLINE.TXT

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=00061ae7-07 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles quiet

PROMPT cat /sys/firmware/devicetree/base/model;echo

Code: Select all

Raspberry Pi 3 Model B Plus Rev 1.3

PROMPT sudo fdisk -l (only the part regarding the SSD)

Code: Select all

Disk /dev/sdb: 119,2 GiB, 128034593280 bytes, 250067565 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00061ae7

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sdb1          8192   3781250   3773059   1,8G  c W95 FAT32 (LBA)
/dev/sdb2       3781251 250067564 246286314 117,4G  5 Extended
/dev/sdb5       3784704   3850237     65534    32M 83 Linux
/dev/sdb6       3850240   3991551    141312    69M  e W95 FAT16 (LBA)
/dev/sdb7       3997696 250067564 246069869 117,3G 83 Linux

PROMPT ls -l /dev/disk/by-partuuid

Code: Select all

total 0
lrwxrwxrwx 1 root root 10 ene  5 22:57 00061ae7-01 -> ../../sdb1
lrwxrwxrwx 1 root root 10 ene  5 22:57 00061ae7-02 -> ../../sdb2
lrwxrwxrwx 1 root root 10 ene  5 22:57 00061ae7-05 -> ../../sdb5
lrwxrwxrwx 1 root root 10 ene  5 22:57 00061ae7-06 -> ../../sdb6
lrwxrwxrwx 1 root root 10 ene  5 22:57 00061ae7-07 -> ../../sdb7
lrwxrwxrwx 1 root root 10 ene  5 22:57 09b3f4fe-3509-4cc3-8f7f-cef058ae6a33 -> ../../sda1

PROMPT cat /etc/os-release

Code: Select all

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

PROMPT uname -a

Code: Select all

Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

I think this is all. With the fstab and the cmdline.txt modified the way I pasted at the beginning of the post it didn't boot

If anyone can solve the problem I will do the microSD trick. I have a 64MB microSD card, I think it will be enough. What do you think?

[rpdom]

It looks like you have a NOOBS based installation, rather than a straight Raspbian image.

I suspect that is causing additional complications with booting.

[LTolledo]

can you try again, by flashing the SSD with a fresh image of Raspbian stretch with Desktop, using Etcher, just to test.

booting to USB thumbdrive/HDD/SSD works best if image file flashed to it.

havent tried booting via NOOBS... and probably wont ever.....

if you dont (won't) want to make a fresh installation because you have installed so much applications/packages to your current raspbian...
then the only course of action is the "export out of NOOBS procedure"

[HawaiianPi]

Yup, as I said in my previous post, NOOBS is a poor choice because it does not update when you update Raspbian, so NOOBS gets out of date quickly. You can try manually updating NOOBS on the USB-SSD, but I highly recommend you just start from scratch with the latest Raspbian.

At the very least you should test it with the latest Raspbian image, because the Raspberry Pi boot-loader is not compatible with all USB drives, and if it won't boot with the latest image you're wasting your time trying to get your old NOOBS/Raspbian install working.

So write the latest Raspbian image to the SSD with the Etcher image writing software directly from the .zip download (don't extract the image first), and see if that boots. If you have trouble writing the image, check the SHA256 hash sum against the one on the download page.

[Yotaphoner]

The big prize for HawaiianPi! It doesn't boot with the fresh install with Etcher, so It has to be the SSD. In fact, is an old SSD. The crucial M4, and I noticed the leds of the adapter cable starts to blink a couple of seconds after the Raspberry is on.

About etcher I have to say it didn't work on the Raspberry. I tried both 32 and 64bit versions and non of them did nothing, not even an error. And yes, I made them executable before try to execute them. Neither on the Ubuntu on my pc it worked. Had to install it on Windows 7 and copy the image from there (Sorry for what I am going to say, but sometimes I have to say God bless windows)

So having a microSD card which says the Raspberry the filesystem is on the SSD seems the only option.

I copied again my filesystem ot the SSD (meanwhile the process I thought maybe it's not a good idea because the NOOBS), marking the option of "New partition UUID", and copied the bootcode.bin (just with a "cp" via terminal") to a 64MB microSD card. Turned off the raspberry, changed the microSD and the SSD were still plugged. And guess what? It didn't boot.

Can be the cable? Can be the NOOBS? Can be the option "New partition UUID" on SD CARD COPIER? I don't have more energy today and I have to go to sleep.

What the hell is going on???

[HawaiianPi]

I'm pretty sure Etcher only supports x86 architecture Linux (not ARMhf Linux used on the Pi).
Not sure why Ubuntu didn't work on your PC. ¯\_(ツ)_/¯

As far as not booting goes, it could be the SSD, but it's more likely the USB-SATA adapter you are using (or a combination of both).

• What USB-SATA adapter are you using (make, model, link)?
• What are you using for a power supply?
• Is the SSD powered by the Pi USB port?

For troubleshooting you should stick with the latest Raspbian image for now. If we can get that booting, then we can troubleshoot your old OS configuration. So write Raspbian to your SSD again with Etcher, and see below.

64GB micro SD cards are formatted with the exFAT filesystem by default, and the Pi can't boot from that. If you have a smaller micro SD card, try that, or download the GUI version of FAT32 Format and reformat your 64GB card with the FAT32 filesystem. Then you can copy the bootcode.bin file to it and see if will boot your SSD with the latest Raspbian Stretch.

[vinaypundith]

If Etcher isn't working, you can write the OS image using Ubuntu's Disks utility. Right click on your image file and say "Open with Disk Image Writer".
AFAIK, you need to have the whole boot partition on the 64MB SD card, not just bootcode.bin. There are many more files needed to boot than just bootcode.bin, like config.txt, cmdline.txt, kernel.img, etc.
Also, your SSD may not be getting enough power, like HawaiianPi said. The hard drive that I booted my Pi from was not able to get enough power out of the Pi USB port itself. I had to give it auxilliary power from an external supply, using a homemade USB tail that connected the data wires to the Pi USB port and the power wires to the PSU, as the external power should not go into the Pi through the USB port.
BTW, is your card 64 megabytes or 64 gigabytes?

[rpdom]

AFAIK, you need to have the whole boot partition on the 64MB SD card, not just bootcode.bin. There are many more files needed to boot than just bootcode.bin, like config.txt, cmdline.txt, kernel.img, etc.

No, just bootcode.bin is usually enough. When it runs it will check for USB devices, and if one is found with the correct files it will continue the boot from that device. This works on any Pi.

[HawaiianPi]

AFAIK, you need to have the whole boot partition on the 64MB SD card, not just bootcode.bin.

Your information is outdated. Using a bootcode.bin only SD card is now the officially documented procedure for USB booting Pi computers that do not support USB boot, or ones that are having trouble booting from USB. The big advantage is that the root filesystem automatic resize works with a bootcode.bin only SD card (it does not work with /boot on SD and the root filesystem on USB).

[vinaypundith]

AFAIK, you need to have the whole boot partition on the 64MB SD card, not just bootcode.bin.

Your information is outdated. Using a bootcode.bin only SD card is now the officially documented procedure for USB booting Pi computers that do not support USB boot, or ones that are having trouble booting from USB. The big advantage is that the root filesystem automatic resize works with a bootcode.bin only SD card (it does not work with /boot on SD and the root filesystem on USB).

Thanks for the info and sorry for my mistake.
On the page linked in the above post, there is a line saying "If you have a problem with a mass storage device still not working even with this bootcode.bin, then please add a new file 'timeout' to the SD card. This should extend the time it waits for the mass storage device to initialise to six seconds." May be you should try that, as like I said earlier, your SSD may be having too long an initialization delay.

[HawaiianPi]

On the page linked in the above post, there is a line saying "If you have a problem with a mass storage device still not working even with this bootcode.bin, then please add a new file 'timeout' to the SD card....

Yes, and of that works, there is a way to make it a permanent change, but that is a few steps down the troubleshooting list.

We need to get more info and try some other things first. I need the OP to answer the questions above, then try the bootcode.bin only SD card with the latest Raspbian image (not his old NOOBS install), and the 64GB card MUST be FAT32 format (exFAT will not work). Currently there are too many other reasons his system is not booting, and we need to eliminate those before moving on.

[Yotaphoner]

First of all, have to make clear the microSD is 64MB, not 64GB. Is one of that old techy things you keep for melancholic purposes. I never thought I would do something usefull with it. And is formatted to FAT32.

The SSD have been installed with the lattest version of Raspbian since you told it to me. And now this is what I have on the SSD.

The SSD: Crucial M4 (like 7 years old, but almost unused)
The cable: https://www.amazon.es/gp/product/B0718Y ... UTF8&psc=1
The PSU: Aukru 3A

Vinaypundith, the cable you mention, the 2 power cables you get from the USB cable which goes to the PSU, they are joined with the power cables of the PSU of the Raspberry of do you have another PSU for that?

I will try tomorrow to get a pendrive and install there the Raspbian and see if it boots.

Just to test: the timeout file to be put on the microSD if the SSD is slow at the weak up time it has to be made just with a "touch" command or which process? I bought a USB 2.0 cable because if you buy a 3.0 you MUST give extra power to the SSD. Anyways, the only SSD to USB cable available to arrive soon was one with double USB, and as I am connecting booth I suppose I don't have to have power problems. Anyways, I am curious about how you did your cable.

I think I forget nothing. If I do just tell it to me

[vinaypundith]

Vinaypundith, the cable you mention, the 2 power cables you get from the USB cable which goes to the PSU, they are joined with the power cables of the PSU of the Raspberry of do you have another PSU for that?

I connected them to the same PSU that powers the Raspberry, but upstream of the Raspberry itself. What are you plugging the 2nd USB plug of your cable into? Another of the Raspberry's USB ports or directly to a power supply? Try checking the voltage at the both the USB ports that the drive is connected to (from the solder points on the bottom of the Raspberry). I think your cable should work though.
What do the power & activity LEDs do/show when you power the Raspberry on? That would help us figure out where things are going wrong.

[HawaiianPi]

First of all, have to make clear the microSD is 64MB, not 64GB. Is one of that old techy things you keep for melancholic purposes. I never thought I would do something usefull with it. And is formatted to FAT32.

My bad ... read that wrong. Thanks for clarifying.

The SSD have been installed with the lattest version of Raspbian since you told it to me. And now this is what I have on the SSD.

The SSD: Crucial M4 (like 7 years old, but almost unused)
The cable: https://www.amazon.es/gp/product/B0718Y ... UTF8&psc=1
The PSU: Aukru 3A

PSU is unknown. Should be adequate, but I have found that switches on the low voltage side can cause voltage loss (it would need to be load tested to be sure).

Does the SSD have any power specifications (PDF found on Crucial's site didn't list power requirements)?

Vinaypundith, the cable you mention, the 2 power cables you get from the USB cable which goes to the PSU, they are joined with the power cables of the PSU of the Raspberry of do you have another PSU for that?

It looks like your USB-SATA adapter has 2 USB-A plugs. One is for power and data, the other is for additional power. Connecting both to the Pi won't make a difference, as Pi3 computers have no per-port limits. You could try connecting the power-only plug to another power supply to give the SSD more juice, but that may introduces a small risk of damage from back-powering.

... if you buy a 3.0 you MUST give extra power to the SSD.

Not true. All of the SATA adapters and enclosures I use with my Pi computers are USB 3.0, and all work fine when powered by the Pi3 USB port (with the official Raspberry Pi Universal Power Supply). I've even booted hard drives on some of those. The USB 3.0 power specification allows for more powerful devices, but an SSD won't necessarily draw more power just because it's on a USB 3.0 adapter.

Anyways, the only SSD to USB cable available to arrive soon was one with double USB, and as I am connecting booth I suppose I don't have to have power problems.

As I said above, the Pi3B/3B+ computers have no per-port power limits, so all 1.2A of the available USB power can come out of a single port, if needed. Which means connecting the 2nd cable to the Pi's USB ports doesn't increase power to the device, and won't help if it is a power issue.

Next thing to try would be the "timeout" file on the bootcode.bin only SD card. The file can be empty, the contents don't matter. It's presence tells the boot-loader to wait a bit longer for USB devices.

If the timeout file fixes your boot problem, you may be able to get it to boot without the card by setting another OTP bit that increases the wait time for USB drives to become ready from the default 2 seconds to 5 seconds (this is a permanent change). To enable the additional wait time for USB drives, add "program_usb_boot_timeout=1" to config.txt on a Raspbian SD card and boot it once in the system. After that the system will wait up to 5 seconds for USB drives to become ready.

I also noticed that you have more than one USB drive connected. Try it with only the boot SSD connected (the bootcode.bin only SD card will only attempt to boot the first USB drive it finds, and if that's not a boot device, it fails. Since your SSD seems to be coming up as /dev/sdb, boot is likely failing on /dev/sda (those may swap from time to time, depending on which gets ready first, but there is no way to force it).

[vinaypundith]

The way I got my hard drive to work was to install a bootloader (like PINN or BerryBoot) onto an SD card (1GB should do for a single OS) and select the hard drive as "Destination drive", ie drive to install the OS to.

[Yotaphoner]

Yeah! I have it!

The "keys" were 2: Power the cable with another PSU and follow the "tempo" and an order.

First I have to connect one of the USB to the PSU and connect it to the Raspberry Pi while being unpowered. Then wait 2-3 seconds, whitin them the SSD´s reads something about itself, and then engage the Raspberry. Also, it works and it doesn´t in this scenarios:

OLD RASPBIAN (NOOBS) WITH SD ===> Does nothing
OLD RASPBIAN (NOOBS) WITHOUT SD ===> Stuck on 4 Raspberries
FRESH INSTALL WITH SD ===> Desktop
FRESH INSTALL WITHOUT SD ===> Desktop

Boot sequence: "Rainbow" ==> Logo (Only on Noobs) ===> 4 Raspberries ===> Desktop

In both Raspbians, when no SD where plug a 3 green led blink code appeared during all the time, and according to this https://elinux.org/R-Pi_Troubleshooting ... ic_pattern , its means "start.elf not found". I have no idea what this means, but don´t care because without the SD it boots perfectly (respecting the tempo and the sequence)

When I try to boot with the Raspbian with Noobs it gets stuck in the 4 raspberries screen, and prompts me the screen pasted below. It´s curious because when I first boot the Raspberry with the SSD with no SD it appears the same screen, but after let´s say 15 seconds it continues booting and never appears again. With the Noobs raspbian never pass through, and I give 8hours to the raspberry to work on it
LINK TO THE IMAGE https://imgur.com/a/jYBMKDQ

It surprises me how the Raspberry "programs" itself depending on the scneario it detects. Sometimes while changing the phisical configuration it starts booting while thinking and detecting everything, reboots itself, and then starts booting perfectly.

Maybe it would be good to explain why I want to keep the old installation. It is because my raspberry is headless, and it has a VNC server configured to run automatically, and I don´t want to struggle with the Raspbian to install and configure it on the fresh install. Maybe you think it´s not that hatd to do it, but the problem is I have a visual problem which makes me dizzy when I look at a screen, very quicly and with all kinds of screen, except.... the eInk. So I have a 10" eInk with android which is my screen, via VNC. I am not the one who configured the VNC server on raspberrian, and once I tried in Ubuntu and it was a hell, and also, never worked. Let´s see

So now I think I have to find the way to export the configuration to the fresh install

[HawaiianPi]

...
In both Raspbians, when no SD where plug a 3 green led blink code appeared during all the time, and according to this https://elinux.org/R-Pi_Troubleshooting ... ic_pattern , its means "start.elf not found". I have no idea what this means, but don´t care because without the SD it boots perfectly (respecting the tempo and the sequence)...

Nope, the blinking pattern on a USB booted system is caused by the system polling the empty SD card slot, waiting for a card. You can stop that by either leaving a formatted but empty card in the slot (which also speeds up the boot process because it bypasses the 5 second wait for a card), or you can add the following to your /boot/config.txt file.

Code: Select all

dtoverlay=sdtweak,poll_once

Which stops SD card slot polling when USB booting (sets card to non-removable if present, disables slot if no card).

I understand you have vision problems, but configuring VNC is not difficult. Probably easier than trying to get your current NOOBS system working. You just need to add a file named ssh (or ssh.txt) to the card or SSD after writing the image to enable SSH logins, then you can SSH in and turn on VNC from the raspi-config utility. You should be able to do that from the Android eINK display (there are SSH apps for Android).

[Yotaphoner]

I understand you have vision problems, but configuring VNC is not difficult. Probably easier than trying to get your current NOOBS system working. You just need to add a file named ssh (or ssh.txt) to the card or SSD after writing the image to enable SSH logins, then you can SSH in and turn on VNC from the raspi-config utility. You should be able to do that from the Android eINK display (there are SSH apps for Android).

Currently I use VNC without SSH, which (I think) makes it much more easy to configure it. I will see.

And I can't configure the VNC server with the eInk monitor because I need the VNC server to use the eInk monitor