Yes, please do.
Okay, install the grub as in the steps above, exit, & reboot with the “3” at the end of the boot command, see if you can get to a root console…
… or, if the install of grub fails, instead install it to the MBR:
grub2-install /dev/sda
In fact, it is probably better to install it to the MBR, as I understand btrfs sometimes has problems with grub installed in btrfs partition – or, at least, did so in the past in certain circumstances.
Bad luck. Same rapid beeping from bios.
even w/ install DVDs, choosing ‘boot from hd’ gives beeps. >:(
Oops, I over looked the mbr install.
will do that now
If that does not work, we might have to try to fix the mount points first, then re-install grub. Probability of new UUIDs interfering.
Grub started from MBR, I thought it hung but while typing this I was welcomed to ‘emergency mode’.
there are > 30 lines of bad tree block start.
After logging in, type "journalctl -xb to view system logs, "system to reboot" to reboot, "system to default" to try again to boot into default mode
after this more bad tree blocks.
guess this explains why when I looked at sda2/var/logs in live cd I did not see anything :’(
I’m logged into sda2 as root awaiting further advise…
Oops, I made some typos in last post, that auto correct gets me every time.
the word ‘to’ was added into the quoted commands, perhaps you recognized that anyway.
Trying to get the screen message text correct:
After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode
Okay.
Let’s first try fixing mount points.
We will do that using the Yast partitioner, by launching the text version of Yast. Do:
yast
Down arrow to system, then use the tab to go to the right window, down arrow to partitioner and hit “Enter”.
Tab to left window, down arrow to Hard Disks, hit “Enter”
Tab to right window, down arrow to root partition (sda2 ?), hit “Alt-e”
Make sure the “x” is in Do not format partition
Tab to Mounting Options, make sure the “x” is in Mount partition
Tab again to Mount Point, hit the down arrow, choose / for root
Do not bother with Fstab options.
Tab to Finish & hit “Enter”
Tab to the right window in the Hard Disks list again, down arrow to get to the home partition, sda3, and follow the same procedure to mount it as /home
Always make certain that Do not format partition is chosen.
Back at the Hard Disks list, use your arrows to get to the Swap partition (sda1) and, same routine, mount it as swap
When ready, these should be the only entries under the Mount Point column. If not, unmount any others.
Finish out of the partitioner.
You will still be in Yast, so up arrow to Boot Loader. You should probably be able to see what needs to be done there. If not, let me know.
This should install your bootloader properly, but to make sure, you can always run the grub2-mkconfig and the grub2-install commands again right from the root console.
So / and /home were set correctly. Swap was not set and now is.
FWIW, each new screen in yast produces the bad tree block errors.
bootloader, ‘enter’ produces error.
internal error. Please report a bug report w/ logs.
Details: expected a Hash, got a FalseClass
Caller: /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:511:in 'mapmap'
progress bar for boot loader settings is stopped at 66%.
awaiting advise.
BTW, I don’t know if it matters but the grub install done earlier had screen output referring to i386 on this x64 machine.
If it is still hung, kill the process and drop out of Yast.
Try the mkconfig and grub install from the command line, report back.
On boot, Welcome to Grub, then “invalid environment block”
I get the grub menu.
Booting takes a very long time with the bad tree block, finally giving me the same emergency mode error as reported earlier.
there are less bad tree block errors than before.
Would fsck be useful?
Yes, I would start with that. Run it from the Rescue DVD.
btrfs check /dev/sda2 has endless scrolling screen of errors. Been going on for several minutes and of course I cannot read any of it.
guess the entire restore is messed up. I’m thinking another shot at clonezilla and if that fails I still have a file backup I can try.
I’m signing out for the night.
thanks
Okay, see you tomorrow.
If you decide to try again to restore sda2 with Clonezilla, this time DESELECT the following option, keep other options the same as before.
[li] -r Try to resize the filesystem to fit partition size[/li]
It may be that the resize caused the problems in btrfs.
Also, snapshots might be causing a problem after such a move. I expect that none of the snapshots will be valid, now.
I did another restore.
I used gParted to reformat sda2 to btrfs.
I then did a
btrfs check /dev/sda2
and it was clean with no errors, and of course, no files.
I ran the restore partition (also checking that the image was restorable), omitting the -r as suggested. I received 2 warnings, both expected. Restore not creating partition table and also not restoring mbr.
I am now booted in Leap LiveCD and the above command had many errors relating to checksums, inodes, and I forget what else as the screen scrolled past.
This is a snippet at the end of the process:
root 1697 inode 1105013 errors 2001, no inode item, link count wrong
unresolved ref dir 71518 index 197 namelen 11 name repo-update filetype 2 errors 4, no inode ref
root 1697 inode 1105015 errors 2001, no inode item, link count wrong
unresolved ref dir 132099 index 331892 namelen 8 name wins.dat filetype 1 errors 4, no inode ref
root 1697 inode 1105024 errors 2001, no inode item, link count wrong
unresolved ref dir 1110 index 4618 namelen 5 name yast2 filetype 1 errors 4, no inode ref
found 17409757217 bytes used err is 1
total csum bytes: 14592736
total tree bytes: 1234878464
total fs tree bytes: 1177501696
total extent tree bytes: 37781504
btree space waste bytes: 190582807
file data blocks allocated: 65080954880
referenced 33851822080
btrfs-progs v4.1.2+20151002
extent buffer leak: start 8808333312 len 16384
extent buffer leak: start 8808333312 len 16384
extent buffer leak: start 8808333312 len 16384
extent buffer leak: start 8808333312 len 16384
There is always the possibility that there is indeed something wrong with the image. However,
fsck /dev/sda3
for /home came up clean and the images were made at the same time so I have to assume that there were no system errors when clonezilla was run. I wonder if restoring to different partition is not doable w/ btrfs partition.
I have not proceeded to fiddle with chroot & grub since the above errors indicate a FS issue that is likely going to prevent further progress unless it is corrected. I note that there are rescue & recovery options for btrfs but don’t know enough about them.
My remaining option is to figure out what rsync commands I need to try restoring backup made with luckyBackup, or to do a fresh install.
Okay. You did not run btrfs check with the --repair option, did you?
I suggest not doing so, and instead leave it untouched at the state Clonezilla restored it.
Now, I think the best solution at this point would be to insert the Leap Install DVD and choose the Upgrade option. This will restore the Leap internals and system to the version on the DVD, but will keep most of the customizing you have done and will repair many problems, perhaps might fix the btrfs problems and will install the proper Grub setup.
Immediately on finishing the “Upgrade”, run all updates.
I am waiting here.
Gerry:
Correct, I did not run --repair. Just basic check.
Currently ‘upgrade’ in progress. In note the installation summary shows booting is from /root and not mbr, code will be written to mbr. Some packages are failing on upgrade, I am ignoring them. Currently failed are all from Packman - Amarok, k3b, and Spectacle (prob spelled wrong). But when done I will activate Packman and update, IF it boots. 
– what you have done here, though, is convince me not to use the btrfs file system on any production machines, yet. If you had originally installed with ext4, you would have been back up and running a long time ago.
… but, I need to set up a test machine and use btrfs on it so I can shake and twist it, see if I can snap the head off the snake that it is.
Reading the btrfs Wiki, I see that it – especially the tools collection – still has a long way to go. Others may disagree (I would have, up until now), but I believe the btrfs file system is far too complicated for the general public, and especially for any Linux newbies or those who do not want to play “geek”, at this stage in its development.:\