Hi All,
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
-- Br, A.
Hi,
Am Montag, 13. September 2021, 10:55:44 CEST schrieb Attila Pinter:
Hi All,
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking for the disk still.
How is the disk attached to the system? If you have the journal of a working GCP instance, that could show what the missing part might be. If you have access to dracut's emergency console, you can dig around with "lsblk", "blkid" and similar tools.
Probably just a missing module in the initrd or maybe GCP deployment tries to change the filesystem's UUID to make it actually unique.
Cheers, Fabian
-- Br, A.
Hi Fabian,
On Monday, September 13th, 2021 at 4:12 PM, Fabian Vogt fvogt@suse.de wrote:
Hi,
Am Montag, 13. September 2021, 10:55:44 CEST schrieb Attila Pinter:
Hi All,
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking
for the disk still.
How is the disk attached to the system? If you have the journal of a working
GCP instance, that could show what the missing part might be. If you have
access to dracut's emergency console, you can dig around with "lsblk", "blkid"
and similar tools.
I did try that, but I don't seem to have access to `lsblk` or even `df` or similar tools unfortunately.
Probably just a missing module in the initrd or maybe GCP deployment tries
to change the filesystem's UUID to make it actually unique.
Did have that assumption as well, but I'm not fully aware as how that tries to make it happen unfortunately. I thought that by installing the required GCP tools would solve that, but unfortunately it did not turn out to be as simple as that. I did however attached the same boot disk to another Leap VM where everything seems to be fine, but I can't edit anything in `/etc`. Without at least some tools in the ER shell I'm kinda stuck here, but your idea of checking `initrd` and the modules it has in the Leap instance could provide some much needed insight which I could implement in the VM. Going to report back with my findings probably tomorrow.
Cheers,
Fabian
--
Br,
A.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, September 13th, 2021 at 8:32 PM, Attila Pinter adathor@protonmail.com wrote:
Hi Fabian,
On Monday, September 13th, 2021 at 4:12 PM, Fabian Vogt fvogt@suse.de wrote:
Hi,
Am Montag, 13. September 2021, 10:55:44 CEST schrieb Attila Pinter:
Hi All,
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking
for the disk still.
How is the disk attached to the system? If you have the journal of a working
GCP instance, that could show what the missing part might be. If you have
access to dracut's emergency console, you can dig around with "lsblk", "blkid"
and similar tools.
I did try that, but I don't seem to have access to `lsblk` or even `df` or similar tools unfortunately.
Probably just a missing module in the initrd or maybe GCP deployment tries
to change the filesystem's UUID to make it actually unique.
Did have that assumption as well, but I'm not fully aware as how that tries to make it happen unfortunately. I thought that by installing the required GCP tools would solve that, but unfortunately it did not turn out to be as simple as that. I did however attached the same boot disk to another Leap VM where everything seems to be fine, but I can't edit anything in `/etc`. Without at least some tools in the ER shell I'm kinda stuck here, but your idea of checking `initrd` and the modules it has in the Leap instance could provide some much needed insight which I could implement in the VM.
Going to report back with my findings probably tomorrow.
Cheers,
Fabian
--
Br,
A.
Before I hit the bed figured I could leave here the `lsinitrd` outputs as well in which I already noticed some pretty significant differences and why I can't access tools like `lsblk`. See some missing Google modules as well. MicroOS initrd: https://paste.opensuse.org/17237977 Leap GCP initrd: https://paste.opensuse.org/52805094
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, September 13th, 2021 at 8:55 PM, Attila Pinter adathor@protonmail.com wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, September 13th, 2021 at 8:32 PM, Attila Pinter adathor@protonmail.com wrote:
Hi Fabian,
On Monday, September 13th, 2021 at 4:12 PM, Fabian Vogt fvogt@suse.de wrote:
Hi,
Am Montag, 13. September 2021, 10:55:44 CEST schrieb Attila Pinter:
Hi All,
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking
for the disk still.
How is the disk attached to the system? If you have the journal of a working
GCP instance, that could show what the missing part might be. If you have
access to dracut's emergency console, you can dig around with "lsblk", "blkid"
and similar tools.
I did try that, but I don't seem to have access to `lsblk` or even `df` or similar tools unfortunately.
Probably just a missing module in the initrd or maybe GCP deployment tries
to change the filesystem's UUID to make it actually unique.
Did have that assumption as well, but I'm not fully aware as how that tries to make it happen unfortunately. I thought that by installing the required GCP tools would solve that, but unfortunately it did not turn out to be as simple as that. I did however attached the same boot disk to another Leap VM where everything seems to be fine, but I can't edit anything in `/etc`. Without at least some tools in the ER shell I'm kinda stuck here, but your idea of checking `initrd` and the modules it has in the Leap instance could provide some much needed insight which I could implement in the VM.
Going to report back with my findings probably tomorrow.
Cheers,
Fabian
--
Br,
A.
Before I hit the bed figured I could leave here the `lsinitrd` outputs as well in which I already noticed some pretty significant differences and why I can't access tools like `lsblk`. See some missing Google modules as well.
MicroOS initrd: https://paste.opensuse.org/17237977
Leap GCP initrd: https://paste.opensuse.org/52805094
Applied the missing initrd modules as suggested and stuck at the same error as before (https://paste.opensuse.org/34392008) :/ Not sure what else to try or do....
Hi,
Am Dienstag, 14. September 2021, 19:22:44 CEST schrieb Attila Pinter:
...
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking for the disk still.
How is the disk attached to the system? If you have the journal of a working GCP instance, that could show what the missing part might be. If you have access to dracut's emergency console, you can dig around with "lsblk", "blkid" and similar tools.
I did try that, but I don't seem to have access to `lsblk` or even `df` or similar tools unfortunately.
Probably just a missing module in the initrd or maybe GCP deployment tries to change the filesystem's UUID to make it actually unique.
Did have that assumption as well, but I'm not fully aware as how that tries to make it happen unfortunately. I thought that by installing the required GCP tools would solve that, but unfortunately it did not turn out to be as simple as that. I did however attached the same boot disk to another Leap VM where everything seems to be fine, but I can't edit anything in `/etc`. Without at least some tools in the ER shell I'm kinda stuck here, but your idea of checking `initrd` and the modules it has in the Leap instance could provide some much needed insight which I could implement in the VM.
Going to report back with my findings probably tomorrow.
...
Before I hit the bed figured I could leave here the `lsinitrd` outputs as well in which I already noticed some pretty significant differences and why I can't access tools like `lsblk`. See some missing Google modules as well.
MicroOS initrd: https://paste.opensuse.org/17237977 Leap GCP initrd: https://paste.opensuse.org/52805094
Applied the missing initrd modules as suggested and stuck at the same error as before (https://paste.opensuse.org/34392008) :/ Not sure what else to try or do....
You can use the booting Leap to figure out how exactly the root filesyystem is connected. findmnt + hwinfo should be enough for that.
If that's not enough info, an image which has some debugging tools in the initrd (though usually looking through sysfs is sufficient) might help.
Cheers, Fabian
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, September 16th, 2021 at 9:51 PM, Fabian Vogt fvogt@suse.de wrote:
Hi,
Am Dienstag, 14. September 2021, 19:22:44 CEST schrieb Attila Pinter:
...
Since last week I've been trying to get a MicroOS image running - with the intention of maintaining the image for the masses - in Google Cloud with not a lot of success. I'm currently at the stage where I have a ready image with google-guest-configs; google-osconfig-agent; google-guest-oslogin; google-guest-agent installed and enabled, but the image can't boot and stops looking for a disk by UUID (more here: https://paste.opensuse.org/34392008). Looking at GCP `btrfs` is not exactly supported, I assume this is the reason behind Leap 15.3 being installed on `XFS` as well, but I'm just making assumptions at this point. Does anybody has any ideas if this is possible at all or should I just skip this?
I don't think this is filesystem related, because at this point it's looking
for the disk still.
How is the disk attached to the system? If you have the journal of a working
GCP instance, that could show what the missing part might be. If you have
access to dracut's emergency console, you can dig around with "lsblk", "blkid"
and similar tools.
I did try that, but I don't seem to have access to `lsblk` or even `df` or similar tools unfortunately.
Probably just a missing module in the initrd or maybe GCP deployment tries
to change the filesystem's UUID to make it actually unique.
Did have that assumption as well, but I'm not fully aware as how that tries to make it happen unfortunately. I thought that by installing the required GCP tools would solve that, but unfortunately it did not turn out to be as simple as that. I did however attached the same boot disk to another Leap VM where everything seems to be fine, but I can't edit anything in `/etc`. Without at least some tools in the ER shell I'm kinda stuck here, but your idea of checking `initrd` and the modules it has in the Leap instance could provide some much needed insight which I could implement in the VM.
Going to report back with my findings probably tomorrow.
...
Before I hit the bed figured I could leave here the `lsinitrd` outputs as well in which I already noticed some pretty significant differences and why I can't access tools like `lsblk`. See some missing Google modules as well.
MicroOS initrd: https://paste.opensuse.org/17237977
Leap GCP initrd: https://paste.opensuse.org/52805094
Applied the missing initrd modules as suggested and stuck at the same error as before (https://paste.opensuse.org/34392008) :/
Not sure what else to try or do....
You can use the booting Leap to figure out how exactly the root filesyystem is
connected. findmnt + hwinfo should be enough for that.
If that's not enough info, an image which has some debugging tools in the
initrd (though usually looking through sysfs is sufficient) might help.
Cheers,
Fabian
Hi,
Didn't give up on this project at all, but ran out of time at work so had to take a different approach and went with Fedora CoreOS as it is already available from GCP as an officially supported image. I think the problem I was facing with is not only missing packages and such, but trying to approach the whole thing as if it were a regular distro I want to get into GCP. Probably a better approach would be to try and test - with the current image that would actually work - with a Combustion/Ignition script again. Which would probably help, but it couldn't even pick up the boot disk UUID so... unsure. Would be more than open for suggestions and guidance on the subject.
Br, A.
-
Attila Pinter -
Fabian Vogt