New install not booting on second boot, disk mounting problem?
Hi, so I've done a new install wiping one disk that had OpenSUSE Slowroll installed on it and keeping two others as-they-were because they just held games and backups. First boot after installation worked fine, but when I try to re-boot I get the splash screen forever with no progress. I've attached a screenshot of what I can see when I look at the boot process.
I think it is failing to mount a disk but I cannot find the fstab when I've booted into a recovery live USB, can anyone help?
31 Replies
yeah it's tryin to mount something
but not succeeding
also yeah
you can get to fstab
it's a bit onnoying though
unless you happened to add the root account
in which case it's pretty simple
I made one user account that was the admin on install, would that be considered the root account?
no it can use sudo but it ain't root
Well then no, sadly
you noticed there's a separate root account option in the installer
we can still get to it the paths are just a bit wonky
compared to normal
I usually do this on new installs too, oh well, wonky paths it is
you can add the
emergency argument to the kernel command line
this is single user mode but in the initramfs
no root password required
mount the system partition somewhere the normal place for it on fedora atomic is /sysroot
that partition has an ostree folder
in there you have the deploy folder
in there you have fedora
in there is some random hash
in the hash folder is etc/fstab
so /sysroot/ostree/deploy/fedora/somehash/etc/fstab
oh it's deploy/fedora/deploy
there are multiple hash folders
for each system instanceOk so I've added emergency to the ostree:0 boot option and started the boot from that, it's on a step 'job dev-disk-by\xxxxxx\ running (6min/no limit)'
oh
i know of another way
init=/bin/bash
this will either work & put you into the system where you can just edit fstab
or send you to emergency mode o the initrdStick the init at the end of the linux line?
yeah
this usually switches to the real system & runs bash as the init process
handy
though it might not work the same on fedora atomic
Same thing has happened, it's hit that job again.
I presume I can access those folders if I boot into my recovery live USB so I'll try that
yeah
try that i guess
or you can mess up the ostree=
argument
Please hold while I boot off the worlds slowest USB drive 😆
this should definitely make it fail
this is why the toram option exists usually i guess
the initial boot would be just as slow though
but after it's booted you just forget the USB
Progress, so I've found fstab in
/root/ostree/deploy/HASH.0/etc/fstabnow you just fix it i guess
So the UUID that is in the job at the top is neither one of my partitions or in the fstab
In fact the fstab looks just fine
this might be the other system's fstab
if it is
you just boot the other system
boom fixed
& update
to make sure both instances are fixed
Do you mean the Ostree:1 version?
yeah
it usually says the system version
in grub
but sometimes not
I just had ostree:0 and ostree:1 in GRUB, just tried the ostree:1 and same issue
I suspect the eaiest thing is just to do a new install at this point, and totally reformat the installation drive. It was only an afternoon old so it's not the end of the world
yeah this time don't forget the root account i guess
Because I don't know what is going on with my swap partition, it should have been 24GB but is 600MB and has a weird UUID
if you ever do manual partitioning
a boot partition is required it seems
OSTree doesn't seem to work without one
To be fair I let the automatic tool do the positioning, I'll do it myself next time
Thanks for your help
oh my bad i looked at the picture again & it looks like it's trying to mount the drive in the initrd
which means fstab really doesn't matter
which explaoms why fstab wasn't the problem
the only other thing i know it can be is
/
more specifically /sysroot
that's the only partition the initrd really needs
so all we probably needed to do is change root=
on the kernel command lineOh to be fair I've not done the reformatting yet!
I was rudely asked to do my actual job so was going to do it this evening, what would need doing exactly to recover this?
you should already have
root=UUID=SOMETHING on the command line you could just add something like root=/dev/sdaX or wherever your / is
this should make it boot at least
fun fact you can also use root=LABEL=YOUR_ROOT_LABEL
if you had one
as for how you'd fix it permanently i'm not sure if it'd fix itself but you can add/overwrite kernel arguments with rpm-ostree karg root=value
i think it was
no idea why it'd mess itself up though