Jump to content

Debian/Refracta UEFI installation to new drive


Hedon James

Recommended Posts

I've been working on a remix of Debian LXQt, with plans to migrate away from my Lubuntu 16.04 remix (underlying Ubuntu base is supported through 2021, but LXDE layer is already 1 year out of support).  I've gotten my DebianQT remix to a place where I'm quite happy with it, and ready to install on all my machines, and receiving the benefits of another 5+/- years of Debian support.  I have Refracta Tools (snapshot, refracta2usb, and installer) on my remix and have used snapshot to create the ISO, dd to create the bootable USB, and using RefractaInstaller for installation.

 

I have since successfully installed my distro in a VM, as well as 2 different laptops, without incident.  Pretty pleased with the results too!  I'm now attempting to install my distro on my main machine, my work computer....my production machine.  I'm running into all kinds of issues, all of which revolve around the installer not being able to find the EFI partition.  RefractaInstaller.log is attached/uploaded for viewing, if anyone can read it.

 

While my other installs were on older MBR partitions, this computer is a UEFI system with GPT.  Given my previously successful MBR installs, I'm fairly certain that the EFI is at the heart of what the problem may be.  Here's what I've done to effectuate installation on the UEFI machine:

 

- completely pulled old SSD (with intentions to save as a backup OS)

- installed new SSD (Samsung EVO 860 - 250GB)

- using gparted, formatted drive with GPT scheme, created 1GB EFI partition with esp & boot flag, and remainder of drive formatted as ext4 for OS installation.  Upon successful installation of OS, I will attach a 2nd HD, which is a "data drive"...similar to separate /home drive, but I prefer my home directory on same drive as OS, and data on separate drive with symlinks.  I will also attach 3rd drive and configure for automatic backups of /home and /DataDrive.  Identical to the configuration that I am currently using....simply intending to "pull old OS drive" and "replace with new OS drive".

- accepting the defaults in installer, the OS installs without issue

- when it gets to the section regarding Install Bootloader, Abort, Chroot, or Continue, I choose Install Bootloader.

- bootloader installation fails, but I can continue setting up machine name, users, etc...

 

As part of my troubleshooting efforts, found a refractainstaller UEFI-installation.readme that showed how to manually install grub with chroot.  Again, fails but I can continue with OS setup.  The OS appears to be fully installed, just missing bootloader.  At this point I have googled numerous hits with the error(s) indicated in log file, but still haven't been able to solve:

 

grub-install: warning: Cannot read EFI Boot* variables.
grub-install: warning: read_file: could not read from file: Input/output error.
grub-install: warning: vars_get_variable: read_file(/sys/firmware/efi/vars/Boot000C-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var) failed: Input/output error.
grub-install: warning: efi_get_variable: ops->get_variable failed: Input/output error.
grub-install: error: failed to register the EFI boot entry: Input/output error.

 

While this is above my paygrade of understanding, I'm fairly certain the line #2-4 warnings are a function of the 1st.  I'd be willing to bet if #1 gets solved, all the others go away.  To sum it up, I have attempted an automatic install with installer; a chroot install will installer; and have manually chrooted from liveusb to install.  Not sure I can even remember everything I've tried, as my brain is jello after 2 days of this.

 

At this point, I am out of time for an installation this weekend, having burned up my Friday & Saturday.  I have reinstalled the previous disk and OS, and emailing from that working system.  But that is only temporary, as I still need to update my out-of-support system (Lubuntu 16.04), to the Debian 10 OS I've remixed.

 

If anyone has any thoughts on what I'm doing wrong, or how to fix, I'd love to hear them.  Thanks in advance for your assistance!

refractainstaller.log

Link to comment
Share on other sites

securitybreach

Well it looks like you do not have an EFI partition and if you do, the installer cannot find it hence the grub errors. Grub is not the problem, its your partition layout that is causing the issue.

Link to comment
Share on other sites

securitybreach

You need something like this for UEFI/GPT

/dev/nvme0n1p1   2048    206847    204800   100M EFI System
/dev/nvme0n1p2 206848    718847    512000   250M Linux filesystem
/dev/nvme0n1p3 718848 500118158 499399311 238.1G Linux filesystem

 

Basically a 100M EFI partition, a 250M boot partition and then the rest for root, home, etc.

