Re: r324353: boot failure: failed with error 19

[Ian Lepore]

On Fri, 2017-10-06 at 22:33 +0200, O. Hartmann wrote:
> First of all, I think something has changed, since /dev/ufs doesn't get 
> populated anymore
> by usage of "gpart label" command. Second, there is a high chance that I 
> messed up
> NanoBSD a bit, a couple of days ago I tried to sync with the code base 
> changes and I made
> most changes effectively what is now "legacy.sh".

Here is the crucial error...  Labels created with glabel are in
/dev/label, they have never been in /dev/ufs.

/dev/ufs is populated by the contents of ufs filesystem labels, which
are created using "newfs -L" or "tunefs -L".  To see what label (if
any) is on your root filesystem, use:

  # dumpfs / | grep vol
  volname   roots1  swuid   0   providersize262135

If nothing appears between "volname" and "swuid" it has no label.

I'm not disputing something may have changed that is causing you
problems, I'm just trying to point out that you are chasing the wrong
cause based on some kind of misunderstanding of the symptoms.

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r324353: boot failure: failed with error 19

[O. Hartmann]

Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST)
Trond Endrestøl  schrieb:

> On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:
> 
> > I run a small appliance on an APU from PCengines. This box is bootet via SD 
> > card, the
> > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning 
> > and
> > booting images.
> > 
> > That worked until two days ago (I do not track the revision numer) when I 
> > wrote (via
> > dd) the last image out. Today, I tried to boot r324353 and it fails at tthe 
> > boot
> > loader:
> > 
> > 
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> > 
> > 
> > I can proceed by manually issuing at the loader propmpt
> > 
> > ufs:/dev/gpt/dsks1a
> > 
> > and booting proceeds as expected.  
> > 
> > 
> > Something seems wrong with the UFS labeling lately.
> >   
> 
> > The gpt layout looks like this:
> > 
> > gpart show -l:
> >   
> > =>  40  60751792  mmcsd0  GPT  (29G)  
> > 40   130   1  boot  (65K)
> >170 6  - free -  (3.0K)
> >176   2057288   2  dsks1a  [bootme]  (1.0G)
> >2057464   2061725   3  dsks2a  (1.0G)
> >4119189   1048576   4  dsks3  (512M)
> >5167765  55584067  - free -  (27G)  
> 
> For one, these are the GPT labels.
> 
> Can you verify the UFS labels (volnames)?
> 
> Try: dumpfs /dev/gpt/dsks1a
> 
> > From dmesg. I can provide this last output:
> > 
> > [...]
> > mmcsd0: 31GB  at mmc0
> > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a 
> > [ro]...
> > uhub0: 4 ports with 4 removable, self powered
> > Root mount waiting for: usbus1
> > uhub1: 2 ports with 2 removable, self powered
> > Root mount waiting for: usbus1
> > ugen1.2:  at usbus1
> > uhub2 on uhub1
> > uhub2:  on 
> > usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> > 
> > Loader variables:
> >   vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
> >   vfs.root.mountfrom.options=ro
> > 
> > Manual root filesystem specification:
> >   : [options]
> >   Mount  using filesystem 
> >   and with the specified (optional) option list.
> > 
> > eg. ufs:/dev/da0s1a
> > zfs:tank
> > cd9660:/dev/cd0 ro
> >   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> > 
> >   ?   List valid disk boot devices
> >   .   Yield 1 second (for background tasks)
> >   Abort manual input
> >   
> > mountroot> Trying to mount root from 
> > ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs []...  
> > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> > random: unblocking device.
> > arc4random: no preloaded entropy cache  
> 
> > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. 
> >  

