Skip to content
This repository has been archived by the owner on Dec 8, 2023. It is now read-only.

Storage error when installing k3os #458

Open
coryjett opened this issue May 6, 2020 · 13 comments
Open

Storage error when installing k3os #458

coryjett opened this issue May 6, 2020 · 13 comments

Comments

@coryjett
Copy link

coryjett commented May 6, 2020

I am getting a wrong fs type bad option bad superblock when both PXE booting k3os or when running sudo k3os install. It appears to be related to this block:

for i in $(lsblk -o NAME,TYPE -n | grep -w disk | awk '{print $1}'); do
if mount /dev/$i /.base; then
success=true
break
fi
done

It looks like this line is attempting to mount the disk and not a partition.

lsblk -o NAME,TYPE -n | grep -w disk | awk '{print $1}'
sda

sudo mount /dev/sda /.base
mount: /.base: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error.

Am I missing something?

@joharper54SEG
Copy link

I have seen this a couple times. The first time is was caused by a bad USB stick. The second time it happened when /dev/sda wasn't the actual drive in the machine. I had a newer intel NUC with a nvme drive, the USB stick was /dev/sda and the system drive was /dev/nvme0n1p1, so when the install ran it was trying to overwrite the USB stick.

Long story short. Make sure /dev/sda is the system drive. If its not, change the grub.cfg or specify the correct one during k3os install.

@coryjett
Copy link
Author

coryjett commented May 6, 2020

Thanks for the reply @joharper54SEG

I tried a couple of different USB drives and had the same problem. This is a NUC as well (NUC5PPYB). There isn't much going on here, just a loop device and a USB drive. I can mount the /dev/sda1 device with no problem and write data to it so it appears the USB device is working ok.

IMG_20200506_111005

IMG_20200506_112545

@joharper54SEG
Copy link

so /dev/sda is definitely your usb drive then. What is the system drive? What are you specifying for the install disk after running k3os install?

I had to look through dmesg or pay close attention to boot process to find that crazy /dev/nvme0n1p1 drive on my system.

@coryjett
Copy link
Author

coryjett commented May 6, 2020

Here is the relevant stuff from my iPXE config:

set root_dev sda

set k3os_args k3os.mode=install k3os.install.silent k3os.install.device=/dev/${root_dev} k3os.install.iso_url=${iso_loc} k3os.install.config_url=${boot_url}/k3os/config.yml k3os.install.power_off=true k3os.install.debug=true

This fails and reverts to just a live install.

On the live install, when I run sudo k3os install I get mount: /run/k3os/iso: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error. error, the installer downloads some things, and then (previously the install was straight crashing and I would lose video and have to hard reset) I get this output:

IMG_20200506_121536

@joharper54SEG
Copy link

try recreating your usb drive with the ISO. Then do a live install and see if you at least get the installer asking questions.

To me, it still sounds like /dev/sda is your USB disk and not your system drive. If you attempted to install and set /dev/sda as the install target, then it probably wiped out data on the USB drive before bombing out.

@coryjett
Copy link
Author

coryjett commented May 6, 2020

So going old-school the install is at least working:

* Burn k3os to USB using Etcher
* Insert two USB drives into NUC
* Boot off bootable k3os drive
* Install k3os to other USB drive using wizard
* Remove bootable install drive
* K3os starts booting but fails with `echo '[FATAL]' Failed to determine boot mode

I ran iPXE with basically the same config and had the same issue:

set k3os_args k3os.mode=install k3os.install.debug=true

@joharper54SEG
Copy link

Does your NUC not have an internal sata disk attached? I would imagine the steps would look like this.

  • Burn k3os to USB using Etcher
  • Boot off bootable k3os drive
  • Install k3os to internal sata drive using wizard
  • Remove bootable install drive

@coryjett
Copy link
Author

coryjett commented May 6, 2020

Not at the moment. Initially, I wanted to run a k3os cluster all in-mem but it doesn't look like there is currently a way to apply a config.yaml to a pxe-booted live install. I had a few USB drives sitting around (and this NUC has USB 3.0 ports) so I figured I would install to a USB drive and boot from that (currently what I'm trying to do).

I've got 15 NUCs and wanted to have a completely diskless k3s cluster but I'll settle for PXE booted installs to USB drives at this point. :-)

@joharper54SEG
Copy link

Ah ok. I have never tried running from RAM or USB drive. You are in new territory!

@coryjett
Copy link
Author

coryjett commented May 6, 2020

Seems like it. A USB device shouldn't be any different than any other block device (like a sata disk) but I have no idea what's going on at this point. Thanks for your time...definitely appreciate it!

@joharper54SEG
Copy link

Whats happens when you try something like this for your PXE settings?

set k3os_args k3os.mode=live k3os.install.config_url=${boot_url}/k3os/config.yml

@coryjett
Copy link
Author

coryjett commented May 6, 2020

That was actually the first config I was working on. It just PXE boots into live mode (it doesn't pull the config.yml). Looks like live mode is literally either a single instance or just an installer environment. I was going to create an issue on that as well because that would be an awesome feature.

Someone else had the same issue, waiting to hear back if they found a workaround.

BTW, I am able to PXE boot CentOS 7, install it to the USB drive, and run with no problem so I think my hardware is good.

@stuartpb
Copy link
Contributor

stuartpb commented Jun 9, 2020

This resembles a problem I'm seeing reported earliest at #376: I'll post my assessment of the issue there.

stuartpb added a commit to stuartpb/k3os that referenced this issue Jun 9, 2020
I haven't been able to test this, but I believe this would fix rancher#376, rancher#458, and rancher#462. See rancher#376 (comment)
dweomer added a commit that referenced this issue Jun 23, 2020
I haven't been able to test this, but I believe this would fix #376, #458, and #462. See #376 (comment)

Co-authored-by: Jacob Blain Christen <jacob@rancher.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants