Looks like I managed to figure it out by looking at journalctl -xb on the last boot before the succe

RRyuzaki Koizumi Looks like I managed to figure it out by looking at journalctl -xb on the last b...

K

Kyle Gospo•7/16/24, 4:08 AM

You can put a no fail on it

R

Ryuzaki KoizumiOP•7/16/24, 4:08 AM

How so?

R

Ryuzaki KoizumiOP•7/16/24, 4:09 AM

I need Bazzite to reliably boot.

RRyuzaki Koizumi How so?

K

Kyle Gospo•7/16/24, 4:09 AM

nofail

nofail

nofail

nofail as a mount option

K

Kyle Gospo•7/16/24, 4:09 AM

Will stop it from dumping to emergency

K

Kyle Gospo•7/16/24, 4:09 AM

Then you can figure out why it's not mounting sometimes

R

Ryuzaki KoizumiOP•7/16/24, 4:10 AM

RIght.... when I did see the journal I did see this:

Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme0n1p1
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: /dev/nvme0n1p1:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: The superblock could not be read or does not describe a valid ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem (and not swap or ufs or something else), then the superblock
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: is corrupt, and you might try running e2fsck with an alternate superblock:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 8193 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:  or
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 32768 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2274]: /dev/nvme0n1p2: recovering journal
Jul 15 22:27:02 KiriSuna audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=emergency comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 15 22:27:02 KiriSuna systemd[1]: Started emergency.service - Emergency Shell.

Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme0n1p1
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: /dev/nvme0n1p1:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: The superblock could not be read or does not describe a valid ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem (and not swap or ufs or something else), then the superblock
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: is corrupt, and you might try running e2fsck with an alternate superblock:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 8193 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:  or
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 32768 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2274]: /dev/nvme0n1p2: recovering journal
Jul 15 22:27:02 KiriSuna audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=emergency comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 15 22:27:02 KiriSuna systemd[1]: Started emergency.service - Emergency Shell.

Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme0n1p1
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: /dev/nvme0n1p1:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: The superblock could not be read or does not describe a valid ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem (and not swap or ufs or something else), then the superblock
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: is corrupt, and you might try running e2fsck with an alternate superblock:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 8193 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:  or
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 32768 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2274]: /dev/nvme0n1p2: recovering journal
Jul 15 22:27:02 KiriSuna audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=emergency comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 15 22:27:02 KiriSuna systemd[1]: Started emergency.service - Emergency Shell.

Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme0n1p1
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: /dev/nvme0n1p1:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: The superblock could not be read or does not describe a valid ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: filesystem (and not swap or ufs or something else), then the superblock
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]: is corrupt, and you might try running e2fsck with an alternate superblock:
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 8193 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:  or
Jul 15 22:27:02 KiriSuna systemd-fsck[2241]:     e2fsck -b 32768 <device>
Jul 15 22:27:02 KiriSuna systemd-fsck[2274]: /dev/nvme0n1p2: recovering journal
Jul 15 22:27:02 KiriSuna audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=emergency comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 15 22:27:02 KiriSuna systemd[1]: Started emergency.service - Emergency Shell.

R

Ryuzaki KoizumiOP•7/16/24, 4:12 AM

could this so-called bad magic number cause it to fail?

K

Kyle Gospo•7/16/24, 4:12 AM

Very possible

Ttryhardsoccermomswag https://universal-blue.discourse.group/docs?topic=2656 you either install the no...

C

Cat Pilot•7/16/24, 4:21 AM

thanks