This is because me stupid hit the backspace key in the boot loader console :-(

> 
> This surely indicates a mangled UFS volname.
> 
> Maybe you should rewrite the volname:
> 
> tunefs -L dsk1a /dev/gpt/dsks1a

NanoBSD, the original one, defines a "NANO_DRIVE", which is the expansion
of /ufs/"NANO_LABEL". When creating the memory backed filesystem via gpart, the 
label is
given by the option "-l ${NANO_LABEL}${NANO_CFG_LBL}". NANO_LABEL is set to 
"dsk".
NANO_CFG_LBL is an extension of my own - I needed for a project GPT/UEFI 
booting NanoBSD
images and I wanted to stay compatible with the code given by Kamp et al., so
NANO_CFG_LBL is set to s3. This should then provide the fstab entry 
"/dev/ufs/dsks3" for
the cfg partition. Accordingly, the primary boot partition has 
"/dev/ufs/dsks1a". It is a
bit messy, since I was in a hurry and had to deal with this crappy MBR slice 
style s1a
through s1h.

This is what I setup in "defaults-add.sh", just to give the impression, what I 
intended
to do:

[...]
# Set NANO_LABEL to non-blank to form the basis for using /dev/ufs/label
# in preference to /dev/${NANO_DRIVE}
# Root partition will be ${NANO_LABEL}s{1,2}
# /cfg partition will be ${NANO_LABEL}s3
# /data partition will be ${NANO_LABEL}s4
: ${NANO_LABEL="dsk"}
#
# Labels for the boot and EFI boot partitions
: ${NANO_BOOT_LBL="boot0"}
: ${NANO_EFI_LBL="efiboot0"}
#
# Label extensions: form, i.e., ${NANO_LABEL}${NANO_ROOT_LBL}
: ${NANO_ROOT_LBL="s1a"}
: ${NANO_ALTROOT_LBL="s2a"}
: ${NANO_CFG_LBL="s3"}
: ${NANO_DATA_LBL="s4"}
#
: ${NANO_SLICE_ROOT="s1"}
: ${NANO_SLICE_ALTROOT="s2"}
: ${NANO_SLICE_CFG="s3"}
: ${NANO_SLICE_DATA="s4"}
[...]

The file "defaults-add.sh" is read by "nanobsd.sh" before "defaults.sh" is 
read. In
"defaults.sh" I altered also all initially set variables to be of the form 
": $VARIABLE=Setting}" so my own settings aren't overwritten by accident and 
later, when
the driver script of nanobsd is setup, one can set his own variables like
VARIABLE=Setting to overwrite the initial settings. The above should give in 

Re: r324353: boot failure: failed with error 19

[O. Hartmann]

Am Fri, 6 Oct 2017 07:10:44 -0700
Warner Losh  schrieb:

> On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann  wrote:
> 
> > I run a small appliance on an APU from PCengines. This box is bootet via
> > SD card, the
> > image is created by a modified NanoBSD, which creates GPT/UEFI
> > partitioning and booting
> > images.
> >
> > That worked until two days ago (I do not track the revision numer) when I
> > wrote (via dd)
> > the last image out. Today, I tried to boot r324353 and it fails at tthe
> > boot loader:
> >
> >
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> >  
> 
> That's odd... But likely a race  It could be that dd'ing the new
> partition, however, was made from an image that didn't have the proper ufs
> label.

The images I write out seem to have the correct /dev/gpt/ entries, but the 
/dev/ufs
entries are missing.  Writing labels with glabel produces entries in 
/dev/label/, but I
still miss those in /dev/ufs/. This is more than confusing.

> 
> What's the rev of the last version that worked?

As I wrote before, I do not track and since the image has been overwritten, I 
do not
know. But it isn't older than two days.


> 
> Warner
> 
> 
> > I can proceed by manually issuing at the loader propmpt
> >
> > ufs:/dev/gpt/dsks1a
> >
> > and booting proceeds as expected.
> >
> >
> > Something seems wrong with the UFS labeling lately.
> >
> > The gpt layout looks like this:
> >
> > gpart show -l:
> >  
> > =>  40  60751792  mmcsd0  GPT  (29G)  
> > 40   130   1  boot  (65K)
> >170 6  - free -  (3.0K)
> >176   2057288   2  dsks1a  [bootme]  (1.0G)
> >2057464   2061725   3  dsks2a  (1.0G)
> >4119189   1048576   4  dsks3  (512M)
> >5167765  55584067  - free -  (27G)
> >
> > From dmesg. I can provide this last output:
> >
> > [...]
> > mmcsd0: 31GB  at mmc0
> > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a
> > [ro]...
> > uhub0: 4 ports with 4 removable, self powered
> > Root mount waiting for: usbus1
> > uhub1: 2 ports with 2 removable, self powered
> > Root mount waiting for: usbus1
> > ugen1.2:  at usbus1
> > uhub2 on uhub1
> > uhub2:  on
> > usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> >
> > Loader variables:
> >   vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
> >   vfs.root.mountfrom.options=ro
> >
> > Manual root filesystem specification:
> >   : [options]
> >   Mount  using filesystem 
> >   and with the specified (optional) option list.
> >
> > eg. ufs:/dev/da0s1a
> > zfs:tank
> > cd9660:/dev/cd0 ro
> >   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> >
> >   ?   List valid disk boot devices
> >   .   Yield 1 second (for background tasks)
> >   Abort manual input
> >  
> > mountroot> Trying to mount root from 
> > ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs  
> > []...
> > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> > random: unblocking device.
> > arc4random: no preloaded entropy cache
> > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error
> > 19.
> >  
> > mountroot> Invalid file system specification.  
> >  
> > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []...  
> > arc4random: no preloaded entropy cache
> > GEOM_ELI: Device gpt/swap.eli created.
> > GEOM_ELI: Encryption: AES-XTS 128
> > GEOM_ELI: Crypto: hardware
> > Link state changed to up
> >
> > [...]
> >
> >
> > Can someone look into this?
> >
> > Kind regards,
> >
> > Oliver
> > --
> > O. Hartmann
> >
> > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> >  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpueu5pLSLGU.pgp
Description: OpenPGP digital signature

Re: r324353: boot failure: failed with error 19

[Warner Losh]

On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann  wrote:

> I run a small appliance on an APU from PCengines. This box is bootet via
> SD card, the
> image is created by a modified NanoBSD, which creates GPT/UEFI
> partitioning and booting
> images.
>
> That worked until two days ago (I do not track the revision numer) when I
> wrote (via dd)
> the last image out. Today, I tried to boot r324353 and it fails at tthe
> boot loader:
>
>
> mountroot: waiting for device /dev/ufs/dsks1a...
> Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
>

That's odd... But likely a race  It could be that dd'ing the new
partition, however, was made from an image that didn't have the proper ufs
label.

What's the rev of the last version that worked?

Warner


> I can proceed by manually issuing at the loader propmpt
>
> ufs:/dev/gpt/dsks1a
>
> and booting proceeds as expected.
>
>
> Something seems wrong with the UFS labeling lately.
>
> The gpt layout looks like this:
>
> gpart show -l:
>
> =>  40  60751792  mmcsd0  GPT  (29G)
> 40   130   1  boot  (65K)
>170 6  - free -  (3.0K)
>176   2057288   2  dsks1a  [bootme]  (1.0G)
>2057464   2061725   3  dsks2a  (1.0G)
>4119189   1048576   4  dsks3  (512M)
>5167765  55584067  - free -  (27G)
>
> From dmesg. I can provide this last output:
>
> [...]
> mmcsd0: 31GB  at mmc0
> 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a
> [ro]...
> uhub0: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus1
> uhub1: 2 ports with 2 removable, self powered
> Root mount waiting for: usbus1
> ugen1.2:  at usbus1
> uhub2 on uhub1
> uhub2:  on
> usbus1
> uhub2: 4 ports with 4 removable, self powered
> mountroot: waiting for device /dev/ufs/dsks1a...
> Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
>
> Loader variables:
>   vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
>   vfs.root.mountfrom.options=ro
>
> Manual root filesystem specification:
>   : [options]
>   Mount  using filesystem 
>   and with the specified (optional) option list.
>
> eg. ufs:/dev/da0s1a
> zfs:tank
> cd9660:/dev/cd0 ro
>   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>
>   ?   List valid disk boot devices
>   .   Yield 1 second (for background tasks)
>   Abort manual input
>
> mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs
> []...
> mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> random: unblocking device.
> arc4random: no preloaded entropy cache
> Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error
> 19.
>
> mountroot> Invalid file system specification.
>
> mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []...
> arc4random: no preloaded entropy cache
> GEOM_ELI: Device gpt/swap.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI: Crypto: hardware
> Link state changed to up
>
> [...]
>
>
> Can someone look into this?
>
> Kind regards,
>
> Oliver
> --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r324353: boot failure: failed with error 19

[Trond Endrestøl]

On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:

> I run a small appliance on an APU from PCengines. This box is bootet via SD 
> card, the
> image is created by a modified NanoBSD, which creates GPT/UEFI partitioning 
> and booting
> images.
> 
> That worked until two days ago (I do not track the revision numer) when I 
> wrote (via dd)
> the last image out. Today, I tried to boot r324353 and it fails at tthe boot 
> loader:
> 
> 
> mountroot: waiting for device /dev/ufs/dsks1a...
> Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> 
> 
> I can proceed by manually issuing at the loader propmpt
> 
> ufs:/dev/gpt/dsks1a
> 
> and booting proceeds as expected.  
> 
> 
> Something seems wrong with the UFS labeling lately.
> 

> The gpt layout looks like this:
> 
> gpart show -l:
> 
> =>  40  60751792  mmcsd0  GPT  (29G)
> 40   130   1  boot  (65K)
>170 6  - free -  (3.0K)
>176   2057288   2  dsks1a  [bootme]  (1.0G)
>2057464   2061725   3  dsks2a  (1.0G)
>4119189   1048576   4  dsks3  (512M)
>5167765  55584067  - free -  (27G)

For one, these are the GPT labels.

Can you verify the UFS labels (volnames)?

Try: dumpfs /dev/gpt/dsks1a

> From dmesg. I can provide this last output:
> 
> [...]
> mmcsd0: 31GB  at mmc0
> 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]...
> uhub0: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus1
> uhub1: 2 ports with 2 removable, self powered
> Root mount waiting for: usbus1
> ugen1.2:  at usbus1
> uhub2 on uhub1
> uhub2:  on 
> usbus1
> uhub2: 4 ports with 4 removable, self powered
> mountroot: waiting for device /dev/ufs/dsks1a...
> Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> 
> Loader variables:
>   vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
>   vfs.root.mountfrom.options=ro
> 
> Manual root filesystem specification:
>   : [options]
>   Mount  using filesystem 
>   and with the specified (optional) option list.
> 
> eg. ufs:/dev/da0s1a
> zfs:tank
> cd9660:/dev/cd0 ro
>   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> 
>   ?   List valid disk boot devices
>   .   Yield 1 second (for background tasks)
>   Abort manual input
> 
> mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs 
> []...
> mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> random: unblocking device.
> arc4random: no preloaded entropy cache

> Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19.

This surely indicates a mangled UFS volname.

Maybe you should rewrite the volname:

tunefs -L dsk1a /dev/gpt/dsks1a

Or is the volname misspelled?

tunefs -L dsks1a /dev/gpt/dsks1a

Or is /etc/fstab on the SD card corrupted?

> mountroot> Invalid file system specification.
> 
> mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []...
> arc4random: no preloaded entropy cache
> GEOM_ELI: Device gpt/swap.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI: Crypto: hardware
> Link state changed to up
> 
> [...]
> 
> 
> Can someone look into this?
> 
> Kind regards,
> 
> Oliver

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"