Support Requests - CLICK TO READ BEFORE POSTING


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Stuck at Grub cannot login
#1

Hello Lite community,

I have a broken machine. Initially it was a dual boot windows-linux-lite (32 bit).

The machine worked well. But the partition for linux was small. With Gparted I erased the old windows partition to have more space and... all hell broke loose.

I am not a complete newbie but my expertise level not sky high.  Here is what I got from grub repair…

https://paste.ubuntu.com/p/2mndMvS8qW/

I should probably add that I do recommended repair from grub.
But after repair I see the lite OS selector -now XP is gone from options as it should - but whatever I choose (latest installed or previous versions of LLite,  regular or advance boot ) it won't boot.

When I look at the various OS available options range from
vmlinux 440 generic 140, 141 and 146

If I go with more verbose version of startup  I see it reaches swap then: 

============================================
[**  ]A start job is running 1m 30 seconds
============================================

Then black then

============================================
Welcome to emergency mode! After login type « journalctl -xb » to view logs […] 
============================================


And  I cannot login.
I try enter, ‘root’, 'linux' or my own ‘admin-pass’ but it won’t work. 

As I can see nothing I type, an interface issue cannot be ruled out.
Is it possible it  lost the fact this is a 32-bit i386?

Best,

lambda user



Reply
#2

Hello All,

Okay just to say I have re-booted  with Grub-repair 32-bit and got to tools GUI with hispter looking lady jumping (not so easy after a couple crashes). So now I could do more advanced repair of grub or do some terminal with a working keyboard, etc. Hopefully some kind soul will have some advice going from here...

Best,

Lambda-user
Reply
#3

This being the weekend, I will try something. I have looked at the partions and saw /sda1/ (former xp) had a boot flag.
I removed it and put one the sda2 where I have my working os. I will also ask bootrepair to do its thing. 

Before I will also try an fsck.ext4 on /sda1/ thing.
Any opinion on the matter is still welcomed!

Best,

lambda-user
Reply
#4

If you are going to have Linux lite as your only o/s I would boot into the live environment and then into Gparted.


Delete all partitions and then Re-partition the drive.


Then a full reinstall.


Might be quicker.


Jocklad
Reply
#5

Did as I had planned:

Same difference. Here is ubuntu paste from grub-repair:

https://paste.ubuntu.com/p/5wxjGD5q8y/

I only see looking into grub-repair advance options as a way out now.

+
Lamba-User
Reply
#6

Hello Jocklad,

You are right. But I got Ardour working there with an Edirol and firewire etc. : my kids music shop. I would hate to loose that set up, which took a while to get working.  Other than that, yes I would wipe the thing.

And I might as well used advanced options on grub repair before I do... 

Lamda-user
Reply
#7

Hi [member=9237]Lambda-User[/member]

I'm assuming the windows partition was first and then your linux lite partiton, so having deleted windows you have an empty partition at the beginning of the disk.

You could move the linux lite partition to where the windows partition was, this might help:

Code:
https://help.ubuntu.com/community/MovingLinuxPartition

Owner and DJ at WKDfm Radio ( www.wkdfm.co.uk )
Reply
#8

[member=7644]DeepThought[/member] this is definitively worth a try.
Anyway this was 2nd down the line of possible improvements for the thing.
And if I read it right, seems like it could be done from grub-repair, if I can get grub repair to load again...  a difficult task right now. As there are many steps in this looks like a multi day process. I will give it a try and let you know.

Best!
lambda-user
Reply
#9

Hi [member=7644]DeepThought[/member]

I looked into MovingLinuxPartition.
  • Step 1: Booting through Rescue CD
I was already on grub-repair
  • Step 2: Create new partition
Asked gparted to help.
  • Step 3: Clone Ubuntu partition to new location
Same as above
  • Step 4: Generate and update UUID
Oups.

I did the copy with Gparted, and then I did lsblk to check where we were.