Link to comment
Share on other sites

I have a 1GB EFI partition (larger than recommended, but I don't know how much it might "grow" over the years), with esp & boot flag, and the rest is OS.  Refracta "sees" the EFI partition and attempts to install grub to the EFI, but throws the warnings/errors.  See above.

 

I have an option for a separate /boot partition in the refracta installer.  Is that the same thing you're describing?  And may I assume it is also formatted EXT4, like the OS, or FAT32, like EFI?  And does it get an esp/boot flag in the GPT table?

Link to comment
Share on other sites

securitybreach

The suggested EFI size is 512mb but 256mb is suffice for most systems. I do not think that you would ever get over 512mb.  The EFI partition must be fat32 as the file system type.

 

The boot partition cannot be the same as the EFI partition:

Quote

The EFI System Partition is the partition the EFI firmware (in ROM on the motherboard) knows of and from which the firmware can load EFI applications like boot loaders. So the ESP is the place where you put GRUB2 for the firmware to load and run. The /boot directory/partition is the place for GRUB to find files it needs, like you said. However, there is no reason the ESP and /boot can't be the same partition.

 

https://unix.stackexchange.com/questions/384494/efi-partition-vs-boot-partition

 

I used that link as it better explains it than what I had typed out.

 

As far as the boot filesystem type. I have always used an ext2 boot partition as that is what all the guides say to use.

Link to comment
Share on other sites

I'm confused again.  That link seems to contradict itself, and I note the comment regarding Debian /boot partition cannot be FAT32, which seems to indicate that I MUST have a separate /boot partition.

 

Looking at the Debian UEFI Wiki, I see the following:

https://wiki.debian.org/UEFI

I'm paying specific attention to the "debian-installer support", but note that I'm using the refracta-installer.

 

Here is the refracta installer READ ME for UEFI installs:

https://distro.ibiblio.org/refracta/files/experimental/uefi_install.readme

 

In the Debian Wiki, I also note the section discussing efibootmgr and efivar.  This catches my eye, because one of my google hits for a potential solution was this:

https://unix.stackexchange.com/questions/541489/grub-fails-to-install-during-debian-10-installer-re-uefi-supermicro-motherboa

Described problem seems very similar to mine, and I tried to implement the solution, but without success.  Although it's possible I didn't do something right, as I have no experience with chroot and limited understanding of how to accomplish.  I think I followed directions to a T, but after a marathon troubleshooting session, who the heck knows....

 

Still not sure what I'm doing wrong.  It feels like I'm missing ONE piece...the Rosetta Stone...that makes it all work, as intended.  Thoughts?

 

Link to comment
Share on other sites

securitybreach
11 minutes ago, Hedon James said:

I'm confused again.  That link seems to contradict itself, and I note the comment regarding Debian /boot partition cannot be FAT32, which seems to indicate that I MUST have a separate /boot partition.

 

Not the boot partition, the EFI partition.

Link to comment
Share on other sites

Still confused.  Your first link shows this:

 

Quote

 

However, there is no reason the ESP and /boot can't be the same partition.

answered Aug 7 '17 at 13:13
photo.jpg?sz=32
Johan Myréen
9,44811 gold badge2121 silver badges3030 bronze badges
  • 5
    Unless you are running Debian, which has a policy that /boot cannot be a FAT32 file system (which the ESP must be), because FAT32 does not support symlinks. – Johan Myréen Aug 7 '17 at 13:15

 

Link to comment
Share on other sites

securitybreach

I am talking about this part only:
 

 
Quote

The EFI System Partition is the partition the EFI firmware (in ROM on the motherboard) knows of and from which the firmware can load EFI applications like boot loaders. So the ESP is the place where you put GRUB2 for the firmware to load and run. The /boot directory/partition is the place for GRUB to find files it needs, like you said.

 

Link to comment
Share on other sites

IH0sDpK.png

 

Ignore the Windows stuff and you see my four linux partitions. Josh is correct that 250 MiB will be more than sufficient for a EFI partition. You can see that I am running /boot from my EFI partition.

 

PAXrCUT.png

 

This is my EFI/boot contents,

 

tJNDNPf.png

 

This is the contents of my /boot/EFI/refind.

 

I know that the Windows stuff complicates things a tad but I hope the shots are of some use.

 

Best of luck.😎

  • Like 1
  • +1 1
Link to comment
Share on other sites

16 hours ago, securitybreach said:

This will give you everything about uefi if you want to dig into the rabbit hole: https://wiki.debian.org/UEFI

 

I posted that link earlier in the thread.  Perhaps that's part of my problem...I dug into the rabbit hole and got lost.

 

I don't want to sound argumentative, as I'm the one asking for help from those who know more than me, but I'm just trying to understand more.  I've looked at your and Abarbarians's partition schemes, and they make sense to me.  You have a separate /boot partition.  Abarbarian has an EFI partition, mounted at /boot, but no separate partition; and Microsoft Reserved partition (recovery?); and multi-booting Windows, Arch, and Anarchy, with a shared swap partition.  Both make sense to me.

 

Referencing my first post, it SEEMS that the refractainstaller IS finding my EFI/esp partition, but "Cannot read EFI Boot* variables."  I don't understand why.  If the EFI partition is mounted at /boot/efi/ on the root partition, or whether it is mounted on a separate partition, shouldn't seem to matter to me (like it doesn't matter if /home is mounted on root partition or symlinked to separate /home partition?).  Or should it?  Unless this guy (previously posted) is correct and /boot cannot exist on a FAT32 partition?

 

16 hours ago, Hedon James said:

However, there is no reason the ESP and /boot can't be the same partition.

answered Aug 7 '17 at 13:13
photo.jpg?sz=32
Johan Myréen
9,44811 gold badge2121 silver badges3030 bronze badges
  • 5
    Unless you are running Debian, which has a policy that /boot cannot be a FAT32 file system (which the ESP must be), because FAT32 does not support symlinks. – Johan Myréen Aug 7 '17 at 13:15

 

If Johan is correct, perhaps that has something to do with the issue?  But if I understand correctly (and that is questionable?), some files are installed to /boot/efi (whether part of root, or separate partition) and some to the EFI partition for vendor firmware.  My issue doesn't seem to be /boot/efi related, it seems to be EFI/esp related.  It seems that files are getting installed to /boot/efi....but files are NOT getting installed to EFI partition because it "Cannot read EFI Boot* variables."  I was hoping Sunrat would have some thoughts, as he appears to be the resident Debian aficionado.

 

It SEEMS there should be something in the EFI partition for the refractainstaller to read, but it's an empty FAT32 partition that was newly created on a new disk for a new install.  Am I correct?  If so, WHAT should be in that EFI partition?

 

Can I copy the files in my old (currently working) EFI partition on my current disk, which is a dual-boot system that came with Windows 7 Pro pre-installed and I added Lubuntu 16.04.  Current system looks like this:

 

image.png.ffdca898ac87056488ae4fdc38c0ce22.png

 

And then mount the empty EFI partition on my new disk within my livemedia and paste the old disk EFI contents into the new disk EFI partition?  And then hope the installer "sees" boot variables and writes the newly installed Debian 10 to the list?  Or possibly "overwrites" the existing list, as there will no longer be an Lubuntu or Windows for grub to find when it updates?

 

I've got until Friday to put together some kind of game plan, as this system cannot be down from M-F.  So it's weekends only, until I get it solved.  Thanks in advance for the patience.

Edited by Hedon James
Link to comment
Share on other sites

32 minutes ago, Hedon James said:

Unless this guy (previously posted) is correct and /boot cannot exist on a FAT32 partition?

 

You can plainly see from my screen shot,

 

That I have a EFI partition created with a 32FAT file sysytem. You can also see that I have /boot installed there. So this guy whoever he is is a dickbrain.

 

23 hours ago, Hedon James said:

I have an option for a separate /boot partition in the refracta installer. 

 

Not familiar with Refacta stuff. So I am guessing that you need to make the /boot partition on the EFI partition.

 

https://jdebp.eu/FGA/efi-boot-process.html

Quote

 

You've come to this page because you've asked a question similar to the following:

What is the boot process employed by EFI (Extensible Firmware Interface) machine firmware?

This is the Frequently Given Answer to such questions.

Bootstrapping on EFI involves a boot manager that is built in to the firmware. EFI systems do not rely upon bootstrap programs stored in boot records (VBRs or MBRs) at all. The firmware knows how to read a partition table and understands the FAT filesystem format. (IBM PC compatible firmware does neither.) A designated partition, that is formatted with the FAT filesystem format and identified with a specific well-known partition type, is known as the EFI System Partition. (The EFI System Partition is a true system volume that is identified by its type code in the partition table, not a Poor Man's equivalent that is guessed at like Microsoft's System Reserved Partition is.) It contains boot loader programs, which are EFI executable programs that are loaded and run by the EFI boot manager.

EFI executable programs are standalone programs, that use only machine firmware services and that do not require an underlying operating system in order to run. They can be either operating system boot loaders or "pre-boot" maintenance/diagnosis programs.

 

😎

 

Edited by abarbarian
Link to comment
Share on other sites

V.T. Eric Layton

I'm so glad that I don't have to deal with that UEFI carp. I may keep using this old system until it's just not reparable anymore. Hopefully, I'll get another 10 years out of it. ;)

 

And when it bites the dust, I have two or three other older machines out in the shop that I can easily revive.

Link to comment
Share on other sites

securitybreach
2 hours ago, Hedon James said:

I don't want to sound argumentative, as I'm the one asking for help from those who know more than me, but I'm just trying to understand more.  I've looked at your and Abarbarians's partition schemes, and they make sense to me.  You have a separate /boot partition.  Abarbarian has an EFI partition, mounted at /boot, but no separate partition; and Microsoft Reserved partition (recovery?); and multi-booting Windows, Arch, and Anarchy, with a shared swap partition.  Both make sense to me.

 

Believe me, none of us took it that way. If it were a normal installation on Debian, it would be easier to assist but most of us have no idea what the Refractor Installer is actually doing.

  • Agree 1
Link to comment
Share on other sites

2 hours ago, securitybreach said:

 

Believe me, none of us took it that way. If it were a normal installation on Debian, it would be easier to assist but most of us have no idea what the Refractor Installer is actually doing.

 

The internet is kinda funny sometimes...you can't look someone in the eye, so all the non-verbal cues get cut from the message.  Just wanted to make sure I'm not coming across as an "askhole"....that person who always asks what to do, but never does any of it.  I just haven't seen any dots connected yet (if they did, I missed it) as to why the installer can't/won't read the EFI partition for grub installation.  I may be way off, but it just seems like something should be in that EFI partition to be read, in order for grub to get configured; but there isn't, so the installer fails.

 

Your comment about the refracta installer is a fair one.  But now you've got me thinking, maybe I should attempt a vanilla Debian installation with the Debian installer and see how that turns out?  If that works, I'll know its an issue with refractainstaller, but maybe I can install MY remix in a dual-boot configuration and the installer will finish because it found the EFI files/variables that vanilla Debian installed?

 

Or maybe I should install my Win7 Pro that came with the machine, in a UEFI configuration, duplicating the setup that the machine came with when I bought it?  Then install my remix in dual-boot, just like I like with Lubuntu on old disk?

 

Hmmm....in the absence of a veritable "i know what's going on and here's how you fix it" scenario, the dual-boot installations sound promising.  Seems like if SOMETHING was in that EFI partition to be read, everything might fall into place?  Ya got me thinking again...

Link to comment
Share on other sites

I don't know anything about Refracta either. Just a few points maybe already made, but in summary.

ESP (EFI System Partition) needs to be FAT32 and flagged as "esp" with partition editor. I usually do "boot" flag too but don't think Linux needs that, maybe Windows does.

There's no point in a separate /boot partition unless / is encrypted. It's only where GRUB files live but initial boot happens from ESP.

I was hesitant to try using UEFI until about 4 years ago with a new PC so I did some reading and installed Win 10 and siduction. It's easier than MBR system as long as you use GPT partition scheme. I've installed/reinstalled quite a few OSs since then. Just did Debian Buster netinstall twice (one for main system  and one for possibly destructive testing. I have broken it already 😈 ) last week and it easily picked up the ESP and used it.

Happy to answer any direct Debian questions if you ask. I'm afraid I got lost in all the words above so may have missed something. Possibly attributable to several classes of a nice shiraz last night closing with a Canadian Club shot. 😵

Link to comment
Share on other sites

Hey, Erik, thanks for the link in your post with info about the "poor man's EFI" partition. Explains what had puzzled me a little about the original partition setup on the refurbished Think Pad T420 I bought about 18 months ago. It had been upgraded to win10 (which I got rid of), but it seems the hardware is too old to have EFI firmware. I had wondered about the ntfs "System" partition and what its use might have been. Now I know!

Edited by ebrke
bad wording
  • +1 1
Link to comment
Share on other sites

I had a similar situation with my T430. It can use UEFI with a firmware upgrade but when I got rid of Windows 10 and installed Debian I was back to legacy BIOS and msdos formatting.

I have one laptop that runs Windows 10 with UEFI and I haven't messed with it.

My best desktop is capable of running either UEFI or BIOS and I just stuck with the legacy setup in Linux. I suppose one of these days I'll have to deal with UEFI but so far my stuff is so old it doesn't matter.

  • Like 1
Link to comment
Share on other sites

GOT IT!!!!

 

Since I probably can't recite the entire long-story, here's the short-story version: 

 

Preface - it was suggested that my brand new SSD could be failing out-of-the-box, although admittedly unlikely.  In effort to save a lot of time, ran smartmontool scan of drive.  Couldn't understand most of the output, but was pretty sure the line "no errors logged" was a good thing, so proceeded under assumption SSD was fine.

 

Problem #1 - I didn't have the package grub-efi available on my livemedia.  Apparently, 2 packages are required....grub-efi and grub-efi-ia32 or amd64.  I had the amd64 but not the grub-efi.  No problem, reboot the livemedia and install grub-efi, so that package can be copied over (rsync) from the livemedia RefractaInstaller snapshot.

 

Problem #2 - at the installer section to install a bootloader, my choices are 4 buttons "Install, Abort, Chroot, Continue".  Previous experience indicated that "Install" failed me, and I wanted to see what was going on under the hood, so chose Chroot.  Learned that Chroot does NOT mean "drop to shell and setup chroot", it means "drop to shell where chroot is already setup".  That simplified things a LOT, but the manual CLI command "dpkg -i /grub-efi*.deb" indicated no such file or directory existed, despite my installation before running installer.  I can only GUESS that the refracta2usb tool places the required files there, but since i created the livemedia with dd, they couldn't be found.  No problem, still in chroot, i type "grub-install" at the prompt and things start happening.  As an abundance of caution, I have a printout of alternative solution from another fella who experienced same errors with UEFI install of Debian.  His solution was to mount efivarfs in the chroot:

# mount -t efivarfs efivarfs /target/sys/firmware/efi/efivars

then "# chroot /target/".  From there I could type "grub-install" in terminal and watch the installation of grub happen.  In building of grub menu, noticed several warnings about "not initialized in udev database".  Back to the wormhole, where Arch forum indicates the solution has to do with a bug in lvm and/or udev, but fix is:

grub-install  --target=x86_64-efi  --efi-directory=/boot/efi  --bootloader-id=grub_uefi  --recheck

With no further errors noticed, I continue with post-installation script in RefractaInstaller and get the message to reboot the system without livemedia.  From prior experience, I look into the /boot directory and see all kinds of folders and files, several layers deep.  This is new!  So I reboot, and there's the Debian Grub Menu!!!!  It's fixed!!!

 

Problem #3 - not so fast...  I didn't install a splash screen so I could watch the messages in Debian startup.  Despite a lot of green "ok" indicators, I get to a black screen where the system hangs.  NO....NOW WHAT?!!!!  Then I remember that SDDM has a quirk where the sddm.conf file does not get copied over.  Don't know why...maybe it's SDDM, maybe it's RefractaInstaller, maybe it's something I did.  I could replace SDDM with good old LightDM, which I've never had an issue with.  But LXQt recommends SDDM as the display manager; and I'm trying to stick with the "Debian recommends...." as much as possible; and I REALLY like the sddm theme I located.  So I start looking for a tty terminal and sure enough, the terminal is waiting for a user to login.  I login with username & password, then type "startx" in terminal and....TADA....there is my DebianQT desktop!!!!

 

I know from past experience on my prior Legacy/MBR installations that I can fix the SDDM issue by generating a sample configuration, then changing the theme= line to the theme I prefer.

 

I''ve got my Firefox Sync and Google Chrome browsers syncing my bookmarks, and now I'm posting to BATL from within my brand new DebianQT OS!  😎  Now I just need to automount my DataDrive HDD at every boot, link my Thunderbird profile on DataDrive to my /home SSD, create symlinks to all my Documents, Downloads, Music, Photos, Videos, etc..., and setup my LuckyBackups to a new & larger 4TB BackupDrive!  Guess what I'll be doing for the rest of the day?!

 

Knock on wood....I think I got the switchover completed on my main production work machine, with no downtime during the work week.  (knock, knock,knock).  Looking forward to 5+/- years of LTS stability, but it's projects like this that make me yearn for a rolling release!  LOL

 

  • Agree 1
  • +1 1
Link to comment
Share on other sites

securitybreach

Great job. I didn't bother to mention your grub-install line as that is what most of the tutorials tell you to do anyway. I had always used that when installing archlinux on machines.

 

grub-install  --target=x86_64-efi  --efi-directory=/boot/efi  --bootloader-id=grub_uefi  --recheck

 

Glad that you finally got it resolved.

 

 

 

 

Link to comment
Share on other sites

@HJ I assume you were doing this Refracta exercise so you could easily install your LXQT system on "client" PCs. Will you have to go through the whole song and dance to do this every time you need to install it? Seems a bit counterproductive.

  • Like 1
Link to comment
Share on other sites

38 minutes ago, raymac46 said:

@HJ I assume you were doing this Refracta exercise so you could easily install your LXQT system on "client" PCs. Will you have to go through the whole song and dance to do this every time you need to install it? Seems a bit counterproductive.

 

Yes, Refracta is my attempt to replace Remastersys.  Won't install on "client" PCs, but I do have several computers around the house....main production machine, laptop, KODI server/media ripper, 2 KODI client NUC boxes and studio recording computer....that I like to have "duplicate" setups for the sake of simplicity.  So I like to create a "master" remix to install on all devices, then install individualized packages depending on what the machine is primarily used for.

 

And I agree, this was counter-productive!  But this was my first foray into the Debian world, and installing proprietary drivers that Ubuntu automatically probes hardware and installs drivers for.  That was a learning process that I guess was inevitable moving from user-friendly Ubuntu to do-it-yourself Debian.  And my old faithful Remastersys is no longer usable, which I was quite proficient at using.  So I had to locate a replacement and learn all the idiosyncracies of that.

 

In all fairness though, the Refracta installation worked like a champ on my legacy/MBR/BIOS installations.  No different than Remastersys used to be.  The overwhelming majority of issues encountered were due to UEFI idiosyncracies, IMO, and my unfamiliarity with UEFI.  Not to mention Secure Boot, Fast Boot, and Private Key issues....plus every time I powered off the MOBO, the UEFI resets to defaults.  So everytime I tried something new, it seemed the UEFI reset itself.  What a CLUSTER you-know-what?!  So while it was a huge PITA, I have learned some things that will hopefully serve me well in the future.  Which may yet serve to turn this into a "productive" exercise.

 

I've only got 1 more UEFI machine, and the rest are BIOS/MBR.  I only have the SDDM issue on BIOS/MBR and that's easy to deal with.  I'll probably take another look at my "master mix" in the VM and see what I can tweak in a universal manner, then create another ISO snapshot and try to use the Refracta2USB tool rather than dd.  Perhaps the Refracta tools are best used in a "chain"....RefractaSnapshot>Refracta2USB>RefractaInstaller...rather than mixing & matching.  Perhaps...

  • Like 1
Link to comment
Share on other sites

Well it has been fun in a schadenfreude sort of way to see your struggles with EFI. My only experience with UEFI/GPT was a few years ago on a desktop mobo that supports both UEFI and BIOS. At the time I didn't bother with GRUB at all - just used rEFInd which I think is a great bootloader.

However when I had to reinstall the whole system to use an SSD and an HDD I just went back to msdos. Call me a Luddite, but the old way is fine for what I need - exclusively Linux, no Microsoft.

And I have very limited experience with SDDM. I got rid of Gnome Display Manager when I installed Debian on the Thinkpad, and went with Light DM (no way to tweak GDM's battleship gray theme that I could see.)

Edited by raymac46
  • +1 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...