OOzzyrockin also I get this when trying to use the system update app ```Terminal kitty not f...

K

Kyle Gospo•7/16/24, 4:21 AM

We don't ship Kitty, if you changed your terminal to kitty I would recommend changing it back

A

arongkatz•7/16/24, 4:22 AM

does someone know why a game installed via lutris from ubisoft connect may not detect gamepad on game mode but itll work on desktop mode?

A

arongkatz•7/16/24, 4:22 AM

valhalla works on desktop but if i open the game directly on steam on game mode its not detecting the controls

A

arongkatz•7/16/24, 4:23 AM

just my device keyboard

C

Crono•7/16/24, 4:49 AM

Side effect from the recent changes to

/etc/os-release

/etc/os-release

/etc/os-release

/etc/os-release?

C

Crono•7/16/24, 4:50 AM

If I recall correctly, that source used to be listed as 'Fedora'

J

Janier•7/16/24, 4:51 AM

there is a problem if i update using sudo rpm-ostree upgrade?

C

Crono•7/16/24, 4:52 AM

rpm-ostree doesn't need sudo

C

Crono•7/16/24, 4:52 AM

Otherwise you'll be missing the other things Topgrade updates

C

Crono•7/16/24, 4:52 AM

As in, you'll only be updating your base image

J

Janier•7/16/24, 4:52 AM

but it will not cause anyproblem at future? i just updat using it so i dont know if rollback

C

Crono•7/16/24, 4:53 AM

Why not just run

ujust update

ujust update

?

J

Janier•7/16/24, 4:53 AM

im dumb idk why i use it

C

Crono•7/16/24, 4:54 AM

ujust update

ujust update

updates the base image and everything else

J

Janier•7/16/24, 4:54 AM

if i just ujust update it will be no problem then?

C

Crono•7/16/24, 4:54 AM

If you're on a desktop image it's going to do it automatically in the background even

J

Janier•7/16/24, 4:54 AM

yeah destokpt

C

Crono•7/16/24, 4:55 AM

No need to run it then, just reboot every once in a while and you'll be up to date

C

Crono•7/16/24, 4:55 AM

As you need to reboot to boot to your new updated image

J

Janier•7/16/24, 4:56 AM

ty,how is it works the auto update? it will try update when you boot your pc and you are doing nothing heavy?

JJanier but it will not cause anyproblem at future? i just updat using it so i dont know...

A

asen23•7/16/24, 4:56 AM

ujust update run rpm-ostree update internally, afaik rpm-ostree upgrade is also an alias to update so no problem

C

Crono•7/16/24, 4:56 AM

If you really want to be sure you're up to date you don't even need to type on the terminal, just run the 'Update System' shortcut from your app launcher

J

Janier•7/16/24, 4:56 AM

nice ty

J

Janier•7/16/24, 4:57 AM

yeah that i always use in general

JJanier ty,how is it works the auto update? it will try update when you boot your pc and...

C

Crono•7/16/24, 4:57 AM

It detects if you're not doing anything intensive and if you're not it begins updating

J

Janier•7/16/24, 4:58 AM

ok,ty for the answers

C

Crono•7/16/24, 4:58 AM

It does check a little bit after boot up usually

T

Techz•7/16/24, 5:29 AM

Any reason why sd card not mounting on restarts? I either need to reinsert or go into desktop and click on the side folder which seems to remount

TTechz Any reason why sd card not mounting on restarts? I either need to reinsert or go...

K

Kyle Gospo•7/16/24, 5:29 AM

works fine here

K

Kyle Gospo•7/16/24, 5:29 AM

would need more info

K

Kyle Gospo•7/16/24, 5:30 AM

is it btrfs formatted?

T

Techz•7/16/24, 5:30 AM

Nope ext4

K

Kyle Gospo•7/16/24, 5:30 AM

did you change the definition in /etc/default/steamos-btrfs?

K

Kyle Gospo•7/16/24, 5:31 AM

we use btrfs by default so if you've manually partitioned as ext4 it's going to be ignored without updating that.

K

Kyle Gospo•7/16/24, 5:31 AM

hence the need to manually mount it

T

Techz•7/16/24, 5:31 AM

Nah haven’t touched anything there I was on ally branch moved into deck lately

F

Frityet•7/16/24, 6:01 AM

Vivecraft looks for SteamVR's LWGL in order to launch the VR stuff, but it cant find this if your launcher is in a flatpak. Is there a good way to make this work on bazzite

F

Frityet•7/16/24, 6:02 AM

or should I just overlay it

F

Frityet•7/16/24, 6:12 AM

solution found

F

Frityet•7/16/24, 6:12 AM

installed prismlauncher in a distrobox

Looks like I managed to figure it out by looking at journalctl -xb on the last boot before the succe

Similar Threads

Similar Threads

Similar Threads