Closed DragonHunter274 closed 5 months ago
This should be fixed by latest changes already, assigning to Tau so they can close if actually fixed.
Nvm, just got confirmed by @axtloss
I am still facing this issue after the latest upgrade, please let me know if i can provide any logs
Could you run:
host-shell pkexec cat /var/lib/abroot/etc/vos-a/shadow
and with (vos-b):
host-shell pkexec cat /var/lib/abroot/etc/vos-b/shadow
Do not post the contents here since that is sensitive information.
Check if both files have your user in there, followed by a bunch of random symbols. Also check if there is any other obvious problems with the files. (every line should have roughly the same format)
The first and the second file should be pretty much the same.
Actually could you try this:
Open a Terminal, run:
host-shell pkexec
cd /tmp
wget https://github.com/Vanilla-OS/ABRoot/releases/download/continuous/abrootv2.tar.gz
tar -xvf abrootv2.tar.gz
/tmp/abrootv2 upgrade
Upgrading with the new abroot resulted in the system not fully booting at all, it is stuck at the grey background vanilla beta screen
The shadow files are identical
Could you try pressing Escape before it freezes and see if there is anything that's failing? (Should be red)
This is what I get
Huh, could you give me the contents of your fstab with: host-shell cat /etc/fstab
# Generated by ABRoot
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=396daf73-93a9-4f9c-9595-e11a1a1e1fa9 / btrfs defaults 0 0
/.system/usr /.system/usr none bind,ro
UUID=3d0951bd-522a-460f-90af-325e2f91ecc8 /var auto defaults 0 0
this is my fstab
Could you run
host-shell pkexec ls -Al /var/lib/AccountsService/users
host-shell mount | grep "/ "
and
host-shell pkexec ls -AlR /var/lib/abroot/etc/
I know it's probably gonna be a lot of output. Just put it into the comment and I will format it properly.
There you go:
Ah, you're missing the /etc/abroot/abroot.json file. (Probably caused by a bug in EtcBuilder that affected some installs in the past)
We can try to restore it if you want. We would need the following information:
host-shell lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS,LABEL,PARTLABEL /dev/nvme0n1
host-shell cat /usr/share/abroot/abroot.json
simon@apx-vso-pico:~$ host-shell lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS,LABEL,PARTLABEL /dev/nvme0n1
NAME SIZE TYPE MOUNTPOINTS LABEL PARTLABEL
nvme0n1 1.8T disk
├─nvme0n1p1 1G part vos-boot vos-boot
├─nvme0n1p2 512M part vos-efi vos-efi
├─nvme0n1p3 12G part /.system/usr vos-a vos-a
│ /
├─nvme0n1p4 12G part vos-b vos-b
└─nvme0n1p5 1.8T part /opt vos-var vos-var
/home
/.system/usr/lib/locale
/.system/usr/lib/locale
/var
simon@apx-vso-pico:~$ host-shell cat /usr/share/abroot/abroot.json
{
"autoRepair": true,
"maxParallelDownloads": 2,
"registry": "ghcr.io",
"registryService": "registry.ghcr.io",
"registryAPIVersion": "v2",
"name": "vanilla-os/desktop",
"tag": "main",
"iPkgMngPre": "lpkg --unlock",
"iPkgMngPost": "lpkg --lock",
"iPkgMngAdd": "apt-get install -y",
"iPkgMngRm": "apt-get remove -y --autoremove",
"iPkgMngApi": "https://packages.vanillaos.org/api/pkg/{packageName}",
"iPkgMngStatus": 2,
"differURL": "https://differ.vanillaos.org",
"partLabelVar": "vos-var",
"partLabelA": "vos-a",
"partLabelB": "vos-b",
"partLabelBoot": "vos-boot",
"partLabelEfi": "vos-efi",
"libPathStates": "/var/lib/abroot/states"
}
Ignore this, it's probably not relevant:
Hmm, the default configuration should be fine here.
It's probably not because of the config after all. You can still try it by editing the abroot config with:
host-shell pkexec nano /etc/abroot/abroot.json
and setting it to:
{
"autoRepair": true,
"maxParallelDownloads": 2,
"registry": "ghcr.io",
"registryService": "registry.ghcr.io",
"registryAPIVersion": "v2",
"name": "vanilla-os/desktop",
"tag": "main",
"iPkgMngPre": "lpkg --unlock",
"iPkgMngPost": "lpkg --lock",
"iPkgMngAdd": "apt-get install -y",
"iPkgMngRm": "apt-get remove -y --autoremove",
"iPkgMngApi": "https://packages.vanillaos.org/api/pkg/{packageName}",
"iPkgMngStatus": 2,
"differURL": "https://differ.vanillaos.org",
"partLabelVar": "vos-var",
"partLabelA": "vos-a",
"partLabelB": "vos-b",
"partLabelBoot": "vos-boot",
"partLabelEfi": "vos-efi",
"libPathStates": "/var/lib/abroot/states",
"thinProvisioning": false
}
after that run an upgrade again.
The thing is that this shouldn't really make a difference here.
Wait, what root are you currently booted into?
So which one is the working one?
I'm currently booted into vos-a
The only problem I see is that the groups aren't carried over to the new install. It's not been a problem for anyone else but you could try manually setting them:
host-shell pkexec chown root:shadow /var/lib/abroot/etc/vos-b/gshadow
Any update on this?
Issue unchanged, when using system installed ABRoot to upgrade I get the login issue, with newer ABRoot versions the freezing issue
A workaround would be running an upgrade and after that running:
host-shell pkexec cp -a /var/lib/abroot/etc/vos-x/. /var/lib/abroot/etc/vos-y/
(the point is important)
Also, x needs to be replaced by the old root (a or b lowercase) and y needs to be replaced by the root that just got upgraded.
The problem is that the issue will probably appear again after the next upgrade.
While I think the workaround worked, now everytime I try to run abroot I get this error:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb0 pc=0x1204afb]
goroutine 1 [running]:
main.main()
/home/[redacted]/ABRoot/main.go:52 +0x33b
This would suggest a wrong configuration file.
Could you run:
host-shell cat /etc/abroot/abroot.json
It's completely empty /usr/share/abroot/abroot.json has the correct file
EDIT: I deleted it and it's fine now, no idea where the empty file came from
The empty file is from the image, it's there to mitigate a bug we had. I would recommend copying the /usr/share/abroot/abroot.json file to /etc/abroot/abroot.json to make sure it doesn't randomly break in the future as we might edit it in the image.
The issue seems to be fixed, i'll close this
Issue Description
After installing the currently latest update (sha256:85d8f21bd86cec9ab88653db0e5368130ba07936564b6735188a9e91c4eff3f6) I am unable to login both through gdm or through tty Error Message in GDM: Sorry, password authentication didn't work, please try again
Steps to Reproduce
Install latest upgrade, try to log in
On what version of Vanilla OS this happens?
Unreleased
Additional Information
No response