Code:
lubuntu@lubuntu:~$ lsblk NAME  MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT fd0      2:0    1      4K  0 disk loop0    7:0    0  642.9M  1 loop /rofs sda      8:0    0  55.9G  0 disk ├─sda1  8:1    0  34.5G  0 part ├─sda2  8:2    0      1K  0 part ├─sda5  8:5    0  19.4G  0 part └─sda6  8:6    0      2G  0 part sr0    11:0    1    721M  0 rom  /cdrom zram0  252:0    0 1005.9M  0 disk [SWAP]

WHERE
sda1 IS THE COPY
sda5 IS ORIGINAL
sda6 IS SWAP

HERE IS A GRAB OF GPARTED
https://tinyurl.com/yxdsoom2

You can see I flagged sda1 as boot.
As recommanded on the suggested page I checked UUID and then tried to assign a new UUID on my cloned partition.
blkid said this about the partitions:


Code:
lubuntu@lubuntu:~$ blkid /dev/sda1: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-01" /dev/sda5: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-05" /dev/sr0: UUID="2017-10-29-01-25-15-00" LABEL="Boot-Repair-Disk 32bit" TYPE="iso9660" PTUUID="7e809be6" PTTYPE="dos" /dev/loop0: TYPE="squashfs" /dev/sda6: UUID="55636d3c-1197-4022-a365-1409b12eb49b" TYPE="swap" PARTUUID="7ec4ada2-06" /dev/zram0: UUID="4701e26f-c6d4-4670-ac10-534417e5d723" TYPE="swap" /dev/sdb1: SEC_TYPE="msdos" LABEL="USB00" UUID="53A9-130E" TYPE="vfat"


I did a fsck  and then asked a random UUID from tune2fs like so:

Code:
lubuntu@lubuntu:~$ sudo fsck.ext4 /dev/sda1 e2fsck 1.43.5 (04-Aug-2017) /dev/sda1: clean, 278663/2252160 files, 3384458/9036024 blocks lubuntu@lubuntu:~$ sudo tune2fs -U random /dev/sda1 tune2fs 1.43.5 (04-Aug-2017) Setting UUID on a checksummed filesystem could take some time. Proceed anyway (or wait 5 seconds) ? (y,N) <proceeding>

After 30 minutes... Why this?  How long is long?

Code:
lubuntu@lubuntu:~$ blkid /dev/sda1: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-01" /dev/sda5: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-05" /dev/sr0: UUID="2017-10-29-01-25-15-00" LABEL="Boot-Repair-Disk 32bit" TYPE="iso9660" PTUUID="7e809be6" PTTYPE="dos" /dev/loop0: TYPE="squashfs" /dev/sda6: UUID="55636d3c-1197-4022-a365-1409b12eb49b" TYPE="swap" PARTUUID="7ec4ada2-06" /dev/zram0: UUID="4701e26f-c6d4-4670-ac10-534417e5d723" TYPE="swap" /dev/sdb1: SEC_TYPE="msdos" LABEL="USB00" UUID="53A9-130E" TYPE="vfat" lubuntu@lubuntu:~$

:'(
Reply
#10

OK twisted stuff. Went on to find someone saying you need to e2fsck the partition just before you tune2fs . So did.


Code:
lubuntu@lubuntu:~$ sudo e2fsck /dev/sda1 e2fsck 1.43.5 (04-Aug-2017) /dev/sda1: clean, 278663/2252160 files, 3384458/9036024 blocks lubuntu@lubuntu:~$ sudo tune2fs -U random /dev/sda1 tune2fs 1.43.5 (04-Aug-2017) Setting UUID on a checksummed filesystem could take some time. Proceed anyway (or wait 5 seconds) ? (y,N) <proceeding>

You would think if you blkid as suggested in the reference page you would see a difference but no...

Code:
lubuntu@lubuntu:~$ blkid /dev/sda1: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-01" /dev/sda5: UUID="b2d85e0f-559b-4350-9ec8-83860ed5740a" TYPE="ext4" PARTUUID="7ec4ada2-05" /dev/sr0: UUID="2017-10-29-01-25-15-00" LABEL="Boot-Repair-Disk 32bit" TYPE="iso9660" PTUUID="7e809be6" PTTYPE="dos" /dev/loop0: TYPE="squashfs" /dev/sda6: UUID="55636d3c-1197-4022-a365-1409b12eb49b" TYPE="swap" PARTUUID="7ec4ada2-06" /dev/zram0: UUID="4701e26f-c6d4-4670-ac10-534417e5d723" TYPE="swap" /dev/sdb1: SEC_TYPE="msdos" LABEL="USB00" UUID="53A9-130E" TYPE="vfat"

This is debian bug apparently which would be closed, but maybe not on the version used in grub-repair...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857336

Anyhow, blkid used on grub-repair 32-bit doesn't give you the straight dope.  But if you do a tune2fs -l you get

Code:
lubuntu@lubuntu:~$ sudo tune2fs -l /dev/sda1 tune2fs 1.43.5 (04-Aug-2017) Filesystem volume name:  <none> Last mounted on:          /mnt/boot-sav/sda5 Filesystem UUID:          fa18b6db-67e1-4bdb-ac96-26184cb12d35 Filesystem magic number:  0xEF53 Filesystem revision #:    1 (dynamic) Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags:        signed_directory_hash Default mount options:    user_xattr acl Filesystem state:        clean Errors behavior:          Continue Filesystem OS type:      Linux Inode count:              2252160 Block count:              9036024 Reserved block count:    451800 Free blocks:              5651566 Free inodes:              1973497 First block:              0 Block size:              4096 Fragment size:            4096 Reserved GDT blocks:      1021 Blocks per group:        32768 Fragments per group:      32768 Inodes per group:        8160 Inode blocks per group:  510 Flex block group size:    16 Filesystem created:      Thu Jul 13 03:32:17 2017 Last mount time:          Mon Apr 15 13:16:38 2019 Last write time:          Mon Apr 15 21:32:16 2019 Mount count:              0 Maximum mount count:      -1 Last checked:            Mon Apr 15 13:51:44 2019 Check interval:          0 (<none>) Lifetime writes:          182 GB Reserved blocks uid:      0 (user root) Reserved blocks gid:      0 (group root) First inode:              11 Inode size:           256 Required extra isize:    28 Desired extra isize:      28 Journal inode:            8 Default directory hash:  half_md4 Directory Hash Seed:      a1564bc5-8d00-459f-a47b-702989d3202d Journal backup:          inode blocks lubuntu@lubuntu:~$ sudo tune2fs -l /dev/sda5 tune2fs 1.43.5 (04-Aug-2017) Filesystem volume name:  <none> Last mounted on:          /mnt/boot-sav/sda5 Filesystem UUID:          7167ab0e-c4fb-49b8-912a-eb025f50f33e Filesystem magic number:  0xEF53 Filesystem revision #:    1 (dynamic) Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags:        signed_directory_hash Default mount options:    user_xattr acl Filesystem state:        clean Errors behavior:          Continue Filesystem OS type:      Linux Inode count:              1272960 Block count:              5091328 Reserved block count:    254566 Free blocks:              1769335 Free inodes:              994297 First block:              0 Block size:              4096 Fragment size:            4096 Reserved GDT blocks:      1022 Blocks per group:        32768 Fragments per group:      32768 Inodes per group:        8160 Inode blocks per group:  510 Flex block group size:    16 Filesystem created:      Thu Jul 13 03:32:17 2017 Last mount time:          Mon Apr 15 13:16:38 2019 Last write time:          Mon Apr 15 18:52:28 2019 Mount count:              0 Maximum mount count:      -1 Last checked:            Mon Apr 15 13:25:28 2019 Check interval:          0 (<none>) Lifetime writes:          182 GB Reserved blocks uid:      0 (user root) Reserved blocks gid:      0 (group root) First inode:              11 Inode size:           256 Required extra isize:    28 Desired extra isize:      28 Journal inode:            8 Default directory hash:  half_md4 Directory Hash Seed:      a1564bc5-8d00-459f-a47b-702989d3202d Journal backup:          inode blocks

The short of it is Filesystem UUID have been changed by  tune2fs  regardless of what blkid says.

Beware false negatives....
So I can mark 4 as done I guess.
And proceed to 5.
  • Step 5: Update grub and fstab


Lambda-user
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)